A group final project for Cloud Computing (6CloudCom): a Flutter app where players sign in, register monsters at GPS spawn points, and catch the ones within range of where they stand. It runs on Android and the web against a PHP backend on AWS, and can start and stop the backend's EC2 server from inside the app.
The course asked each team to design and build the cloud infrastructure behind a monster-catching app: a web server and a database server in different AWS regions, a VPN between the phone and the server, and control over whether the server is running, all with CRUD for players and monsters, catching and a leaderboard.
What it does
Player accounts: register, sign in, and update the profile and password, with the login remembered between launches.
Add monsters with a spawn point and catch radius picked on a map.
Catch Monsters scans the player's GPS position for monsters in range, then sounds an alarm, vibrates and flashes the phone's torch.
Edit and delete monsters, and see a player's catches on a map.
A Top Hunters leaderboard of the players with the most catches.
An instance screen that shows whether the EC2 server is online and starts or stops it.
Catching pauses while the phone is offline.
Engineering decisions
The backend address is set at build time
The API and instance-control addresses are passed in when the app is built rather than hard-coded, so the same code builds an Android APK or a web app pointed at any backend.
Screens are tested against a fake server
The test folder holds 45 widget and unit tests, covering account creation, catching, monster management and response parsing, that run against a fake HTTP server instead of the real backend.
Known backend gaps are written down
The setup guide lists what the PHP backend still needs: hashed passwords, prepared statements, reading the player from a session instead of the request, and protecting the start/stop endpoint.