The application will select a random latitude and longitude to create a point which the user must find.
The user's distance from the point will be displayed using a "hot-cold meter", which will change color depending on the distance. This meter must constantly update, which would require that I constantly retrieve the user's location. I would also need to use kCLLocationAccuracyBest. However, this sounds like it would use up a lot of battery.
Can I do anything to save battery?
From the official documentation
Gathering location data is a power-intensive operation. It involves powering up the onboard radios and querying the available cell towers, Wi-Fi hotspots, or GPS satellites, which can take several seconds. Leaving the standard location service running for extended periods can drain the device’s battery. (The significant-change location service drastically reduces battery drain by monitoring only cell tower changes, but the service works only on devices with cellular radios.) For most apps, it is usually sufficient to establish an initial position fix and then acquire updates only periodically after that. If you are sure you need regular position updates, you should use the significant-change location service where you can; otherwise, you should configure the parameters of the standard location service in a way that minimizes its impact on battery life.
http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html
PS: On the same link there's a section at the bottom of the page with other tips too :)
My iphone app runs 8 hours of recording fixes evey second on iphone4. The display needs much more power. Dont worry. Measure how long you can record. Then claim, not before.
Related
I am new to development using GPS so any help will be most appreciated.
Project:- I am attempting to locate gps tracking hardware for a student project to locate animals.
I do not want to use cell phone SMS or yearly subscriptions packages as this is not practical where there a number of animals to be tracked. A solar powered device would be a bonus?
My understanding is the following will be required:
A GPS receiver (to get the gps location from satelites) - result is a 'navigation message'. This hardware device would be on the animal.
A transmitter with an antenna which will listen out for radio waves on set frequencies from the receivers, amplify them and its tuner will filter based on a particular frequency.
The 'navigation message' (or number of navigation messages) would be held on the the transmitter.
I am not sure if I can get an appropriate hardware transceiver with both the receiver and transmitter in 1 that can be attached to the animal?
The data would then to be sent over the internet from the transmitter to a web server via a HTTP request and parsed to be stored on the database.
A phone app / web app could then query the database to identify where the animal is at its last stored location or analyse data to determine its route over time when required.
If you have any advice / suggestions on the process above or advice on types of hardware / location of hardware to complete this project I would really appreciate it.
Polly, here are a few commercial solutions for GPS Animal Tracking. Some are rather expensive, but at least this shows what is out there professionally.
I think one of your primary issues here is battery power, size, and weight. GPS receivers use a fair bit of power when on, so it would have to be "off" but for a few seconds every-so-often, the rate determining how long the batteries will last. Solar recharging is an idea, but is that compatible with these particular animals?
If you wanted to construct something like this, there are a vast array of GPS modules to start with, depending on how integrated and customized you want to get with the idea. But these are receivers only - they will not broadcast anything. To get the GPS data remotely, you're going to need both a way to store the GPS data, and a transmitter (your #3) to send it to you. Since the transmitters would be small and low-power, this will limit the range you can receive them from. Not impossible, just a little more challenging.
Is a web developer available that can write that web and database code?
Is a phone developer available for the phone app?
Here are some interesting articles from others that have DIY their own low-budget trackers. I hope this gives you some ideas.
I am implementing a GeoFence related functionality where the app notifies when user enter / exit into certain location. Here my problem is, when I am using Location manager services it is taking using battery. Can anyone suggest me on how to get the current location updates using GPRS.
Or suggest me a better way.
Thanks.
Set the desiredAccuracy to 3000 and you can get a location using WiFi or cell tower triangulation only. That will reduce battery usage significantly by turning off the GPS.
I am new in android and wanna get user current location using GPS_PROVIDER, but every time getting different-different location how can I use Google Play Services. and what is the best way to get accurate location in android.
Thanks you.
In general there are two different types of locations available through the Android API.
One is the GPS-Location which only works outdoors and which has an accuaracy between 5m and 50m.
The other kind of location is the so called Network-Location which is a loaction measure based on Wifi Networks in you surrounding and GSM-Base-Stations which have a accuracy between 100m and 1500m. This localization technique also works indoors, because it only requires you smartphone to have network access. The accuaracy gets better in urban areas where a lot of Wifi and GSM-Base-Stations are located. The more GSM-Base-Station / Wifi hotspos are available the better is the accurarcy of the loation measurement. It can also get down to 5m.
When requesting such an location Google does internally some magic to compute the position. This request requires a internet connection (you don't need to explicitly give the permission). Interanally Android sends a request to a Google server which contains fingerprints of the surrounding GSM-Base-Stations and afterwards computes your location (if you are curious you can find the code here).
With GPS-bases location the location accurarcy is the same all over the world without any internet connection, but works only outdoors.
With my applications I implemented a logic which detects if GPS is present or not and if not I switched to network localization, this works fine.
The number of questions on SO related to iBeacon and its background capabilities is increasing and there is some confusion on that point.
I have been testing the AirLocate project.
iBeacon has 2 "capabilities": Region monitoring and Ranging.
Region monitoring is limited to 20 regions and can function in the background (of the listening device) and has different delegates to notify listening app (and user) of entry/exit in the region - even if app is in the background or phone is locked.
Ranging works only in the foreground but will return (to the listening device) an array (unlimited?) of all iBeacons found along with their properties (UUID, etc..)
In addition, that 20 regions monitoring is a device limit. If the user is using geofencing reminders, other apps that use region monitoring; this will lower that number.
So are we saying that I can not deploy a mall-wide (100 stores+) app that uses store iBeacons to send a "store specific" notification to the user, while the app is in the background or the phone is locked?
I gather that the advertising device (the beacon) has to be in the foreground as well to advertise a region that the listening device could "enter" into. So are we saying, that if the owner of a store had an iOS device; I could not for example save him money by asking him to use his iPhone (at least early on) as an advertising device (beacon) - since the app will likely not always be in the foreground?
So in the case of iBeacon + MLB, a single UUID (or <20 UUIDs) is/are used for the app to possibly determine entry door and, then will the user be required to unlock the phone/bring the app to the foreground to use it (find seat, etc..)?
Can I then call the iBeacon: a single location/event (store, park, etc..) feature that requires the user's most "foreground" attention to have a "complete" practical use case?
I have tried to be articulate about the user cases to bring it to practical. Please reply with more than yes or no.
Sounds like you are on the right track. In general you are correct that an app needs to be in the foreground to fully use iBeacon capabilities. A few specifics on your three main questions:
Your mall use case can work with a couple of limitations. (a) you have to conserve your CLBeaconRegions by having many or all 100 stores share the same UUID and/or major number, differing only in the minor number. This allows you to set up a single CLBeaconRegion to monitor many. (b) If the app wakes up into the background from seeing iBeacon 1, it won't be able to wake up a second time from seeing iBeacon 2 in the same CLBeaconRegion unless it first stops seeing any other beacon in that CLBeaconRegion. (You can game this a bit by setting up several CLBeaconRegions and trying group stores so adjacent ones in the overlapping 50 meter bluetooth radio range are in different CLBeaconRegions.)
No, a store owner cannot use their iPad act as an iBeacon in the background -- it has to be in the foreground to work. But they can have their Windows or Mac computer do this using a virtual iBeacon program. My company offers one for free download: http://developer.radiusnetworks.com/ibeacon/
In the door entry use case, yes, the user would have to acknowledge the notification on the lock screen to bring the app into the foreground. A typical implementation would use a single CLBeaconRegion (probably with all iBeacons sharing a ProximityUUID and maybe even a major) to alert the user.
Edit 4/11/2020: Apple announced plans for a new beacon advertisement that will work in the background. See here for more info.
I have a live tile working which updates how many users are online and how many lobbies are open within the app. This begins updating when my app loses its visibility (no point it updating the live tile whilst the app is running), but I want it to update when I first turn the computer on.
I have had a look around and mentions of making the app a lock screen app have popped up but that is all, no explanation how to do it.
Does anyone know how to do this and provide a nice little explanation or link of how to do so?
Many thanks,
Kevin
You should use push notifications for this kind of behaviour. This msdn link has more info:-
Using tile notifications
Choosing the right notification method to update your tile
There are several mechanisms which can be used to update a live tile:
Local API calls
One-time scheduled notifications, using local content
Push notifications, sent from a cloud server
Periodic notifications, which pull information from a cloud server at a fixed time interval
The choice of which mechanism to use largely depends on the content you want to show and how frequently that content should be updated. The majority of apps will probably use a local API call to update the tile when the app is launched or the state changes within the app. This makes sure that the tile is up-to-date when it launches and exits. The choice of using local, push, scheduled, or polling notifications, alone or in some combination, completely depends upon the app. For example, a game can use local API calls to update the tile when a new high score is reached by the player. At the same time, that same game app could use push notifications to send that same user new high scores achieved by their friends.
You're right with the assumption that you require a lock screen capability to be able to run background tasks without your app being started once. The main process would be to extract the part of your application that gets the data into a background task that is probably triggered by a timer and write some code to be on the lock screen.
When I first encountered that restriction I was kind of surprised, but in terms of battery performance this design decision makes sense: Only consume battery power if the data is absolutely worth it. If it's worth, it is also of interest having it on the lock screen.
On MSDN is a good overview about lock screen along with further reading links. It's much better than what I could type in here. Come back with problems related the implementation (which actually even better fits the purpose of SO). This blog might be useful, too.