In my first deployment my Android Application maintains throughout its execution (from power on until the device is turned off) a socket with the Web Server and in a Background Service await messages from the server.
Now I was wondering if you can do the same without having a Socket open all the time.
Is there an alternative way?
yes.
It's called Google Cloud Messaging (aka. GCM)
http://developer.android.com/google/gcm/index.html
it's quite straight forward to implement and you won't kill your devices battery,
Related
It seams like to work with chat application, using openfire and smack there can be two ways below,
First Way
Smack makes a connection with the openfire server and it can receive and send updates to the server as long as its connected to the openfire server. In case its not connected, theres a plugin on openfire which keeps the messages offline, and send them once the client is connected again.
In this scenario to receive all messages,
1.1 Device should only disconnected from the openfire in case if it don’t have internet.
1.2 User is sign out
1.3 Device is offline
If connection goes disconnected with the server in any other case this cause messages loss. Currently application is working with this architecture.
Problems with this method:
The major problem for this is if due to any crash, or problem application gets completely killed, and its not alarm manager task also gets killed. App didn’t restart until the application opens again.
Second problem with this is, its consuming battery due to continuous process
On updated OS application goes in deep sleep, doze mode, ulta power save mode, background
Second Way
2.Smack makes a connection with the openfire server and it can receive and send updates to the server as long as its connected to the openfire server until the application is in foreground. As soon as this goes in background the application will completely disconnect from the server. In this case as application is offline openfire have to send all the messages to the Firebase server, same application listens for the firebase notifications and when it receives the notification from firebase it reconnects to the openfire and gets the message and display or shows the message directly from firebase (in this case this record goes to the firebase server as well). Application receives that notification from the gcm and then need to manage in application about message delivery etc.
Problems
Disconnect from server when app goes in backgound, handle its usecases as app is in background for long time or not. Is app goes in background to select any file and use cases like this.
This makes the code and application very compelex and need to manage multiple servers as well.
There can also be more security breaches as i don't want to share my application messages data with any third party.
My Questions
Which way is better, secure and more reliable to use?
My application is working with way 1, should i switch to second way ?
what can be possible reasons to make sure that app stays connected in each and every way? and it consumes less batter as well?
1- Which way is better, secure and more reliable to use?
A: Second Way
2- My application is working with way 1, should i switch to second way ?
A: You should but obviously that would require Openfire skills to develop a plugin which will route messages to FCM.
3- what can be possible reasons to make sure that app stays connected in each and every way? and it consumes less batter as well?
A: Simply said, if we reduce XMPP traffic, processing power can be saved and as a result reduction in battery consumption. But obviously for a chat application, that won't be the option. So for keeping the application interactive and battery friendly you should disconnect XMPP when app goes to background and rely on Push notifications (integration on server side).
I am developing a client server system. The server is a Java application that runs 24/7 and get information from the web all the time to keep updated. The client is an Android app.
This is the way that the system has to work:
The client can register to the server for some information.
If the client registers correctly, the app has to run in background 24/7 waiting for server messages.
The server has to know the clients registered and send the information to all the registered devices everytime its information is updated.
If the client receive information that meets a condition then it stops running in background, unsuscribe to the server and activate an alarm.
My questions are:
Is it possible to do the communication using Google Cloud Messaging?
The way to do the client run in background 24/7 is using android services or am I wrong?
Thanks,
SB
you definitely can and should use GCM, that's why it exists. doing anything else is going to be a lot of work to get right, and is going to be highly inefficient when it comes to network and battery usage,
http://developer.android.com/google/gcm/index.html
What's the best way to send constantly updating data from a server (over a REST API or a socket) to an iOS or Android app? Should I create a socket connection and have a socket server that pumps out data, or should I have the app periodically poll a backend resource? Thanks!
Should I create a socket connection and have a socket server that
pumps out data
This is an option. I know some top apps on the play store that use web sockets for streaming data.
Have the app periodically poll a backend resource
I would recommend against this. Polling drains the battery. The android OS will keep the CPU in idle mode at times and constant polling can wake the CPU up and cause a drain in battery. Users wont like that. You are also wasting processing power when there are no results from the server.
The easiest way to send push notifications / minor updates to the android phone is via GCM. The GCM messages are delivered in near real-time (I noticed a lag of about a second for my apps). The payload is limited to 4k and the messages are stored for up to 4 weeks. This is another option you can consider based on your use case.
The typical model I follow is to hit the server on a specified interval and download the updated data.
Polling is bad, it drains out the battery
If you want to update the screen when the application is in the foreground, it is better to go with Socket Connection. You can see the changes in realtime.
For this, you need to create a socket server and open a connection between the device and the server.
https://www.raywenderlich.com/3437391-real-time-communication-with-streams-tutorial-for-ios
I would suggest to use MQTT protocol to publish and subscribe data. Libraries for iOS(Moscapsule) and Android(Paho) for integrating MQTT protocol are available and can easily be integrated in mobile apps.
Backend needs to be configured to support MQTT also. Detail information about how MQTT works can be found here.
I am going to paste my accepted answer from a similar question that was posted a few hours ago.
It can be done using sockets or polling the server but I wouldn't recommend either for a production level app. You will eventually need security features and as a frontend developer, it would be difficult to start from scratch.
I would suggest using a third party service. Take a look at Space Cloud. It is an open source alternative to Firebase where you can use your own database and has built in security features. If you want to go deeper, it uses Apache Kafka for realtime database features.
If those don't suit you then the best option would be to go with GCM.
should I have the app periodically poll a backend resource?
this must be the last option to put in consideration. as long as the client number increases you need to scale out backend/server and this is not as simple as putting an another server next to existing one.
the perfect solution will be a push oriented design and best approach will be to register clients to events and server will push clients if that specific events occur.
you need to be more specific about your business case. you had mentioned real-time in your question but what kind of real-time is that. is it a video streaming, chat application or just ordinary rest calls?
Typically, you'll want your server to push updates to the clients because polling is expensive, may not scale well with N number of clients, and will drain your phone batteries faster. Depending on your server technology:
.NET/Core:
May want to take a look at SignalR to push notifications from the backend to your client apps.
Java:
May want to take a look at Atmosphere to push notifications from the backend to your client apps.
I have used SignalR with good results publishing to phone clients. Have not used Atmosphere, but it has good reviews.
I have already implemented a push notification system for the android. My system works as following: From my server I communicate through the Http protocol with the google servers. Then the google servers are sending the notification to the mobiles. So, I was wondering if there are any alternatives ways to implement this functionality. However, I want something which will be reliable.
P.S. I would like to hear opinions from people that they implement something similar.
Not sure why you're looking for something else, if you've already got it working through the Google servers, but a good system to send push notifications easily is Urban Airship.
I was working with some Chinese tablets that could not receive android push notifs (very annoying). I had to implement a Comet like system on android.
Basically, on the android device, I created a service which essentially polled a URL. But since polling is very battery intensive, I used a push technique called long-polling. I had the Android http client set a very long timeout. I then on the server side had the server hold the connection open also for a very long time. What would end up happening is that as soon as a message had to be passed, the connection would finish, and the android device would get the message immediately. This is just an additional method of "push" technology.
The only other option not discussed here is a persistant TCP/IP connection. This can be very dicey because Android could kill the service at will, and it can be somewhat battery intensive as well.
From my experience, GCM is the best method out there, and I wish there was something as good as it available for iOS Devices!
I installed today from Market, the Yahoo Mail application and I was reading it offers push message notification technique. Indeed it works, as I got exactly the same moment the alert on my desktop computer and my mobile mail client.
How is it accomplished?
There already is another question discussing how to implement push notification without the cloud to device messaging in older system.
There are several frameworks that give you push abillity. They all require a running a small background thread that is polling a server at a very short interval(Bad for data rate and battery) or keep an open connection to a server that is kept alive somehow and the client is notified every time a new message is waiting on the server.
Have a look at the question and maybe choose on of the mentioned frameworks, the frameworks will reuse the same service for all applications that are installed on the phone using the same framework and therefore save battery and general system usage.
Soon, you will be able to use the Cloud-to-Device Messaging (C2DM) system, though it will require Android 2.2 or higher. You might also want to watch the Google I|O 2010 conference presentation on it, which gives a few clues as to how they implemented it.
Without installing the app, setting up my router to capture packets, and doing some packet inspection I can't tell you exactly how they do it. At the lowest level it's as simple as keeping an open TCP connect to a remote server and having the server sending the client a packet when it needs to do something. My educated guess on the specific way they are doing it is either with IMAP IDLE, or XMPP.