search

traccar / traccar-client-android

Traccar Client for Android
https://www.traccar.org/client
Apache License 2.0
661 stars 732 forks source link

Backwards compatibility broken? #144

Open tacman opened 9 years ago

tacman commented 9 years ago

It looks like a new version of Traccar has been released. Since we use our own server rather than the Traccar server, this is quite an issue for us. First, all our clients received a message saying to change their port. Since we're specifically listening on different ports of different clients, this is NOT something we want our clients to do.

It appears that points are now being pushed (via a GET request) to the endpoint, and being re-submitted unless the app receives a 200 response. Of course, we're completely unprepared for this.

Is there any documentation describing these new changes and what needs to be done if you're using a custom server? Is there any setting to simply go back to the old way?

manmet commented 9 years ago

Unfortunately I am also pushed to migrate away from this branch of traccar. The previous $TRCCR protocol was lightweight and stable. The previous Traccar was very well done, of course, with improvement possibilities. Upgrading the traccar client, i did not expect that the previous protocol would be completely dropped. Unfortunately the new GET approach generates 3-4 times more traffic and uses more battery power that is not acceptable for me. Is there a place were to download the older compiled version of Android apk? Or could you specify the stable revision of the version with previous data protocol?

tananaev commented 9 years ago

I can understand the frustration, but I have mentioned many times that I plan to change communication protocol. There was no way to keep the old protocol because the app was re-written for the most part.

As for traffic, it does generate more traffic, but I don't expect it to be more than 2 times comparing to the original one. Do you have any evidence to support 3-4 times increase?

As for power usage, it should improve with the new version as it doesn't use wake lock as much as the old version.

I will provide an old version later for those who want to stick to it. Alternatively you can compile it from the source code using the version tag: https://github.com/tananaev/traccar-client-android/releases/tag/v3.2

tananaev commented 9 years ago

Here is an old version (3.2): https://www.dropbox.com/s/g6sboncs72vtw6a/traccar-client-3.2-release.apk?dl=0

Traccar server will continue to support old protocol, so you can keep using it as long as you want, but I would strongly recommend to move to the new release as it has many improvements (especially around buffering data and power usage). For more info on the new release you can read following blog post: https://www.traccar.org/blog/traccar-client-3-3-for-android/

manmet commented 9 years ago

Thank you very much Tananaev for overall a very nice product! Sorry, I was wrong the data increase in the new protocol is indeed more like 2 (not 3-4) times larger. But note that in low GSM signal conditions due to packet drops several incomplete resends are happening each time drawing the battery. In my previous general tests conclusion was to avoid the html request approach favoring to data transfer via direct TCP socket: because of application stability and energy consumption reasons of Android devices. The most energy consuming is mobile data transfer not data processing. My suggestion would be to make TRACCAR with 2 protocols (or more if counting extended) as 2 separate apps. I have no experience myself in Android programming but I believe thanks to your great product I will learn it. Thank you!

tananaev commented 9 years ago

The old protocol was the source of many problem. That was the main reason for switching to the new one.

If you want to use the old one, you can install the APK file I provided above.

redge76 commented 9 years ago

One possible improvement would be to decouple the "thread" storing the data in the DB and the "tread" sending the data (not really thread... but one call the other) so that you can send your data every 5 minutes even if you collect the position every minute. The improvement would be event better if you use HTTP pipelining. http://mttkay.github.io/blog/2013/03/02/herding-http-requests-or-why-your-keep-alive-connection-may-be-dead/ Looking at this page, it looks like you could use HEAD instead of GET.

tananaev commented 9 years ago

Some people want real-time updates, so I don't think it's a good idea to decouple location updates and sending data.

As for HEAD, I don't see any difference. Server side doesn't send any payload data anyway.

redge76 commented 9 years ago

Some people want real-time updates

Of Course this should be optional.... But if people want high resolution but don't really care of real time, this may be a good way to save some data quota and battery life.

Server side doesn't send any payload data anyway.

Ha OK. I saw the following line in sendRequest(). but did not check server code... while (inputStream.read() != -1);

tananaev commented 9 years ago

I would prefer to keep the logic simple. Also, what is the benefit of batching reports? I don't think it will save much battery life.