Overview
| Milestone 4b | Overview |
|---|---|
| Worth: | 25% (250 marks available) |
| Due: | No earlier than 11:59 December 15 |
| Hand-in: | N/A (link to repository) |
| Notes: | No late work will be considered — marks will be based on condition of repository at the deadline. |
Final project presentations and deliverables marking scheme/links to instructions follow below.
Worth: 25% of overall grade.
Most of your instructions have already been added to your project GitHub as a set of issues! This document just centralizes the information in one place.
The grade you/your teammates receive is schemed out of 250 marks total:
- Project code is built/linted before pulled into
main- See the “Enforce build on pull request/push” issue I created in your repository for more information.
- See the “Enforce code quality and style” issue I created in your repository for more information.
- Project code uses appropriate grade/sdk versions
- See the “Update Gradle/SDK Versions” issue I created in your repository for more information.
- Application releases are published to Firebase using a GitHub workflow
- See the “Implement Firebase App Distribution Workflow” issue I created in your repository for more information.
- Coding contributions by each member will be made clear by strict branch management (pull requests into main for release-ready changes, separate branches for testing/development)
- to best of ability, all changes are reviewed/tested before pull into
main; - to best of ability, commits are atomic (see course notes on this subject);
- to best of ability, pull requests are linear series of commits, linear branch history is maintained
- Issues are used effectively, relevant, clearly written, and their statuses are up to date by project deadline.
- Wiki+Readme+Project polished and up to date
- See the “README” and “Wiki” issues I created in your repository for more information.
- A developer release has been made available for your project code and is documented on your GitHub
- See the “Dev Release” issue I created in your repository for more information.
- A production release has been made available for your project code and is documented on your GitHub
- See the “Prod Release” issue I created in your repository for more information.
- You have chosen a license for your project code.
- See the “Choose a license” issue I created in your repository for more information.
- Meet the business logic requirements as per your design proposal
- Meet the technical and functional requirements set by the teacher (see below)
- Use a declarative UI approach (Compose) with separation of concerns between display and data (e.g., MVVM approach)
- Apply the key techniques taught in class for state management (including ViewModel), user authentication, navigation, coroutines & flow, Material 3 design, layout, etc.
- Persist data provided by the user (Local storage or remote database)
- Include a user login/register capability with associated serverless authentication (e.g., Firebase)
- Implement a navigation approach that allows user to move to different screens and that works with device back button (e.g., NavBar, but other approaches are possible)
- Prevent access to some UI elements and associated access based on whether user is logged in or not.
- Include an “About Us” screen that describes your team and the motivation for the app.
- Include at least one information screen in addition to the About Us screen.
- Include at least three functional screens (not including login/landing/about-us/info)
- The user should be able to perform all interactions with the application by starting the app and then navigating appropriately within the app.
- User inputs should be handled appropriately (e.g., hide password, some minimal form of validation)
- The application should not hang or crash
- Include 1 “advanced feature” suggested in class.
- See the “Advanced Feature” issue I created in your repository for more information.
- All screens use Material design and share a common look and feel.
- How well did your app meet the soft requirements and your design aesthetics? Does it have a good aesthetic design?
- See the “Material Design & Style Refactor” issue I created in your repository for more information
- Is your app usable? How useful is the app? Are instructions to the user clear (where needed)? Does the app provide a cohesive experience?
- The principles learned in the Assignment 4 codelab have been applied to your project
- See the “Accessibility” issue I created in your repository for more information.
- Kotlin/Compose best practises and uniform style are applied
- See the “Enforce coding quality and style requirements using Spotless” issue I created in your repository for more information
- Important source code files must be appropriately documented meaningfully.
- See the “Comments and Attributions” issue I created in your repository for more information
- Source code project name/package name is appropriate (not EmptyActivity or Assignment2 or similar)
- See the “Project/Package name” issue I created in your repository for more information
See form distributed on Teams (Will be distributed December 15 after the strike)
See form distributed on Teams (Will be distributed December 15 after the strike)
Informed by the above two evaluations, as well as my own evaluation of your contributions to this project. I will base my assessment off code and documentation changes that are visible to me on GitHub. Make sure all team members are contributing code and managing the project issues/documentation!