Android Weather App
Helped deliver a functioning Android weather app by preparing place data, analyzing nearby-city coverage, integrating settings, and replacing fragile Gemini response parsing with structured JSON.
Overview
The app lets users save cities, view station-based weather observations, explore maps and nearby places, select visual themes, and receive four context-specific weather questions and answers. The public demonstration uses recorded Android workflows rather than a live hosted app.
Problem
City selection, mapping, nearby-place lookup, and station observations required a consistent geographic data pipeline. The weather insights feature also needed a more reliable interface than manually escaped requests and delimiter-separated model responses.
Constraints
- Integrate with an existing collaborative Android/Java application without redesigning the UI
- Preserve the relationship between place names, coordinates, and weather stations
- Use a bounded four-question response contract that the existing insights screen can display
- Demonstrate the working app without publishing shared application code or distributing configured API credentials
Approach
Built Python tooling to transform place records into Android resources and inspect spatial gaps with a KD-tree. Updated the Gemini integration to construct requests with Android's JSON library, request schema-constrained output, and parse typed response steps. Validated the request/response shape separately in Python and demonstrated the integrated workflows on an emulator.
Key Decisions
Separate place-data preparation from Android runtime lookup
Generated name and detail resources support consistent city selection, mapping, and station resolution without repeating source-data processing in the app.
- Perform the full place-data transformation at runtime
- Maintain separate hand-edited city and station lists
Use an offline KD-tree to diagnose nearby-place coverage
Nearest-neighbor distances reveal gaps in the underlying dataset without incorrectly claiming that the Android nearby-city feature itself uses a KD-tree.
- Select search tolerances without examining place spacing
Replace delimiter-separated LLM text with schema-constrained JSON
An explicit four-pair contract avoids positional splitting on '#' and allows the client to find the model output by step and content type.
- Retain the original free-form response and delimiter parsing
Tech Stack
- Android / Java
- Python
- SciPy cKDTree
- NOAA METAR observations
- OkHttp
- Gemini Interactions API
Result & Impact
- 4Questions per insight request
- 3App themes
- 6Recorded workflows
The team application now has demonstrated end-to-end weather and contextual-insight workflows. The public repository contains selected Python tooling and experiments, not the full collaborative Android source.
Learnings
- Geographic joins and sparse station coverage shape the mobile experience as much as the UI does
- Schema-constrained generation reduces brittle response parsing, but does not eliminate API errors or the need for defensive client behavior
- A recorded walkthrough can demonstrate a collaborative mobile application without exposing API credentials or requiring visitors to install it
Recorded demonstration
This project is presented with a recorded Android emulator walkthrough rather than a live interactive demo. The selected recording shows the app workflow; the linked case study explains the data preparation, spatial diagnostics, team contributions, and Gemini integration. The shared Android application source is not included in the public tooling archive. Additional recordings can be viewed below.
Additional Demonstrations
Six recorded demonstrations covering application features and workflows.
View all video demonstrations (6)