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
Related
We have been trying for the last two weeks to get a reliable solution to try and sync our app data with a server in the background. We have tried the Background fetch mechanism but due to the iOS restrictions on when it runs it is not a viable solution.
iOS does provide Remote Notifications (https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app?language=objc) that we would like to use as we can use the same mechanism on Android.
The issues is that when sending a type 2 notification CN1 only delivers the notification when the app is brought to the foreground by the user.
On Android I see there is a Build Hint for android.background_push_handling that allows the notifications to be sent to the app even if it is in the background.
Is there a similar build hint that we can use for iOS?
If not, is there a way then to override the application:didReceiveRemoteNotification:fetchCompletionHandler: method that fires when the Notification arrives so that we can forward it to our app?
You can use silent push notifications for that purpose. To send a silent push notification you just have to include "content-available" : 1" into the body of the notification. More info on that here: Apple docs-silent push notifications
You should bear in mind that this will only work when your app is in the background, it won't work when the app is killed. When the app is killed the only solution is standard push notifications, unless your app has VoIP functionality, in which case you are allowed to use PushKit framework (if you use it in an app without VoIP functionality, you won't get pass the AppStore).
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.
Goal
Create a long-running background service with a network connection, similar to Zello app.
Problem
Starting with API level 26 (Oreo), there're tight restrictions on background services and their network activity.
Looking at the Zello app which has a constantly running background service which is able to accept audio and text messages even if the device is sleeping, I wonder how they achieved that?
Their service is not running on the foreground. Also, it doesn't look like they use push messages for that, since the app works quite stable in conditions where there's a problem with push messages reception (e.g. low-end Xiaomi phones).
Any ideas would be appreciated.
From what I gathered these apps use the Firebase Cloud messaging service:
https://firebase.google.com/docs/cloud-messaging/
The Firebase Service is embedded in the Android system and maintains a constant network connection to the firebase server. The apps then contact the firebase server which in turn to notifies the destination device.
Advantages:
The Android system is responsible of keeping the server connection alive and running
The network load is minimized because one connection is used for all apps using the firebase service.
Disadvantages:
All data is sent through the firebase server and is therefore (in theory) directly accessible by Google
Depedning on how many devices use your app, you need to pay for the service.
A similar question asked might be helpful in tackling the problem too:
How does push notification technology work on Android?
These apps don't have long-running services with constant network connections. They use push notifications. When there is a new message for a user, the server sends a push notification to wake the device up.
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.
Is it possible to send push notifications to an android application without using Google server: C2DM?
So, I would like to have my own server which sends notifications directly to the app, but I'm not sure how are the notifications perceived by the device, because the device needs to receive notifications even if the app is not running and the notifications should appear in the notification center.
I think that the guys from www.airpush.com have managed to this, but I'm not sure how.
Can anyone help me with this please?
UPDATE:
Also I would like to know how to display the notifications in the notification center if I don't use C2DM? And if it is possible to configure the notification center to receive notifications from my server even if the user deletes the application developed by us, application which registered that device to receive notifications.
I want to send 3-4 notifications a day, but these notifications need to appear in the notification center and they should go only through our server. How can I configure the notification center within the app to make requests on my server for push notifications.
Thank You!
There is a solution from UrbanAirship called Helium push. According documentation Helium:
Works on Android 1.6 and higher
Does not require a Google Account
No default pushes per day limit
No default pushes per minute limit
Works on Amazon devices (e.g., Kindle Fire)
End to end Urban Airship support (i.e., API to to device)
Best throughput
The problem is that you need development app key for using this one.
Take a look at MQTT:
MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks.
It can be used (and was used in some applications) to implement custom server push solutions. One of the most well known applications using MQTT is Facebook Messanger.
You can easily find more information on MQTT in the Internet, e.g. in this SO question or in this blog post.
According to the FAQ on airpush.com, they're not using real push notifications but rather polling the server a few times per day. One reason I think this is a viable solution for you as well is that Android's C2DM apparently makes use of the Google Play Store, so it won't work on devices distributed outside of the Google eco-system. With over 5 Million Kindle Fires having sold already, that is worth thinking about.
From Airpush FAQ:
When executed once from the main activity of an Android™ application, the Airpush client utilizes Android™ OS's AlarmManager framework to schedule ongoing server polling events a few times per day. If an ad is polled from the server it is cached until optimal display time, which is algorithmically determined by the server.
Without using C2DM there's not option for a "real push notification". Because (afaik, correct me if I'm wrong) an android device registers at google (they can still deinstall malware from your phone via remote) and with this ip they are able to do a push notification. All other solutions could tend to be a "register at a server, keep the connection alive and wait for requests" or something and tend to be more battery-inefficient.
Parse has an excellent push notification service for Android, very easy to setup. More info here: Parse Android Notification Doc
If you want the user to only receive 3-4 messages per day and your messages are not bound to specific arrival times, you don't need pushing mechanisms.
Just create a service in your app that checks your own web service 5-10 times a day. If there is new data, make your app display it in the notification center.
If you don't want to have a service running all the time (like many messaging apps do), you can set up alarms (using the Android AlarmManager framework) that wake your app up regularily to check for new messages to display.
And if it is possible to configure the notification center to receive
notifications from my server even if the user deletes the application
developed by us, application which registered that device to receive
notifications.
That sounds like you want to write a virus or root kit ;-) You could use e-mails for your messages instead.
UPDATE 2013-12-30:
As just noted in my comment, rebuilding what GCM does is not a nice approach. It's enough when Google Services already load the device with this functionality. If your goal is just that Google does not see what messages you send to your users, you might aswell encrypt them. For Google not being able to actually read your messages, the client app should generate a key and send it to your server. All messages you send via GCM can then be encrypted using that key.
If you just want to circumvent Google's restriction on the amount of messages sent to users, you could pack multiple messages into one GCM notification and show them one after the other. But then again, we are back at some kind of polling solution as described before, with the exception that the user does not need to have internet access when you want to show the messages as they are cached on the device.