Android has the Gmail push features, which means the new message arrives in the mailbox without checking or refreshing the mailbox.
As I understand, the sync processes are like these:
1) User turns on the sync
2) There will be a alert msg and the sync flag in the Gmail DB of this device will be True
3) When a new email reach the Gmail Server, it will check if the device sync value, if it's True then send the email
OK, here, I don't quite understand how exactly does it work,
For a WiFi and cell signal connection, does the phone has a TCP socket open keep listening to the Gmail Server, or when a new email arrives the Server and it sends a SMS alert to the phone, and the phone will open the data channel to fetch the email? Do the two ways of connections have different approaches?
And second question is which method is the priority one?
Say when you are in the middle of receiving data(emails), and suddenly the phone connect to a wireless network, will the data socket be closed and then reopened for the WiFi one? What's the behavior for the case when carrier's data channel and WiFi flips?
I have also downloaded the source code, anyone knows which part should I be looking into in order to solves my questions? I found a folder called "email" inside the folder "package", should I be looking at its code?
I know I asked quite some questions here, I'd appreciate if you know the answer for any of them, thanks very much!
This technically is not part of Android, but rather Google's proprietary application suite that runs on Android. It also is not really implemented in Gmail -- the google apps collectively have a push data connection with google's servers (built on the gtalk data protocol, but mostly there for historical reasons) which they share. When new mail is available, the push connection is used to send a "tickle" to the device to say that something has changed in mail, and on the device this is then dispatched to the gmail app which opens a new socket connection with its server to synchronize the local state with whatever changes have happened. This same mechanism is used for contacts and calendar sync, as well as things like instigating downloads from market.
The way this works is an implementation detail, but currently it is done by keeping an open socket connection. On a network that can't do voice and data, the connection is dropped when a voice call takes place. When switching between wifi and cell, the connection is dropped and restarted.
Note that doing push notifications this way is quite resource intensive on the device, which is why this has been carefully designed to allow one such instance to support all Google services.
Related
I want to develop an android application for LAN calling.My app resembles apps like whatsapp, viber etc, so I googled for the same. What I got from different answer is:
Whenever we install whatsapp, the whatsapp server register our number and contact list. The app continuously pings the server and update its status on server.
When we open the app, it gets the data from server, and if a number is found in contact list, it displays the status of the number and other things.
Whenever we message some one, the message goes to server and stays there until delivered successfully.
For my app the two steps are:
Find all the devices which has my app, their IP and mac address.
When devices are found,allow calling between them.
For step 1, I have two options:
As whatsapp, I can have a server. It registers the info of the mobile phone, whenever the app is installed. The app pings the server and shows its status.
I can use my own network device discovery code. This code scans the network and find the devices.
This step is costly, whole network is flooded with the packets. And also it is quite difficult to write network device discovery code.
For step two, I want to implement client-socket programming and simply connect the microphone of one device to the speaker of another phone. I think it is challenging, but it is possible.
Please help me with network discovery code or the server setup. I am quite familiar with android development, but very novice to networking.
Also how calling is done between these devices?
I have searched for the answer and found the following links: Peer-to-peer SIP call with Android SIP Stack?
how to implement voip in android
VOIP on Android libraries or sample code
I also put a question on quora:
https://www.quora.com/How-can-I-develop-an-app-having-feature-like-whatsapp-calling-in-android
But, still I am stuck at the beginning. Please help me with it.
Not a complete answer yet, but here are the things to look for:
Assuming Java is your language, use Multicast Network discovery in Java using multicasting and https://en.wikipedia.org/wiki/IP_multicast
Calling needs more description. Does the call starts immediately (as soon as the peers detect one-another) ? How does one know the identity information - a number or a username etc. ?
As the topic name suggests, what I am looking for is to add my android app the option to send data to a different phone running the same application so the receiving phone will process it accordingly.
The obvious option for me was to use app engine and use push notification with the phone number acting as the identifier.
Does a simpler solution exist?
Thanks ahead :)
The best and most robust solution is to have something like your messaging clients, in which Device A sends data to the server, which pushes it to Device B. Device B sends a reply to the server, which pushes it to Device A.
This process has the advantage of retrying the sending without requiring your users to stay connected, as may be required if Device B is offline when A sends a message.
A less foolproof solution is to have a server work as a middle man, and get each device's IP Address, and then open up a direct socket between them. In this solution, you'll lose any data that doesn't make it through.
If the devices are on the same network or in Bluetooth range, you could try Bluetooth or WiFi direct.
I'm trying to figure out what the solution is to having multiple android devices on one network share data.
Assuming all of them are running the same app, and a user "registers", I'd like to figure out (without any user input) what other devices on the network are available to be talked to and then to send them this registration data, so that when the user goes to the next device, their info is already there.
I'm able to ping the 255 connected devices in the x.x.x.0-255 range to see which respond, but am not clear on how I can write an app resident server (using the term loosely) that I could then send the data to.
I can't be the first person to need to solve this problem, but am unable to find anything useful on this front.
One caveat is that this is for devices that have no 3G (or other means) of getting to the internet, and the wifi network they're on won't have access to the internet either, so the solution has to be 100% internal network and can't include any additional devices (like a box running apache that all the device can use as a server).
TIA
but am not clear on how I can write an app resident server (using the term loosely) that I could then send the data to.
Create a Service that has code that opens a ServerSocket and listens on incoming requests, such as an HTTP server.
On the whole, this is dangerous, but for constrained circumstances -- such as your "100% internal network" -- it should be safe.
I've been looking around for some way to simulate Peer 2 Peer for games on the android and the best way I've been able to come up with is connected an android to a server and then routing through that server. I'm just looking for some thoughts on my way of solving the solution so that you could literally type in someones phone number and try and connect to them.
By use of a service module to check incoming text messages, which would be properly formatted for detection, it would interpret that another phone is trying to request a connection to another one of the androids applications. If the application is found it would then prompt the user as to if they wished to connect to the other person. If yes, their phone would send back a text message to the original phones, which also has the messaging system installed on it, which states it would like to connect and that this is my current IP address. The original phone, or host phone, would then open a connection with the other users phone via the Internet at which point the newly made connection could be used to transfer information back and forth.
Basic list layout
Service module:
- Writes/Receives formatted text messages to alert/verify someone is trying to connect to an application of theirs
- Sender attempts to make a connection with the recipient phone, which takes connection and passes to desired application along with sending back a confirmation package
- On confirmation Sender phone passes connection to original desired application.
Any thoughts, ideas, constructive criticism would be helpful.
* srry for bold, but I hope you understand why.
the best way I've been able to come up with is connected an android to a server and then routing through that server
This is called TURN P2P implementation. You want to read about STUNT implementations too. You'll probably be interested in the JXTA P2P framework.
I would like to write an Android application that can be activated by sending it a command from a web site. Is this possible? Actually, the app would be running on the phone and I would be sending it a command via HTTP.
As of Android 2.2, you can start playing with the cloud to phone messaging system (more information here)
You could have your application maintain a connection to the webserver waiting for a command. This kind of technique is often used in AJAXy websites that update in real time, and is called the "comet" pattern or "long polling".
Basically, your client (the app on the phone in this case) requests a certain page. Your webserver (or PHP or whatever you're using) checks to see if there are any outstanding messages or commands to be sent to the client, if not it keeps the connection open and waits either until a message for the client is received, or until a certain timeout.
There are a couple of obvious drawbacks to doing this:
Your webserver needs to maintain 1 open connection per user of the application. Depending on the server, this can tie up resources fairly quickly if you have lots of users
Your application will be using resources constantly as it will also have to maintain an open connection and re-establish it periodically
This is all assuming you need near-realtime responses to your commands. If they can be delayed, normal polling should suffice.
You could have the server send an SMS message to Android. On the Android side, your app listen can listen for the SMS message and execute the appropriate command. Here is a question about sending SMS from a server. Here is some help on using sms in android.
I'm not sure if you can keep your SMS messages private to your app. Ideally you wouldn't want the user to see these SMS messages as a text message. Perhaps you could just delete the message as soon as it is processed.
This is completely possible. Just start a webserver on your phone. For instance: http://l00g33k.wikispaces.com/micro+HTTP+application+server
A bit of tooting my own horn:) Now with that addressed...
This will not work over many 3G networks (no public IP address)
If no general public access is required, you can use two SSH connections to an SSH server. I have done it many times and is as secure as your SSH setup.
and has all the security ramifications of running a Web server on an actual server without most of the tools (e.g., firewalls) to manage them
If general public access is desired, you can do it with one SSH connection from the phone to the SSH server. You need to open a port on the SSH server but you don't need firewalls management because you can run another Perl script to filter the source address and forward to the phone through the SSH connection. There is another thing that is good/bad about it depending on your view. Since it requires an active SSH/Android ConnectBot connection, you know when it is active and it drops off when you close the SSH connection. To me this is added security. And I have done this to send KML files to Google Maps' Google server (KML file must be publicly accessible without password to the Google server even though the file is on your phone; I filter by Google's IP address.)