Mobile Web Application Development

Portfolio Assessment

Assessment weight: 100%

Given Date: 30 September 2024 00:00

Submission Date: 6 January 2025 until 23:00

Submiss450ion type: Turnitin submission (as pdf) + a publicly accessible video component

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 does the report should include?

As mentioned earlier, students are required to submit a report that consists of several sections. This report must be uploaded to Turnitin as a PDF file. Please avoid submitting a Word document,as this can often lead to changes in formatting and structure. The report is divided into nine sections, which correspond to the chapter titles that should be included. Some chapters, such as Reflection and Discussion, contain subheadings, meaning the content should be further divided and discussed in detail.

2.1. 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. Do not provide separate links for each app; all applications, along with your development and reflection process, should be explained in a single video. If the video is not publicly accessible or cannot be accessed by the marker(s) at the time of grading, you will not be contacted, and it will be assumed that no video component has been submitted.

2.2. Introduction: this section should briefly discuss whether you have successfully achieved and developed all of the applications. If there are any errors, absent parts, applications you were not able to finish or any other business - you need to mention these in this section. Please be upfront and honest, inform your marker on what you managed to accomplish, and what was not done or have errors/absent parts in your work. Additionally, if you sought to go above and beyond, clearly highlight in which applications you did this and what enhancements were implemented.

2.3. Wireframes and User Experience: This section should focus on wireframes and the user interface of your applications. While guidance is given to you in each application regarding how the apps should work – these guidelines are not set in stone.As an example, you can change the theme of an application or completely use different pictures or even a completely different layout. As an example, in application 3, you are asked to complete a Pizza order app, however, this can be changed to “make your own bowl” app with an Asian cuisine theme. The theme of an application can be changed, and you are highly encouraged to do so in order to avoid high similarity in your report.

Before you start developing the applications, you will need to do some pre-development planning. The first step in designing applications is to decide what the user interface (UI) should be and how it will function. To create the UI of applications, 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). Provided wireframes and the developed user interface should be labeled as figures and be discussed in this section, and you do not need to provide any code – only the wireframes and the UI of your app. In other words, XML code of the apps is not needed in your report submission.

2.4. Back End development: this section should include critical sections of your Kotlin/Java code. Please do not discuss every line of code in this section but rather focus on the parts that were challenging for you and/or difficult to overcome during the development. The quality of the work you present in this section is more important than the quantity. Therefore, instead of discussing each activity or class you implemented, discuss how you improved your code to overcome the challenges you have faced, what decisions were taken, what was the original code? What did you end up writing to fix the errors and how this can contribute your skillsets that are potentially useful and valuable in mobile development. If you did not overcome a certain bug, and this created several problems for you, this is also a good section to mention.

2.5. AI and CoPilot tools used: This assessment allows you to use ChatGPT and other AI software development tools such as CoPilot, Blackbox AI or Google Gemini – which 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 Artificial Intelligence (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 application, these should be discussed individually for each application developed.

A very bad practice often repeated by students is to simply say “I used ChatGPT to create the recyclerView activity class in exercise 6”. Instead, explain why you needed to use this, how did it help you, and what enhancements you added on the top of the ChatGPT code.Another bad practice is simply copying and pasting the code generated by ChatGPT and not doing any modifications on the code. Please be aware that it is possible for academicians to detect AI generated code, and this usually increases your similarity in the report. Therefore, make sure to be very clear and upfront about how you used these tools and what sort of modifications were made on the top of the AI generated code.

2.6. Reflection & Discussion: what was planned, what was done right or wrong in this assessment? Bugs, Errors in your code/apps should be mentioned in this section very clearly. What did you learn throughout this assessment?

Reflect to your experience both in terms of front and back-end development.This is a section student 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.

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?

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).

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.

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: Do you think this was a successful work of yours? Did you get any external help? Speak your mind freely and be critical of yourself. You can also mention/recognise your module leader here if you believe the work given is aligned with industrial level software development. 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). Please be aware that just because you are allowed to use resources (e.g., YouTube videos, CHATGPT), and show references, it does not mean that you did not commit plagiarism if your similarity check is very high. This is explained in detail down below.

