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.
Related
I am writing a simple Single Page Application that allows people to be chat. The app will mainly be used on mobile devices (mainly Android, but some iOS although Android is the main focus).
In terms of notifications, I was leaning towards https://github.com/primus/primus . However, my main issue is that I need notifications to be delivered even when the users have their mobiles off -- or are not visiting the specific page.
So, I am also looking into service workers and push notifications -- and am wondering if I should use those for everything and forget about Primus.
So... questions:
Questions:
Should I go for a hybrid architecture (Primus + Push notifications using web workers), or shall I stick with one?
Going the Service Worker's way, how would I go about it without using Firebase etc.? That is, what would the service worker look like? And what would the push code (node/server and client side) look like?
Again in terms of service workers, if the user restarts their phones, or for whatever reason the service worker isn't running on their client, is there a way for the server to know this? (in that case, I'd send an SMS or an email...)
OR, is it even possible for a mobile site to get the device ID viewing the page, and go for a mobile push architecture instead?
Should I go for a hybrid architecture (Primus + Push notifications using web workers), or shall I stick with one?
You should not build an RTC system on the top of the Web Push API. That's not the intended purpose of Web Push but offering a mechanism of notifying the user about timely events.
You could use Web Push when you can not establish an RTC connection for getting the user to reopen your SPA and reconnect.
Going the Service Worker's way, how would I go about it without using Firebase etc.? That is, what would the service worker look like? And what would the push code (node/server and client side) look like?
If you want to receive Web Push notifications in Android, you can not avoid Firevase since you need GCM (which now is Firebase Cloud Messaging).
Again in terms of service workers, if the user restarts their phones, or for whatever reason the service worker isn't running on their client, is there a way for the server to know this? (in that case, I'd send an SMS or an email...)
Honestly, I don't know. But you could build your own ack system. If you don't receive an ack in a reasonable time window you could assume the device is not receiving the notification.
OR, is it even possible for a mobile site to get the device ID viewing the page, and go for a mobile push architecture instead?
Perhaps with specific browser extensions but not in a standard and cross-browser supported way.
I have an Android GCM based Alarm Clock application that, for our specific industry use case, works great.
Here’s how it works now: A back-end system sends a GCM message to the phone. A BroadcastReceiver starts the Alarm Clock Activity which overrides volume settings, plays the alarm, turns on the back light, displays a full screen UI over the lock screen, and communicates (via upstream GCM) to the back-end when the Alarm is dismissed. The phone can be restarted, the app not launched by the user, and the Alarm Clock will still get launched when the back-end pushes the GCM message.
Programming design question: What is the correct way to replace this with Firebase?
Approaches I have tried out:
Simply replace GCM with FCM (not using a Firebase Realtime database)
Start a Service at boot (and within onCreate) that keeps a reference to a Firebase Realtime database. (https://gist.github.com/vikrum/6170193)
Both of those approaches work. Certainly replacing GCM with FCM is straightforward. Is keeping a Firebase reference alive in a Service the right architecture for processing an Alarm? Doesn’t feel right.
I have not yet coded with keepSynced(true). Perhaps that is what I should be using. I’m looking for a design that uses Firebase data synchronization instead of having to deal with the FCM RemoteMessageBuilder layer directly - I'll be able to retire a lot of XMPP code, a Windows Service, etc..
What’s the correct way to implement my Alarm Clock using Firebase?
This guidance from Doug Stevenson on Quora is the best I've found:
The big difference between Firebase Cloud Messaging and Firebase Realtime Database is this: With messaging, you will be able to wake the device from sleep even while the app is not running. The database can only receive updates to registered listeners while the app is currently running, and if the device is not in doze mode (for Android M).
Use Realtime Database when users are in your app and actively interacting with its data.
Use Cloud Messaging for times when you don’t know if the user is in your app, but you want to get them into your app (or make your app do something at a particular moment that you decide).
Messaging also has very restricted payload sizes (4k). With Database, you can read as much as you want from any node in your structure.
I’m speaking here in a general sense for all of Android, iOS, and Chrome. Each platform has their own particular ways of handling messages, but the semantics are similar.
I am pretty new to the mobile development scene and there is a very basic question to which I cannot seem to find the answer. Here is the scenario.
I have a mobile application. That application is connected to a server that I own. To use the mobile application, users have to login using unique credentials. Now lets say there are certain events on my server, about which I want to notify a particular mobile application user. Can my server proactively send a signal / data to the particular mobile app instance [using sessions data perhaps] so that a notification can be displayed on their screen?
Polling by mobile application towards the server to look for such events is not allowed / feasible.
I can speak to an iOS solution. Android surely has very similar functionality.
There are 2 ways to accomplish this:
Silent push notifications
Background fetch
A silent push notification can be, well uh, pushed to devices without alerting the users. This means that upon reception of the notification, the app can start downloading what it needs from your server. You will need to set up proper backgrounding for this to work properly. Otherwise, the notifications will be queued up and will only take effect when the user opens your app the next time. Start here for push notifications. The payload you send is what controls the notification.
Background fetching is process where your iOS app gets woken up by the operating system (iOS) periodically to allow you to perform a task. This task can be fetch data from a server or anything else you want pretty much. This is probably the best of the 2 solutions given that push notifications are not guaranteed to be received and this puts the onus back onto each device to fetch their own data as opposed to you creating a whole back-end system to perform the push notifications. Start here for background fetches.
You mean something like push notifications? You can read this tutorial (or any other tutorial on google) about how to implement push notifications in your app:
http://www.vogella.com/tutorials/AndroidCloudToDeviceMessaging/article.html
Lookup about push notifications on each of the platforms you're talking about.
Plus look into some live web apps, two that come to mind are meteor.com and nodejs
I'm building an app using cordova most likely Android/ios. My app need to send a reminder to the user and ideally that notification would bring the user to the app. The app might and is most likely not running when the notification kicks in. The next notification is knows by the app in advance and does not need Internet to find the content of the notification. Currently the data is in localstorage so might not be accessible by native code ?
The way I see it would be a cron job running everyday at a specific (configurable) hour, then notify the user if it has to.
I wonder what is the best way to achieve this. Here's what I've found so far:
Dialog/notification plugin in cordova, but that seems to kick in only when the app is running.
Push notification plugin : from a first sight perspective, this seems to be Internet pushed notification and not really what I need.
Specific code for different platform. In Android : a service using an AlarmManager to kick in at the right time and send a Notifications when necessary. This would need access to the localstorage in native code, or store the data elsewhere and is platform dependant, but looks like the only solution so far.
Something else ?
What is the best solution ?
Thanks
I think you need this plugin. Katzer It runs locally, so no internet dependency. Can repeat itself monthly, weekly, daily etc. Notification can be given when app is closed.
Prior to posting this query here, I have gone through a similar requirement by a user in the post here
Based on research, what I understand is, push notification concept can be used to notify the application of any changes happening in the server, if and only if, the server control rests with us.
I have made an application which would display the data from a mobile website. Is there a way out by which I can notify the handset user of any change happening in the server, such that the user gets an alert in his handset, so that he can open the application and see what is the new addition/change that has occurred in the website, when I have no control over the server? Pardon me , if I sound totally dumb with this question. Had such a requirement and was curious to know the way out, if any.
This way you should build your own web service which will poll other service for changing and then push alert to android device via Google Cloud Messaging for Android (GCM).
But you also can poll this service with your own application in background service. This method is very bad because of battery drain and network connection using, but this is no need for 3rd party services
try noczone.com, they have custom notification service with an easy to use PHP sdk
https://noczone.com/?page=custom_alerts_sdk
i use it to let me know whenever i receive a support ticket or any new registrations.
and you will need to have their app installed to receive notifications on it
https://play.google.com/store/apps/details?id=com.wr.noc