The Mobile Web Application Development (MWAD) module is assessed through a portfolio submission, which students are required to submit during the Fall Semester of 2024-2025 at the University of West London.
2025-03-13 02:12:21
Mobile Web Application Development
Mitigation & Resit Portfolio Assessment
IMPORTANT: Please be aware that if you obtained an acceptance for your mitigation application or that you are taking a resit from MWAD, the following is the correct assessment to do. If you submit the term assessment as mitigation/resit submission, it will not be marked. Resit/Mitigation assessment must be different than the assessment given during the term.
Assessment weight: 100%
Given Date: 21 January 2025 00:00
Submission Date: 21 March 2025 until 23:00
Submission type: Turnitin submission (as pdf) + a publicly accessible video component
Submitted to:
Submission includes Turn it in report which includes a video component link shared on a public streaming platform (e.g., YouTube, Vimeo, or UWL Panopto). The video length should be in between 6 – 10 minutes.
1.What is the assessment?
The Mobile Web Application Development (MWAD) module is assessed through a portfolio submission, which students are required to submit during the Fall Semester of 2024-2025 at the University of West London. This portfolio assessment involves evaluating a student’s competence through a collection of work, including a report, programming code, wireframes, and reflection of the software development process. As part of the assessment, students should develop seven different mobile applications, all to be created as native Android apps. To showcase their work, students must submit both a written report and a presentation video that outlines the development process of these seven applications.
Each application is detailed in the following sections, along with supplementary documents to guide students on how the applications should function. For each app, students must create and submit wireframes to demonstrate pre-development planning and compare these to the final versions to highlight front-end progress. Additionally, the video component should showcase the event-driven functionalities of the apps, developed in either Java or Kotlin.
Students are required to submit a report (with a format provided in the next section) and a video that reflects their development process. The video should not only demonstrate the functionality of the applications but also discuss challenges encountered, existing bugs, potential errors or missing features, as well as an overall reflection on the design and development process. Only one report and one video submission are allowed.
The next two sections cover the specific requirements for the report and the video.
2.What do I need to submit?
You only need to submit a PDF report which consists of 9 different chapter. Within this report, you should share your video demonstration link on the cover page. Each section of the report is discussed in detail in the following sections.
Cover page: This section should include student name, surname, id, course, module name, module leader (i.e., Dr. Cain Kazimoglu) and your video component link.
The link to the video component (e.g., the video presentation link) must be placed on the cover page and nowhere else. Please note that each student should submit only one video link, which must be publicly accessible to the marker(s) of the module.
2.1 Introduction: this section should indicate how many of the apps you successfully managed to develop. If there are bugs, errors, workarounds regarding the apps, these should be mentioned in the introduction part very clearly and honestly.
2.2 Wireframes and user experience: the initial design: The first step of designing an application is drawing the pre-development planning sketches which represent the user interface and interactions of the app. To achieve this, you will first need to do the wireframes – which are simple, low-fidelity visual representations of an app`s layout, focusing on structure and functionality without detailing design elements. Wireframes are used to map out the user interface and user experience before diving into the full design process. Therefore, with each application, you will need to complete one or more wireframes as these are your pre-development planning of the apps. Once wireframe(s) are done, you are responsible for creating the UI. The apps are finished, you compare these to the final version of your user experience. The comparison of this, and the final version of your application should be displayed and discussed in this section. You need to use a wireframe tool to draw your wireframes, and some of the popular choices are Figma, Balsamiq, Miro, JustInMind and many more!
Some applications require verification or validation of input data. If this is the case, you can display how you planned and implemented this both in wireframes and in the user interface of the application. Please bear in mind that this section should not include any code such as front-end/user interface code (i.e. XML code).
2.4 Back-end development challenges: This section should include the challenges you faced in terms of coding in each of the apps. You will need to provide code level discussions in this section such as what you were trying to do, and what was happening, and how did you solve the problem. If you did not overcome a certain bug, and this created several problems for you in an app, this is the section to mention and provide code level discussion.
2.5 Artificial Intelligence (AI) tools: This assessment allows you to use ChatGPT and other AI software development tools such as CoPilot, Blackbox AI or Google Gemini - Gemini is now integrated as part of Android Studio. If you had used any of these tools in this assessment, this section should clearly indicate which AI tools are used and in what area – e.g. front-end and back-end. If you used AI tools in the development of multiple native applications, these should be discussed individually for each application developed.
A very bad practice often repeated by students in the AI section is to simply write very vague lines such as “I used ChatGPT to create the recyclerView activity class in exercise 6”. Instead, explain why you needed to use the AI despite the fact that recyclerview was displayed to you in the class, how did AI code help you, and what enhancements you added on the top of the generated AI code. Another bad practice is simply copy and paste the code generated by AI tools and not even attempting to optimise the code. Please be aware
that it is possible for academicians to detect AI generated code, and should you copy/paste the exact code generated by AI tools, it is highly likely that your similarity is going to increase.
2.6 Reflection and discussion:
Reflect to your experience both in terms of front and back-end development. This is a section where students usually struggle to write or keep very short and lose a lot of marks. Therefore, use the following headings and discuss each with at least 5 sentences.
2.6.1. The completion of the work
Discuss if you managed to complete all of the applications. Are there any missing parts? If so, please highlight these: what is exactly missing and why?
2.6.2. A list of bugs
In software development, bugs usually emerge during the run time when applications attempt to run or trigger an event base action. Do you have any bugs in your applications? Did you manage to fix these bugs, or do they still exist? Please discuss these by providing application alias (e.g. in Pizza ordering app).
2.6.3. Above and Beyond
Did you go above and beyond and implement innovations to enhance your applications. An innovation is not a simple gimmick but rather a disruptive approach you might have applied on the top of the given requirements. As an example, you do not need to use Firebase for Application 7, but if you do, this is counted as going above and beyond.
2.6.4. Self-Critical Evaluation
Evaluate yourself, the portfolio assessment in general. Did you manage yourself well in this assessment? Did you manage to develop all of the apps? Was the module useful to you? Whether you write negative or positive comments, you will get full marks in this section so long as you are constructive and honest.
2.7 Conclusion: Did you manage to achieve what you aimed in this assessment? Do you think you learned a lot in this module? If you have to do this assessment all over again, what would you change or do? Finally, do you plan to enhance your work? If so, please discuss the future work in this section.
2.8 References: resource you used and cited in your report should be listed as a reference in this section with Harvard style (click the link if you do not know how to reference in Harvard style). Make sure to even cite/reference AI tools used.
2.9. Appendix: This section should include all back-end code regarding the application. Every single activity and class used should be copy/pasted here. All code should exist as text in your document. This section solely exists to detect your code similarity as it is going be used to observe any potential plagiarism issues. To avoid high similarity, make sure to change the code generated by AI tools used, as well as the tutorials you found.
3.What does the video component should include?
As mentioned above, on the cover page of your report, you need to submit a video link to show your demonstration. In this publicly accessible video, you should display wireframe pre-planning, briefly discuss if wireframes match with the final version of the UI, the functionality and the even driven run time of the apps, any bugs/errors and any enhancements done – and your overall critical evaluation of yourself. Please also display the back-end code of each app you developed and discuss the critical parts you struggled with in your assessment.
The video must be uploaded to a platform publicly accessible by your markers (e.g., YouTube, Vimeo,
UWL Panopto). During the marking, if your video is not accessible by the marker(s), the module leader will not contact you and ask for your video upload/access, so make sure that when you upload your video component, this is publicly accessible.
The video component should be at least 6 mins, at most 10 mins.
4.Applications
This section shows all five applications that are requirements of this assessment.
4.1. Button Interactions
4.2. Radio button and Spinner Interactions
4.3. Catalogue of items
4.4. Login Screen
4.5. Calculator with chain of operations
4.6. Inventory App (with database backend – can be SQLite or Firebase)
4.7. List of products and Basket app (with database backend – can be SQLite or Firebase)
Each application has a video showing how the apps would function. Please watch these videos as they can help you greatly in developing all 7 apps.
4.1.Button Interactions
Number of wireframes: minimum 2
This exercise practices arrangement of buttons on a screen with a background image. As shown from below, there are 5 buttons in the exercise and 4 of these are at the corners of the screen whereas the image button is located at the centre. When a button is touched, a message appears according to the location of the buttons. As an example, top buttons always display messages at the top region of the screen (above the centre button) whereas the bottom buttons show the messages at the bottom region (below the centre button). When the image button is touched which is at the centre, the toast message appears on the centre of the screen. You can decide/customize button colours, shape, and the background image of the application – you do not need to use exactly the same colours, or the background image displayed below. However, please pay attention that the toast message is a custom toast message which requires you to customize the colours and the content of the message. A video demonstration of the application is available, please check the relevant exercise video.
4.2. Button Interactions
Number of wireframes:minimum 3
The second exercise is based on practicing interactivity of radio buttons and a spinner. The spinner content is dynamically changed according to which radio button is selected by the user. As the user selects a radio button, a different content is being displayed in the spinner. When the user selects a radio button and the preferred content from the spinner component, the selected choices appear on a text view. Like the previous exercise, you do not need use the same content given below – as such you do not need to design a travel country/city application – the content can change as long as it makes sense within the application context. The following screenshots show how the application proceeds and there is a video shared in resources which demonstrates how the exercise should work.
As shown from above, initially, no city is selected in the spinner object. When a country is selected from among the given radio button choices, the cities available within country are listed in the spinner object. When the user submits, the selected content appears on a text vew.
4.3. Catalogue Application
Number of wireframes: minimum 3
This application practices horizontal and vertical scrolling and multiple activities. Initially, four different items are listed in a catalogue and the user can swipe to right (or left) to view the catalogue content. The catalogue is the main activity of the application, and when the user touches an item in the catalogue, more information about that specific item appears in the catalogue which is displayed on a new activity. From this new activity, the user can press “go back” button which takes the user to the main catalogue screen of the app. The following screenshots displays how the application should work. Both the item images and the information given are static content – which means you do not need to use a webservice or a database back-end for this application – you can simply embed the images and the information into the application itself.
In the above exercise, an animal gallery is listed which the user can browse horizontally to right (and to the left). When the user presses on the image of an animal, more information about that animal appears on a new activity. From this activity, user can press “go back” button to go back to the main catalogue screen where all items are listed. As described in previous exercises, the images and text content of this application can be customized by you – which means you do not need to develop an animal gallery or whatever text is listed above – you could decide what sort of catalogue items (images and text) you want to display in your own catalogue. A video demonstration of the application is available in the resources folder, please check the relevant exercise video.
4.4. Login Screen
Number of wireframes: minimum 3
This application practices a login exercise screen without the back-end database/web services part. In this exercise, two customized edit Text are used with floating text information which are dedicated for a username and a password field respectively. The fields have a validation and both fields do not accept less than 4 characters or otherwise the floating text displays an error. When user fills both username and password with 4 characters, the floating error is automatically removed. The user is also given 3 attempts to enter correct credentials and if this is not done within 3 attempts, the application closes automatically. Moreover, the right credential for the login is username: “admin” and password: “admin”. When the right credentials are entered, the login screen successfully goes to another activity which displays that the user has successfully logged in. The following screenshots display how the application should work. Similar to previous exercises, you do not need to design an application with the UWL logo however, you need to use a customized username editText, and a customized password editText with login and clear buttons. Additionally, the user should have only 3 attempts to enter the correct credentials. A video demonstration of the application is available in the resources folder, please check the relevant exercise video.
4.5. Calculator with chain of operations
Number of wireframes: minimum 3
You will need to design and develop a calculator which can perform chain of arithmetic mathematical operation which are addition, subtraction, multiplication, and division. The user is allowed to use fractional numbers or natural numbers in the calculator, however, once the user presses dot (“.”) sign, this cannot be repeated again for that specific number. As an example, the user can type 25.5 but they are not allowed to type 25.5.5.5. There is only one editText in the application and the calculator performs all basic arithmetic operations (+, -, *, /) based on the entered numbers. Bear in mind that once a number is entered and an arithmetic operation is pressed, the calculator remembers the entered number and performs the arithmetic operation entered with the new number the user is going to enter.
The following screenshots show how the application functions. Operations and their explanations are given below:
+
|
Addition
|
-
|
Subtraction
|
*
|
Multiplication
|
/
|
Division
|
=
|
Equals to which should show the result of an operation
|
.
|
Used for writing decimal numbers
|
C
|
Clears all operations, sets the initial value to 0
|
The most difficult part of this application is to perform chain of operations such as: 55 + 44 – 22 * 2.
Each time a number is entered, and an operation is selected afterwards, the next number entered by the user is going to be operated with the previous number entered. This chain of operations should be implemented correctly in the application. A video demonstration of the application is available in the resources folder, please check the relevant exercise video.
4.6. Inventory App
Number of wireframes: minimum 4
This application is aimed at practicing database usage via a mobile app through the perception of an administrator. The app is an inventory system where items can be added, deleted and updated. You will need to use SQLite or Firebase FireStore for this project. As shown from the following figures, the application is designed to keep an inventory stock managemeny system for an office. When the app opens, the user sees an interface where they can add an item and delete/update an existing item. To add an item, the user needs to enter item name, item type – which can be “Electronics”, “Furniture or General Office Equipment”, “Computer and Network Equipments” and finally “Other” – and the item quantity. The item name is added using an editText, whereas both item type and item quantity are spinners.
When an item is added successfully, this is displayed at the bottom of the add/update/delete interface as a list. The list can be a recyclerView list or simply a textview as show from the above figures. The list will expand as the user adds more and more items from the user interface to the stock. Each item is added with an autoincrement number and this is done automatically at the back end of the application. In other words, the user does not need to enter a primary key number from the application’s user interface.
In addition to adding to the inventory, the user can update any item that already exists in the stock. The app allows users to change items’ name, type and quantity. To do this, the user needs to toggle Update option by selecting the turn on button (i.e. enable/disable update). Having done so, the user needs to select the id of the item that is going to be updated, and the information regarding that item is placed to the editText and the two spinners used on the main user interface. Once changes are made, the user can click on the Update Item button to update the new information.
Finally, Delete item removes an item from the inventory. In the above application, you can either remove the last item or simply provide the same procedure as in the update and create a switch on/off button for the delete procedure. Once the delete switch is on, the user can select the item id – similar to how
update operation is done – and click on the delete item – which will then remove that item from the inventory of the app. Either way is accepted for this application. A video demonstration of the application is available in the resources folder, please check the relevant exercise video.
4.7. Products and Basket App
Number of wireframes: minimum 4
This application is aimed at practicing a list of products and a basket system via using a database back end. As shown from the following figures, when the app opens, it offers a list of products that can be added to a basket system. Once the user selects a quantity of the product they want to purchase, this can be added to the basket which opens a dialog window showing the list of products checked in the basket. From the dialog window, the user can either go to checkout to complete the purchase or stay on the products page to continue shopping. Each time a product is added to the basket, the dialog window expands.
When the basket dialog window is open, the user has also the option to remove a product from their basket. At this point, the user does not need to select the quantity to remove as the product itself all together is removed when “remove from basket” button is clicked
If the user chooses to “go to my purchase” option on the dialog windows, the application goes to a new page that shows the checkout. The checkout lists all items in the basketand the total amount that needs to be paid at the purchase. As there is no real purchase, this screen does not list any purchase action, but rather offers the option to go back to the main screen. If the user goes to the main screen, the app remembers the choices selected and thus the basket stays the same. A video demonstration of the application is available in the resources folder, please check the relevant exercise video.
5.How is the assessment going to be evaluated?
The assessment evaluation is 100 points, and each application is evaluated over 10 points. In other words, 7 different apps make up 70 points overall. The rest of the evaluation is distributed among expertise (i.e. professionalism), the video and the report quality.
A break down of the app evaluation is given below:
5.1. Wireframes and User Interface 3 pts
5.2. Verification of data and Back End Code 4 pts
5.2. Successful demonstration of the app 3 pts
Please be aware that individual marks are not given for User Interface, back-end, and demonstration of the app and instead, an overall mark over 10 is given for each tasks alongside with the feedback.
6.Anything else I should know?
Please submit your work on time as there is no guarantee you will get an extension and even if you do, this delays the marking process. Please be aware that as a student at University of West London (UWL), you are bound students’ rules and regulations which are available in Student Handbook. Please follow the guidelines regarding plagiarism.
Please read each section in this document multiple lines and highlight important parts you might likely to forget as this assessment documentation very descriptive.
Before you submit your work, make sure to pay attention to followings:
6.1. All submissions are done on Turnitin. Do not send an email to the module leader attaching your report or video link. This is unacceptable and not professional.
6.2. If you forget to put anything to your report and submitted your work, or that uploaded the wrong version of your report to Turnitin, you and only you are responsible to fix this. Please do not send an email about this to module leader. You are responsible to do this assessment correctly. If you realise that you made a mistake after the deadline, then you need to do a new submission – which means you need to apply for a mitigation. Therefore, please check your work 10 times before you upload it. Make sure that everything is in place in your report and the link for your video is working.
6.3.The word count for this assessment is 8000 words. This does not include the appendix section which should have all the codes of the applications in text format – not as a screenshot!
6.4.The video link you upload should be publicly accessible. If it is not accessible, the marker will not contact you. Your video should be in between 6 mins and 10 mins. Any video you upload that is less than 6 minutes or over 10 minutes will either be not accepted or penalised.
Good luck
100% Plagiarism Free & Custom Written, Tailored to your instructions