2.9. Appendix/Code: This is the section where you should put all Java/Kotlin code. In a previous section, you should have discussed all of the code, here, you put all back-end code for similarity check. You will need to name each activity/class/fragment and copy/paste the Java/Kotlin code under this section.

All back-end code (Java/Kotlin) should exist in text format in your in your report (in appendix or in other sections). Do not take a screenshot of code or display code as images.Additionally, the code/report similarity must be lower than 35% in your entire report.You can use video tutorials or AI tools to find solutions to the tasks, however, be aware that you are responsible to keep your code as original as possible, so you do not get high similarity in your document. Just because you reference a video tutorial you used to solve a task; it does not mean that you own that work – or that you did not commit plagiarism.

When generating content with AI tools, always optimize the code to lower similarity and a potential detection of AI usage. As an example, you can create functions to do repeatable patterns, change variable names used by AI, avoid duplications of code and re-factor the code as much as possible.

3. What does the video component should include?

As mentioned above, the PDF report is not the only component you need to submit in this assessment. On the cover page of the 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 module leader,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 describes all four applications that are requirements of this assessment.

4.1. Cute Icons App (practices Layouts, ImageView, Textview and Button Interactions)

4.2. Travel from London App (practices radio buttons, spinner, custom layout)

4.3. Pizza Ordering App (practices checkboxes, arithmetic and logical operations)

4.4. Catalogue of items app (practices images in an array, dynamic information, optional external intent)

4.5. Register and Login app (practices creation of realistic forms, sharedPreferences/files verification and validation of data – optionally the use of database or web services)

4.6. Contacts App (practices instant search in a collection, optional exploration of dynamic contact adding to phone memory)

4.7. Library Book Reservation App (practices a basket or a reservation system with dynamic pictures and data. This means that the pictures and the data of each item come from external sources – such as a local database, a remote database or simple webservices such as a JSON storage)

Each application has a video showing how they function. Please watch these videos as they can help you greatly in understanding how the applications work. The theme of each application can be changed; however, the functionality should be the same. As an example, instead of a library reservation app, you can develop a hotel reservation system.

4.1. Cute App

Number of wireframes needed: 1

This exercise practices arrangement of images on a screen and basic button interactions. As shown from below, there are a number of images arranged in a specific way and each one of these images are clickable/touchable.When the user interacts with the images, a textView informs the user which image they interacted with a distinct colour. By default, the “clear text” button is not visible but when the user interacts with the images, the button appears on the screen which gives the option to the user to take back the app to its original stage. The use of FrameLayout and/or LinearLayout is suggested in this app to arrange the images and the buttons. Please be aware that you do not need to use the same images or colours in this assessment. Please check the supplementary folder to view the video that shows how the app functions.

Going above and beyond is completely optional in each application. For this exercise, you can go above and beyond by embedding open licensed sound files associated with the animals being displayed on the app. Therefore, when an animal icon is touched, a sound associated with that animal can be heard. As an example, when the dog icon is touched by the user, a dog barking sound file can be played once.

4.2. Traveling in/from London

Number of wireframes needed: 1

This exercise practices radio button and spinner component usage. Additionally, custom layouts are needed in order to create the user interface of the applications. As shown from below, the user is offered a Travel mode from/in London which are Boat, Train and Airplane. The user must select one of these travel options. When a selection is done, the spinner displays a series of destinations – which is the second selection the user needs to complete. For example, if the user selects “boat” as a travel mode, the spinner object displays “Greenwich Boat Ride”, “Westminster to Kew Cruise” and “Thames River Sightseeing” as options. The displayed option in the spinner directly depends on what is selected in the radio group of buttons. Assuming the user selected the “Train” option as travel mode,then the spinner object displays “Brighton”, “Bristol” and “Birmingham”. Once the user completes the travel mode and the destination selection, they can either clear their selection or press on the submit button. When the clear button is pressed, all selections are cleared – as in no radio button is selected. When the submit button is pressed. Then the title of the selected destination and some brief information is displayed on the app. Please be aware that this app does not need to be a travel app, but the use of radio Buttons and spinner should function in the same way. Please check the supplementary folder to view how the app functions. Please check the supplementary folder to view the video that shows how the app functions.Going above and beyond is completely optional in each application.For this exercise, you can go above and beyond by showing the information on a new activity with a picture of the destination. As an example, instead of Greenwich Boat Ride opening on the same activity, this could be opened in Activity2 with a picture of Greenwich Cutty Sark, the title and the information. A back button can also be added to return back to the main activity.

