Suggestions for fixing the connection problems.

Wed Jan 22, 2014 11:15 am in AirDroid Web

page 1 / 1
HippoMan
OP

Suggestions for fixing the connection problems.

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.
HippoMan
cvika
#1

Title

I knew that Amazon had a cloud messaging service. I didn't know that Google had one too. I suppose it make sense though with how involved they are with mobile technology.
cvika
quail60drain
#2

Title

Yes, Google has that service, and it's intimately integrated with its message processing. Many of their apps (SMS, Chat, etc.) use GCM, and Android is set up to efficiently respond to "push" requests that come through GCM.
quail60drain
LVHAlfons
#3

Title

Hi HippoMan,
Really thank you for your suggestion.

Actually we do implement GCM in AirDroid.

We have been working on the disconnection issue since we knew some of you were experiencing it. Sorry for the inconvenience this have caused for you.

We'll make some improvements on the Front End in future updates. Hope the connection will become more stable for you.
LVHAlfons
quail60drain
#4

Title

Thank you very much. I'm looking forward to the changes!

Suggestions:

1. Save the login ID and the password, so that if the session disconnects, these saved values can be automatically resubmitted without the user having to retype the password. This would allow reconnections to automatically take place without any manual interaction with the user, at all. This could be controlled via a setting, so that those users who don't want automatic re-login on connection failures can still manually enter their password each time they want to re-connect ... although my guess is that most users will want the auto-reconnects to be fully automated.

2. Don't require the Front End to be active, at all, in order for he app to work. Put all the logic in a persistent service, so that even if the phone is asleep or the front end is not active, the connection can be maintained. Only use the Front End to trigger actions that are performed within the persistent service.

Thank you very much for considering these suggestions.
quail60drain
LVHAlfons
#5

Title

Thanks!
I'll show your suggestions to the developers :)

Please feel free to let us know if you have any questions or suggestions.
LVHAlfons
(Sign in or sign up to post a reply.)
page 1 / 1

Statistics

22632 posts

6157 threads

Members: 146282

Latest Member: kb

Online: 12