Project Grading Guidelines

This page contains guidelines for how your work will be graded. For the guidelines where it make sense, a higher grade includes the guidelines for the lower grades. For example, to be able to get Grade 5, you also need to follow the guidelines for Grade 3 and Grade 4.

Note

This page does only contain guidelines for how your work will be graded. When we grade your work we'll make an assessment of your entire work, which is not limited to these guidelines, so do not use these guidelines as a checklist for a certain grade. Instead, rather see them as minimum requirements to be able to get a certain grade.

Indentation Convention

The convention used for indenting code (such as 2 spaces, 4 spaces, a tab, etc.). For more information, see Wikipedia's article on indentation style

Grade U No indentation convention has been used or there exists too many places where the convention has not been followed.

Grade 3 The same indentation convention is mostly used, but at a few places the convention has not been followed.

Grade 4 Each file correctly use an indentation convention, but different conventions are used in different files, and there's no consistency in when to use which one.

Grade 5 The same indentation convention is consistently used across all files of the same type.

Coding Style

The conventions used for writing comments, (not) using optional curly brackets, maximum line lengths, white-spaces in the statements, etc. For more information, see Wikipedia's article on coding style. xkcd has a web comic about it.

Grade U No coding style has been used or there exists too many places where the style has not been followed.

Grade 3 The same coding style is mostly used, but at a few places the style has not been followed.

Grade 4 The same coding style is consistently used in each file, although individual files (even of the same type) use different coding styles.

Grade 5 The same coding style is consistently used across all files of the same type.

Naming Convention

The convention used when naming variables, constants, functions, methods, files, etc. For more information, see Wikipedia's article on naming convention.

Grade U No naming convention has been used or there exists too many places where the convention has not been followed.

Grade 3 The same naming convention is mostly used, but at a few places the convention has not been followed.

Grade 4 The same naming convention is consistently used in each file, although individual files (even of the same type) use different naming conventions.

Grade 5 The same naming convention is consistently used across all files of the same type.

Mnemonic names

The names used (on variables, functions, files, tables in the database, etc.) reflect what they represent. Optimal names are short and very descriptive. For more information, see Chapter 2.12 in Python for Everybody (Severance).

Grade U Many names are not mnemonic.

Grade 3 Many names (at least 90%) are mnemonic.

Grade 4 Almost all names (at least 95%) are mnemonic.

Grade 5 All names (100%) are mnemonic.

Magic Numbers

Avoid using magic numbers in the code. Does not only apply to numbers, but all values that are better put in descriptive constants.

Grade U 3 or more magic numbers exist.

Grade 3 At most 2 magic numbers exist.

Grade 4 At most 1 magic number exists.

Grade 5 No magic numbers exist.

Error Handling

Handling of various errors that can occur when the user is using the application, such as validation errors, no network connection, the device doesn't have a camera, the user doesn't grant you a permission, etc.

Grade U Errors are not handled, or the error messages shown are confusing to the user.

Grade 3 Handles and display error messages for at least 90% of the errors that can occur.

Grade 4 Handles and display error messages for at least 95% of the errors that can occur.

Grade 5 Handles and display error messages for all errors that can occur.

Graphical User Interface

The logical placement and usage of components (buttons, input fields, etc.), the support for different screen sizes, how intuitive it is to use the application, etc.

Grade U -

Grade 3 The user understands how to use the application without external instructions.

Grade 4 -

Grade 5 -

Fundamental application components

The usage of fundamental application components.

Grade U -

Grade 3 Fundamental application components are used.

Grade 4 Fundamental application components are mostly used properly, such as code belonging in a service is written in a service.

Grade 5 Fundamental application components are used properly, including the communication between them (for example no global variables).

Report

The quality of the report.

Grade U The reader does not get a good understanding of what the project is about (the problem and the solution) nor how the solution works/will be used/has been implemented.

Grade 3 The readers gets a good understanding of what the project is about and how the solution works/will be used/has been implemented. Figures are used, they have been numbered and given descriptive captions, and they are referred to from the main text using their figure numbers. The text does not contain obvious spelling mistake nor incomprehensible sentences.

Grade 4 Chapters and sub-chapters are properly used to give the report a good structure. The reader can easily find the specific information she's looking for in the expected chapter/sub-chapter.

Grade 5 Everything with the report is great.

