Data and Sensor Fusion, Geospatial Data, Innovation Funding, Mobile Development, Pervasive Location™, Requirements Definition, Solution Design
Offering services linked to a very specific location is predicted to be the next big thing. To support this Apple has pinned its hopes on iBeacon while Google has developed its own rival Eddystone 'open beacon' protocol. With the focus very much on beacons and their rival technologies where does this leave developers? Which technology do they support in the race to corner the market?
Location-aware mobile applications combine two key pieces of information: location and contextual information. Location could be determined by any relevant technology, such as GPS or beacons. The contextual information defines what is provided to a user at any pre-defined location. For example, a mobile application which supports train travel will provide train timetable information whenever the device is sufficiently close to a station, or if the device is within the pre-defined confines of the station (known as geofencing).
What is important to note here is that consumers do not care what the underlying technology is that provides the location-based service. Apple may want you to use iBeacon, and Google may want you to use Eddystone, but consumers only care about whether the service works or not.
Where does that leave developers? Mobile app developers can pin their colours to one technology, especially given the care Apple has taken to lock iBeacon into iOS. If as developers you control both the software and hardware infrastructure, this is fine, but most of us do not. For example, many companies looking at location-based infrastructure implementations will necessarily be focused on cost as well as ease-of-use and maintenance. Beacons can be difficult to maintain, so here then there are alternatives to picking just one technology, such as using existing Wi-Fi infrastructure, GPS when the accuracy requirements are lower, as well as picking whichever beacon technology may help solve the problem at hand.
The problem for app developers is that currently the only way to support as wide a range of technologies as possible is to code the technology support from scratch. Want to use both iBeacon and Eddystone on iOS? iBeacon is only supported through CoreLocation, whereas to support Eddystone you would need to code your own protocol handling using CoreBluetooth. Two separate implementations, both with different background processing requirements. Android is at least more flexible, but where does that leave us with integrating Wi-Fi and GPS? Lots more work on both platforms.
You might think by now there is an easier solution. For example, if you want to use geofencing on GPS, then there are a number of different SDKs available that make cross-platform development easier. There are also cross-platform beacon libraries which at least enable you to code to a consistent interface on iOS and Android to make use of beacon infrastructure. However, there are two problems with available SDKs. First they tend to lock you into a specific web-service to serve locations to your apps (this is how they tend to make revenue). Second, and crucially, none of them combine GPS, Wi-Fi and all flavours of beacon into a single SDK so that your app can be truly technology agnostic and future-proof.
We think we have a solution to this problem. Launching later this year, Pervasive Intelligence has a mobile SDK which will enable you to develop location-based mobile apps without having to worry about which technology you want to use.
The new Pervasive Location SDK will allow you to seamlessly combine GPS, Wi-Fi, iBeacon, Eddystone and AltBeacon on Android and iOS using a consistent interface. To keep things simple and prevent you having to worry about yet-another web service, you can serve locations to the SDK either locally in the app, or via your own web-service which simply has to provide a single RESTful endpoint to serve locations.
As well as being technology agnostic, Pervasive Location is also very flexible. Do you want to be able to define your own geofence size and shape? How about combining different technologies into a single location? For example, perhaps you want a service on a train, but you only want the service to trigger when the train arrives at a station and the consumer is travelling on the train? Here you need to be able to combine Wi-Fi or beacon technologies deployed on the train with GPS geofencing for the station. By allowing you to define your own location classes for use within the SDK, you can define whatever triggers you need, whether they are location or temporal or both.
You may have noticed our reference to train travel, and this is because the first deployment for the Pervasive Location SDK is coming soon in the Travel Guardian app that is being developed by ManagePlaces Limited and partners . As part of an Innovate UK funded project, Travel Guardian will bring a new level of personalisation to travelling on public transport , using location-based services to give you real-time, personalised updates while you are on your journey.
If you are interested in Pervasive Location, Travel Guardian or want to know more about how you can develop more flexible location-based services apps, just get in touch.
Digital processing is at the heart of innovation. It may be that you have a difficult or complex problem. Pervasive Intelligence have the expertise to cut through the complexity to give you a solution you can use in the real world.