App developers and stakeholders are always on the lookout for bringing more value and context into their apps to reach their target audience and their needs better.

Location-based triggers and features add a tremendous value, bringing in a lot of meaning, depth and sense into the business.

Today’s Location Management Options
Location management needn’t be a simple tracking of user movements along a map, like in your ride sharing apps.

  • Think of selective targeting of users when they cross a particular geological radius (called a geofence) with attractive offers or value added services,
  • Think of accurate push notifications based on which well known geographical point the user is nearby
  • Think of studying the typical geographical routes of users day to day to bring in more context based info and alerts.

And most importantly we want these to be used from the mobile apps without the need for specialized hardware like beacons or extra sensitive GPS.

While these kind of location management can be selectively built for each of the apps you manage, it makes much more sense to think of it as a separate component that can be simply plugged into any app with minimal coding for integration. Don’t you agree?

While iOS and Android have their own in-built components for managing location and triggering events based on changes, as of today, they are quite limited in a number of ways –

  1. Managing custom points of interest and triggering events based on these can be quite tricky involving developers to rely on their backend to supply massive chunk of the support.
  2. While the platforms do support circular geofences, the support for polygonal geofences is not yet present.
  3. iOS core location has a limit of 20 geofences if it is to be monitored exclusively by the app without backed support. For major businesses, this is highly limiting.
  4. There is no integration with geographical points of interests like from Maps or other location providers. Everything needs to be defined manually.
  5. There is no support for a dashboard based management and every new geofence edit needs an app update.
  6. Tracking user location and changes manually using these in-built SDKs can be quite processor-intensive and bug-prone too.

What should a Location Management Solution Do?
When we try and choose a component that helps us with our complicated location needs, we think of out of the box support for

  • Efficient data collection,
  • Reliably storing this data,
  • Finding context based on the data,
  • Analysing usage patterns,
  • Confidently acting on the data

And from an implementation standpoint, we look out for

  • Easy to use SDKs
  • Cross platform support
  • Neat dashboard to configure everything
  • Minimal strain on user’s phone battery
  • Background monitoring
  • Support for triggering multiple type of events – notifications, in-app alerts

And trust us, there are very few platforms that does this all with reasonable flair! (Wink wink, potential billion dollar business idea). In this article, we are going to brief on one such platform we have come across that we think tackles these problems reasonably well – Radar.

Enter RADAR
At its core, Radar is a platform to add location context and tracking in mobile apps. It aims to make a whole lot of location related use cases easier to manage and implement with minimal dev hours spent.

Radar concentrates on

  • Geofences for triggering events if a user enters/exits a custom point of interest,
  • Insights for clustering historical location data for each user enabling one to predict when user is at home or at work, for e.g.
  • Places for triggering events if a user enters a place not specifically included as a custom geofence but is identifiable based on Facebook Places.

Let’s take the case of iOS. While iOS has geofencing enabled in its latest versions, at its heart it relies on the app to define geofences, track them as required and take actions. Compared to this, everything in Radar is managed with an administrative dashboard. So, it becomes easier to define and manage points of interest and rely on the mobile app mostly only for responding to triggers generated from the Radar SDK. It also supports creating geofences from mobile or API if the use case requires the app to handle this. But for most general use cases, separating the management of geofences from app logic is a huuuuuuge bonus.

Other advantages include support for

  • Polygon geofences,
  • Unlimited number of geofences,
  • Integration with Facebook Places,
  • Location category detection with historical data,
  • Cross-platform detection and
  • A lot more ease of use.

In their own words, Radar in short, is a full stack solution with iOS and Android SDKs, an API, a dashboard, webhooks, and integrations.

A Simple Use Case
Consider you are a retail chain with numerous outlets in the country. If the user has your mobile app installed, you can ask for permissions and track his location when the app is in use or is in background. And if the user is near one of your outlets (defined as a custom geofence by you), you can entice him with deals and coupons. While this behavior can be triggered by a custom setup between your app and your backend, Radar makes it so much easier with literally just a few lines of code.

Your app

  • Need not explicitly track location every so often,
  • Need not worry about managing battery consumption while tracking in the background
  • Or numerous checks with your backend for possible matches.

The Radar SDK manages all this silently and your app just needs to respond to events it notifies you of. What we like best is that all geofencing and event generation happens on the server side and so you can concentrate on other fundamental features of your app.

Radar also claims that while used in background, it consumes less than 2% of battery per day. Say whaaaat! 😮 It also doesn’t send location data to the server every minute, it does so only when the user moves about 100 meters or stops in a location for more than a few minutes. Clever, don’t you think?

Radar also boasts of numerous meaningful integrations with external services. Again, in their own words, Radar integrates directly with mParticle, Segment, Appboy, and Yext. Through mParticle and Segment, Radar integrates with hundreds of other platforms, including Amplitude, Mixpanel, and Amazon Redshift. Radar also supports webhooks for custom integrations. Did you read that right? Support for webhooks, aaaand we are sold!

