This is like a really basic feature an application must perform.
The app has a queue of tasks pending and is waiting for the Internet to come online for execution.
Its easy to do this in foreground by using a stream subscription. But how would one achieve this when the app is closed?
Related
I'm making an app in kotlin that query an API once a day with alarm manager.
Now I thought of a problem: what to do if there is no internet connection when the alarm manager is executed?
My best idea is to query the API and if there is no response I would set another alarm manager to half an hour later.
the problem is that the alarm manager needs a pending intent and I don't know how to call another function in the activity with a pending intent.
I can just call the same activity with another intent, but I'm afraid that if there won't be internet connection several times in a row something bad will happen because there will be to many intents.
So my question is if the bad thing will actually happen because of all the intents
or maybe you have a better solution than mine...
You should use WorkManager for this purpose. It is designed to support these kinds of tasks. You can schedule periodic execution and tell WorkManager that your task needs Internet connectivity. WorkManager ensures that the task only runs when there is connectivity. Tasks scheduled with WorkManager are persisted across device restarts so you don't have to worry about rescheduling them after a device reboot.
See https://developer.android.com/topic/libraries/architecture/workmanager
I'm using react native android and want to ask if there's any way to have mqtt connection with background service so that when the app closes I can still receive messages via mqtt?
I have not done this myself, but this should be somewhat possible. While I do not know if it is possible to leave a single connection open that will receive MQTT messages regardless if the app is running in the foreground, running in the background, or has run and closed, I do think that effect can be achieved.
Background tasks (run when the app is in the background or has been closed) do not always work cross-platform (mostly Android-only), and do not allow you to run on an event-based trigger like receiving an MQTT publish. For this reason, you will see my suggestions based on things like setInterval and checking for messages at a given point. Because the connection is not alive at all times, you will have to either set a large keep-alive interval (or unclean sessions) on the MQTT connection to match with the interval you are checking for messages and rely on QoS 1 or 2 (harder), or close and re-open MQTT connections and rely on retain (easier).
If you only need the MQTT messages to get through when the application is in the foreground or background, you can use something like https://github.com/ocetnik/react-native-background-timer to setInterval and wake-up to check for messages at specific intervals that have tight granularity. If you need the messages to get through even when the app has been closed, you require something like https://github.com/vikeri/react-native-background-job , which will only allow you to run code at a granularity of 15 minutes and above.
I wish you the best of luck!
I am trying to make a chat app using XMPP protocol. The app is working fine except it doesn't show message notification when the app is in background. In Android I have used a Service for this purpose, however in Windows Phone I couldn't find anything similar to this.
I am trying Background Tasks for this, but as far as I have understood, they're made to run on prespecified trigger and I cannot add any custom trigger to it. In Android I have put my socket connection and parsing message calls in the service itself so that they can run on background too and the socket doesn't get closed even when the app is stopped.
So my question is, is there any similar way to do it in Windows Phone 8.1 (WinRT, not silverlight) or if Background Task is the only option, can you suggest a way to implement the notification functionality. I don't need the exact code, I just need a push to the right direction.
First: You cannot run a network connection in background.
Suggested way is using PushNotifications:
Either directly with a Toast Notification
Or with a PushTrigger to handle a Raw Notification, work out what to do
with it (who was it from, prepare data, etc.) and then create a ShellToast from it. Adds flexibility and improves user experience, but is quite complex.
Known downside: You have to use a server.
Only workarounds: Background-Tasks that checks for new messages about every 30 Minutes.
I have an application where I need to create local notifications via polling without doing push - primarily due to client infrastructure limitations and their security model.
I've read: http://www.objc.io/issue-5/multitasking.html, I've seen David Chan's WWDC presentation - where single push messages kick off download tasks - but what I truly need is background fetch - on a regular basis - like every ten minutes - in iOS 7.
I've seen the VOIP hacks. No. What non-hack way is there to do this without user interaction or push messages? Any examples you can point me to?
Here's what I know:
Background data tasks will work in the debugger but if you can get a console on an IPA, you'll quickly find out they really are prohibited (thereby invalidated many examples).
Background URL tasks require custom delegates - but fetch completion handlers are iffy. This too I found with an IPA and console.
I would love to avoid using the AFNetworking lib - for something quite simple.
Background fetch is not a reliable solution - you are at the mercy of the OS, and it is not very merciful. Abusing iOS background modes is not a reliable solution - Apple is known to reject applications that enable background modes, such as location, VOIP and music playback, without a legitimate reason. Background URL tasks are not something you can rely upon to wake your app; they will wake it, but the app will not be awake enough in the background to enqueue a background URL task.
Your best and most intended method is still background fetch, but be prepared to be disappointed. Your app will not be woken app in the interval you need. Also, the user can kill the app in the app switcher screen, causing your app to never wake up until opened.
No real reliable method other than push. You need to insist with your client for the sake of user experience.
Unfortunately there is no "reliable" way to do that on iOS. With the background fetch API you are not guaranteed to have process run when you would like it run. As you've said, you've already looked at the API so i'm probably telling you something that you already know. A local notification wouldn't solve your issue either as this isn't a way that you can wake your application up and kick off network events. This is behavior that Apple doesn't want as this would negate the whole purpose of their background task coalescing.
You really need to have a push mechanism in place for something like this, so if this is something that is needed, then you may have to stress that to the client.
So I've read that in iOS, all timers will pause when your app is running in the background. I've also read that you can run tasks in the bg using beginBackgroundTaskWithExpirationHandler (like so).
What I am trying to achieve is to call a method once every 3 minutes, and another method a fixed-amount of time before the first one. I have managed to do this within one NSTimer which repeats in a way that lets me do this. It works fine but is obviously disabled (or paused) when the app is in the background - I can only assume because of the reason described above.
Does anyone know if there's a way to run a timer or at least call something after a specific amount of time so I can do this?
Basically if you want to continue running active in the background you have to meet one of the following requirements. From the Apple docs:
Implementing Long-Running Background Tasks
For tasks that require more execution time to implement, you must
request specific permissions to run them in the background without
their being suspended. In iOS, only specific app types are allowed to
run in the background:
Apps that play audible content to the user while in the background, such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
Apps that implement these services must declare the services they
support and use system frameworks to implement the relevant aspects of
those services. Declaring the services lets the system know which
services you use, but in some cases it is the system frameworks that
actually prevent your application from being suspended.
http://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW24