I know you folks are working on fixing the connection problems that I and various people have been reporting, and I trust that you are well versed in Google's API's. Nonetheless, I'd like to make a few suggestions about how the app might be structured in order to eliminate the problems that many of us are seeing.
Please don't take this as condescending or in any kind of negative light. It's possible that you have already tried (or are already doing) what I am about to suggest, and it just doesn't work. However, I still want to put this out to you, in case it might be helpful. If not, PLEASE don't take this in the wrong way, and feel free to throw my entire suggestion into the "bit bucket".
Last year, I worked on an app which provided a small subset of the functionality that you are offering with AirDroid. It also had to remain alive and in two-way communication with an external server, even when the app was not in the foreground, and even when the Android device was asleep. I was able to successfully get this to work as follows:
1. I made the main functionality of the app run inside of a Service. The user interaction was done through a GUI which simply interacted with this service. The advantage of this approach is that the app's main logic was always active, even when the GUI was not in the foreground, and even when the device was asleep.
2. The external server communicated with the app via GCM ("Google Cloud Messaging"). This ensured that "push" requests could be sent to the app, and that the app would always respond to them ... again, even when the GUI was not in the foreground and even when the device was asleep.
3. The app sent information to the external server via simple HTTP (or HTTPS) requests. These requests were initiated from within the Service, and they were managed on separate threads.
The end result of this is that the app worked no matter what the state of the GUI was (foreground, background, etc.) and what the state of the device was (awake, asleep, etc.).
Again, I'm well aware that you you folks might already be doing something like this in your implementation of AirDroid, or you might already have tried and abandoned this approach. But just in case you haven't tried this, I want to bring it to your attention.
PS: This worked irrespective of whether the Android device was using a WiFi connection or a cell-phone connection.
Please don't take this as condescending or in any kind of negative light. It's possible that you have already tried (or are already doing) what I am about to suggest, and it just doesn't work. However, I still want to put this out to you, in case it might be helpful. If not, PLEASE don't take this in the wrong way, and feel free to throw my entire suggestion into the "bit bucket".
Last year, I worked on an app which provided a small subset of the functionality that you are offering with AirDroid. It also had to remain alive and in two-way communication with an external server, even when the app was not in the foreground, and even when the Android device was asleep. I was able to successfully get this to work as follows:
1. I made the main functionality of the app run inside of a Service. The user interaction was done through a GUI which simply interacted with this service. The advantage of this approach is that the app's main logic was always active, even when the GUI was not in the foreground, and even when the device was asleep.
2. The external server communicated with the app via GCM ("Google Cloud Messaging"). This ensured that "push" requests could be sent to the app, and that the app would always respond to them ... again, even when the GUI was not in the foreground and even when the device was asleep.
3. The app sent information to the external server via simple HTTP (or HTTPS) requests. These requests were initiated from within the Service, and they were managed on separate threads.
The end result of this is that the app worked no matter what the state of the GUI was (foreground, background, etc.) and what the state of the device was (awake, asleep, etc.).
Again, I'm well aware that you you folks might already be doing something like this in your implementation of AirDroid, or you might already have tried and abandoned this approach. But just in case you haven't tried this, I want to bring it to your attention.
PS: This worked irrespective of whether the Android device was using a WiFi connection or a cell-phone connection.