4.3. Pizza Ordering App

Number of wireframes needed: 1

This exercise is based on practicing interactivity of checkboxes, buttons, and arithmetic and logical operations in mobile programming. As seen from below, there are several topping options the user can select from and add on the top of a pizza base to make their own pizza. Each topping costs a specific price which is listed on the given user interface (UI) as well. By checking the check boxes, the user can add the toppings on the pizza which also results an icon for the relevant topping to be visible on the ingredients selected part. Once the user is happy, they can touch/press the order your pizza button to make an order, or alternatively, they can press/touch clear order to clear all of the toppings. As the user adds the toppings, the total price needs to be paid changes accordingly. Please check the supplementary folder to view the video that shows how the app functions.

Going above and beyond is completely optional in each application. For this exercise, you can go above and beyond by showing the actual pizza being formed as the user adds the ingredients. This means that in addition to the image of the ingredients displayed, the top pizza image is going to change dynamically each time ingredients are added/removed by the user.

4.4. Catalogue App

Number of wireframes needed: 2

This application practices horizontal scrolling and dynamic button and image button interactions. The titles, the text, the images are all dynamically fetched from arrays, HashMap or other type of collections.

Initially, four different items are listed in the 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 at the bottom of the browsable icons, the information regarding that item and a picture appears on the screen. The user can browse the catalogue either by clicking/touching the small images of the items at the bottom navigation bar, or simply by interacting Previous and Next buttons. The following screenshots displays how items and the selections. Please check the supplementary folder to view the video that shows how the app functions.

In the above exercise, an animal gallery is presented which the user can browse horizontally from left to right (or from right to left). The user can use the bottom navigation picture bar to browse the catalogue or simply interact with the previous or next buttons. Any fading or sliding animations that are added to the image gallery can be an attempt to go above and beyond. Additionally, you can create a navigation menu to offer the same image gallery options as an alternative side menu.

4.5. Register and Login App

Number of wireframes needed: at least 3 (login, registration, welcome screen)

This exercise practices the creation of registration and login forms in order to deliver a realistic sign up and sign in experience. The application opens with a login screen which allows the user to login to the system. Naturally, login only works if the user already has completed a registration. If the user does not have valid credentials, they can touch on the register link (which is an underlined textview) and go to the Register Form. On the register form, the user needs to fill in details such as their full name, their sex by birth, the year they were born, a valid username and password.There are several validations in this form to ensure that the received data from the user are consistent. As an example, all text fields must be filled and one of the radio buttons regarding the sex should be selected. Additionally, if a username is already taken before or if the password and re-password fields do not match with one another, the user is notified about this. Once a valid registration is done, the user is notified, and they can use their credentials to login to the system. All the information defined during the registration is visible to the user when a successful login is done.

Once the user successfully logged in, they can see their information that was entered by them during the registration. The only option offered fundamentally on this screen is to log out from the system when the user wants to do so. Please check the supplementary folder to view the video that shows how the app functions.

Going above and beyond is completely optional in each application. For this exercise, you can use an actual database persistency – such as SQLite that is integrated in Android OS, or even better, a NoSQL database such as firebase to save and display the records. You can also allow each user to upload their picture dynamically should you want to do so.

4.6 Phone Contacts App

Number of wireframes needed: at least 3 (main, searched query, call to contact)

This application practices the use of RecyclerView with dynamic content and an instant search functionality with SearchView component. Additionally, when a contact is touched, an intend is triggered to call to that contact’s number.

You will need to use a recyclerView in this exercise with a custom layout attached to the recyclerView to display several information about a number of people – such as pictures, full name and other info.In this exercise, each item in the recyclerView is referred to as a contact. Initially, all contacts are listed in the recyclerView with their pictures, name,and email addresses.When the user searches for a name of a contact (which queries both name and surname), the recyclerView automatically refresh to show the matching results of repeating characters. As an example if the user types “ et “ , the recyclerView displays Ethan Matthews and Emma Bennett since both names have et in their full names. Once the user finishes the search query, the results are automatically displayed – there is no need to press any button or the enter key. When the user selects/touches a contact on the list, the phone calls the phone number of the selected contact.