Within a year of its launch, Radar has also grown quite significantly as they claim to be on a million devices and processing billions of location requests.

How Radar Actually Fared When We Implemented It
First things first. Understanding the platform and what it does was very easy. Their documentation is pretty straightforward and you can get everything setup and integrated with your app in a matter of hours. We loved this ease!

We think these will be the simple chronological order of steps for any app integration (with code snippets for iOS)

  1. Sign up for a dev or admin account with Radar (did we say it is free for upto 100,000 monthly tracked users and upto 10,000 geofences even for commercial apps? 😮)
  2. From the dashboard, add a couple of geolocations and give them a radius to qualify as geofences in Test environment.
  3. Pick up your dev key from the Organization section in the Dashboard.
  4. From the app, integrate the Radar SDK using Cocoapods
  5. Initialize Radar with your dev key with a simple line of code. Radar.initialize(publishableKey: EnvironmentVariables.sharedInstance.getRadarKey()) – Here we are storing and picking up the string key from our Environment Variables file. Pro tip – keep all your keys and URLs separate in a file to make your dev life so much more simpler and mess free.
  6. From the start, we knew we wanted to associate our custom user info with our Radar events, so we used – Radar.setUserId(email!)
  7. The controller we wanted to put location tracking functionality was made to support RadarDelegate and we had our controller be the delegate for the Radar instance with Radar.setDelegate(self). You would need to do something similar.
  8. The next step is to see the status of location permissions in the app.
    1. If the location permission was denied once already, we wanted to gracefully show a simple alert explaining the need for the location access and if the user denied it again, never ask him for it again for a while (you know as a user you hate those repeated alerts that you have already responded to right?)
    2. If the location permission was not set, we had to show the standard iOS alert with just the foreground access (we want to give the user as minimal chance of rejecting the permission request. If we ask for background permission at first go, it is highly likely that we don’t get it). We do this again in one line – Radar.requestWhenInUseAuthorization()
    3. When the user has used the app and this feature for a couple of times, we wanted to slowly entice him to giving us background location access. This ensures that we don’t force the user and since the user has shown interest already by using the feature, he is much more likely to give access at this stage. Again, simply call – Radar.requestAlwaysAuthorization()
  9. When the location authorization is only for foreground, we needed to make a call to Radar to do its stuff based on some custom business logic – like every time an action is triggered or based on a timer (we do tend to avoid this route). Radar provides us with a handy closure to perform the necessary actions if the tracking hits a valid geofence. You could do something like this – 
    Radar.trackOnce(completionHandler: { (status: RadarStatus, location: CLLocation?, events: [RadarEvent]?, user: RadarUser?) in
    
                    DispatchQueue.main.async {
    
                        if status == .success {
    
                            if let events = events {
    
                                for event in events {
    
                                    let eventString = RadarUtils.stringForEvent(event)
    
                                    print(eventString)
    
                                    if(event.type == .userEnteredGeofence){
    
                                        if(event.confidence == .high){
    
                                      // your custom logic in handling the event - like an alert, a business action etc
    
                                         }
    
                                     }
    
                              }
    
                             }
    
                     }   
  10. When the location authorization is for background as well, it is simply managed with Radar.startTracking()  and we fall      back on the delegate methods to handle receiving the events as when they are generated, like –
    func didReceiveEvents(_ events: [RadarEvent], user: RadarUser) {
    
            for event in events {
    
                  if(event.type == .userEnteredGeofence){
    
                        if(event.confidence == .high){
    
                                // your custom logic in handling the event - like an alert, a business action etc
    
                         }
    
                    }
    
               }
  11. And that’s it. We were almost done and so will you be.
  12. You can test with entering the locations in your simulator – locations you originally configured in the dashboard – and see these events triggered. 

Note: We did see a repercussion in implementing both background and foreground support for Radar events (since we can’t possibly guess which user will opt for which level). When foreground closure is triggered, it triggered the didReceiveEvents method too. So, we had our custom logic called in twice. You can solve this by a simple flag or counter but we wish Radar had handled this better in their SDK.

With this example, we have covered only the geofences feature from Radar. Like we said before, you can make use of their places and insights data too. If you need help with these in your app, drop us a line!

Remember:
User input is critical with location management. The whole can of features can become stale if the user just doesn’t want to turn on location in his phone. The prevalent phobia among most users that giving access to apps for location drains the battery and invades their privacy can be quite tough to break. But educating users to their benefits and assuring that their data is securely stored and processed only for the respective feature can convert these doubtful users to actively engage with your app. Be honest, direct and clear and the users will understand the benefits your app provides with location access enabled.

So …
Did we interest you into considering adding location management in your app and possibly use Radar for it? Let us know! We do a whole suite of interesting integrations and would love to chat with you about your app/idea.

 

Have something to add to the conversation? We’re all ears!

Leave a Reply