6G6Z0014 – Mobile Computing 1CWK100 Assessment Brief 2026 | Manchester Metropolitan

Assessment Cover Sheet 2025/26

Learning outcomes being assessed

LO1: Create application capable of running on contemporary mobile devices using appropriate tools and techniques.
LO2: Utilise specialist on-board mobile hardware by interfacing with appropriate APIs and libraries.

Note: it is your responsibility to make sure that your work is complete and available for marking by the deadline. Make sure that you have followed the submission instructions carefully, and your work is submitted in the correct format, using the correct hand-in mechanism (e.g., Moodle upload). If submitting via Moodle, you are advised to check your work after upload, to make sure it has uploaded properly. If submitting via OneDrive, ensure that your tutors have access to the work. Do not alter your work after the deadline. You should make at least one full backup copy of your work.

Penalties for late submission

The timeliness of submissions is strictly monitored and enforced.
All coursework has a late submission window of 7 calendar days, but any work submitted within the late window will be capped at 40%, unless you have an agreed extension. Work submitted after the 7-day late window will be capped at zero unless you have an agreed extension. See 'Assessment Mitigation' below for further information on extensions.
Please note that individual tutors are unable to grant any extensions to assessments.

Assessment Mitigation

If there is a valid reason why you are unable to submit your assessment by the deadline you may apply for Assessment Mitigation. There are two types of mitigation you can apply for via the module area on Moodle (in the 'Assessments' block on the right-hand side of the page):

• Non-evidenced extension does not require you to submit evidence. It allows you to add a short extension to a deadline. This is not available for event-based assessments such as in-class tests, presentations, interviews, etc. You can apply for this extension during the assessment weeks, and the request must be made before the submission deadline. For this assessment, the non-evidenced extension is 2 days.
• Evidenced extension: requires you to provide independent evidence of a situation which has impacted you. Allows you to apply for a longer extension and is available for event-based assessment such as in-class test, presentations, interviews, etc. For event-based assessments, the normal outcome is that the assessment will be deferred to the summer reassessment period.

Further information about Assessment Mitigation is available on the dedicated Assessments page.

Assessment Brief

Students will be tasked with the development of a mobile application, utilising the .NET Multi-platform App User Interface (.NET MAUI) framework for the display of data, and making use of the mobile device's hardware for suitable additional functionality.

You will need to commit your code to your designated GitHub repository regularly. The final submission will be assessed using the following criteria. Each element of the criteria will be explained by you in the form a screencast. Code quality and GitHub usage will be checked by the tutor, but you should also mention these in your screencast.

What should my App be?

Your app can be anything you wish and could align to your own interests. Some examples could be a workout planner for health and fitness, a skills development app for programming within an education theme, or a travel app that can include a city guide and use GPS to find useful landmarks near you. These are just examples. With this flexibility of choice, you can create something unique. More examples will be posted to Moodle. You can also explore the common app stores for inspiration: Google's Play store and Apple's App Store.

Development Software and Use of Macs

In the labs, we will use Visual Studio 2022 on Windows machines with .NET MAUI using .NET 9.0. The labs provide everything needed to develop your assessment. If you use your own Windows machine, please try to match up versions with the lab to avoid any software mismatches and to align with the support provided. As we do not use Apple Mac machines, we have limited support for people using their own Mac/MacBook, so you will be expected to understand your own personal machine and set up accordingly. Visual Studio is no longer supported by Macs, so you will need to use Visual Studio Code on your personal machine if you decide to keep using your Mac for development.

Another alternative IDE is JetBrains Rider, which can work on both Windows and Mac. This is not set up in the university labs, so you can only use it on your personal machine. It's free for non-commercial use and as a student, you can sign up for the JetBrains student pack here.

We can help the most with lab machines as they are set up for the module. If you decide to use your personal machine, be aware that it is your responsibility to set up everything correctly.

Submission Criteria

1. UI/UX Design and Accessibility

You should create a good user interface (UI) and user experience (UX). The UI should be simple and kept uncluttered to avoid overwhelming users. You should be consistent in your design, such as with the use of colours, fonts, and icons. eXtensible Application Markup Language (XAML) should be used for defining Uls. For the UX, the navigation should be intuitive and straightforward. A good idea is to use elements you see every day in mobile applications, such as arrows for going back or a question mark (?) for accessing help. The performance of the app should also be as optimised as possible to improve the overall experience when using the app, for example, minimising load times and reusing code as much as possible. Accessibility in mobile computing is essential to ensure that all users, including those with disabilities, can effectively interact with mobile applications. In a lot of cases, it will be a legal requirement for apps that are published. This criterion will be assessed on how much consideration is put into applying best accessibility practices, for example: ensuring font sizes are readable and changeable, the ability to turn on dark mode or similar, and screen readers.

