[APP][2.2+] Backitude - General info and discussion
- Thread starter backitude
- Start date
I haven't gotten your beautiful tracks...I'm hoping to duplicate though. Did you have wifi on or off? When I let Backitude poll the gps every 5 minutes with wifi off, I get a rediculous map of me bouncing back and forth between my house and a school over 2 miles a way. If I turn on wifi it works a little better. But I can't seem to find a way to force Google+ to only update my location with GPS, it still seems to use cell triangulation which is miles off even when I leave GPS running 100 percent of the time. Do you ever experience this?
Sent from my GT-N5110 using Tapatalk 2
Sent from my GT-N5110 using Tapatalk 2
As a long time user of Latitude, and a HUGE fan of Backitude, I just wanted to throw my "me too" in as well.
I'd really, really like to see Backitude have the ability to make a custom URL call. I'm tinkering with tasker and custom apps, etc, and I know in the long term it'd be best to pair with a service. However, there are numerous very technical users such as myself that may get creative for personal or other use. The ability to call a custom url with the location info would give us the tools we need to make things work.The beauty of Backitude is in it's lightweight ability to make these calls, save batt life, etc. I'd hate to have to reinvent that wheel, but the rest is easier...
I'd really, really like to see Backitude have the ability to make a custom URL call. I'm tinkering with tasker and custom apps, etc, and I know in the long term it'd be best to pair with a service. However, there are numerous very technical users such as myself that may get creative for personal or other use. The ability to call a custom url with the location info would give us the tools we need to make things work.The beauty of Backitude is in it's lightweight ability to make these calls, save batt life, etc. I'd hate to have to reinvent that wheel, but the rest is easier...
Just realized the recent Maps update turned on Location Reporting from my tablets at home, so my history shows me bouncing back home every minute. Ruined two weeks of history. Just a warning to anyone who might find themselves in a similar situation.
When I turn off location reporting from my tablets, it turns it off on my phone also. Must be some sort of bug I guess.
Sent from my GT-N5110 using Tapatalk 2
When I turn off location reporting from my tablets, it turns it off on my phone also. Must be some sort of bug I guess.
Sent from my GT-N5110 using Tapatalk 2
I conducted a series of tests by updating Google Maps to the latest version, updating Google+, turning on location reporting for my Google account, and prevented Backitude from syncing with Google. (by enabling Data Saver mode and sync'ing only with Wifi which I am not currently connected to)
I ran Backitude every 15 seconds with GPS while I watched my location on Google Maps and watched my public location on Google+. Google+ location started miles away, from a cell tower location I imagine, and updated finally about 20minutes into my walk, and then updated again sometime later when I got home a half hour later.
In conclusion, Google+ locations currently seems to suck. Granted, there has not yet been an update since it's original release. Perhaps an update will bring about basic features and improvements. Until then, Google Maps is rolled back, and Google+ is uninstalled.
Time to start focusing on changes to Backitude.
I ran Backitude every 15 seconds with GPS while I watched my location on Google Maps and watched my public location on Google+. Google+ location started miles away, from a cell tower location I imagine, and updated finally about 20minutes into my walk, and then updated again sometime later when I got home a half hour later.
In conclusion, Google+ locations currently seems to suck. Granted, there has not yet been an update since it's original release. Perhaps an update will bring about basic features and improvements. Until then, Google Maps is rolled back, and Google+ is uninstalled.
Time to start focusing on changes to Backitude.
I have it calling a URL now (in test).. but I am trying to work out the details. Should each request just send one location like it worked for Latitude, or should it create a KML and send the whole thing. I'm tentative on the kml because there are so many syntax variations from system to system, it might be easier for you server developers to get the data and create your own in the format you'd like.
Just trying to get SOMETHING working as quick as people to hold onto some users.
Send SMS back from Push update was easy.
KML export will be tonight, but i need to figure out how this will all work together. We have locations being sent to users, being sent to URLs, exported to KML... when are they cleaned up from the local app data? That kind of thing.
Eventually, google drive and dropbox for exporting the kmls.
I wish I had another couple weeks, but maybe users will come back.
It's a great app with a very dedicated developer, the users who have used your app know this so even if they leave for a while, I'm pretty sure they'll be back in a short time.
Thanks for your continued support!
Sent from my GT-I9100 using Tapatalk 4
Thanks for your continued support!
Sent from my GT-I9100 using Tapatalk 4
I think it's safe to say that most of your users are using Backitude because they wanted much better than the norm - and that's what you've always delivered. They'll stick around - it's always rocked, it will again. People know this, and hopefully everyone on this thread will contribute with more great ratings.
The SMS is a great stopgap, and I think the basic user will make easy use of it.
As far as the URLs go, I think the dropbox/etc for kmls makes the most sense down the road. I think the URL call should probably just be current location as it was - short and sweet. Perhaps, though, you could have two options, enabled independently if they desired. It seems like the kml should be phase two, giving a little time to work out the logistics? Things like current location url, sms, etc are pretty cut and dried event-wise, I would guess.
EDIT:
So when passing the querystring args of the url, I assume lat/long, and also a timestamp of the location data? And perhaps just several GETs in a row if sending stored-up historical stuff?
I suppose you've given this a lot more thought, but is there a unique device or phone identifier that's easy to include? If the URL is freeform, I guess it's easy to add your own random string and use https .. just need an easy and secure way to correlate users (and also correlate the same user over multiple device).
Last edited:
Don't use GETs to send data that will change things, do POST that data if at all possible. You don't have to form encode it, but you should at least be using the right verb.
It is ok to use multiple POSTs (or if you want to be fancy PUTs) in a row to push historical data.
Almost ready to test a beta APK for posting location to a URL and SMS ping back.
Who has a server ready to accept posts and would like to try this debug beta version? Email me, backitude@gmail.com
Instead of a random unique identifier, I'll just include a text box field for you to configure your own ID /name for the instance on the device.
Thanks,
Who has a server ready to accept posts and would like to try this debug beta version? Email me, backitude@gmail.com
Instead of a random unique identifier, I'll just include a text box field for you to configure your own ID /name for the instance on the device.
Thanks,
Not sure you have decided on any option regards to cleanup options, but my view on that matter is the following : KML export schedule can be scheduled on a once a day, a week etc ... After pushed to the server if the responde is a success the exported file(s) is(are) automatically deleted from the local app data. In case of failure, (e.g. no connection) you might have a parameter to define a sliding window of the number of file to keep before deleting. If user indicate 10 files, only last 10 files are kept. If failure the oldest (11th) is deleted (round robin approach).
Just a thought
Gimli
Feedback to beta version
Hi Brian
thanks for all the work! The last beta is really impressive.
Here are a couple of suggestions:
Kind regards
Michael
@all beta testers: Please delete the default custom server settings in the beta version. Otherwise you would be uploading your data on my server (which you probably don't want
)
Hi Brian
thanks for all the work! The last beta is really impressive.
Here are a couple of suggestions:
- We need a method to upload offline data. I think, there are three possibilities to do this:
- Upload single points multiple times. So, if 5 offline points are taken, just upload 5 times a single point. Should work as it is now.
- Upload all points in one upload: You could use an array POST for this ("latitude[0]=xxxx", "latitude[1]=xxxx", etc.). Should be very simple and I think you could upload up to 100 points in one upload. This would be very easy both on client and server side.
- Or upload all offline data in a kml file (instead of manually exporting this). The kml file would need to be parsed on the server. More work, but possible for sure.
- Backitude should act differently depending if the upload was successful or not. There would need to be two checks:
- Check 1 checks the return status of the httpclient call. If there is an error the server could not be contacted (maybe no internet, maybe the server is down, etc.) In this case we have got offline data instead...
- Check 2 checks the response from the server. There should be one (possibly configurable) success response, in which case backitude knows that the upload was successful. In all other cases, it should mark the upload as failed (=> offline data) and show the response in the error history.
The response might be read with the following code (I'm not an android programmer, so don't know if that is correct):
Then backitude would know if there is an error or the uploaded data was successfully stored. One error example could be "ERROR: wrong password" or "ERROR: user unknown". The configurable success message could be simply e.g. "SUCCESS".Code:ByteArrayOutputStream outstream = new ByteArrayOutputStream(); response.getEntity().writeTo(outstream); byte [] responseBody = outstream.toByteArray();
Kind regards
Michael
@all beta testers: Please delete the default custom server settings in the beta version. Otherwise you would be uploading your data on my server (which you probably don't want
)I have an own site from one.com, does this mean I can use this server for backitude?
Sent from my Nexus 4 using xda app-developers app
Sent from my Nexus 4 using xda app-developers app
Probably yes. I don't know "one", but it seems to be a web hoster. Generally, everybody who has his own web site can also have backitude report to his server. The requierementsare php5 and mysql, which is in most cases included in typical web hostings.
Mind you, the code for the server is not ready yet. I will finish this some time after the final backitude is released. Then everybody can use his own server, if he wants.
Backitude will also be so flexible to work with different server code. So, people who understand a bit of php (or any other server language) can code their own code.
There will be many ways to use backitude, Brian is working on enabling upload of location data to Google drive as well as saving data to local storage. Uploading to a custom server is another option. The latter one allows for several different options :
1) You may have your own server and write your own code (coding knowledge necessary)
2) You have your own server but use code from other people (no coding necessary)
3) Other offer a public service and you use it the same way as before latitude.
1) You may have your own server and write your own code (coding knowledge necessary)
2) You have your own server but use code from other people (no coding necessary)
3) Other offer a public service and you use it the same way as before latitude.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
33Greetings fellow developers and/or Android enthusiasts,
I wanted to take a moment to start a thread on for the Android application (2.2+) Backitude: Configurable Background Location Tracking. I would like a place to discuss the app publicly, discuss troubleshooting solutions, bugs, or motivate ideas and improvements.
Check out the Full version, ad-free available for free in the Android Market/Google Play store:
Download here: Backitude: Configurable Background Location Tracking
EDIT: Google Latitude shutdown their API on Aug 9, 2013 which completely changes the makeup of the application. Its sole purpose was to send locations to Google in order to maintain an accurate and timely history with Latitude. Now, it will be more geared towards keeping its own history and integrating with a number of systems or personal custom servers.
Backitude provides a bundle of extended features and functionality for updating Google Latitude locations from your Android device. If you are a Google Latitude user or once had interest in the concept of Google Latitude, then Backitude is an essential addon. Background gps location updating at your own specified time interval is now within your realm. Backitude expands your updating options, accuracy, and even allows you and your friends to force updates on eachother when needed, all seamlessly behind the scenes.
I created this app about a couple years ago to address two issues: I wanted to fix the short-comings of Google Latitude and make it a plausible application for users to enjoy and utilize effectively and efficiently. Also, I wanted to provide Google Play Store with such functionality free of charge. At the time, no such free application existed.
Google Latitude is somewhat inadequate on its own, but this is of no fault of the Google developers. They designed the application with battery efficiency as a number 1 priority. The conserve battery, Latitude on its own does not update locations in the background using GPS for accurate reporting. Instead it relies on Wi-Fi and cell tower triangulation to determine your location. Since many users refrain from enabling Wi-Fi when not stationary in their own network, or since Wi-Fi cannot be obtained while travelling, the resulting location updates are large, inaccurate "blue circles" on the map. Cycling through your Latitude friends, I mostly would see large, city-wide, inaccurate location readings- like I said, therefore truly defeating the purpose of Latitude. Latitude also fails to give the user any configurable options to location reporting. What good is a location history if majority of the values are city level and inaccurate? Backitude, to the rescue.
Backitude was designed to address all of this and put the power back into the hands of the user. You have complete control what, when, and how to update. Power can be a dangerous thing however. Google chose not to give the user a chance to configure their settings and risk draining batteries and having Android or Google products labelled as "battery drainers." Backitude is for the intelligent user, to know how to manage their battery, know their priorities, and know the effect of such functions. GPS polling is a very battery-intensive maneuver!
The final issue and gap Backitude inspired to bridge is updating a friend's location. It is great to have control over your location updates and allowing your friends to see exactly where you are, but what if they haven't updated recently or exactly when you needed to know their location? Backitude has an answer for that. "Fire an Update on a Friend" is the newest feature which utilizes SMS messaging to receive requests from other Backitude users. If your friend is also using Backitude and has this option enabled, you can send a request to their device which will in turn trigger an update at that very moment.
Additionally, there are many, many more features that all serve to give the user complete control of Latitude updates and battery consumption (in the context of Latitude updating). Thank you for checking it out, and I look forward to supplying any troubleshooting information right here for all to find, and hear ideas and feedback from those other enthusiasts out there.10I conducted a series of tests by updating Google Maps to the latest version, updating Google+, turning on location reporting for my Google account, and prevented Backitude from syncing with Google. (by enabling Data Saver mode and sync'ing only with Wifi which I am not currently connected to)
I ran Backitude every 15 seconds with GPS while I watched my location on Google Maps and watched my public location on Google+. Google+ location started miles away, from a cell tower location I imagine, and updated finally about 20minutes into my walk, and then updated again sometime later when I got home a half hour later.
In conclusion, Google+ locations currently seems to suck. Granted, there has not yet been an update since it's original release. Perhaps an update will bring about basic features and improvements. Until then, Google Maps is rolled back, and Google+ is uninstalled.
Time to start focusing on changes to Backitude.10The future....
Google is removing Google Latitude from the Google Maps android application and creating a new Friend Location system within the Google+ app. You will have to re-friend and re-share your location (permission-wise) within the Google+ application.
I am not yet sure if the API is shutting down entirely, or just retrieving data. Backitude only needs to performs inserts of new locations. It currently works with G+ system so I don't see why they would remove it?
It doesn't look good though.7
I have it calling a URL now (in test).. but I am trying to work out the details. Should each request just send one location like it worked for Latitude, or should it create a KML and send the whole thing. I'm tentative on the kml because there are so many syntax variations from system to system, it might be easier for you server developers to get the data and create your own in the format you'd like.
Just trying to get SOMETHING working as quick as people to hold onto some users.
Send SMS back from Push update was easy.
KML export will be tonight, but i need to figure out how this will all work together. We have locations being sent to users, being sent to URLs, exported to KML... when are they cleaned up from the local app data? That kind of thing.
Eventually, google drive and dropbox for exporting the kmls.
I wish I had another couple weeks, but maybe users will come back.6
I have about 10 minor bugs / enhancements to bang out before I'll release, but I don't think it'll be too long. It's been a lot more work than originally foretasted because the app wasn't exactly designed for this purpose from the beginning so I'm trying re-focus the functions, rather than mash it into what we have.
