Blog

Wherever you go, there you are. Unfortunately your mobile phone doesn’t see it that way.

By John Fontaine  |  November 14, 2014

This entry was posted in SR News, SR Thoughts and tagged , , , , , , , .

Developers know that working with location services on mobile devices is a bit like working with an old map. You inevitably get to a spot where it says, “Here be dragons.” Yes, if you want latitude and longitude with a low precision, the phone will give it to you, but as soon as you explore further, you hit the same set of problems like battery life, user behavior, venue datasets, and complex, poorly documented optimization strategies.

You can read my extended rant below, but TLDR; SocialRadar has combined with Gridskippr to develop an SDK that can help app developers solve these problems without having to spend their days crawling stack overflow. You can request more information about our SDK here. You can also catch me in person at MoDevCon on December 11-12.

__________________________________________

As a developer, the first challenge you face is the battery life. The platforms deal with this in various ways, but ultimately they leave it up to you as a developer to decide what will work best. If you are like me, you set up a number of identical devices with different strategies and start testing to see what really gives you the performance you want.

Of course few strategies survive contact with real users, so you ship your app and end up redoing it all based on user behaviors like how often they kill apps, restart their phones, and turn on and off wifi, GPS, Bluetooth.

Once you overcome the issues of getting these services running in a reliable fashion, you run into the problem that the data you get isn’t very good. Moving from the rough location in the raw location services data to something precise enough to enable many common use cases requires learning some dark arts and pulling off some mathematical wizardry. Refresh your knowledge of things like Kalman Filter, stochastic calculus, particle filters, and predictive algorithms. Recognize that there are different strategies for the user’s current activity. Improving location accuracy for a person driving is different from how you improve it for a person riding a bicycle, walking around, or standing still.

Now you have the location at an acceptable accuracy and you’ll probably think you are ready to do some geocode lookups, get some addresses, and provide some venue information for your users. That’s when you find out you are just getting started. The location data is terrible. There are many overlapping data providers and they all have problems, not to mention conflicting and often difficult licensing terms.

At the end of this journey you may find that you’re collecting a bunch of noisy data and not providing a lot of value to your users. Except for that one guy who is able to become the mayor of the local Starbucks. But that is probably not the outcome you or your users wanted.

During the last two years, as I’ve become intimately familiar with these problems. In my search for solutions, I’ve gotten to know a team of folks at company called Gridskippr. They’ve helped me and my fellow SocialRadar developers overcome these challenges. Now we’ve combined our teams to be able to pass on our shared expertise to the world through an SDK.

By packaging this knowledge into reusable libraries that you will be able to easily add to an IOS or Android project, we have solved three big problems:

  • Location accuracy. We spent a full year in R&D cleaning up GPS data so that you’ll have doorway-accurate GPS data almost everywhere you go (and 18- meter accuracy in the worst urban canyons of NYC).
  • Way better battery life. Running our SDK in the background consumes less than 2% of a phone’s battery life per hour, at maximum accuracy. Slightly more if you want to track a running path, less if you only need a momentary location look-up. This is compared to the 8% – 14% battery drain that occurs if using the iPhone always-on location capability. 
  • Automatic venue identification. This required us to rewrite the lat/lon data for the most popular places people go. When we detect a person entering a pho restaurant, our SDK will tell you the exact venue name and other details. Your user won’t have to select his place from a list of nearby venues (unless he really wants to, in which case we have that option, too). Plus venue identification happens in the background, so when your user opens your app, you’ll already know where he is.

This is just the beginning. Over the last year SocialRadar has developed a set of tools for managing and searching through social data based on location and proximity. Our integration with multiple social networks allows for a single screen that shows who’s nearby and how you are connected to them. Imagine going to your next meetup and your app already knows not only where you are but also who’s there with you, even before you launch it. Networking, proximity-driven gaming, and sharing are all made possible because our combined companies will give you location and social context through a single SDK.

Comments

No comments yet.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">