I'm trying to implement a fast communication between two android phones at a certain moment by, preferably, going through a server (since it's easier to be consistent).
The phones have to communicate their gps locations every x seconds, with x being as low as possible, with only one of the phone having to be on the app, the other can be idle (but obviously not turned off).
The first solution I tried is a syncadapter in the app which updates every x seconds, sends requests to server writing its location in a DB, and then the other retrieves the location in the same DB.
Note : I've implemented it this way only because I already had the underlying architecture (REST API and all) beforehand, but I don't know how to do this in the real world, so feel free to cricize my initial choice and advise me on a better solution
Thank you in advance :) !
You can look at Firebase https://www.firebase.com/ which is a real time database. It does have active listeners in the sdk to get real time updates for your GPS coordinates.
The problem you mentioned can be addressed with
https://github.com/firebase/geofire-java/tree/master/examples/SFVehicles
Related
I have 2 android applications A and B, and both of them are reading gps values based on different parameters. Considering both the apps are running on the device, which of the folllowing approaches would be better?
Both A and B are to be different apps, each one with a component to read from GPS.
To develop a third application with a remote service component to transmit GPS data to both A and B
Would battery usage be minimized by going for the second approach or will the GPS component read once and serve all processes, as in the OS?
Please help
There is a very good explanation given in the Android Developers Website about Location Strategies. I would suggest you to take a look at the code examples on the page.
In both of your approaches i believe second approach is quite better because Turning on/off GPS is a quite expensive operation in terms of battery usage.
GPS’s battery draining behavior is most noticeable during the initial acquisition of the satellite’s navigation message. Acquiring each satellite takes 12 to 30 seconds, but if the full almanac is needed, this can take up to 12 minutes. During all of this, your phone is unable to enter a deep sleep. A-GPS (Assisted GPS) partially solves this, by sending the navigational message to your mobile device over your cellular data network or even Wi-Fi. As the bandwidth of either of these greatly dwarves the 50bps of the GPS satellites, the time spent powering the GPS antenna or avoiding deep sleep is greatly reduced.
Referred from this.
I think the most battery-efficient way would be to poll the GPS location with app A normally, and in app B, use LocationRequests and use setPriority() with PRIORITY_NO_POWER. As mentioned in the docs, PRIORITY_NO_POWER will make app B get updates only when another app gets GPS updates (in this case, app A!!). I haven't tried it, but it should work. It definitely saves you the hassle of an extra app :)
Some more info on Google Play Location Services here and here.
is it the same as OS gPS component will run once to serve all
One GPS serves all.
There is no half GPS saving half the power.
But there are other location providers like cell tower and Wifi locationing which uses less power.
But if you need GPS it is absolutley no difference how many apps uses the GPS service.
If GPS is enabled it uses full power.
For the sake of compatibility and function I would suggest having a third process or program which reads and outputs GPS data, as multiple processes polling data from GPS is less efficient.
It would also be faster to have those two apps read the output of a single GPS tracking app and not needing individual components in each app to do so.
For the sake of power the GPS will use the same level of power regardless, though if it's polled more often due to two applications using it then it may use more - though the amount is likely to be minimal unless there are constant requests for location.
Though this may not be the question it would be most power efficient to have the third application poll GPS at specific intervals and the applications may read from its output rather than search location every time.
Second approach seems to be more appropriate but not sure about battery drainage.It depends upon how you implement it.
Also I would suggest try to use passive providers.Refer following link help it works :)
http://fypandroid.wordpress.com/2011/04/11/298/
I have an app which will take some (internet) action every time the user approaches any one of a set of locations (for example, let's say it notifies a server whenever I am near a Starbucks shop, so my coffee habits can be analysed).
What's the most battery-efficient (yet reliable and relatively accurate) way of causing the phone to do something whenever it's at a certain location? I don't need perfect location accuracy - within 50m or so is fine.
Currently, I set a ProximityAlert for each location with a 100m radius, and have it raise an Intent, which is then served by a Service which runs in the background. The service also includes an Alarm which causes a download every three hours or so.
The Service itself doesn't appear to drain any significant amount of battery - the battery is all drained by "Android OS". According to the Android 4.1.2 Battery monitor, Android OS is using 3x as much CPU as a phone without my app, and has "stay awake" on for most of the time.
Would changing it to an IntentService make a difference?
Would reducing (or increasing) the radius of the alert make a difference?
Would converting it to a Geofence (https://developer.android.com/training/location/geofencing.html) make much difference?
Can I set it to use a cheaper location service unless it thinks it's close to one of the locations (or will it do that automatically?)
I have never worked with the LocationManagers proximity alert functions, so I do not really know how much they drain the battery, but as far I know the new Geofence services (https://developer.android.com/training/location/geofencing.html) were specially designed in a battery-friendly fashion.
LocationManagers pose a very difficult way to program something that you need. Google has reinvented its location providers to fuse them with sensors. Its the latest and best, uses less battery and does magic with your application, by removing all the 1000's of lines of useless code that you need to write between your gps / network providers.
The new api's are LocationClient api's. Watch this video and demo for yourself.
you can use new geo fence api provided by the Google recently,its more power efficient
https://developer.android.com/training/location/geofencing.html
We have an android(or iphone) client we are developing. The client allows the android user to send entries to a server which we also develop. If the client does not have data services (GPRS) at the moment the user sends the entry to the server, the client also supports saving the entry to an offline database and sending it later to the server.
One important aspect of the whole process is accuracy of the timestamps on which the user sent the entry to the server (whether the entry is made in real time or sent by the client from the offline database)
When available on the client, we get a GPS location and are able to use the GPS timestamp to send that to the server (or save the GPS timestamp on the offline DB and send it later to the server). However if the user has turned off the GPS (and all other location services), the device will not have a GPS fix and therefore the server can not determine accurately when an entry was made.
We can not use the local device clock as the user may change the clock to make entries on different times than they actually occurred (these entries are part of the users salary so he might have an interest to "fix" them).
So basically I am searching for a way to determine as best I can the time some entry was made when I can not trust the internal clock of the mobile. The algorithm should support both entries sent in real time or entries sent from an offline DB. the algorithm should also support cases where the user changes the time of the mobile, turns the mobile on/off, turns the GPS on/off while the application is running on the mobile etc...
Few ideas that I thought of:
Although I can not trust the mobile's time, it can still perform as a stop watch:
Have a class that will loop until the application exists, the loop will sleep 1 second and increase an internal clock variable by 1 second. On every GPS location my code gets we update the internal clock variable. This way I have an absolute clock that came from outside the device (from the GPS) and when the client sends an entry to the server, we can use the internal clock as an absolute time.
PROS: the user can not modify this clock as it is only updated when we get a location from the GPS
CONS: the application needs at least one GPS fix before the user can make any reliable entries
I can take advantage of the fact that the server has an accurate clock which is correct. If the client would send to the server info that the age of the entry is 10 minutes, the server could use its internal time and know the exact time the entry was made on.
The biggest problem is how to know the entry age? I thought about saving the entries to the offline DB with an age of 0, then every 1 second increase the age of the entry in the DB. The problem is that if the app is closed and/or the device is off this will now happen
This is where I am currently stuck. Any ideas on how to solve this are more than welcome
Thanks
Here's how I handle this issue for iPhone. When the app starts, I call my server and ask for the current GMT time (you could also call a public NTP server if you preferred). I then compare it to the system time. If it is different by more than X then I popup a message saying, sorry your system time is wrong so you can't use the app until you fix this. I then monitor for the user changing the system time while the app is running and if they do that, then I do the compare again (and popup the error message if the time is off by more than X). This ensures that their system time is always correct (within some reasonable allowance) and you can trust [NSDate date]. However, this solution does require a valid network connection. If this solution works for you, I can post the sample code.
i think i am going to combine Jules and Joel's answers into one solution which will provide for my needs the best solution:
since the user might change the clock when the mobile doed not have GPRS, just detecting the time change event will not help us as we can not validate at that moment the new time is correct.
As Joel recommended i will pull the time from my server when my application is started (at that point i still must have communications with the server or else my application will not start). The time pulled from the server along with the current device upTime will be saved.
when the user wants to make an entry i will calculate the current time using (Server Base Time + Current UpTime - Base UpTime). this way i will have an independent source of time regardless of the current clock of the device
this will defenitly work on android
on iPhone we will try to use something out of http://www.cocoadev.com/index.pl?FindingUptime to get the upTime
Jules & Joel, thanks for your answers!
Look into android.os.SystemClock. Specifically, elapsedRealtime() returns a time since the phone was switched on, which is not affected if the clock is changed by the user.
You can correlate times in event the phone is switched off by having code that runs when it is switched on and checks the realtime clock. As the clock can't be changed when the phone is off, I suspect you could use this to put together a system that will catch any simple attempts at cheating. (If the user roots the phone all bets are off -- they could modify the behaviour of the APIs from under you).
Running code every second will kill the phone's battery life. Most phones would be unlikely to last a day if you did this.
I'd like to know if this is possible on either Android or iPhone:
I would like to have an application run in the background of the phone and send a GPS location to the server every N minutes. As far as I know this is difficult on the iPhone, but can it be done on an Android?
Thinking a bit more on the iPhone - could I create a web service that runs timers for each application and, on timer elapse, push a notification to the phone to start the GPS service and send the location information back to the server? Can I push notifications to an iPhone application in the background?
Thanks!
Re Android: yes, this is also possible, and just as with the iPhone, the less accuracy you need, the faster this will be. It is also asynchronous , so you will need a similar approach. As opposed to the iPhone though, you can start the GPS and wait for location updates in a background service, so that you can send the current location to the server whenever you have it.
Re iPhone: yes, you can push notifications when the app is in the background, but you should know that the location services API is an asynchronous API (having been working on it myself...:)) so you can't time it per se (you can for example "expose" it every N seconds, saving the last location that was provided - so essentially implementing a logic that will make it asynchronous, but with a certain cost to the user experience).
Also note that having location services running in the background is a huge drain of battery. here it really depends on the type of application that you are building. If you dont need high accuracy (say, knowing the city is enough) you could set the accuracy of the API to be large, which wont trigger WiFi and GPS, and will use only cell - less battery drain. If you need really high accuracy (street corner, etc.) this wont be super useful for you.
Adding some more info for your convenience: like I mentioned, accuracy requirement will trigger the different location services, which in return affect batter consumption. In general the accuracy is:
GPS: ~10 meters
WiFi: ~100 meters
Cell: 500 meters (urban canyon environment) to 50Km (in open environment)
Hope that helps.
I am a complete Android programming newbie.
I have completed some tutorial examples like HelloAndroid and the HelloViews/Layouts, but that is about the extent of my Android programming abilities.
I am not the programmer on this project, I am the tester(QA) for a company that is developing an Android application that will track company owned devices every 1 minute, and send the positions back once 5 or so are stored.(Limiting mobile network usage, to conserve battery.) My company bought and pays for the android devices, and the employees are aware they are being tracked, both for safety purposes of the employees as well as accountability. Behind making phone calls and some mild emailing, this is one of the most important functions/uses of our devices.
Our biggest problem is that our application can be killed at any time by the Android OS, for any number of reasons(device resources, etc.) Right now, we have an Android service that checks if our app is running every so often and if not, it starts it back up. Once our app is running it can be in the background and request positions using a service in the app itself, then send them to our server for processing and storage.
From everything I have read about Android Development practices, this does not seem to be the most Android "appropriate" way to do this. From what I can gather, and this is fairly limited, we should have an Android service that runs in the background and requests then sends positions, but even this can be killed without notice from the OS, right?
Any advice or suggestions anyone could provide that would point me in the right direction?
It might be worth mentioning that this will kill everyones battery extremely fast... but you pretty much have it right as far as the best way to do it. If the OS does kill your app in the background, your service can just restart it.
What are your concerns, that the OS will repeatedly kill it and not allow it to do its job?
Or that the GPS locations wont be accurate? Location.getAccuracy() could help you figure out if the location is worth saving
http://developer.android.com/reference/android/location/Location.html