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 am currently writing an Android app, and I would like to send push notifications from my server to the phones where this App will be running. Due to security reasons, I would like to avoid any third party server like Google's servers that are used when using GCM (Google Cloud Messaging). How can I achieve that? Or do I need to use a workaround (e.g. polling or working with GCM and encrypting the messages)?
Thank you very much in advance for your help!
The easiest way to prevent Google from reading your messages is simply not sending any data to GCM. Use send-to-sync-messages for that. To improve performance use collapse_key.
On receipt of a send-to-sync-message fetch the new data from your webservice. I also used this approach in a recent project with high security requirements.
I'm trying to make a chat application using GCM, but I'm a little confused about what the best practices are.
The tutorials I've seen recommend using the XMPP-protocol because you can use existing connections and pass bi-directional messages which makes it faster. The problem is that the GCM payload is limited to 4kb. I wonder whether it's safer to use the push notifications to actually deliver the messages or just to notify the clients that there more messages to download using the HTTP-protocol.
There is also the security problem. I use the OAuth resource owner flow to secure many of HTTP-endpoints. It feels bad to also include the client-id, user-id and access-token/refresh-token in my GCM upstream messages since the payload is already limited. Also, it would require me to write a lot of code ensuring that the access-token has not expired and when to retry and include a refresh-token instead and so on.
So I wonder if it's better to just send the upstream messages using the HTTP-protocol and then using GCM to notify the receiver to download the message.
Lastly, I wonder if it's worth using the XMPP-protocol if you are using HTTP for upstream messages anyway. Is the XMPP-protocol still faster, or is it just faster if you are going to use it to send upstream-messages?
Hope I was able to explain my problem well.
I want to implement an instant messagign service analogously to whatsapp.
The messages are delivered, even thoug sender and receiver do not need to be online at the same time.
Is there a framework existing to do so (btw I use a linux server). Is the Google Clouse Service suitable for this? Thank you
Google Cloud Messaging (GCM) is a service that manages small messages to / from android. It does require users to be using google play.
What makes it so cool is they will manage the connections for you. They will queue stuff up for a period of up to four weeks, and after that will send a message telling you that its been more than weeks, and you will need to process a new request to obtain the original messages again.
Its a free service. There are some rate limits, but they seem pretty reasonable. i.e. You can't use it for sending frequent game moves, but its totally fine for normal text messages. As I understand it, GCM is only a server interface. You will have to roll your own XMPP server to store and manage messages. Note: there is a payload limit on GCM messages, I think its 4k or so... not big enough for images. You'd have to manage those via http, and send image names via GCM.
They will also broadcast messages to users (1000 at a time). Did I mention this is a free service?
Something like this link will get you started. The API keys thing and registration #'s is sorta confusing. Once you figure that out, it all works. You can test to your emulator via curl messages to the google server, etc..
Oh, and GCM also keeps track of all your user analytics as well..
You can try openfire. It has offline message and everything. Server can be hosted in linux as well.
There is Layer (Android and iOS support for the moment)
Hey Checkout this easy way to implement chat
Quickblox Api
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.