An activity has onReceive() implemented, and it also starts a long running background service. It may happend that android kills the activity while service is still running. So if service broadcasts its results then how would it be handles as activity is dead?
Related
I have UWP app service with TimeTrigger. Every time this trigger fires i'm trying to download some data from the internet.
Is there anyway my service can notify my second UWP UI app about data load success|fail? The only way i've found is to run the second service in UI app thread and call it to send the notification.
The original task is to create an always-running data update checking service and load a data consuming UWP UI app that may or may not be running.
I am writing a UWP app that expect to have updated data from a remote, say a cloud service or a remote station or whatever.
So, I thought an obvious solution would be to write a service that will sync data periodically and UWP app will just show it. I started reading about it and ended up reading this MSDN article about Windows 10 AppService
https://learn.microsoft.com/en-us/windows/uwp/launch-resume/how-to-create-and-consume-an-app-service
But after reading the article, I stumble upon this portion as per screenshot below which basically tells that if my app is back-grounded (minimized or covered by another app), then the service will continue running for up to 30 seconds and then stop running. This means after 30 seconds, my background syncing will stop:
How can I make sure that my data is being refreshed when needed even though my app is not in the foreground?
Your background task can only run for 30 seconds for processing information but you can make it so your background task runs ever 15 minutes to check if new information is available using a Time Trigger.
If you want your application to check more frequently you will have to use a Toast Notification that comes from a server, such as Azure Mobile App Service, AWS Simple Notification Service, etc. or you can create your own service using the WNS(windows notification service).
Azure
https://azure.microsoft.com/en-us/services/app-service/mobile/
AWS
https://aws.amazon.com/sns/
Applications can register for significant location changes.
(Recommended) The significant-change location service offers a
low-power way to receive location data and is highly recommended for
applications that do not need high-precision location data. With this
service, location updates are generated only when the user’s location
changes significantly; thus, it is ideal for social applications or
applications that provide the user with noncritical, location-relevant
information. If the application is suspended when an update occurs,
the system wakes it up in the background to handle the update. If the
application starts this service and is then terminated, the system
relaunches the application automatically when a new location becomes
available. This service is available in iOS 4 and later, only on
devices that contain a cellular radio.
From https://developer.apple.com/library/archive/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
An app can be relaunched when the location changes. However, can it be started automatically when the phone is started? The documentation isn't quite clear.
The service will start when the user launches your application, and terminate if it is closed. The service will remain running if the application is running in the background.
Developers cannot integrate services into the OS, for security purposes.
No, you cannot have your application run automatically when the phone is started. In addition, if the user starts your application manually and puts it into the background, the system may eventually kill it when it needs the memory.
"Including the voip value in the UIBackgroundModes key lets the system know that it should allow the app to run in the background as needed to manage its network sockets. An app with this key is also relaunched in the background immediately after system boot to ensure that the VoIP services are always available."
check iOS docs here
Although if you do this for an illegitimate reason I am guessing your app will either not get approval or get booted quickly.
I'm working on a location tracking application that uses both the standard location service and significant change location service in the background (my app is registered for background location updates in iOS 4+) as applicable. Thanks to this question I have a solid understanding of how significant change comes back from the background state and relaunches from a terminated state. However, I'm still not clear on how the standard location service behaves in these instances. Could anyone break down the exact behavior of the standard location service running in the background?
Specifically:
How does the standard location service behave when you leave it running and the app suspends into the background? From my own testing, I've seen that it will continue waking up to receive callbacks on locationManager:didUpdateToLocation:fromLocation: (I have it send the location out a socket and I can see it on the network). Is there a time or memory limit for this callback to process?
Does the standard location service continue to run even when my app is terminated? That is, will it ever relaunch with application:didFinishLaunchingWithOptions: with UIApplicationLaunchOptionsLocationKey the way the significant change service does? I assume it the CLLocationManager would also need to be restarted in this case, as the significant change service does.
Thanks.
Answer to both 1 & 2, If you have registered your app as using background location then your app does not get terminated and continues to run in the background until you do this:
[locationManager stopUpdatingLocation];
So, there is no time or memory limit however there is a battery limit. If your battery is low, all apps using gps will be closed. Since your app is not terminated in normal circumstances, either it is not required to or it does not relaunch (after being terminated coz of battery) with UIApplicationLaunchOptionsLocationKey
Standard and significant services are different in this manner that significant wakes up the app whenevr there is a location update but standard makes app run continuously and hence drain battery.
Before you choose what service to use consider reading the Location-Awareness Programming guide.
I'm in the process of porting an app originally developed on iOS to Android. I'm trying to accomplish the following:
every time the app is started, call the start() method on a Manager class
every time the user leaves the app, call the stop() method on the same Manager class
every time the user comes back to the app (resuming from idle), call the start() method on the Manager class
The so-called Manager class handshakes with a server on the Internet and needs to do a variety of book-keeping activities every time the user the user enters and leaves the app.
Whereas iOS enables you to subclass the UIAppDelegate class and have code that runs when the app starts, ends, or resumes from idle, it seems Android doesn't have an equivalent approach. Instead, these are the options with Android:
1) Activity class: methods for every time an Activity (view) is created, stopped, or resumed
2) Application class: onStart and onDestroy for every time the app is started or killed
3) Service mechanism to create a background task that can be used to perform long-living operations in the background while the app is active or even while its not active
None of the above align real well with what I'm used to in iOS. Option 1 would require every Activity in the app's view hierarchy to have code that runs when the app starts/stops/resumes. Of the 3, I sense option 3 is more relevant. I'm just not entirely clear how I could start/stop a service in Android as the user starts/stops/resumes an app without regard to the specific activity they're on at the time.
I would appreciate input from Android developers or developers that work on both iOS and Android.
The so-called Manager class handshakes with a server on the Internet and needs to do a variety of book-keeping activities every time the user the user enters and leaves the app.
This might be a valid design pattern on iOS -- I have no idea. It is not a valid design pattern on Android. You don't "leave the app" on Android any more than you "leave the app" in a Web app. "Leave" is determined mostly as "you didn't come back in a while" in both Android and Web apps.
2) Application class: onStart and onDestroy for every time the app is started or killed
Note that the method is onTerminate(), not onDestroy(), and it actually never gets called. The Application object is created when the process is and lives until the process is terminated outright.
Its just not entirely clear how I could start/stop a service in Android as the user starts/stops/resumes an app without regard to the specific activity they're on at the time.
You might elect to use a service for doing the "handshaking" -- in fact, that's probably likely.
However, there is nothing built in for "leave the app". I would strongly encourage you to simply get rid of the concept entirely.
If not, you're welcome to rig up a service that is notified on each onPause() and onResume(), does the bookkeeping to see if there are any live activities, and if there hasn't been for X period of time, does your "leave the app" logic, then shuts down. You'd also trigger the "leave the app" logic in onDestroy(), if the service is shutting down at OS request vs. your own shutdown request. This is not 100% guaranteed to work -- users can force-stop your service and the OS can kill the process with impunity.
If you want to avoid duplicating code in all your Activities, why not have 1 subclass of Activity with the common code, and have the other Activities subclass that?
You can track activity lifetimes using a variety of mechanisms, including setting/clearing SharedPreferences in onPause/onResume, or use a singleton with reference counting.
Hope this helps,
Phil Lello