Requirement: I am looking for a (open-source/free-to-use) mechanism:
to deliver messages (similar to GCM) to android clients which do not require google play service/store on client side.
Support for more than 10,000 concurrent clients.
Support for sending messages to individual client, group of clients or all clients.
Only authorized entity (can be another server) should be able to send/publish messages.
Support for "only data" messages i.e. message need not be shown in notification bar. It will be consumed by client app for its own operations (e.g. perform some action based on data, display in-app notification, etc).
I have explored some MQTT based solutions (e.g. rabbitMQ) but didn't find any recent documentation/tutorial for android based client.
Let me know any solution which can satisfy my requirement.
Look into UnifiedPush. They even want to be the open-source pendant to GCM.
An Alternative could also be Gotify.
Related
Environment:
Ejabberd Version : 16.04
Smack-android-4.1.0
I have created an Android chat application with a XMPP server. However due to Google play permission issue I had to narrow down the feature from app which supported receiving incoming message notifications when the app is in the background.
As an alternative I received the following suggestion from GooglePlay Review Team.
Once you’ve removed this permission, you might consider using Firebase
Cloud Messaging (FCM) if your app’s message delivery requires a
temporary exemption from battery optimization. Please set high
priority only if the message is time-critical and requires the user’s
immediate interaction, and be aware that setting your messages to high
priority contributes to more battery drain compared to normal priority
messages
So at the moment users can send messags via the app. But when he close the app, he will be considered as an offline user, and will not receive any notifications from app. When he opens the app again, he will get all the offline messages those were saved the Ejabberd server.
I want to enhance the current app so that even though a user had closed the app he will still receive a notification when some one sends a message to him (Similar to whatsapp)
Is there a module in ejabberd which integrates the server with FCM and handles this?
If we can not achieve this by Ejabberd, is there a 3rd party library to support this?
If not do we have to write an Erlang module from scratch?
I found similar questions in the internet but I could not find any working solution. Since I am not much experienced with Erlang and would be glad to hear your solutions/ideas on this. Thanks in advance.
This can be achieved in Ejabberd with offline_message_hook. This hook is trigger when sending a message to the receiver and receiver in an offline state. So create a custom module using this hook and you can send a push notification to FCM and APNs servers.
Refer this blog -- https://jasonrowe.com/2011/12/30/ejabberd-offline-messages/
Looks like you need to try apply approach below:
Create REST API for store of user tokens with JID's of users
Create custom hook for fetch XML packages.
Integrate into project the epns library(this library can send FCM/APNS)
In custom hook call the spawn function where will be get the user token from DB by JID and creating payload with sending FCM/APNS notification
I want to create a notification system provider that is not based on Google services or similar. In fact, I want to get information about its overall architecture and needed Android sdk functionality.
The most weird point for me is to understand how to send a notification to an Android device.
I mean, how can I identify the Android device on which my application is installed from millions and millions of other Android devices on the Internet?
And how do I send information to him?
Should I use sockets for this or similar stuff?
simple answer: YOU CAN NOT
before everything else i should correct your question, pusher and FCM are not in the same group at all! you can build somthing like pusher or oneSignal or etc but you can not build something like FCM/APNS
you should understand three simple yet important sentences below:
when you want to pull anything from place_1(e.g. api) to place_2(e.g. browser_client) you most have an identifier of the place_1_resource (which commonly is the uniform-resource-locator of api)
when you want to push anything from place_1(e.g. notification_central_server) to place_2(cellphone_client) you most have an identifier of the place_2_resource
you must know the differences between a real server push with server-push-like technologies like long-pulling or ... and you should be aware that what is intended in this concept is a real server push not any kind of pulling with a push jacket!
if you don't have any identifier for a cellphone which you want to send it a notification, your server dont know where to send that notification so we need a resource_identifier_like for cellphones which is actually a device_token_like and you have just one approach to get this device_token_like and that is the FCM/APNS
FCM is like a dns server containing all identifiers of every android device that google supports (almost every android device) and APNS is just the same but for apple devices
note1: even if your app can obtain it's corresponding device device_token_like it can not be used for push notification if its not registered on FCM/APNS
so when you get that device_token_like identifier of your desired clinet_device now you can use different approaches for sending sth to that clinet_device. there are several approaches like SSE, Webpush, HTTP_server_push, Pushlet and etc but none of these approaches supported by mother_companies of these devices, the only approach that is completely supported and standard is the same approach that FCM/APNS official websites suggests
for example an iranian Incorporation named najva uses webpush to send notifications because of USA sanctions but webPush method works good on browsers and android devices but they didn't even apear on an apple devices
finally i should say that i admire your curiosity to less using anything from a benefit_based Inc. like FCM/APNS in your developing but i strongly recommend these articles and books for you cause i think you didn't learn enough:
wikipedia of push technology
story of some guy who tries to make his own push notification service
Push Technology A Complete Guide - 2020 Edition
Data Push Apps with HTML5 SSE
Short, direct answer
You can't (At least till you create your own ROM)
TL;DR, Reason why?
Before you build your own push notification server, you first need to know how it works internally in android.
Whenever you/your server sends a push notification message to the android client, the SDK processes it and shows you the notification. But when your app is not running (or being killed), your app cannot respond to it since it was not running. In such a case, your notification message is sent to a system service which is known as Google play service. For this even to work, you will first need to bind your app with Google play service and that is what FCM does. FCM SDK registers your app to the operating system service on the first initialization. That FCM service is opened to a port which listened to the incoming message from the server and when it receives the message, it publishes a notification on behalf of your app with a PendingIntent containing the data. Then the PendingIntent is delivered to your app when the user clicks it and then finally your app process the data (or the push message)
So basically, for your server to communicate with the client, It first needs to communicate with the FCM service and for that, FCM gives you a token which identifies the application to register with the internal Google play service.
Simplified furthermore, the workflow is as follows:-
Server send push message ---> FCM ---> Google play service,
If your app is running, it is directly handled by the client SDK So, Google play service --> Your app
If not, then it is delivered by the service itself using PendingIntent So, Google play service --> PendingIntent --->| Publish notification
Totally impossible, Workaround?
There is nothing like impossible because an absolute impossibility doesn't exist. Saying impossible generally means near to impossible. (This is similar to math where also we say tends to infinity because no one has achieved it yet).
To make it work, you need to somehow bind your app to the Google play service and you can't because Google hasn't exposed any direct API to do that. The only possible way is using the FCM ;-) (Bad luck again). So the only possible way is to build your own custom ROM with a custom push service that acts as a client for your Push server and a Server for your Push client (which is your app).
Since the above option tends to impossibility, you have to choose a workaround.
The best among the worst workarounds are:-
To make a malicious SDK.
Malicious because it needs to keep the app running in the background with a service that is connected to a WebSocket endpoint of your server. (Harder in new android versions).
Make use of a database where your push notification is saved and your app checks it periodically using AlarmManager.
Hope you have got the point.
I am building an Android app with a server at back end. What I want to do is, whenever anything new is updated in server the app should trigger a notification into the users phone showing the newly added content.
EDITED TO ADD: This is even more important as of Android M and beyond. As part of a comprehensive effort to improve battery life, the OS actively restricts many of the techniques that apps have used in the past for sync and notifications. Use built-in methods like JobScheduler and GCM in order to avoid issues.
The core notification mechanism in Android is Google Cloud Messaging (GCM), documented here. It's built in to the platform at a low level and directly supported by mobile networks, so it's usually the most efficient choice. It doesn't have a guaranteed latency, so it may not be appropriate for very time-sensitive messages, but it's generally quite fast--at least as fast as sending SMS, for instance.
There are a number of different commercial products as well as FOSS libraries that wrap GCM in various ways, for instance to provide support for very old (pre-Froyo) devices or devices without Google enabled, or to provide a single cross-platform solution between various competing mobile platforms. Firebase, Parse, and Urban Airship are some that I'm aware of.
To use GCM, you need to get an API key from Google. You use this API key to authenticate requests to the GCM server. Once you have a key, sending a notification is as easy as sending a POST request to the GCM server. GCM also supports XMPP, but I haven't used it.
On the client side, your app needs to call the GCM API to register for messages. You provide the project name that you used to create the API key, so that GCM knows which server messages should go to your client app. Once your app has registered, incoming messages will be sent to it as intents, which you can receive by implementing a BroadcastReceiver.
There's a tutorial on the Android developer site that walks you through the GCM process.
I am currently building a messaging application that allows users to send and receive messages on their Android mobile phones over an internet connection to each other. I have decided that I do not want to use polling because it means that a user may not receive another user's messages as instant as possible. I have my own server available for use.
I am currently tied between using Google's Cloud Messaging for Android platform in order to send the notifications from the server to the Android device. The other option is to keep a live TCP connection between my server and the Android device via a service, and send 'keep alive' messages every 5 minutes for example.
From your best opinion, what is the best way to do this - or is there a better way? I don't want to use third parties apart from Google to do this. There are similar answers available, but they don't address this specifically.
Alex
using Google's Cloud Messaging for Android platform in order to send the notifications from the server to the Android device.
This is not a realtime notification either; the notifications may be delayed longer than you experienced with polling. Also GCM is meant for broadcasting messages to a number of users, not for targeting a message to one specific user.
The other option is to keep a live TCP connection between my server and the Android device via a service
I don't know how many users you are expecting, but this may not scale. You are limited in the number of TCP connections to one server.
No need to re-invent the wheel here, use an existing implementation such as XMPP.
Take a look at this:
https://pusher.com/docs/client_libraries
https://github.com/pusher/pusher-test-android
It may be what you're looking for
I want to send a notification from some server to android device. The most obvious(and power-hungry) way is to keep searching some database for any new messages using a service/broadcast receiver.
I am sure there are other ways to get this job done. I took a look at GCM(google cloud messaging) , and it seems that google always keeps some TCP/IP connection active. This essentially means that using GCM will use less power.
However, I have a few questions regarding GCM.
Does a user NEED to have google services, and a registered play id ?
If a user side-loads an apk, will he still be able to receive notifications ?
I would like to know if there are alternatives to GCM
What about devices running forked android versions, like nokia X , kindle etc? How are push notifications sent to those devices ?
Does a user NEED to have google services, and a registered play id ?
Yes, it is necessary to use Google Play Services in your development. However users do not need to have a Google account or the Google Play Services Installed.
If a user side-loads an apk, will he still be able to receive notifications ?
Yes.
The steps that must be followed to send a notification to a device are:
Developer creates application in Google Developer Console
User installs application
Application gets a NotificationID and sends it to your database
You store the NotificationID at your servers with any other information related (your username, device info, etc.)
Whenever you want to send a Notification you connect to GCM sending one or more NotificationID and the notification content.
The users related to the NotificationID will receive in your Application the notification content.
Do any action you need.
Have a look here.
IMHO there is not any real alternative to GCM in Android (based on efficiency and simplicity). You may look for 3rd party services that will help you in the implementation and add value (marketing, business intelligence). As an example of this take a look to UrbanShip.
If you want to implement your own solution you should have a look to WebSockets. This will mantain an active communication between your server and the device. Those sockets are thought for real time communication between your server and the mobile.
Two issues:
How is the application affecting the battery depends on your implementation and the application use-case (how frecuent are you sending information, how long is the connection stablished).
I am not aware of any native implementation of this in Android but there are a few Libraries coming from open source projects. Google it.