Context
GPS Satellite Maps & Navigation is a GPS and mapping utility app built around one core surface — the map — with a wide set of tools layered on top of it: turn-by-turn navigation with a route planner, live traffic alerts, satellite/live/street map modes, a nearby places finder (restaurants, hospitals, hotels, gas stations, tourist attractions, and more), live location sharing, saved favorite places, a distance measurement tool, a built-in digital compass, and weather forecast integration tied to location. Every one of those features either draws from the same underlying map and location data, or needs to render on top of the same map view without the app turning into a pile of loosely related screens. I built the entire app end-to-end, solo, on native Android using the Google Maps SDK.
The Product
A tour of the core surfaces — the GPS compass home screen, the tools menu, route planning, nearby place categories, and two of the reference tools (Countries Info, Wonderful Places) built on the same navigational shell.
The Problem
- A dozen features, one map. Satellite view, live traffic, nearby places, saved favorites, distance measurement, and route navigation all need to render on or interact with the same map surface — the architecture had to treat the map as a shared, central resource that multiple features layer onto, rather than each feature owning its own map instance.
- Location data has more than one consumer. The device's GPS position feeds turn-by-turn navigation, live location sharing, the "nearby" search radius, and the compass — each with different accuracy, update-frequency, and battery-cost requirements. A single naive "get location" call used everywhere would either drain the battery for features that don't need constant updates, or under-serve the ones that do.
- Map modes aren't separate screens, they're views of the same data. Switching between live map, satellite view, and street view has to feel instant and consistent — the user is looking at the same world, just rendered differently — so mode-switching needed to be a rendering-layer decision, not a navigation event that reloads the map.
- External data sources needed to feel native to the map, not bolted on. Nearby places (via Google Places API) and weather data both come from outside the Maps SDK itself, but both needed to appear as though they belong on the map, rather than looking like separate widgets stitched on top.
- Auxiliary tools needed to work with the map, not just near it. The compass and distance measurement tool aren't just calculator utilities — the compass needs to orient relative to what's on screen, and distance measurement needs to draw directly onto the map the user is already looking at.
What I Built
A single map core with layered modes
Built the app around one central map component powered by the Google Maps SDK, with live map, satellite view, and street view implemented as rendering modes on that same component rather than as separate screens or map instances. Switching modes changes how the map renders, not what map the user is looking at — keeping the transition instant and the user's context (position, zoom, markers) intact across mode changes.
Turn-by-turn navigation and route planning
Built the navigation and route planner on top of the Maps SDK's routing and directions capabilities, layering live traffic data on top so route suggestions and turn-by-turn guidance account for real-time congestion rather than just static distance.
Nearby places, sourced from Google Places API, rendered as map markers
Integrated the Google Places API to power the nearby places finder — restaurants, hospitals, hotels, gas stations, and tourist attractions — and rendered results as markers directly on the core map component, so a places search feels like a natural extension of the map rather than a separate results list disconnected from it.
Location-aware tools built around the same GPS stream
Built live location sharing, saved favorite places, the distance measurement tool, and the digital compass as tools that read from and write to the same underlying location and map layer, rather than each maintaining its own separate location-handling logic. The compass reads device orientation sensors and displays relative to the map's current view; distance measurement uses map taps to draw a measured path directly onto the same map surface.
Weather forecast tied to location
Integrated live weather data scoped to the user's current or searched location, surfaced alongside the map context rather than as an unrelated separate section — keeping trip planning (where am I going, what's the weather going to be there) in one coherent flow.
Why These Choices Mattered
Treating satellite/live/street view as modes of a single map component — rather than separate map instances — is what made switching between them feel instant, and avoided the complexity (and bugs) of keeping multiple map states in sync.
Navigation needs frequent, high-accuracy location updates; a saved favorite place needs none once saved; live sharing needs periodic updates without being wasteful. Designing location access around each feature's real requirement, rather than one-size-fits-all polling, was the difference between a GPS app that's usable all day and one that drains the battery by lunchtime.
Keeping nearby-places results as markers on the same map component, rather than a separate list-first UI, kept the spatial context intact — users could see how far a result actually was and how it related to their route, not just read a distance number.
The compass and distance tool only earn their place in a GPS app if they feel connected to what's on screen — building them to interact directly with the core map component, instead of as standalone utilities, is what made them feel like part of the navigation experience rather than bonus features bolted on for a feature checklist.