While there is not a set amount of accessibility features to include in the assignment, it is recommended that you research the Web Content Accessibility Guidelines (WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C) to understand the principles and how to meet them in your app. You will then need to ensure you understand and talk through what you have applied in your final screencast.

2. Use of Mobile Hardware

Your app will need to utilise the specialist hardware available on mobile devices, such as the camera or accelerometer. There will be different marks given based on the number of hardware features used (see in depth mark scheme below). It is expected that the hardware feature should work for this to count. For higher marks (75%+), it will be expected to use the hardware features in more unique ways. For example, using the camera for a computer vision application that classifies an image.

The following is a list of hardware features that would count towards this criterion (please ask a tutor if you are unsure if something is a feature):

Camera (using both the front and back camera only counts as 1 feature)

• Microphone
• Accelerometer
• Суговсоре
• Magnetometer
• Barometer
• Shake
• Compass

Flash (needs to be implemented in code, not just used as the in-built function on the camera)

• Location/geolocation/geocoding (can be spoofed in an emulator rather than a real location)
• Haptic feedback and vibration (using both only counts as 1 feature)
• Text-to-speech

The following is a list of hardware features that would not count towards this criterion (please ask a tutor if you are unsure if something is not a feature):

• Battery level
• Orientation
• Device information
• Buttons or any other UI element

Speaker

• Touch screen gestures
• Storage

Databases

The above lists may not be exhaustive, so please ask if you are unsure.

3. Functionality

The functionality of the app will be assessed here, for example, if the buttons created go to the right place, the menus work, and you are able to show all this in your screencast. Other criteria may link to this, for example if you have a camera element to take a picture and it works well, this will also go towards this criterion. If your app should work in any orientation, such as portrait and landscape, then this should be demonstrated as part of your app's functionality. If your app is intended to only work in one type of orientation, then make sure to state this in your screencast.

4. Validation and Error Handling

Part of this criterion is to check how you handle user input correctly. So, if you have a login page, you will need to ensure that a user enters the information and does not leave a box blank. If they do, you need to provide a validation check and provide a response to the user to correct the mistake.

In addition, your code should show evidence of handling errors. In your screencast, you may walk through elements of your code, or you can input data that will throw an error and show how you handle it without the app crashing. All code should have some form of error handling as best practice, so ensure you show it off during the screencast. Not doing so will mean this criterion will be scored low. You do not need to do unit testing but make sure to demonstrate error handing and validation in some way.

5. Code Quality

The quality of your code is how well-written and maintainable your code is. The higher the quality of code will make it easier to work with, less likely to have bugs, and can be maintained over longer periods of time by yourself or others.
High-quality code will perform intended tasks correctly and efficiently; it should be readable and easy to understand with proper naming conventions and detailed comments. It should be consistent and follow coding standards and best practices (for this assessment, it will be for .NET/C#). You should also use common techniques, such as code reuse, to improve the quality of your code.

6. Deployment

As we are working in a cross-platform framework, you should be able to show evidence that your app can compile and run on multiple device types. You will need to show that you can deploy to Android and at least 1 other device (Windows, iOS, tablets). This can be through emulators or physical devices. Due to the university labs only running Windows, we cannot deploy to iOS in the labs directly. However, you are welcome to try to deploy your code on an iOS device if you have the means to do so. It will count towards a deployment, but it is not a requirement to deploy to iOS.

An example of deploying to just 1 Android device would be:

An Android phone emulator

• An Android phone physical device
• An Android tablet
  To score higher marks, you will need to deploy to an Android device and at least 1 other type. Some examples are:
• An Android phone emulator AND an Android tablet emulator
• A physical Android phone AND an Android tablet emulator
• An Android phone emulator AND an iOS phone emulator

If you use a physical Android phone and an Android phone emulator, this will only count as 1.

7. GitHub Usage

You will be assigned a GitHub repository (repo) that will be set up by your tutor. There will be a very basic sample project to begin with that you can modify and work on. You can also completely push your own project if you prefer. You will need to sign up to GitHub if you do not have an account.

You must ensure the most recent version of your work is committed or published on GitHub before the deadline. Any work committed after your deadline will not be considered towards the mark of this assessment. Instead, your tutors will revert to the project's latest version before the deadline. As part of the assessment, you must demonstrate good working knowledge and continuous usage of GitHub, not single-push repos.

To get the highest marks, you need to regularly commit to your repository. You should commit little and often. For example, if you are committing over 200+ lines of code in one commit, you likely need to break your commits down more. We also do not expect you to submit every tiny change, such as spelling mistakes or changing a single variable name. A good rule of thumb is to commit when you add something like a new function or UI element.