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.
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 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 from Apple world, so I don't have much experience with Android.
But what I am looking is a way that Android devices receive push notification, without using any third party servers. Notification need to be standard Android notification (look and feel)
The reason I need this is, because I would need this in a room that does not have access to outer world. (can't connect to any server) But I have my own WiFi so users can receive push notification from my server via my wifi.
I know that on iOS this is not possible, what about Android?
it is possible using Service left running in system (background) after app exit. some samples HERE, you should be interested in START_STICKY flag
you have to keep some connection (socket?) or interval requesting (not so well, but possible) inside your Service. Google Services (including Firebase) does that by itself and "redeliver" received push messages to properly declared (in manifest) app
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 have a few apps which are dependent from server side. From there are getting they data.
The server side needed development anyhow. Server code hosting is done in our side. The client-server communication, structure is already up.
In this state we need to implement a push notification:
If there are new data on the server than it should be visible at user somehow.
The "standard", recommended way now is to use Google Cloud Messaging System.
I have a few concerns about it:
Requires client and server side coding and bind they technology in our code. And not this is the biggest:
Is changing relative often the technology: deprecation, and need to change our code. This is the biggest. Previous of this was something other and before that something other. In 4-5 years 3 changes is to much.
I am thinking to implement like this:
I will write a broadcast receiver listening when the user got internet connection.
On Internet connection it will check the server to see if it has something new or not.
If is does than it will show a notification and job is done. If the user clicks the notification it will start the app and download the playload.
I will use an alarm schedule, to check the server again after 1 or 15 min or 4 hours, whatever. There it will be no service running in background, just receivers!
The register - unregister functionality should be done in app.
Communications to server in plus:
registerMyDevice(IMEI)-or username+password
unregisterMyDevice(IMEI)
isSomethingNewData()
When the client comes to server it will send his IMEI anyhow to identify, so the server will know for who need to send push.
Anybody can take Google proposed solution and prove it is better in this case than our in-house solution?
The main problem with that solution is that you'll add one more background process that shortens the battery life. Imagine what would happen if many app developers choose to implement your solution. A user that installs several such applications will have their battery emptied quickly. With GCM, one connection is maintained with one server, and that connection serves all applications on the device.
I believe integration with GCM is simpler than developing a push solution by yourself. The API changes always come with improvements (original GCM allowed multiple senders while C2DM didn't; the new GCM gives you user notifications and device to cloud messaging), but even if you don't choose to work with them, the old APIs still work (even if they are deprecated).