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
Related
I am writing a mobile application in Flutter, which is Google's SDK for developing mobile apps.
Basically, I was researching into how to mobile push notifications and every source I could find would point me in the direction of Firebase, which is Google's mobile and web application platform. Firebase is extremely nice and makes it really easy to send push notifications from user to user,
but I would like to learn how to do it myself and I can not find documentation to do that.
All I could find was creating a Dart Isolate in the background of my application to solely listen for incoming notifications. The Firebase plugin for Dart, from what I can gather, does just that; creates an Isolate to listen for notifications, even when the app is closed/user has killed the app.
So my main question is, is it possible to create an Isolate in the background to keep a WebSocket connection alive at all times that would listen for data from a server, and then push that data to the screen in the form of a notification without the use of Firebase? (I have created a server in Node.js, and it would be cool if I could just handle all notifications from my Node server). Thanks!
Of course you can implement push notifications without Firebase. Do a web search for “list of push notification services” and you’ll see lists of a variety of services out there. And, on the iOS side, you can have your web service interact directly with the APNs, and have no third party service (such as Firebase’s FCM) involved at all. On the Android side, though, FCM is probably still the logical choice. It’s easy, scalable, and is free.
I would not suggest trying to keep a socket connection alive at all times, though (if that’s what you’re contemplating). First, you won’t even be able to do that on the iOS side when the app is not active. Second, these push notification services are designed to solve the problem that web sockets introduce, namely the user device resource drain and the cost of maintaining a scalable server to maintain all of those connections.
Sure, use sockets where you need them (e.g. near-instantaneous communication while the app is active, etc.), but it’s not the right solution when the app is no longer active.
For iOS side, I would love to point you to Send Push Notification Through APNs Using Node.js. I tried it with my own node server and found it super easy.
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.
I come from the JavaEE development and I'm totally new to android app developement and I'm a bit confused how to implement my requirements. I have a server, where the user has to authetificate and can perform CRUD-Operations via REST-webservice. When a specific event is triggered server-side I want to send a notification to the app. The user should recive the notification even when the app is not running at the moment.
So now my questions:
What do I need on client side so I can recieve this notifications even when the app is not running? Or do I recieve them even if the app is not running? The data input from the notification needs to be safed app-side.
How do I send a notification from my server if the event is triggered? Do I have to use FCM(/GCM?) or can I directly send notifications from my server to the app?
Any help is appreciated!
Typically, 'instant notifications' are done via websocket severs, for mitigating the process of setting one up yourself, people typically use something like Pusher, which has a library available for java, or you can obviously use FCM/GCM. In conjunction with this document you should be able to keep the service running on the andriod app even when running in the backround so you can still send notifications, just remember you'll have to still attempt to detect if they have internet connection or not when sending out those notifications.
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.
One user manages mobile users via a website interface. By clicking on a button on that website I have to display the current position of the chosen mobile user. So what I need to do is send something to the mobile app to trigger sending the GPS position to my server. My website then starts polling the database to check every 10sec whether the GPS coordinates have arrived.
Questions:
Is it possible to use Push Notifications for this purpose? I already implemented it, so everything would be there.
Can I do that silently, so that the mobile user doesn't get notified? I have found something called Silent Push Notifications - is that what I'm searching for?
I have to do it on Android and iOS.
On Android it is definitelly possible. There is no default behavior (such as alerts/badges/sounds) to notify the user of the app that they got a notification. When the app gets a push notification, a broadcast receiver is created and its onReceive method executed. You can have whatever logic you need in that method, though if you require a logic that requires a long time to execute (such as server calls), you should start an intent service from the receiver and do you logic in the service (get the location of the device and send it to your server).
On iOS I believe it is possible since iOS7. Until iOS7, the application logic for handling the push notification would only be triggered after the user clicks on the notification/alert to open the app. iOS7 enable the app to do background processing as a result of the arriving push notification. I believe you should use the {"aps":{"content-available"=1}} payload in this case (which is used for background content downloads), since you don't want any payload that would be displayed to the user.
For android you have some ways to implement the push service:
GCM - http://developer.android.com/google/gcm/index.html:
MQTT - http://mqtt.org/
implement your own persistent connection.
All of them have their advantages. If you need a ack that the mobile client got the msg you should use MQTT. It is also faster than GCM because of less overhead and you don't have the GCM server in between. On the other hand GCM is easy to implement and you don't have to worry about the persistent TCP connection from your server.
Also the silent way is possible because you just trigger a service each time. so if you don't want a notification, the user don't get it.
I am not sure about iOS. For iOS6 it was not possible to implement your own service, which is necessary to "wake up" your app. I am not sure about about iOS7. So for iOS6 you definitely need to use Apples push server.