I'm trying to make a communication between my App and the server side. The app needs to receive messages from the server because it's remotely controlled. It works as a Background Service.
I'm currently getting the messages from the external MySQL by using HTTPPost, doing requisitions every 20 seconds, but it spends much battery.
I tried doing a Socket connection to a server (build in java): device connects to the server every 20 seconds and close the conn when it just receive the data, but it also spends much battery.
Is there a way of receiving these messages instantly as Whatsapp does?
If the app is open it's most likely a socket connection. This is usually how messengers work.
In the background though it's most probably using push notifications (Check FCM - Firebase Cloud Messaging). This source of info can be unreliable so making a service with requests once a minute or two could be cool
In our messenger, we use long-live HttpsURLConnection as the main channel. The connection is hosted in Service and it is run in separate thread. In case of disconnect, we try to establish a new one. And we stop the service after our application is inactive for 2 minutes.
As the second channel, we use FCM.
This is what concerns messages. We also use WebRTC for multimedia data transfer. And we are going to use SIP calls to init voice- and video- call.
Related
I am developing an Instant chat messaging Application using XMPP framework in android. Chat works fine while I am on chat screen. But if I minimize the app i.e If I put the app in the background on receiver end then also chat works fine while I am continuing sending messages. But when I stop sending messages and leaving the app in background on receiver end then after a certain duration may be like 30 mins or an hour if try to send a new message, it stops receiving messages.
I think the reason should be that XMPP connection is getting broken for some reason. Is there any way to mantain the connection for forever so that it never gets broken. Or do we need to run a service in background in order to do that. If yes please tell me the code for doing so.
Thanks in advance.
One possible solution is to select 'Do not disconnect clients that are idle.'
in the connection manager of openfire web admin.
Open your admin console and go to Server > Server settings > Client connections > Idle connection policy (http://127.0.0.1:9090/client-connections-settings.jsp). Then select the option 'Do not disconnect clients that are idle'.
In this way, openfire won't disconnect inactive users.
I am writing an Android app that among features has a chat module. I have choose to implement the chat using long polling.
Because I am trying to avoid eating up the user phone battery I thought about adding to the implementation a GCM messages platform to notify the device about new messages.
The idea is to use long polling while the user has the app open on his screen so engaging in a real time chat would be fast and does not involve sending a lot of GCM messages, while when idle, the server will know that the user is not currently polling and will send the device a GCM message to wake it up when a new message arrives.
I am struggling with a few issues implementing this method:
What is the best way to know the status of the user - Is hes polling right now or waiting for the push message to wake it up. Should I set the app to notify the server when it goes to sleep or the server should detect it by itself?
If I set it so the app will notify the server when to switch between modes, how do I recover in cases this notification did not got through. (when the client is waiting for gcm and the server thinks it's polling and will not send one..)
I experienced some case where the client was polling and the server did not responded even when it got new messages. Maybe some kind of timeout on the server that the client is not aware of... If that's a bug I'll fix it, but what can I do in cases when the client thinks it's polling while the server does not know about it (the timeout of the requests is too long to wait for the next poll).
My client is native Android and the Webservice is WCF (C#).
Any thought will help.
I haven't used GCM but i have experience with lots of messaging applications on mobile so will try to explain what we followed.
What is the best way to know the status of the user
First off - long poll when app is in front isn't the best way to receive instant message. You need to keep a tcp connection open to receive it instantly ! ( hopefully your notification should also contain the message ) Any kind of polling will ensure that you wasting battery and not receving instant messages.
Second - I would think that client should inform the server about its state ( foreground/background ) so server knows how to respond.
So my suggestion would be to use TCP socket for CIR and use poll as backup when in background ( in case server loses the "client went to background message" )
To recover use long poll (10 minutes) to get updates from server and also informing server about your state.
If you use the approach i have mentioned ( using tcp socket ) the server should know that your app is in foreground as long as the connection alive. Also a server should always respond to the poll with delta updates ( your poll should send last time the server sent something )
Hope this helps.
I am working on a project in which I can see webcam images from the people who is in front of the door on my Android app.
But I am getting a bit confused. I've managed to setup a connection with a service on my phone to a server which handles the image sending.
But i only want to get images from the server when someone presses the doorbell, so I need to send a notification or something to my app so I know there is one in front of the door, and I want to decide if I want to answer his call or not.
Now this is why I am confused: if I open the tcp socket in the android service, how can I know that my server sends a 'call' message, because the tcp socket is openend when the service is created. Do I need to keep polling every second? Then there is still a little chance that I will miss the call message?
Or do I have to run the application as server and the doorbell as client, so the client request a connection?
Have a look at cloud to device messaging, c2dm , a lot more power efficient too. Built into android.
https://developers.google.com/android/c2dm/
If the tcp socket is opened when the service is created, just send some appropriate message from the server to connected clients. If your client is connected, it will get it. You only need to poll if the client continually connects and disconnects, eg. like many HTTP 1 web services.
I have a J2ME app running on my mobile phone(client),
I would like to open an HTTP connection with the server and keep polling for updated information on the server.
Every poll performed will use up GPRS bytes and would turn out expensive in the long run, as GPRS billing is based on packets sent and received.
Is there a byte efficient way of polling using the HTTP protocol?.
I have also heard of long polling, But I am not sure how it works and how efficient it would be.
Actually the preffered way would be for the Server to tell the phone app that new data is ready to be used that way polling won't be needed to be done, however I don't know of these techniques especially in J2ME.
If you want solve this problem using HTTP only, long polling would be the best way. It's fairly easy. First you need to setup an URL on server side for notification (e.g. http://example.com/notify), and define a notification protocol. The protocol can be as simply as some text lines and each line is an event. For example,
MSG user1
PHOTO user2 album1
EMAIL user1
HEARTBEAT 300
The polling thread on the phone works like this,
Make a HTTP connection to notification URL. In J2ME, you can use GCF HttpConnection.
The server will block if no events to push.
If the server responds, get each line and spawn a new thread to notify the application and loopback to #1.
If the connection closes for any reason, sleep for a while and go back to step 1.
You have to pay attention to following implementation details,
Tune HTTP timeouts on both client and server. The longer the timeout, the more efficient. Timed out connection will cause a reconnect.
Enable HTTP keepalive on both the phone and the server. TCP's 3-way handshake is expensive in GPRS term so try to avoid it.
Detect stale connections. In mobile environments, it's very easy to get stale HTTP connections (connection is gone but polling thread is still waiting). You can use heartbeats to recover. Say heartbeat rate is 5 minutes. Server should send a notification in every 5 minutes. If no data to push, just send HEARTBEAT. On the phone, the polling thread should try to close and reopen the polling connection if nothing received for 5 minutes.
Handling connectivity errors carefully. Long polling doesn't work well when there are connectivity issues. If not handled properly, it can be the deal-breaker. For example, you can waste lots of packets on Step 4 if the sleep is not long enough. If possible, check GPRS availability on the phone and put the polling thread on hold when GPRS is not available to save battery.
Server cost can be very high if not implemented properly. For example, if you use Java servlet, every running application will have at least one corresponding polling connection and its thread. Depending on the number of users, this can kill a Tomcat quickly :) You need to use resource efficient technologies, like Apache Mina.
I was told there are other more efficient ways to push notifications to the phone, like using SMS and some IP-level tricks. But you either have to do some low level non-portable programming or run into risks of patent violations. Long polling is probably the best you can get with a HTTP only solution.
I don't know exactly what you mean by "polling", do you mean something like IMAP IDLE?
A connection stays open and there is no overhead for building up the connection itself again and again. As stated, another possible solution is the HEAD Header of a HTTP Request (forgot it, thanks!).
Look into this tutorial for the basic of HTTP Connections in J2ME.
Pushing data to an application/device without Push Support (like a Blackberry) is not possible.
The HEAD HTTP request is the method that HTTP provides if you want to check if a page has changed or not, it is used by browsers and proxy servers to check whether a page has been updated or not without consuming much bandwidth.
In HTTP terms, the HEAD request is the same as GET without the body, I assume this would be only a couple hundred bytes at most which looks acceptable if your polls are not very frequent.
The best way to do this is to use socket connection. Many application like GMail use them.
Can a J2ME app be triggered by a message from a remote web server. I want to perform a task at the client mobile phone as soon as the J2ME app running on it receives this message.
I have read of HTTP connection, however what I understand about it is a client based protocol and the server will only reply to client requests.
Any idea if there is any protocol where the server can send a command to the client without client initiating any request?. How about Socket/Stream based(TCP) or UDP interfaces?.
If the mobile device doesnt allow you to make TCP connections, and you are limited to HTTP requests, then you're looking at implementing "long polling".
One POST a http request and the web-server will wait as long time as possible (before things time out) to answer. If something arrives while the connection is idling it can receive it directly, if something arrives between long-polling requests it is queued until a request comes in.
If you can make TCP connections, then just set up a connection and let it stay idle. I have icq and irc applications that essentially just sit there waiting for the server to send it something.
You should see PushRegistry feature where you can send out an SMS to a specific number have the application started when the phone receives that SMS and then make the required HTTP connection or whatever. However, the downside of it is that you might have to sign the application to have it working on devices and you also need an SMS aggregator like SMSLib or Kannel
You can open socket connection and implement "Hide" (or "Minimize") functionality in your app. Call this to hide:
Display.getDisplay(MyMIDlet.instance).setCurrent(null);
Listen to the server in a loop, and if you receive some message, popup the applicaion by calling this from canvas:
Display.getDisplay(MyMIDlet.instance).setCurrent(this);
But it dosen't work on all devices.
Socket push are supported by j2me. But it could work only if your server could deliver data to your mobile phone. Most likely that operator gateway don't allow to do this.
Maybe it would be possible if your mobile has static external IP address - some operators could provide this for $$.