Technical Requirements Document

MyWeather Motion is a hybrid Android application authored in MIT App Inventor. Native AI2 components handle location services, HTTP requests, persistence and timing, while the visual dashboard is bundled as HTML/CSS/JavaScript and rendered in a WebViewer.

The project’s editable properties may change before release. Confirm actual signed build metadata rather than assuming the stored snapshot matches the uploaded Play version.

Presentational code runs locally in the bundled asset, while AI2 handles device integration. The Android app therefore has no requirement for a custom backend server to fetch forecast data.

Current and daily forecast

GET https://api.open-meteo.com/v1/forecast with latitude, longitude, current fields, daily fields, 3-day horizon, timezone and requested temperature units.

current=temperature_2m,relative_humidity_2m,
  apparent_temperature,is_day,precipitation,
  weather_code,wind_speed_10m

daily=temperature_2m_max,temperature_2m_min,
  precipitation_probability_max,weather_code,
  sunrise,sunset,uv_index_max

forecast_days=3&timezone=auto

Search a city

GET https://geocoding-api.open-meteo.com/v1/search?name=.... The input must be URL-encoded; use a selected result’s coordinates to request forecasts.

Do not claim no personal data processing solely from local preference storage. Complete a data-flow review and accurate privacy disclosures before publication.

1. The user requests GPS, searches a city, switches units or refreshes.
2. AI2 blocks receive the action and resolve a location when needed.
3. Web1 performs the forecast request and parses the returned JSON.
4. Relevant values are passed into the embedded weather dashboard.
5. The JavaScript UI updates text, forecast tiles and condition-driven effects.
6. A failure state is surfaced and allows another attempt.

App Inventor’s block-to-WebViewer contract should be maintained as a typed, documented message structure. Sanitize dynamic text before rendering it in HTML and avoid injecting untrusted scripts or markup.

• Location: used for optional current-location weather. Denial should not block city search.
• Internet: needed for API requests, search and forecast refresh.
• Local preference storage: TinyDB retains app choices on the device.
• APK distribution: serve release builds over HTTPS and publish hash/signing details for independent integrity checks where practical.
• WebViewer: render the bundled local HTML and restrict unnecessary external navigation, scripting bridges and untrusted content.

The privacy policy and Google Play Data safety declarations must reflect the tested, final APK/AAB, platform SDKs and actual network behavior.

1. Open the .aia project in MIT App Inventor and review Screen1 components/blocks.
2. Confirm project name MyWeather, version code, signing strategy, and package appinventor.ai_renzterrie.MyWeather.
3. Use the appropriate MIT App Inventor build command to produce an APK for direct download or an AAB for Play Console. They are not interchangeable.
4. Test the signed release build on supported Android versions before posting download links.
5. For direct download, host the actual APK under releases/MyWeather.apk (or a trusted HTTPS URL) and update the website config.js.
6. For Google Play, only link a confirmed live listing after the app is available.

These are proposed checks. Record device, Android release, result, evidence and defect reference during testing.

• MIT App Inventor platform updates may alter component versions and build behavior.
• Provider API changes or unexpected weather-code values may require parsing and display adjustments.
• WebViewer behavior can vary by Android WebView version.
• Store compliance, SDK requirements and privacy disclosures should be rechecked at submission time.
• Potential enhancements: stronger caching, request debouncing, a clearer typed bridge contract and an automated regression checklist.