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 feasure 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 username or password; 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

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.

• Your application must manipulate and store some information related to your problem e.g., recipes for a cooking application, markdown documents for a journalling 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.

See the picking a project page for suggestions.

Examples

Recipe tracker

Image courtesy of Recipe Keeper

Users

A group of friends that want to cook together e.g., roommates.

Problem

How do you keep track of what recipes you have tried, and which ones each person liked?

Proposal

A recipe planning and tracking application that allows users to:

• Enter recipes (imported from a recipe site or manually entered).
• Browse a collection of recipes, with pictures. Search your recipes and friends recipes.
• Rate recipes, and view what other users have rated.
• Generate a list of “most wanted” recipes, or “most popular” after the group has tried them.
• Extra: track food allergies and support automatic filtering of recipes.

Design

Technical aspects to consider.

• Android application, with screens for all of this functionality
• Multi-user, so each person has a profile (login/logout/edit).
• Local database for caching details (SQLite & file storage)
• Remote database for storing user data and recipes (Firebase)
• OAuth authentication using Google accounts (also Firebase)

Software design tool

Image courtesy of Visual Paradigm

Users

Software developers that are interested in collaborative design.

Problem

Collaborative tools aren’t tailored towards software design, so we end up trying to create UML documents in Google Docs (awkward). UML tools often don’t support collaborative, which would be incredibly valuable!

Our goal is collaborative UML drawings.

Proposal

An online tool that lets multiple people work together to draw UML diagrams in real-time.

• Can have multiple drawing canvases; on launch choose which one to open and work on.
• Canvases should have a name, date-created, date-edited. Anyone can edit anything.
• Drawing tools: draw shapes; draw lines to connect them; move shapes; change properties.
• Export canvas to JPG (PNG, other formats) for use in other applications.
• Extra: Templates so that you can draw a plain box-arrows diagram, or a specific UML diagram e.g., class diagram, component diagram. (Do not support all UML, but a small subset; focus on infrastructure to add more later).
• Extra: Support more diagrams by expanding the templates!

Design

• Desktop tool, since it’s more precise for drawing.
• Multi-user, so each person has a profile (login/logout/edit).
• Investigate canvas classes in Compose for drawing arbitrary shapes.
• SQL database, since we expect a large collection of templates (predefined shapes) and think that’s a better approach.
• Will likely need a way to handle real-time updates for multiple users working on a document e.g., WebSockets.