Apps General Http Connection Discussion (not about codes)

[ac4android]

I am not sure I have chosen the right way to do it.

Assume the user has a data plan, his personal "hotspot", on the smartphone.

For example if I use .PHP to _POST data every 30 seconds on the server, and use java.net.URL and java.net.Connection on the Android end, whether it would be better to keep the connection alive on Android and keep the loop running until the user shuts down the app OR re-connect in however many seconds.

On the server side, it executes a .PHP, grabs the values from the URL and insert them into the database.

Since we are using 4G LTE, and we have only 4 to 5 variables in the URL-string, it shouldn't be a problem (P.S. I am using T-Mobile).

But what if the user does not have a data plan or has just exhausted his 7GB data plan? Than he would rely on the relatively slow 4G LTE.

Also keeping the connection open might be an issue in a production environment with a heavy traffic, especially since the user is driving.

I am assuming the user plugs his smartphone into the charger in the car. The battery wouldn't last 2 hours.

Any thoughts and practical experience you might want to share?

 

[Deleted User]

Is your app transferring data every 30 seconds? If it uses a lot of bandwidth, users won't be happy about it chewing up their data allowance.

 

[HeavensSentSword]

Are you tracking the user? You could look at the Google maps api and see how often they send the information about location. But I thinking depending on what you need from the user, sending data that often you should only sent maybe a few numbers nothing over 2-4 kb like a push notification.

 

[ac4android]

At the moment, I am looking at using both GPS_PROVIDER and and NETWORK_PROVIDER and found some very interesting facts:
NETWORK_PROVIDER thru cellular phones is hardcoded in Android SDK to refresh every 45 seconds, that means this piece of code will not generate an error, but will not work as intended either:

locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER,1000,10, locationListener);
locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER,1000,10, locationListener);

For better accuracy, use GPS even if it means a much shorter battery life, but I cannot do fancy math averaging both.


And another curious thing, if I get a GPS signal, then technically I have PERMISSION, but no, I have to require permission as well. Otherwise A/S 2.1.2 will give you a warning, but the app will run happily.

I check for gps availability, like this:

boolean gps_on = locationManager.isProviderEnabled(LocationManager.GPS_PROVIDER);
if ( gps_on) {
// TODO
}

I still have to check for PERMISSION after requesting it in AndroidManifest, like this:

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"></uses-permission>

One would assume that if I can get GPS, I can use it. No?


P.S. Apparently only for SDK versions >= 23, then require permission in code, else no.

 

[ac4android]

Is your app transferring data every 30 seconds? If it uses a lot of bandwidth, users won't be happy about it chewing up their data allowance.

Not to mention batery life

 

[ac4android]

Are you tracking the user? You could look at the Google maps api and see how often they send the information about location. But I thinking depending on what you need from the user, sending data that often you should only sent maybe a few numbers nothing over 2-4 kb like a push notification.

Yeah, you hit the nail on the head, just sending 3-4 variables in the URL link, notably latitude and longitude. the grunt work is done by .php and sql on the server.

 

[HeavensSentSword]

You could just do a simple post to your server. Its small and won't take up much processing power and bandwidth. you can try okhttp but I used the standard httppost methods built into android.

 

[ac4android]

You could just do a simple post to your server. Its small and won't take up much processing power and bandwidth. you can try okhttp but I used the standard httppost methods built into android.

It's a bit more than that.

I'll start a new thread.