I am doing a prototype that involves messaging between clients.
What I want to do - from MyApp on device1, able to send message to MyApp on device2. Device2 should receive this and show a notification.
I don't have my own application server to push notifications from GCM to GCM clients.Is this possible ? How to do it ?
What I investigated - PubNub, which has a trial license that seems to answer my need to send messages on a channel without needing a server.
This discussion at SO didn't help much.
sending client to client messages without server interaction
Can anyone suggest better ways ?
You basically have to use a server in one way or another. I think Firebase would be perfect for your purposes. It has an Android plugin you can use that will basically alert your app when something changes in the database. Here is the documentation for that feature. Take a look at this example for implementation. Before you can use the plugin, you need to create an account and whatnot (basic one is free). Here are the instructions.
PubNub Realtime Messaging and Push Notifications
(server not required)
With PubNub, you do not need your own server to do the realtime messaging or the mobile push notifications. You likely have your own server for your database (MySQL or similar, traditional RDBMS, a No SQL DB like MongoDB, or a realtime DB sync, like Firebase) to authenticate users and such.
For realtime DB or non-DB type change notifications and signaling (any type of realtime messaging), PubNub makes is super simple to receive messages in realtime with a mobile push notification fallback in one publish action. So the GCM message will be sent along with the realtime message. If the app is actively running, you get it in realtime (< 1/4 on average - typically faster) and the GCM message will be received if the app is not active (background or not started at all).
And PubNub's free plan is not a trial (anymore). It is free (including all add-ons) for as long as you stay within the free plan limits.
See the PubNub Android docs for more details and contact PubNub support if you have any further questions with getting started or getting answers to any questions you have as you progress with your app implementation.
Another possibility is to use the SMS.
Android Send and Recieve Messages
"Send Binary (Data) SMS
We can send binary messages (as opposed to text based messages that we covered earlier) to specific application ports using sendDataMessage(). According to this Stack Exchange thread data sms is one which is sent over 2G/3G as well as GSM. I’ve tested it with mobile data turned off and it works fine charging me the same amount, so not very sure on whether it uses 2G/3G or not, but generally the term data is used in telephony when it’s related to network (tcp/ip). Anyway, SMS’s are generally sent to a specific port on the device (which is probably port 0 [zero]). But using sendDataMessage() we can send SMS’s to some other random port on which our app can listen for incoming SMSs and do something with that. In this case the default messaging app will not store the SMSs in their inbox for both the sender as well as the receiver.
"
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'm new to Android and want some advice please.
I need to build two Android applications.
Android application for train travelers
Purpose: Sending a custom message (for assistence) to the railway guard. The railway guard will be identified on the basis of the wagon number that has been sent.
Android application for train guards.
Guard must be able to login and be able to receive (realtime) messages from travelers.
In short, this should be a one-way messaging system.
I'm used to build RESTful web application with databases. I have no idea which technologies i should use in this situation. As far i know i can't use databases such as MySQL, Oracle on Android. I've read that Firebase is an alternative for this but i'm not sure if it's the ideal solution for this kind of application.
I could build a RESTful server and make calls from the application. I guess if i do so the messages won't be received as realtime push notifications.
Any advice please?
RESTful services are hosted on a server and cater to incoming requests with a response.
Remote notifications are handled by a remote server. Under this
scenario, the client application needs to be registered on the server
with a unique key (e.g., a UUID). The server then fires the message
against the unique key to deliver the message to the client
application via an agreed client/server protocol such as HTTP or XMPP
and the client displays the message received. When the push
notification arrives, it can transmit short notifications and
messages, set badges on application icons or play alert sounds to
attract user's attention.[21] Push notifications are usually used by
applications to bring information to users' attention.
Source of above text
You can understand the basics and implement it into your application.
However, it is too much work and you really won't be gaining much.
It is much better to use Firebase and the documentation is quite good.
You need to pay as you go based on how much you are using Firebase.
A place to start:
https://firebase.google.com/docs/cloud-messaging/
I need some clarifications.
I'm using Firebase realtime database.
Now I've to implement a realtime chat between two android devices. I need also push notifications.
So, the solution based on realtime database is to drop because if the app isn't running, it will not handle the onChildAdded event.
I read on the documentation that I can achieve my aim, using the upstream message from the device to the server.
Now, it's written also that we need an app server.
I just want to be clarified the need of the app server (XMPP or HTTP), and which is the entire flow of message m1 sent from the device A, and the notification on the device B.
In my opinion the app server should act as a man in the middle, so:
A ---> XMPP SERVER ---> FCM
FCM ---> XMPP SERVER ---> B
Is this the flow?
On the documentation I can't understand if I'm right or not.
If so, how do I send a message from the FCM back to the XMPP Server?
The notification message is sent from FCM to the client o from XMPP Server?
Please someone clarify me.
Other solution thought by me:
Since I find really powerful firebase realtime database, I thought these solution to walk around the problem:
Create an app server the is listening for onChildAdded and when it changes send a notification to client device.
Creating a background service on the client app listening to onChildAdded and create notification when necessary.
Even all, I don't like these solutions.
Just want to understand the standard and correct way to achieve my aim.
Firebaser and author of the article debated in the question comments here
To send messages to a device with Firebase Cloud Messaging, you need to specify your project's FCM Server Key. As its name suggests, this key should only be used in code that runs in a trusted environment: i.e. a server that you control.
To send device-to-device messages (such as in a 1:1 chat application where the receiving user is not necessarily online) you need two steps:
one user send an upstream message
the other user receives the downstream message
Using Firebase Cloud Messaging and your custom app server code, you can handle step 2. But that still leaves step 1: the user needs to send a message that somehow triggers your code on the app server. There are quite a few ways to do this.
For example you could implement an HTTP endpoint on your app server and have the chat application send the messages there too (in addition to sending to the database).
You could also implement an XMPP endpoint and have the chat application send the message there (again in addition to sending it to the database).
My article suggest yet another way, one that doesn't require implementing an endpoint at all. It uses a node.js script that runs on your app server and is essentially just a client to the database. Whenever this script detects a relevant chat message, it calls the FCM API and sends the downstream message.
This pattern of using the Firebase Database as your endpoint and then using server-side scripts is quite common when using Firebase. We documented it in our classic blog post Where does Firebase fit in your app? (as option 2) and in this article in the Google Cloud documentation.
Our organization has an Android app and an iOS app.
We want to start pushing notification to these apps.
Android has GCM.
Apple has APNS.
But we want to create an API which will work on both android and iOS.
What is the easiest way to setup a server so that when a push notification needs to be sent, it knows exactly which server to send the message to?
I use a service called Parse to do my notification pushes to both Android and iOS. They have great documentation and libraries available. You can get some details here: https://parse.com/products/push
As a little background this is for a university setting where multiple colleges apps as well as distance education may be using the service. Here is the approach that we are using in our organization. If you look at the way APNS works it can be used by just sending a web call to the APNS service with the token id. GCM is very close to the same type of system. Basically create a JSON package and send it to the desired service.
Here is our steps we used to create this service.
Server admins created a server and database that can be called that will collect the tokens from both android and ios devices. When the device registers we also send what type of device it is. This is possible since we are just sending data to the database that is has been created.
From here we then created a couple of python scripts that send the data do the desired service whether it is ios or android. These scripts gather the appropriate data from the database and sends the packaged data (JSON package) to APNS for ios message and GCM for google cloud.
We also created a web interface so that those who need to send messages to the devices can.
The rest of the implementation is up to you to decide the best way to utilize the service. For example when to check for invalid devices,
Because we are planning on using this same server for multiple applications we can send the type of device, token, application, or whatever else is needed for an application to distinguish it from others we produce so that each application that wants to use the service can. I hope this helps and gives you some idea on how to accomplish this.
For APNS, Maybe you may consider this forked version of PyAPNS that has enhanced message support.
https://github.com/jimhorng/PyAPNs
which means it will catch error response for failure messages and resent the message which are discarded by APNS while sending between failure messages and receiving error response.
Solution:
Non-blocking ssl socket connection to send notification without waiting for response.
A separate thread for constantly checking error-response from read connection.
A sent notification buffer used for re-sending notification that were sent after failed notification, or arbitrary connection close by apns.
(Reference to non-blocking apns pull request by minorblend, enhanced message by hagino3000)
Result:
Send notification at throughput of 1000/secs
In worse case of when 1st notification sent failed, error-response respond after 1 secs and 999 notification sent are discarded by APNS at the mean time, all discarded 999 notifications will be resent without loosing any of them. With the same logic, if notification resent failed, it will resent rest of resent notification after the failed one.
For GCM, you may consider https://github.com/geeknam/python-gcm
For generic wrapper that support both or more mobile provider:
https://github.com/Redth/PushSharp
Since I want to build reliable communication in mobile apps, could I get push failed reports(maybe device is offline) from the third party push services (C2DM, APN, urban airship) ?
Or We need to build it by ourselves?
The intended purpose of Android C2DM is to be a battery-saving way for your server app to signal the mobile device that it wants to start reliable communications.
You can structure your message so that each new C2DM encompasses everything that has occurred since the last two-way interaction with the server (i.e., "come and get whatever I've got"). Your failed delivery report is implicit in the mobile device not responding promptly (you can do this because you know C2DM activates your app with an Intent).
Is that really any worse than guaranteed delivery of each message in a lossy medium? Okay, it's worse in that you also have to implement a primary communication method. But you had to do that anyway because C2DM is inbound-only, right?
As Vinay says, MQTT may offer you the feature you desire. When a client connects to the server, it can register a "last will and testament" message with the server. If the client disconnects unexpectedly, the server sends this message to the topic it was instructed to do.
In this scheme, your client could send a message "online" to something like client//status and register the message "offline" as a LWT for the same topic. You could then have a server local client that listened to the topic client/+/status and it would know which clients were online and which offline.
I would suggest that the tokudu demo isn't the best place to look. This blog post by Dale Lane gives insight into using MQTT on Android: http://dalelane.co.uk/blog/?p=1599 and there is a review of MQTT power usage (again on Android) at http://stephendnicholas.com/archives/219
There are client implementations to suit both IOS and Android, see http://mqtt.org/software
No one service does not provide reports about failed pushes.
Failed push report makes little sence with APN/C2DM/Helium
All services are aimed to deliver the push-message under all circumstances.
If device is offline now, then push will be delivered when device becomes online.
Moreover, for iOS push-message is just a notification for a user, not for an application!
Simple case will illustrate it:
Assume that push is received when the application is turned off. In that case, notification for the user will occur. But, application will receive data from push, only if user taps on that notification! If user will tap on application's icon, then data will not be received.
So techically, push is delivered to the iOS device and application is started, but data is not delivered.
UrbanAirhip with APN and Helium
You can consider to implement your own transport for pushes. MQTT seems to be a good option.
But in this case, you have to deal with keepalives, device sleeps and battery optimisations.
All that hard work is already done by engineers from Apple, Google and UrbanAirship.
Depending on your business needs, it can be easier to adapt your architecture for existing solutions, then reimplement push-service again.
Take a closer look to UrbanAirship. In fact, C2DM has some limitations and sometimes timings for delivery of push-message is too big. Because of that UA has implemented their own transport - Helium, it works pretty good. Helium is a paid service, but UA provides good SLA.
I am suggesting for push notification IBM MQTT protocol. This fine enough for push notification.
see the demo from https://github.com/tokudu/AndroidPushNotificationsDemo
I did something similar where I had a database keep track of push queues to known subscribers and had reporting when failed. It was very simple and went something like this...
The schema was like so:
pushMessages
messageID , GUID, PK
message , nvarchar (256),
expires , datetime
messageQueues
subscriberID , GUID, PK
messageID , GUID PK
failedPushMessages
subscriberID, GUID, PK
messageID , GUID PK
(subscriber table omitted)
Once a client received the message successfully, the client would ping back to the push server and notify it via the unique queueItems ID that it received on the push notification. There would also be a daily database process that would check for expired push messages. When found, it would do a join on the queueMessages matching the messageID then remove them from the messagesQueues table and copy them to the failedPushMessages table.
This was very easy to understand and maintain but I don't have experience doing it another way.
Push Services are an efficient and reliable way to alert your users. They allow even background applications to inform users of new information in real-time. Push Services are widely used for a variety of fields in mobile applications, such as weather updates, messaging services, mail notification, coupon services, and so on. Push Services are no longer optional but have become essential.