This is the introduction to a ten part series about building movement-aware applications. Mobility The was invented so users could stay connected while on the move. And then mobile phones got smarter and staying connected evolved from voice to apps. App developers used location-based services to be aware of their users’ location and power better app experiences using location. mobile phone Location-based services The leading Operating Systems provide primitives to get user location as points in time. The leading map providers provide primitives to build experiences with location points — getting address for the location, displaying location on the map, getting routes and distances between locations, navigation between locations and much more. Developers use these as building blocks to deliver location-based services. It has been a decade of app development using location-based services. I would have predicted a small single-digit % of apps requesting permission to use location at the end of a decade. Instead, the numbers are more like and (these numbers are for Android only). I do not remember the last time I got an app on my phone that did not request permission to use my location to enable a useful feature. 24% of all apps in the US 72% in India Movement is much more than location. While location tells us where the user is, activity tells us what the user is doing, device health tells us what happened when data goes awry, and maps give us sharper context about what the user might be doing. Movement Developers have imagined products, experiences and businesses that rely entirely on user movement. Developers care about movement, not just location. From PokemonGo, Strava and SnapMap to Uber, Deliveroo and Instacart. From live location sharing through your favorite messengers to tracking of rides, deliveries, employees and dog walks. Companies have invested a tremendous amount of research, development and engineering to build and operate movement-aware applications. Generate. Manage. Consume. Mobile devices keep pushing the envelope on the hardware sensors available in every new release. OS APIs continuously improve the primitives through which sensor data is made available to developers. Map providers keep pushing the envelope on mapping our planet from meter to centimeter level granularity. Map APIs continuously improve the building blocks through which this data can be put to action by developers. The OS helps generate movement data and maps help consume it. However, the developer is left with the heavy lifting to generate, manage and consume movement data, often at the expense of focusing on their core business. Generate The complexity of generating movement data is in balancing real-timeness, accuracy and battery drain. It gets harder with diverse devices, hardware components, OS versions, privacy policies and network conditions with each being a moving target. This balancing act often requires the server to connect with tracked devices on-demand, a technology that is far from reliable. Manage The complexity of managing movement data is in composing it in abstractions that integrate naturally with your application. For example, for an Uber-like app, tracking and storing movement data in context of pre-assignment, pickup and dropoff is more useful than a raw stream. A monolithic implementation of the first use case (e.g. live tracking experience of picking up a customer) might incur technical debt that makes it incredibly hard to build the next few features (e.g. surge pricing and assignments based on mapping the demand and supply) on the same stack. The right feature modeling upfront would serve developers well for future application of machine learning algorithms. For example, modeling deliveries as drive, walk and dwell segments will help learn the ETA model for the overall milk run. Managing response times, availability and reliability gets harder as movement data explodes at scale. Movement data presents a unique set of devops challenges to operate real-time features and analytics. Consume The complexity of consuming movement data is in using the right map APIs, visual libraries and customizations, with each being a moving target. It gets harder with the fine prints of map software license agreements and costs that scale opaquely. Map APIs and visuals focus primarily on location when movement has gone beyond location to include activity and device health. The gap The OS is not in the business of generating and managing other’s movement data as a service in the cloud. Similarly, maps are not in the business of managing and consuming other’s movement data. This structurally limits their ability to alleviate the developer’s pain with regard to movement-aware applications. We will dive deeper into these structural limitations in the various articles of this series. The series This ten-part series of technical articles — — talks about the complexity of building and operating applications with user movement. These articles are based on the interactions with 5,000+ developers from 100+ countries who have engaged with HyperTrack to build movement-aware applications. These applications represent consumer and business apps, small garage teams to large high-growth startups, pure-play products of young businesses to new initiatives of publicly listed enterprises. movement These articles will cover the hidden challenges and complexity in managing a movement stack, the implications of incurring technical debt, learnings from the HyperTrack journey, and useful resources to generate, manage and consume movement data. The ten parts are organized as: Part 1: OS Part 2: Accuracy Part 3: Real-time Part 4: Battery Part 5: Abstractions Part 6: Data Part 7: Maps Part 8: Visuals Part 9: Scale Part X: Security Let the movement begin… Original post on HyperTrack blog (Feb 15, 2018)
