More Core Location [5] – obtaining compass heading data

…continuing on from the last post, I present you the final instalment of extra notes to my video2brain video training “iPhone and iOS Application Development Workshop” (see course contents): This time I’m going to cover how you can access compass data…

Obtaining Heading information from a device’s compass

If your user’s device has a compass then you’ll also be able to obtain heading data and determine the direction in which their device is pointing. This will work independent of whether or not your App has Core Location Services running and active.

If Core Location Services are active and accessible for your App (i.e. the user has granted your App permission to access their location) then you’ll receive both magnetic headings and true headings data – with the true heading having being calculated based upon the device’s location and taking magnetic declination (sometimes called magnetic variation) into account!

Without Core Location Services running for your App you’ll only receive magnetic heading data, making headings used by your App less accurate.

Adding heading information to your App is simply a matter of setting up and initialising your Location Manager to receive heading updates:

The code below shows compass support added to the myLocation App including the required delegate method, used to receive updates to heading data:

When accessing a device’s compass for the first time, a calibration display will be shown:

To remove this display from the screen after a short amount of time, allowing you to maintain the integrity of your visual design, use the CLLocationManager dismissHeadingCalibrationDisplay method.

An important thing to note when using headings data is that you MUST check for device support using the headingAvailable method of CLLocationManager. If the device does not have a compass and you start monitoring for heading-related updates, your delegate methods will receive no events at all.

Also, if your App stops running, all heading-related updates will also stop. You will then need to start receiving updates again upon restart of your App. If your App continues to run in the background, updates will be suspended and then resumed automatically once your App is awakened. This is an important difference in the treatment of heading data updates from location data updates.

Developing location-aware Apps – over to you!

You’ve now seen how to implement location-based features in your Apps and also learned more about the important issues of battery life. There are practically limitless opportunities out there for good location-aware Apps and the very nature of mobile devices such as iPhones (and iPads) makes this type of App not only a logical, but also an often very practical, choice.

The only limit to what you can do with a user’s location and heading information lies in how we choose to use it. Combined with other device capabilities, we have powerful tools at our disposal for the creation of exciting and entertaining Apps!

 

tags: , , , , , ,

More Core Location [4] – accuracy & power-saving

…continuing on from the last post, the fourth of five extra notes to my video2brain video training “iPhone and iOS Application Development Workshop” will cover accuracy and distance filters – with reference to the “myLocation” App developed as part of the course (see course contents):

Accuracy

As already stated in my last post in this series, this is one area where you can provide your users with a “power-saving” option or by default ensure that battery drain is lower for your App than for others.

If we take a look at the init method of our CoreLocationController Class for myLocation, we can limit the amount of updates we’ll receive and hence the reported accuracy by implementing a desired accuracy:

Using a desired accuracy of

kCLLocationAccuracyKilometer

will result in the user’s device attempting to achieve a level of accuracy to within 1 kilometer. If an even lower level of accuracy is acceptable we can choose

kCLLocationAccuracyThreeKilometers

instead. For the highest level of accuracy possible within the limitations of the device being used, we’ll choose

kCLLocationAccuracyBestForNavigation

All possible options for desiredAccuracy are:

kCLLocationAccuracyBestForNavigation

– Uses the highest possible level of accuracy available, augmented by additional sensor data. This accuracy level should be used only when the device is connected to an external power supply as power drain will be high.

kCLLocationAccuracyBest

– The highest level of accuracy for devices running on battery power. Power drain will, however, be high and you should provide a “power-saving” option if possible.

kCLLocationAccuracyNearestTenMeters

- Accurate to within 10 meters.

kCLLocationAccuracyNearestHundredMeters

– Accurate to within 100 meters.

kCLLocationAccuracyKilometer

– Accurate to within one kilometer.

kCLLocationAccuracyThreeKilometers

– Accurate to within three kilometers.

Distance filters

Distance filters provide another means for reducing power consumption. A distance filter does not define the accuracy of location data but rather defines when an update will be triggered. For this reason, it makes a great deal of sense to use distance filters to limit the number of updates your App will receive.

The following code shows a distance filter defined for the init method of our CoreLocationController Class for myLocation

The result of adding this filter is that the myLocation App will report new location data updates every time the device is moved 1000m or more, to within an accuracy of 1000m, or 1 kilometer.

You can specify any distance in meters for a distance filter. The default value for distance filters is none –

kCLDistanceFilterNone

With a combination of desiredAccuracy and distanceFilter, it’s possible to create a location-aware App with various power consumption schemes and levels of reported location accuracy. Giving your users the choice between high accuracy with high battery drain OR lower accuracy (but still usable) with lower battery drain may well help your App to stand out from other competitive Apps!

Note: These notes were compiled at the time of production of the “iPhone and iOS Application Development Workshop” course and there have since been some exciting updates to the Core Location API. Watch this space for some more iOS 5 updates – coming soon!

If you haven’t seen the course yet, then you have no excuse NOT to buy it now – you can currently buy it for 20% off using the Special discount code: IOSD20 = £17.59 – that’s 3 hours 45 minutes of video training (a lot of coding!) for less than a pizza and a beer! Here’s the link:

https://partner.video2brain.com/robertturrall/courses.htm#/?c=1183&t=1

Meanwhile, the final part of these extra notes will be released in a few days’ time… Watch this space.

 

tags: , , , , , ,

