Team Project (20 pts)
Projects are the final part of the course. You will form teams, come up with your own idea for an Android application or IoT solution, present your idea, implement it and finally present your solution & write a report.
Projects are done in teams of 3 persons.
Requirements
The topic is up for you to design. However, we require you to base your idea on certain 'building blocks'. Some of them (core blocks) are mandatory for all projects, others (feature blocks) can be picked based on suitability to your project idea. Some feature blocks include topics not covered in the course so far, giving you a chance to learn something completely new if you wish.
Core blocks - Requirements for all projects
Missing any of these reduces points!
- The application features multiple screen views (minimum of 3 different UI screens)
- Both Activities and Fragments count towards screen views. Multiple fragments within one screen count as 1.
- E.g., HA1 consisted of two views - the contact list, and contact details views.
- In addition to the views, there is a functioning settings screen
- Accessible from Actionbar or some other location, where the user can do some configuration for the app - e.g. clear all stored data, change style of the app (dark mode vs light mode), toggle sensor refresh rate and so forth.
- See here how to do it 'properly' (not mandatory)
- The application does not unexpectedly crash, takes care of lifecycle & permissions management
- Rotating the screen, hitting home/return button in the app should not cause crashes.
- The app can take care of requesting necessary permissions and will not crash if they are missing.
- Use resource files to manage constants used in your app logic & GUI:
- Text values - strings.xml
- Make use of string formatting at least once!
- Colours, Styles - colors.xml and styles.xml
- Dimensions used in UI layout files: dimens.xml
- Text values - strings.xml
- The application uses Threading, Coroutines or other background worker mechanisms to delegate some work off the UI thread.
- The result of the background work should still be notified in the UI.
Feature blocks - Choose a minimum of 3!
Use persistent storage.
- It can be either a Local database, e.g. Room, or Remote database, such as Firebase Cloud Storage.
Uses Services
- Running services, a notification should always be displayed when the service is running
- The user should be able to open the application from the notification and have a way of manually stopping the service.
- Running services, a notification should always be displayed when the service is running
Use some Web REST API
- Such as a weather service, Twitter, ..
- You may also write your own HTTP API / server code and host it somewhere, e.g. Heroku
Language & orientation localization
- Support your app in 3 different languages using Android resource localization and provide different UI layouts for landscape and portrait modes for all views.
Location-based functions: Maps & GPS
- Use Google Maps API or the GPS sensor in your app.
Sensors
- Use the smartphone's integrated sensors (accelerometer, gyroscope, proximity sensor, compass) in your app.
UI tests
- Implement Espresso UI tests for at least 3 of your views.
- Cover both sunny day and rainy day user flows (e.g. user provides erroneous input)
IoT - ESP32
- Incorporate the ESP32 board(s) to your project.
- We can provide additional sensors, actuators to help build more useful solutions. See: List of sensors available for the project.
IoT - Cloud Platform
- Incorporate Thingspeak to your project
- Use Matlab Analysis
- Enable the Android App to interact with Thingspeak (read data, send commands to ESP32).
- Incorporate Thingspeak to your project
External Communication events
- The app should react to Firebase push messages.
Use a part of Android API not covered in the course so far.
- Choose from:
- WorkManager API
- Calendar Content Provider
- Camera API
- MediaPlayer
- Bluetooth
- Google authentication
- App Widget
- Something else: consult the lecturer if your proposal is OK.
Note: If you implement a block, but it does not serve a purpose to the general topic of the app (e.g. randomly displaying sensor values in a contact manager app), you will lose points for Complexity and Cohesiveness (see grading info), even though you implemented that block. Instead, you should make sure the minimum 3 features form a meaningful whole. For example, sensor data for a contact manager may make more sense if you come up with some gesture recognition app that has a feature of sharing a sensor-based gesture pattern with contacts.
Other remarks.
Feel free to bring in additional assumptions or solutions to complement the above, but make sure to document them in your report.