I want to know how to ensure your app stays alive, without the persistent notification method.
The most common solution I see is to have a sticky notification permanently on, which will keep the app alive.
But how do email apps do it? Outlook and Gmail and K9 don't have a notification permanently at the top of the screen, so there must be another way?
So far I have tried START_STICKY, and I've tried disabling battery optimisation on the app, but overnight it will still get killed for some reason, yet I can see apps like Outlook have been running for several days without me even having to open them.
How do email apps keep alive in the background?
They don't.
I want to know how to ensure your app stays alive, without the persistent notification method.
Create your own custom firmware build of Android and install that on your own hardware.
Outlook and Gmail and K9 don't have a notification permanently at the top of the screen, so there must be another way?
Yes: they let their processes terminate.
Outlook and Gmail could use Firebase Cloud Messaging (FCM) to restart their processes if/when needed for incoming messages. K9 uses WorkManager to poll mail servers periodically. Neither require continuously-running processes.
Also bear in mind that apps that are pre-installed, are from Google, or are from the device manufacturer do not have to play by the same rules that apps from developers like you and me have to.
Related
For devices that don't have Google Play Services, there are a few options to be able to receive push notifications.
Those options can be Baidu in China, Pushy, Facebook own push notifications, etc.
But I cannot understand how is that even possible to overcome those two main problems :
Since we cannot have an "SDK" of some sort like the Google Play Service on a device-level, our only option is to integrate it on an app-level. This means, we cannot have one socket connection to the push server that would be mutual for all apps, like the GCM does. Instead, we need to have as many socket connections alive as the number of apps installed.
Even if we close an eye on problem number 1, to make that connection survive Doze and App Standby, we would have to handle them in a Foreground Service, which is the only way to guarantee its running even after killing the app, or when the device enters Doze state.
But how come we don't see the notification of a foreground service in the notification bar in Chinese phones, or apps that use Pushy for example?
Are they simply polling the push server periodically? with AlarmManager (marked with setAndAllowWhileIdle) and a BroadcastReceiver ? that would be too resource-heavy and inefficient.
It is necessary that even after the application is completely turned off by the user, notifications come from the node server. Tried to do through Broadcastreceiver and Service, but they only output if the app is in the background. I'm considering The firebase messages option, but I can't fully understand if it will work when the application is completely turned off. If there are options as it is possible to make it on another, prompt, please, in what direction to go.
When the user did not force stop(Settings -> app -> Force stop) the app, FCM will work.
It means, Firebase Cloud Messaging will work after user close the app
normally
I'm implementing an app with an internal calendar, fetched from a remote web service. I want to send a local notification to the user when an event of interest is scheduled in the calendar, at a specific time chosen by him. Just like the iOS calendar app, when you can create an event and ask to be notified X hours/days before it happens. The main difference is that you can't create events: they are downloaded from a pre-populated remote calendar.
In Android I've solved the problem by using AlarmManager, while in iOS with Swift 3 the closest I've got to porting the same solution was via opportunistic background data fetch. The main difference between the two solutions is that background data fetch doesn't work when the app has been killed.
It would be really important for me that local notifications worked even when the app is killed. I think users expect apps notifications to work even when the app is closed, like it happens with WhatsApp or Facebook. I know that those notifications are triggered by someone writing something and therefore they are Push Notifications, but the average user just expects notifications to keep working even when the app is closed.
What would be the most elegant solution to "emulate" the behaviour of Android's AlarmManager in iOS?
Scheduling a bunch of notifications in advance hoping that the user will eventually open the app before all of them are dequeued looks a badly designed solution.
Also, delegating all the work to the server and push the notifications to the subscribed devices looks quite bad too as it requires much more work on the server side. Plus it requires a server which is able to awake itself to send push notifications, which is something that I don't have. I only have a simple webserver which answers to HTTP requests.
EDIT : The ideal solution I'm looking for isn't any of the previous 2 options, since I find them more like workarounds than actual elegant solutions to what I perceive being a fairly common problem. There has to be a third option...
In iOS there is no way to achieve this. Looking at the documentation of application(_:didReceiveRemoteNotification:fetchCompletionHandler:), it states that
the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.
You can receive push notifications, but no code will be executed until the user launches your app. So unless you are sending remote push notifications from a server, you cannot set up new local notifications until the user opens your app.
Can Pusher messages be received on Android/iOS app when the app is closed or the phone is turned off?
What i expect to happen...
When phone is on & app is on, it's pretty straight forward from the Pusher docs on how to react to pusher messages sent to the app.
When phone is on & app is closed, the phone should receive a notification that something has been sent to the app.
When phone is turned off, a notification should be received by the phone when it's turned back on to notify that something has been sent to the app.
Are these even possible? If yes, what are some suggestions to lookout for? If no, what can be some workaround?
When an application using Pusher moves into the background on iOS and Android the connection to Pusher will likely stay active for a few minutes. But eventually that connection will be closed. You can't stop that happening within your application (although there may be a "hack" around stating your app is a Voice app when submitting to the Apps store).
Therefore, you should monitor your application moving to the background and put a fallback in place to delivery messages to the phone when it's not connected.
Please see How get pusher events when the iOS app go to the background? for libPusher (the Pusher iOS library).
Here's an extract from the Android Processes & Threads Lifecycle docs on a "Service Process":
A process that is running a service that has been started with the startService() method and does not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing music in the background or downloading data on the network), so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes.
So, running a Pusher instance in such a thread is a viable option.
However, there will still be occasions where the user goes offline. In that situation your server you can detect if a user is online by querying the Pusher HTTP API or by using WebHooks where your server can be instantly informed if the user has gone offline or come back online.
Using the mechanisms above you can facilitate smart notifications; if the user is online (the app is in the foreground) then send the message to them by Pusher, if they are offline (the app is in the background) then use an alternative mechanism for delivery (native Push Notification, SMS or email).
Problem Description:
We have a service which has applications for main mobile OS’s. We use push notifications. When user is log in, we store his device authorization data (lets say token) for later use in the push service. The problem is about few device authorizations for one user and properly keeping them valid when the user uninstall the application.
Example:
I gave my login to system to a few people, in case to try it. They logged in through the mob. application and the system automatically add a few device authorizations into database (tokens). So now we have N device tokens for 1 user. So that if we send push notification everyone will receive it. Now, suppose those who have installed applications want to uninstall it. Without logout they uninstall application through application manager. And at this time we have NOT VALID data for authorized device. And if we try to notify them, notification will be sent nowhere. Which is wrong, and useless work for server. How to let the core know that some of stored data is no longer valid?
Shortly – is there any possibility in Android / iOS to trigger application delete event. If the application is being delete application call server to clean-up data in the storage. Or if the application is open and the user uninstall it, would there onDestroy() trigger fired? Or some other?
I’m not iOS developer, not Android developer, just know a little about second one and nothing of the first. Any advice will be appreciated. Thanks in advance.
I cannot speak for iOS. You cannot get control when your application is uninstalled in Android.
That depends on which push service you are using. Afaik, if you are using C2DM, the act of uninstalling the application will automatically unregister it from C2DM.
Edit:
Oh, and about iOS - afaik it does not directly track uninstalled apps, it does however come with a failed notification feedback service that after a sequence of failed notifications (reported by the device to the push network) will notify you - allowing you to clean up after an uninstalled app.