Big news: 20% off my iOS and iPhone Dev Workshop!

Still not checked out my “iPhone and iOS Application Development Workshop” video training?

Now you’ve got no excuse as I’ve organised a special 20% discount offer for all readers of my blog!

Keep reading for the special discount code…

If you’re an iOS developer and want to learn how to take advantage of ANY of the following advanced APIs or device features, then the video training is for you:

  • - Core Location and Map Kit
  • - AddressBook
  • - Event Kit
  • - Camera and Media libraries (including the Assets Library)
  • - Email and Messaging
  • - an introduction to Universal Apps

This 3hr 45m on-demand course was released in July this year and has been very popular – not least because the contents are still totally applicable following the release of iOS 5!

Give yourself a pre-Christmas treat and purchase the course online from my video courses link above or using the following link:

https://partner.video2brain.com/robertturrall/courses.htm#/?c=1183&t=1

Don’t forget to enter the special discount code during checkout to get 20% off!

Special discount code: IOSD20

Enjoy!!

 

tags: , , , , ,

More Core Location [3] – monitoring & updates

…continuing on from the last post, the third of five extra notes to my video2brain video training “iPhone and iOS Application Development Workshop” will cover location change monitoring and updates in a little more detail:

Receiving Location Updates

Now you’ve made sure that Core Location Services are enabled, device support for your update scheme is present and your user has granted permission. Now just how much of that location data do you need, and when?

Do you need to deliver a constant stream of up-to-date and accurate location data or is it enough to simply detect a change in the user’s location every kilometer or so. Equally, you may not need to constantly receive updates and it may be fine for your App to run in the background and trigger an update only when a user enters a certain region – by using region-based location change monitoring.

Standard monitoring:

In the myLocation example we used standard monitoring to receive location updates. Standard monitoring is the most logical and suitable choice for Apps which are intended to be used actively while tracking location, as opposed to Apps which will run in the background and serve to provide some form of location-based alert. Examples of such Apps are route navigation and interactive “where am I?” type Apps. These Apps are normally used only for a certain period of time as the potential for battery drain using standard monitoring is high unless settings are used to limit this.

We didn’t specify a desired accuracy or distance filter in myLocation but these are two settings that you certainly would want to set in practice.

Desired accuracy is possibly the most important setting to consider when designing and implementing your App as it’s the setting that will have the most potential impact on power consumption – one of the main issues associated with location-aware Apps.

Distance filters are used to define the amount of distance a device must be moved before a location update is triggered. This will also have an effect on battery life and you should, therefore, ensure that you only trigger updates as you need them.

We’ll take a closer look at settings for accuracy and distance filters in a few moments. First, a few words about region-based monitoring:

Region-based monitoring:

Region-based monitoring is going to be easier on your user’s device batteries and is ideal for implementing location-based reminders or alerts, for example:


– A “geonote” Alert created by the “Geoloqi” App

So, how do you set up your App to monitor for, and react to, region-based location changes?

Once you’ve confirmed that a device can monitor for Region changes your App will need to define Regions to be monitored for and then react to updates from the Location Manager. Add a region to monitor for by creating a CLRegion Object:

(The desired accuracy of 100.0 will ensure that an update is triggered once the device is within 100m of the region. Reduce this for more accuracy)

Then using the CLLocationManager delegate methods didEnterRegion and didExitRegion to start monitoring for entry into, and exit from that region:

You’ll probably want to save a reference to regions being monitored within your App and then display an Alert or information relating to that region, or react to entry into the region in the didEnterRegion method.

One important thing to consider about using region-based monitoring is that your App will receive location updates should your user move into a defined region while the App is not running. This means that you’ll need to be able to react to your App then being restarted or “woken up” by the system and ensure that you have the correct code in place in your App Delegate to then present the required alert to your user (or provide other functionality as required):

Significant location change monitoring:

Significant Location change monitoring is an excellent way to react to changes in location which involve movement from one cell tower to another as, as such, to reduce power consumption and avoid too-frequent updates. Using this update scheme will result in an initial location fix being carried out upon initialization of the Location Manager and then for updates to be delivered only upon a significant location change.

As with region-based monitoring, significant location change monitoring will remain in effect when your App is closed down and may result in your App being restarted. Ensure that you react to these events in your App delegate as required by your App’s design:

Making the right choice

With the various location update schemes available, it’s important to consider which type of updates your App will need.

Another important point to remember is that you’ll increase your chances of having happy App users if you describe how your App uses location data in your App Store description – and address any concerns users may have about the amount of battery drain they may experience when using your App:

If possible, provide a means for your App users to choose a less intensive “power-saving” option and use this as an important selling point for your App. Battery life is always a potential point of contention with location-aware Apps and making a feature of your power-saving functionality may well be a deal-clincher for more hesitant buyers.

Note: These notes were compiled at the time of production of the “iPhone and iOS Application Development Workshop” course and there have since been some exciting updates to the Core Location API. Watch this space for some more iOS 5 updates – coming soon!

If you haven’t seen the course yet, then take the opportunity to purchase it today for only £21.99 – that’s 3 hours 45 minutes of video training (a lot of coding!) for next to nothing. Here’s the link:

https://partner.video2brain.com/robertturrall/courses.htm#/?c=1183&t=1

Meanwhile, the fourth and then final part of these extra notes will be appearing here in a few days…

Until then, have a good weekend!