Requirements

Guidelines

We are designing and building graphical applications that leverage cloud services and remote databases. The project should be a non-trivial Android or desktop application that demonstrates your ability to design, implement, and deploy a complex, modern application.

You must use the technology stack that we present and discuss in-class:

  • GitLab for storing all of your project materials, including documentation, source code and product releases. All assets and source code must be regularly committed to GitLab. See specific requirements as the course progresses.
  • Kotlin as the programming language for both front-end and back-end. No other languages are allowed.
  • Jetpack Compose or Compose Multiplatform must be used for building graphical user interfaces.
  • Ktor must be used for any networking requirements that your application might have.
  • The kotlin-test classes and JUnit for writing tests.

You may choose any hosted cloud/db provider. The following have been used successfully in past offerings of this course, and are recommended: Firebase, Supabase, and MongoDB.

Additional libraries may be used, provided that you follow the course policies.

You are also expected to leverage the concepts that we discuss in class:

  • You should demonstrate design principles that we discuss in lectures.
  • You must build a layered architecture, using MVVM, MVI or another pattern we discuss.
  • You are expected to write and include a reasonable number of unit tests for your application.

You will be assessed based on:

  • How well you define the problem you are solving, and understand the users you are solving it for.
  • How well you design features to address that problem and the quality of your design.
  • The clarity, quality and ease-of-use of your application.
  • Your ability to work as a team to incrementally deliver features over time.

Requirements

In your Project Proposal, you will define your target users, a problem to address, and a set of custom features that you intend to implement to address that problem. The details will be unique to each team, but should be non-trivial features that demonstrate your ability to design and implement complex functionality to address a problem. You should be able to articulate how these features make your product different or better than existing applications.

Your application should minimially consist of a desktop or Android application with the following requirements.

1. Graphical user interface

Your application must have a graphical user interface, created using either Jetpack Compose (Android) or Compose Multiplatform (Desktop).

Your application should include at least three different screens, and you must support navigating between them as part of your normal application functionality.

You should have a custom theme that you have produced i.e., custom colors, fonts and so on. Marks will be deducated if you simply use the default Material theme that is included in Compose.

For a desktop application:

  • Your screens should be windowed.
  • Users should be able to minimize, maximize and resize windows as you would expect for a desktop application, and windows should have titles.
  • Your application should have a custom icon when installed.

For an Android application:

  • Users should be able to use normal gestures to navigate between screens. You must support back-stack navigation.
  • When rotated, your screens should rotate to match the orientation, and layouts should modify themselves to fit the screen dimensions in either orientation.

You are expected to produce prototypes for these screens as part of your initial design.

2. Multi-user support

Your application should support multiple users. Each user should be able to login, and see their own specific data and application settings.

  • Each user should be able to create an account that represents their identity in the application.
  • Accessing user data must be restricted by account i.e. users can only see their own data, unless a feature specifically reveals shared data e.g., sharing a recipe among friends using the application.
  • You should support standard account functionality:
    • Each user should be able to create their own account, and login/logout using that account.
    • You should perform standard validation when creating accounts or entering information e.g., do not allow duplicate usernames; mask out the password when entered; passwords must contain special characters.
  • Credentials should persist between sessions i.e., your user should not have to login each time they launch the application.

3. Networking and security

You must use Ktor for any network access.

  • Network requests do not need to be encrypted, but you should require authentication for any access (i.e., the user has to login before they can access any service or data).
  • You should leverage existing authentication services where possible e.g., Firebase Auth or Supabase Auth. Do not “roll your own” insecure system!

4. Data storage (local + remote)

Your application must manipulate and store data related to your problem e.g., recipe for a recipe tracking application; user profile information needed to login; the user’s choice of theme to use in the UI.

You must implement both local and remote storage.

Local storage

  • Local storage should include the last-known-good application data.
  • Your application should attempt to connect to a remote data store and fetch that data (and either merge, or replace your local data, depending on the design).
  • If remote data is not available (i.e., no internet connection, or unable to login to a remote database) then the local data should be used instead. The application should be completely functional using local data.
  • Your local data storage does not need to be any specific format: it can be a file, or a local database e.g., SQLite.

Remote data

  • This is your preferred place to store data, either to keep personal data in the cloud, or to share it with other users e.g., sharing recipes with other users of your recipe application.
  • If remote data is available, your application should fetch it on launch (see above) and use a local copy. On exit, or when other reasonable conditions are met, your application should push local data to the remote data store to keep it synchronized.
  • Your remote data storage should be in a hosted database of your choice. This can be a dedicated instance e.g., one that you have installed and control, or a hosted database through a cloud provider like AWS, Firebase or Supabase. Use of a custom SDK is allowed, as is a database framework like Room or Exposed.

5. Custom features

Using the guidelines above, you are expected to propose, design and implement multiple features that solve a problem for your users (see the Design thinking lecture for details).

  • Your application must manipulate and store some information related to your problem e.g., recipes for a cooking application, markdown documents for a journaling application.
  • Your functionality must be more complex than just simple CRUD operations. e.g., your recipe app should also generate a shopping list, or store user reviews of recipes, or suggest alternate ingredients.

Stuck on what to build? See picking a project page for some project suggestions.