Extra Functionalities

Implement extra functionalities listed in the table below.

Grade U Not applicable.

Grade 3 Implement extra functionalities worth at least 3 points in total.

Grade 4 Implement extra functionalities worth at least 7 points in total.

Grade 5 Implement extra functionalities worth at least 11 points in total.

Note!

You may not get all the points for the functionality you implement. You need to implement the functionality in a good way to get all the points for that functionality.

Points	Feature	Description
1	Multiple languages	Full support for at least two languages everywhere (English + one more): No strings shown to the user hardcoded in your Kotlin/Java code (use string resources). No strings shown to the user hardcoded in your XML code (use string resources). Text entered by the users will of course only be in one language.
1	Runtime permissions	On newer versions of Android, ask for the permissions you need at runtime (when you need them). If you don't get them, deal with it in a good way (for example, if you don't get the accurate location permission, you can ask the user to enter the city name or latitude and longitude manually).
4	Runtime configuration changes	Handle runtime configuration changes in a good way throughout the entire application, such as: HTTP requests are not re-sent. Bluetooth connections are maintained. Results of long running operations are cached. I.e. use ViewModels.
1	Widget	Create a widget the user can use from the launcher. Too simple widgets (such as only "click on the widget to start an activity") are not accepted.
2	Foreground service	Make use of a foreground service in a suitable way (important background computations, geofences, Bluetooth connections, etc.).
3	Re-using fragments	Re-use none-elementary fragments you have created, such as one fragment showing a list of items, another one showing a single item, and then show one fragment at a time on a small screen and show both side-by-side on a large screen.
1	Third-party authentication	Let users login with their account from another company, such as Google or Facebook. This is of course in addition to ordinary login with username and password, or similar.
1	Loading indicators	When the application starts a long running operation/waits for something, show a loading indicator of some kind reflecting this. Remove the loading indicator afterwards.
2	Alarm Scheduling	Schedule alarms/jobs that notifies the user at certain times, for example 15 minutes before a meeting starts. If the meeting is cancelled or the time for the meeting is changed, the scheduled alarms of course need to be deleted or updated too. Structure your solution well, so there's no need to copy-paste similar code if you for example want to create new meetings at multiple different places in your application.
1	Push Notifications	Automatically send a push notification to a user's device (for example using Firebase Cloud Messaging) when there is something the user needs to be notified about ASAP, such as new event created nearby, new message sent to the user, an event the user has signed up for is cancelled, etc.). Note: Push Notifications are not the same thing as ordinary Notifications in Android; Push Notifications are "pushed" to the device from a server.
1	Different type of accounts	Support different type of accounts, such as guest accounts, ordinary accounts, admin accounts, etc. Users should be able to do different things in the app depending on what type of account they are signed in to. For example, an ordinary user might only be able to create data belonging to her own account, while an admin can create data belonging to another account (acting as if she is signed in to another account). Note: Simply hiding/showing a few GUI components depending on the account type (such as admin accounts have a link to an admin activity ordinary users can't access) is not enough.
0.5	Creating QR Codes	The app can create different QR codes that can be used by the app itself or another app.
0.5	Reading QR Codes	The app uses the camera on the Android device (either directly or indirectly) to read and react to QR codes.
1	Uploading and downloading images (or any type of files)	The user can select an existing image or create a new one (for example through the Camera app), which then is uploaded to a server of some kind (for example Cloud Storage for Firebase. The images can also be downloaded and shown in the app. (just using the server to store files like this does not fulfill the base requirement the application you create must make use of at least one other device).
3	Using 2 other type of devices	The base requirement the application you create must make use of at least one other device is fulfilled twice, for example the app uses Bluetooth to communicate with one type of device (for example another Android device), and a REST API or FireStore to communicate with a server. For full score, it's very important that the communication with both device types are implemented in a good way, including dealing with errors (showing error messages to the user and give users the ability to recover from errors), and that the communication is not "minimal" (for example all 4 CRUD operations are implemented when using the server).
1	Periodical updates	Periodically update something in the background, such as fetching new data from a server each night, and also enable the user to trigger updates manually through the GUI in the app. Structure the code good, so the logic performing the update isn't duplicated.
?	Own suggestions	Come up with your own suggestions of extra functionality. Describe the functionality and email the examiner for approval at Peter.Larsson-Green@ju.se).