iOS has a printing feature known as AirPrint, which does not require to install a specific device driver. My iOS App prints an image data through AirPrint, but sometimes print queue of AirPrint gets stuck. Print queue of AirPrint is FIFO and if the first job remains with some reasons such as temporary network failure, the next job will not send to the printer.
Thus I wish to flush Print queue, or cancel a dead job in case of getting stuck in Print Queue. I know we can cancel printing jobs in Print Center (background app of iOS printing system), but I wish to do that in my own iOS app.
Questions:
(1) Can we cancel or clear printing jobs in Print Queue of AirPrint from iOS app?
(I really appreciate if you have a sample code of Swift to do such a thing!)
(2) Does anyone know how long it takes for printing jobs to get timed out?
Any suggestion would be welcomed.
Reference of AirPrint:
https://developer.apple.com/library/archive/documentation/2DDrawing/Conceptual/DrawingPrintingiOS/Printing/Printing.html#//apple_ref/doc/uid/TP40010156-CH12-SW2
There is a UI available in iOS for PrintJob Management. So there might be an API available.
If an iOS-PrintJob returns the ipp job-uri you could implement print job management within your app. You'd have to implement the ipp protocol and support the Cancel-Job operation.
iOS uses CUPS as ipp client. I have analysed the behaviour of iOS by running tests against my own AirPrint implementation. The http User-Agent used is "CUPS/2.3.4 (iOS 14.4.2; iPad8,3) IPP/2.0"
iOS only cares about successful print job submission.
It does query the job state though via the Get-Job-Attributes operation. It would make sense that iOS presents a UI that allows the user to monitor (and control) a print job. We should file a bug or feature request for iOS #Apple.
iOS also queries the printer state. In my tests when I stop my AirPrint server I get notified that the printer is offline and I am presented an option to cancel or try again.
When the printer-state is 'stopped' and reason is 'paused' the print center is available!
Summary:
Job monitoring and control is available via the print center.
It depends on the AirPrint implementation wether the print center shows up.
Related
I have looked at some posts within this domain (e.g. iOS background fetch custom interval) and I am concluding that what I need to do is not possible.
I have an external device communicating to ios over bluetooth (NFC chip card reader). The external device goes to sleep if not pinged every minute (59 seconds).
When the app is in the foreground I can manage the pinging. When in the background I want to continue to ping. Is this impossible?
The ping operation is fast; it is just to send a message and I dont need a response back to ios.
(What works really well is the opposite, bluetooth communication can flow from the device to ios from the background. That is done via UIBackgroundModes in Info.plist to bluetooth-peripheral.)
Please note that I am feeding the iphone from external power in the application here. It is an industrial application; and the normal iphone usecase is not applicable.
Short answer, no. The best iOS offers is back ground fetch. But there is no guarantee when background delegate method is called. You can specify a timespan as a guide but it primarily based on how often the app is accessed.
https://www.raywenderlich.com/143128/background-modes-tutorial-getting-started
I'm newbie in iOS App world so pardon me if my questions are simple and banals
I have this scenario:
my server side generates MQTT messages on a well known topic
my app can connect to the MQTT Topic and can receive messages
All works pretty good; what I would like to do now is the following (if possible)
When the user stops the app (by deleting it from the task manager) I'd like to have a kind of service able in being connected (or remaining connected) to the MQTT Topic; in this way also when the app is no more running I can receive MQTT messages
Basically I'd love to have something similar to Facebook messenger that is able in receiving messages also when the app is not running
NOTE: i can't use remote notification mechanism provide by Apple
Remote notifications would be perfect for this, shame that it's not an option for you.
There are a few other situations where apps can run periodically on the background, they are described here:
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
BUT, from that page: "In most cases, the system does not relaunch apps after they are force quit by the user."
So in general an app will run in background only if the user exits it normally, not if he forces it to quit in the task manager.
I am using the Socket iOS SDK with the 7Xi scanner. The scanner is fast enough to register duplicate scans in quick succession if a user holds a barcode in front of the scanner when in stand mode. To handle this, I am simply removing my scan delegate when the first scan arrives, and not setting it again until I am ready for the next scan.
Of course, the scanner itself continues scanning. Is there some way to silence the beep while I am handling the scan, so that my users don't think the scan was correctly received when the app does not. It must be fast enough that I can reliably re-enable it within a second or so.
Background
The scanner has three confirmation modes (device, sdk and app) which determines who is responsible for acknowledging a barcode was scanned. The default is device, which will acknowledge any successful scan (i.e. the barcode type is supported and the device successfully decoded the barcode).
Solutions
Option 1
Currently, you remove the scan delegate, which doesn't prevent the scanner from scanning the next barcode; It only prevents your application from receiving the event notification. You provide ScanApiHelper with a timer routine that calls doReceive to check for new events and if it finds one it calls your delegate.
You could add a flag to your timer so that it will only call doReceive when you are ready to handle the next event.
There are two limitations to this approach. There will be a delay between the device acknowledgement and feedback from the application, if important feedback is provided, when a scan is held in the queue. Second, a queue is only suitable for handling a brief burst of activity, but your application will require downtime to catch back up.
Option 2
Caveat: I'm not sure if this works in presentation mode
Switch the confirmation mode to app and have your application acknowledge the barcode after it is done processing. This has the benefit of essentially locking out the scanner (it won't beep, flash or vibrate for any scan) unless your application has received and handled the barcode.
The downside here is there is a small lag between the barcode being read and the scanner acknowledging it, when using app confirmation mode. Adding an additional delay while processing the data may not be the best user experience.
I'm spec-ing an iOS app (which will be built outside of our company) which will upload a user's data entry to a server. If the device is not connected to the Internet, we'd like to save data on the device and upload it when the network is re-connected. (The app will primarily run on iPod Touch devices that will be disconnected most of the time).
If the user unlocks the device and re-opens our app after the network is reconnected, then uploading to the server should be easy because the app is running.
But what if the app is not running, where "not running" can mean one or more of:
device was power cycled
user has locked the device and it's sitting in his pocket
app crashed
user exited the app
user started using other apps so our app isn't running in the foreground anymore
are there other cases?
In the cases above, is there a way (ideally a battery-efficient way) to ensure that local data is uploaded soon after Internet connectivity is restored? Is the answer different depending on which of the cases above caused the app not to be running?
And is there a minimum iOS version the device will need in order to enable some (or all) of the above not-running cases to still upload when the app is not running?
My apologies if these are obvious newbie questions-- I'm not an iOS expert.
There is an interesting technique that is used by among others Instapaper and News.me(the pioneers of this technique) where you use region monitoring to initiate background downloads or uploads. Marco (Instapaper) blogged and talked (in episode 80 of the Build and Analyze podcast) about his communication with Apple so it should be a allowed in the App Store.
In brief the technique is that you set up certain regions (geofences) like "home" or "work" and respond to the locationManager:didEnterRegion: (and similar) callback(s). Your app will wake up from the background once you enter the pre-specified region and you can check to see if there is any data to upload.
This technique won't guarantee that the data is uploaded when the network reconnects but it will allow your app to automatically upload the information when the iPod Touch users gets home to their WiFi network.
That should most likely be at least once a day which may or may not be frequent enough for you. You could add a timestamp to when the initial upload was attempted and send that along the upload once it succeeds to get the correct order of events (data entries) on your server.
There is no way to ensure this. If your application is "not running" (by the definition described in your question), it will not be capable of responding to a change in the device's network status. It should be setup to resume upload operations the next time the application runs again.
EDIT:
Some of the cases you've described may indeed provide different opportunities for your application. Specifically, if the user "exits" the app by pressing the home button or launches another app in the foreground, your application may continue to run the in the background and could potentially respond to a change in network reachability.
The nature of what may be done in the background and for how-long is well documented, and supported by any version of iOS that supports multi-tasking. I recommend you review the documentation pertaining to App States and Background Services.
device was power cycled --> really NO WAY of resuming, unless you open the App!!!
user has locked the device and it's sitting in his pocket --> apps applicationStatus is UIApplicationStateInactive but it is running in the background. You still are able to react to notifications and i.e. accelerometer events. Try the Reachability Class and Log the changes!
app crashed --> NO WAY, unless opening the App
user exited the app --> App is sitting in the background. There you have a maximum of 10 Minutes Restriction of fully using your App (like the App "Pastebot" does)
user started using other apps so our app isn't running in the
foreground anymore --> Same as user exited the app
On multitasking Apple says the following:
Real multitasking only for certain kinds of usage, as there is Audio Background playing, VOIP (like Skype), navigation applications
All the other apps can request a specific amount of time after the app is closed/in the background, to finish certain tasks (as sending an email, sms or uploading/downloading important data)
Important Quote from dev docs:
Your app delegate’s applicationDidEnterBackground: method has approximately 5 seconds to finish any tasks and return. In practice, this method should return as quickly as possible. If the method does not return before time runs out, your app is killed and purged from memory. If you still need more time to perform tasks, call the beginBackgroundTaskWithExpirationHandler: method to request background execution time and then start any long-running tasks in a secondary thread. Regardless of whether you start any background tasks, the applicationDidEnterBackground: method must still exit within 5 seconds.
If you're building a restful API then I would recommend using RestKit, it has a request queue that checks the network status on the device and starts uploading once network access has been assured. You can read more about this here: http://mobile.tutsplus.com/tutorials/iphone/advanced-restkit-development_iphone-sdk/. Read the sections about Request Queue and background download/upload. It should be noted that RestKit is a big library which has it's advantages and disadvantages. I'm not completely sure how this que works with the app lifecycle, if it saves the request que even if the app is terminated. You would have to investigate that. RestKit does support background uploading/downloading, but as already noted, I think it's impossible to do any uploading if the app is terminated and not in background state.
I wouldn't recommend using RestKit if the API isn't Rest though.
You can download and experiment with RestKit here: https://github.com/RestKit/RestKit.
Within my iPhone application I periodically make calls to a webservice, providing the endpoint with a list of numeric IDs. The webservice then returns information relating to the IDs it receives.
This is all well and good. However, I would like to be able to provide functionality whereby the user will receive a local/push notification when these changes occur, regardless of whether the application is open or not.
I'm just looking for guidance on my options in this scenario. As I see it, there are two main approaches: calculate any data changes on my webserver and send a push notification to all devices, or query the webservice from the device itself.
The second option seems ideal, as not all devices will need each push notification, but I'm unsure as to whether this is possible with the current state of iOS' multitasking APIs. Any advice would be appreciated.
Bad news: it's not possible. Apps can only run in the background for a short period of time after the user has exited unless it fits into a small number of categories (GPS, VoIP, etc).
Web services, unfortunately, do not count. So this would have to be performed on the server side and with push notifications.