- The PrintActivity has to handle all config changes to not loose track
close the connection to the printing app
- In the case where onDestroy is called we need to make sure to
- not do any more UI operation
- on async calls after destroy is already called, handle failure to
unbind services.
Change-Id: If21335543fbfa16ecfe77d1965b2e8a13dfa14b8
- Support unbounded ranges, e.g. 4- == 4-pageCount and -2 == 1-2
- Do not allow reverse ranges, i.e. 7-3 is not allowed anymore
- restrict characters that can be typed into field
- force numeric keyboard
- Fix bug that we update the selected pages even if the page ranges are
invalid
Fixes: 13126748
Change-Id: I515d9346ceb152a41b7260792c5dd9bd91b27cab
scrap
documentInfo.PageCount might be set to "unknown" == -1. Hence we don't
know where the last page to scrap ends. Hence defer this decision all
way until PdfManipulationService.removePages as then we know the actual
pages of the document.
Change-Id: I063c3cd084d65a3ac5c60c3d85cec3a346be2680
Fixed: 27948632
This service connects through the print manager to the print spooler:
PrintSpooler.AddPrintersActivity <-> PrintManager <-> PrintManagerService <-> UserState <-> RemotePrintServiceRecommendationService <-> PrintRecommendationService <-> PrintRecommendationServiceImpl
Hence there is a lot of mindless plumming.
The actual changes are only in the AddPrintersActivity which is extended
to show another list of services: The recommended services.
The PrintServiceRecommendationService is based on the experimenal print
service stubs provider. This provider was contributed the Android by
Mopria. As this services uses Android own network discovery service most
code from the experimental provider goes away. In fact the only logic
left over is the selections of mdns-txt fields to look at and the
printer vendor configuration.
This relies on the Android MDNS to get fixed (Bug: 27696905). This also
does not deal with how to update the recommendation service.
Bug: 24533249
Change-Id: I6edc6e25fc08a50d478b61c71bb8ea158b08624c
... if it cannot connect to remote PrintDocumentAdapter. Then the state
will be set to destroyed and the print activity will be aborted via the
onDied callback.
Bug: 27899066
Change-Id: Ieb287b92ac21fc71a56b491a1035feaff6cd2837
Bonus: null advanced keys produced a exception deep in the print
spooler. Hence prevent null keys on the surface from now on.
Bug: 27716355
Change-Id: I3c064956f4e670cd7091437ade06605aa8d797b0
layout changes
Before we updated the print preview when the paper size changed but not
when the page ranges changed. This is not consistent. We always change.
Also if there is a change to the options that changes the layout (i.e.
papersize, orientation, minMargins) then clear the selected ranges as
this does not make sense anymore.
This also fixes a bug that when having pages selected while we reduce
the number of pages in the preview we got a NPE.
Bonus: do not constantly re-update the options UI when range or copies
text is updated.
Bug: 27830850, 27741420
Change-Id: I7abe4a74b44ac5c5ee54d12cc0c1ca1540793f0e
destroyed synchronously.
Also: Always destroy print spooler provider when it was initialized to
avoid service leakage if print activity was finished after
onCreate but before onPrinterRegistryReady.
Bug: 27814338
Change-Id: I8401dc6e447cbd726b1a8f7c361b4ddf42e7e11d
In PrintActivity.OnPause we set the print job state based on the
PrintActivity state. The issue was that FINISHED was interpreted as
"cancel print job". Actually with FINISHED does not tell what state the
job should be in.
The only purpose of the finished state was to guard against
double-invocation of doFinish().
Hence remove this recently introduced state and use a simple boolean to
guard against doule invocation of doFinish().
Bug: 27760331
Change-Id: I0767c2b0b9c28e8904647cc832c236f67f92bcfe
of pages.
If the printing app declares more pages than the print preview pdf has
we used to throw an exception in the PDFManupulationService. This caused
the bitmap to be never written and the read-bitmap function to hang
forever. This was because read() return 0 meaning "pipe is closed" which
lead to an infinite loop. Now a read of 0 page might cause an exception
if the page is not fully read. This exception then causes the
preview_page_error to be displayed.
Bug: 27556666
Change-Id: I7b9de50dce930629e8d38efd4e2659a00b70cc4e
are canceling the command.
Before it could happen that we have a pending cancel on a layout command
but the layout command finishes normally. This enqueued a new write
command before the PrintActivity is notified. This in turn prevented the
printactivity from finishing as the write command was still pending.
Bug: 27642724
Change-Id: I3c532d53b0c66c40d2e48ab8b4419251ff473a79
In this case it cannot call back into the recyclerView and update the
data. For the call path please see the bug.
Bug: 27614499
Change-Id: I84733fea30429c20a2c96085efb47d4da5e1948a
This fixes two bugs
(1)
1. Printer was unknown when "all printer" activity was opened
2. Printer gets selected in "all printers" activity
3. Printer is unknown at the time the activity returns and thereby does
not get selected
(2)
If a print service gets disabled _all_ printers of the print service
will be marked as "removed" but do not removed from the adapter. This
is superflous as none of them can be selected anymore. The only thing
we want to make sure of is that the currently selected printer does
not get removed.
The workflow is now always:
- set mCurrentPrinter if needed
- Adjust mPrinterHolders
- adapter.notifyDataSetChanged()
-> PrintersObserver.onChanged()
-> onItemSelected
Bug: 27643305
Change-Id: I35ea7078367ad5a918c6362c04a26c4326e6c3f4
It can happen that before we stopped we reported a set of printers. Then
while the loader is stopped, we lost all printers. Then on re-start we
need to tell the clients that there are no printers anymore.
There is one issue: The fused-printers-provider might be started
before the printer registry is fully created. In this case we get a callback
and get all king of NPEs. Hence enqueue the first load behind the
current thread. This makes sure that the current operation - creation of
the printer registry - is finished.
Bug: 27643300
Change-Id: Ife6993d57457f23a0a4a54a11869c742c05da850
It can happen that multiple async calls fail and we end up calling
doFinish from all of them. We should just ignore the later ones.
Bug: 27198033
Change-Id: Ica596b966f96e9ade6409cc45c50fd62c4018b1e
... we should not check if it is updating. As it is not initailized,
we do not have to check either, hence we can just ignore this.
Bug: 27516795
Change-Id: If618f2a10563e83074e38f0b37342a648d54202a
updated. Also fiddle with the UI to use more standard values.
To be sure the print service state alwasy updated I changed
PrintManager.getPrintServices to return a loader which just wraps a
registerListener/getList/removeListener combo.
I also added a new function to enabled/disable a print service to be
keep all updating logic inside the PrintManagerService->UserState.
Then I changed all code to use this new interface.
Detailed comments:
PrintServiceInfo:
- I had to add the enabled state to the PrintServiceInfo as some users
of PrintManager.getPrintServices want all services but then display
different data depending on the enabled state. Of course I could have
created two PrintManager.getPrintServices-loaders to load the two
separate list of services. I think it is much easier to add this
property though. It is updated every time new data is returned to the
PrintManager.getPrintServices-loader.
AddPrinterActivity:
- This is shown as a dialog-style overlay to indicate that the user will
return to the select-printers activity. It contains of three list that
are updated via separate loaders.
- The recommended services will be added later to keep this path set
small.
PrintActivity:
- There are two small places where we have to update the data when we
get a new list of print services.
- In very, very rare conditions it can happen that the print service
of the current printer gains or looses the "advancedOptions"
activity
- If we have no enabled print services we want to show "Add printer"
instead of "All printers...".
- Also the print registry is not the only loader anymore, hence we have
to assign loader ids to it to not conflict with the other loaders in
this activity.
- Small bug in onPrintersChanged: If a printer is selected and the print
service of this printer gets disabled the holder goes into "removed"
state which disables the printer. When the print service is then
enabled again, we forgot to re-enable the holder.
PrinterRegistry:
- The registry assumed that the FusedPrinterProvider was the only loader
in the activity. This is not true anymore, hence it has to assign the
appropriate loader ids.
- The FusedPrinterProvider has an internal loader, hence we have to
forward a loader Id into it.
- The PrintRegistry is only called backed for a single loader, hence no
need to check the loader-id.
SelectPrinterActivity:
- The AddPrinterDialog was removed as we now have the
AddPrinterActivity.
- Added a loader for the enabled services to update the empty state.
- Added dedicated loader Id for the PrinterRegistry again.
- If we have no enabled services, the SelectPrinterActivity chainloads
the AddPrinterActivity as this is the only thing the user can do
anyway. "Save a click". This should only happen when the activity is
create the first time.
- Moved the "add printer" from the menu item to the list of printers as
suggested by UX and Zach.
PrintManagerService, UserState and IPrintManagerParamtersTest:
- As the only place where the print service state is updated is now the
userstate, we have no more sychronization problems. Whohoo.
- The users can now register for changes to the print services similar
as they can register for changes to the print jobs.
- UserState.getPrintServices is the only function can exposes any
knowledge of the print services to the outside world.
Change-Id: I9be2c7300431e06aaff9bdf7eb36120d869b56ac
When switching between two printers with different margins but with the
same paper size we were missing updates of the print preview. This
change triggers these updates.
The issue was the we reuse the a bitmap when a page is rewritten. This
causes View.setBackground(drawable) to do nothing as the old
background is the same as the new one. This function only checks the
background drawable object reference, not the content. Hence we need to
add a call that notifies the listeners to the changes on the content of
the drawable.
Bug: 26961677
Change-Id: Id8b9be59c9ca7220f40ac59168f78bfdcccb2761
Bonus: Remove Printer-onChange listener before other state gets cleaned
up. Otherwise onChange callbacks at the wrong time cause into
destroyed data.
Bug: 27219320
Change-Id: I8335b9d8dd71112b76aa684f00524d4d8aad3f94