In this exercise, adding contacts to the phone memory during the creation of the recyclerView is above and beyond. If you seek to go above and beyond, add each contact to the phone memory when the recyclerView is created. If you do this successfully, you will see the contact details when you trigger the internal intend to call the contacts’ number from the recyclerView.

4.7 Library Book Reservation App

Number of wireframes needed: at least 4 (main, reservation dates, reservation success, checkout)

This application practices the use of a reservation system done on a data repository such as a direct web service (e.g. JSON web service), a NoSQL database (such as Firebase) or a relational database (e.g. SQLite). When the application runs, a series of items are loaded into a RecyclerView via the webservice/database. In the following case, this is a JSON web service where a JSON is located. The Internet images can be read in a recyclerview using Glide or Picasso – which are both powerful image loading libraries.

Having loaded the values to the recyclerView, the books are displayed on the application with a reserve book button. When the user presses on the “reserve book” button, a datePicker is displayed to select the date range for the reservation of the selected book. Once a successful range is selected, the book is reserved. The user can repeat this process as many times as they like and each time a book is reserved, this is displayed in an alertBox with the selected range. At the end of each reservation, the user can either go to checkout or stay on the same page. Should the user prefer to go on the next page (i.e. checkout), a summary of all reservations is displayed. From the checkout screen, the user can either go back to the list of books available where the user can alter their reservations or simply close the app. While the following figures can provide an idea of the workflow of this app, the best way to understand the workflow is to watch the videos recorded in supplementary documents. While a recyclerView is needed for this app, reservations can be done in many different ways, so using a datePicker or an alertBox for noticiations is not a must in this exercise. You can design your own UI as long as the same options are given to the user and the workflow is the same. If you seek to go above and beyond in this exercise, you can use FireBase database instead of the JSON web service.

5. How is the assessment going to be evaluated?

The assessment evaluation is 100 points divided into 7 apps where each app is 10 points. Each app is marked individually according to three main categories:

5.1. Front-end design and User Interface 3 pts

5.2. Back End Code 4 pts

5.3. Validation of input, verification, and Professionalism 3 pts

In addition to 70 points that can be collected from the apps, the portfolio is evaluated in three more categories which are Professionalism, Report and Video Demonstration. These three sections exist because building a portfolio does not only rely on programming skills and academic integrity and the quality of each submission is also evaluated.

5.4 Professionalism 10 pts

Professionalism covers how students approached the work in general, their pre-planning, and how far they sought to go above and beyond. This section primarily tackles if students have done pre-development planning with wireframes and whether or not these are followed. Additionally, professionalism covers clear and easy documentation, realistic design of user interface matching with the wireframes, an object-oriented approach that prioritizes the minimum repetition in the code. Professionalism is also academic dignity which means your honesty and owning your own work are very valuable. Clear mentions of what was achieved, and what was not achieved, what lessons learned and solely being the owner of your own work and mistakes are all part of professionalism.

5.5 Report 10 pts

 The report should follow an academic tone and should easily be followed. Bugs, errors, enhancements should be highlighted early on in the report. The given chapter titles must be used and clearly addressed. Any research done; AI support, Chat GPT usage and so forth must be clearly identified and demonstrated with examples, Finally, the word count given must be followed.

5.6 Video Demonstration 10 pts

The video must professionally be recorded and presented. The video should not use any AI support – such as an AI voice. The students must use their own voice to create the videos. Only one video component should be recorded and submitted. The video should not only include a demonstration of the apps but provide a progressive presentation of how these apps are designed and developed. The wireframe of each app should be briefly displayed. Additionally, the codes written by you (the back-end code) should be displayed in the video. The most challenging parts, bugs that exist and enhancements made to the top of the given requirements should be mentioned. The video link must be provided on the cover page of the report.

6. Anything else I should know?

Please submit your work on time as extensions/mitigations often result your work to be evaluated much later in the semester. 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 be aware the plagiarism can be a major offense, and the consequences of these might even result you to lose your degree. Please see: https://www.uwl.ac.uk/about-us/policies-and- regulations/academic-offences-regulations#Major