Coursework Submission Requirements
An electronic copy of your work for this coursework must be fully uploaded on the Deadline Date
For this coursework you must submit a single PDF document. In general, any text in the document must not be an image (i.e. must not be scanned) and would normally be generated from other documents (e.g. MS Office using “Save As .. PDF”). An exception to this is hand written mathematical notation, but when scanning do ensure the file size is not excessive.
For this coursework you must also upload a single ZIP file containing supporting evidence.
There are limits on the file size
Make sure that any files you upload are virus-free and not protected by a password or corrupted otherwise they will be treated as null submissions.
Your work will not be printed in colour. Please ensure that any pages with colour are acceptable when printed in Black and White.
You must NOT submit a paper copy of this coursework.
All courseworks must be submitted as above. Under no circumstances can they be accepted by academic staff
The University website has details of the current Coursework Regulations, including details of penalties for late submission, procedures for Extenuating Circumstances, and penalties for Assessment Offences. See HYPERLINK “http://www2.gre.ac.uk/current-students/regs” http://www2.gre.ac.uk/current-students/regs
Detailed Specification
Please read the entire coursework specification before starting work.
You are to create a mobile app to be used as restaurant rating application. The app will allow the user to find, add and edit restaurant ratings. The app will be called i-Rate. The features the app should support are given below
Features a) to f) are to be implemented as a hybrid app coded using PhoneGap
Features a) and c) are to be implemented as a native Android app coded in Java.
Feature h) can be implemented as either or both additions to the native android app or PhoneGap app.
1.1 Description of the application
a) Design app screen – Basic details input screen
Note that users must be able to enter all of the following fields:
Restaurant Name – required field
Restaurant type (e.g. Grill , Fast food, See food, etc.) – required field
Date and time of the visit – required field
Average meal price per person – required field
Service rating (e.g. Need to improve, OKAY, Good , Excellent) – required field
Cleanliness rating (e.g. Need to improve, OKAY, Good , Excellent) – required field
Food quality rating (e.g. Need to improve, OKAY, Good , Excellent) – required field
Notes – optional field
Name of the reporter – required fields
b) Design app screen – Restaurant rating screen
Base on the data entered using the basic details input screen, users can view restaurant rating screen which includes the entered details and total rating for each restaurant. The total rating is the average rating of service, cleanliness and food quality.
c) Implement forms validation
Required field means that the user must enter something in this field otherwise they will get an error message. Optional field means that the user can enter something if they wish but they will not get an error message if they don’t enter anything.
The app will check the input and if the user doesn’t enter anything in one of the required fields the app should display an error message to the user.
Once the details have been accepted by the app (e.g. no required fields were missing) it should display the details back to the user for confirmation and allow them to go back and change any details that they wish.
d) Store, view and delete the basic details and check for duplicate events
All the details entered by the user should be stored on the device in a Web database.
The user should be able to list all the details for all restaurants entered in the app.
The user should be able to delete all the details from the database.
e) Search
The user should be able to search for a restaurant. At its simplest this could mean entering or selecting a restaurant type and displaying the details of all information about that type. Ideally the user should be able to enter more details and search for a restaurant that matches.
f) Add a note input screen
The user may select one of the restaurants that they have entered and use this screen to enter information about something that is related to this restaurant (e.g. Restaurant name, Restaurant type, quality of the services). It is up to you how complex or simple you want to make this. At its most simple form the user can just enter a textual description of the restaurant.
The app should store all details entered on the device in a Web database.
It should be possible for a user to select a restaurant and display the report for that restaurant.
g) Features a) and c) are to be implemented as a native Android app coded in Java
h) Add additional features to either or both the Android or PhoneGap version of the app
Features a) to e) are the core requirements for the app. If you have implemented these and want to add some additional features, then you may. Any enhancements should be implemented in addition to NOT instead of the core requirements. The idea is that these features stretch your skills so be prepared to do your own research and feel free to show off! You can think of your own enhancements. Here are some possible examples:
• Allow photos taken by the camera to be added to the restaurant data stored
• Send social media messages (e.g. twitter) each time a report is added
• Save/Show the locations where the restaurant located
1.2 Report
Section 1. A concise table containing a checklist of the features you have been able to implement. Please refer to the features list given above in the specification. For example, you might write:
Feature
Implementation
a)
Fully implemented
b)
Fully implemented
c)
Fully implemented
d)
Implemented but sometimes it gives an exception. I haven’t been able to debug this
e)
Implemented but the app can only do a simple search by restaurant type
f)
I have created the user interface for report entry but the data is not being stored
g)
I have create a native restaurant of feature a) but not feature b)
h)
No additional features implemented
Section 2. A concise list of any bugs and/or weaknesses in your app(s) If you don’t think there are any bugs or weaknesses then say so though this is quite unlikely. Bugs that are declared in this list will lose you fewer marks than ones that you don’t declare!
Section 3. A brief (less than half a page) description of any special strengths of your app(s) that you think should be considered when awarding a mark. Please be very specific and realistic in this: vague statements such as “it is easy to use” or “it is well designed” will not gain you marks.
Section 4. Screen shots demonstrating each of the features that you have implemented. Give captions or annotations to explain which features are being demonstrated.
Section 5. An evaluation of your app(s). Write between 300 and 500 words evaluating the app(s) that you have produced. Be specific and justify any statements you make. Just saying things like ‘my app is well designed” without justifying the statement will not gain you any marks. Also explain how your app could be improved. Again, you need to try to be specific e.g. saying something like “It needs to be made more secure by adding security features” will not gain marks. Your evaluation should include, but need not be limited to, the following aspects of your app:
Human computer interaction (you will have a lecture on this)
Maintainability
Changes that would need to be made for the app(s) to be deployed for live use
This sort of discussion will form an important part of your final year project report so use this opportunity as a way of practicing your skills in writing an evaluation.
Deliverables
A brief demonstration (approximately 10) of what you have achieved. You need to demonstrate your App running on a machine in the labs or on your own laptop.
You will be asked questions about your implementation and be expected to show an understanding of the functionality you have implemented and the design decisions that you have made.
The date, time and place of the demonstrations will be announced on the Moodle page of the course.
Student didn’t attend demonstration (maximum mark for work is 20%)
A zip file containing all the files required to run your app(s). Please try to structure your work so that it is easy for the person marking your work to compile and run your app(s) if they need to. Any compilation, installation or running instructions should be included in a “readme” file.
If you have borrowed code or ideas from anywhere other than the lecture notes and tutorial examples (e.g. from a book, somewhere on the web or another student) then include a reference showing where the code or ideas came from and comment your code very carefully to show which bits are yours and which bits are borrowed. This will protect you against accusations of plagiarism. Be aware that the marker will look for similarities between your code and that submitted by other students so please do not share your code with any other students as this is considered to be plagiarism. Note that the upload of this zip file is a mandatory interim submission. It must be uploaded by the specified interim submission date or you will lose marks and are likely to fail the coursework.
A report consisting of all the sections described in section 1.2 of the detailed specification. This is the final deliverable.
Grading Criteria
Note that this coursework will not be marked anonymously. Student didn’t attend demonstration (maximum mark for work is 20%).
1st Class (90% to 100%)
A hybrid app coded using PhoneGap application fully implementing at least features a), b), c), d) , e) and f). Very few minor bugs or weaknesses. Exemplary quality code.
A working naïve android application (a and c) and two or more good additional features (h) to one or both apps.
Demonstration: able to show good knowledge of code implemented at the demonstration. Not only able to answer questions about how you did something but also why you chose to do it in a particular way and compare with possible alternative implementations.
Report complete, accurate and easy to read. Section 5 within specified word count, logically structured and making some insightful points about all three of the issues specified.
1st Class (80% to 89%)
A hybrid app coded using PhoneGap application fully implementing at least features a), b), c), d) , e) and f). Very few minor bugs or weaknesses. Outstanding quality code.
A working native Java android (a and c) and one or more good additional features (h) to one or both apps.
Demonstration: able to show good knowledge of code implemented. Not only able to answer questions about how you did something but also why you chose to do it in a particular way.
Report complete, accurate and easy to read. Section 5 within specified word count, logically structured and making some insightful points about all three of the issues specified.
1st Class (70% to 79%)
A hybrid app coded using PhoneGap application fully implementing at least features a), b), c) , d),e) and f). Very few minor bugs or weaknesses. Excellent quality code.
A working native prototype (a and c).
Demonstration: able to show good knowledge of code implemented. Not only able to answer questions about how you did something but also why you chose to do it in a particular way.
Report complete, accurate and easy to read. Section 5 within specified word count, logically structured and making some insightful points about at least two of the three issues specified.
Upper Second Class (60 to 69%)
A hybrid app coded using PhoneGap application fully implementing at least features a), b), c),d) and e) and a good attempt at f). Few minor bugs or weaknesses. Very good quality code.
A working native prototype (a and c).
Demonstration: able to show good knowledge of code implemented.
Report complete, accurate and easy to read. Section 5 within specified word count logically structured and making sensible points about at least two of the three issues specified.
Lower Second Class (50 to 59%)
A hybrid app coded using PhoneGap application fully implementing at least features a) and b), c) with an attempt at d), possibly with some bugs and weaknesses. Good quality code.
A working native prototype (a and c).
Demonstration: able to show good knowledge of code implemented.
Report complete including some attempt at section 5
Third Class (40 to 49%)
A hybrid app coded using PhoneGap application with a good attempt at feature a),b) and some attempt at c).
A working native prototype (a and c).
Demonstration: able to show reasonable knowledge of the attempted features.
Report mostly complete.
Assessment Criteria
Your app(s) will be assessed on the following criteria.
Features implemented. The number of features (listed as a to f in the specification above) that you have successfully implemented will have a big effect on your overall mark.
The quality of the application code you produce. Credit will be given for inclusion of meaningful comments in the code, use of the sensible naming standards (e.g. for packages, classes, variables, and methods), code layout (e.g. indentation to make the structure of “if” statements and loops clear), avoidance of unnecessary duplicate code.
The user interface. This is not a course about user interface design but credit will be given for making your application as pleasant an experience as possible for the user. Examples of good practice are: allowing the user to choose options rather than their having to type in input, sensible default values, validation of input, and meaningful messages. Credit will be given for showing the use of a range of appropriate features from the Android GUI API.
Your report will be assessed on the following criteria.
Are all the required sections included and completed properly?
Does the report give an accurate reflection of what you have achieved?
Is the report clear and easy read? Does it follow the structure specified?
Is the evaluation (section 5) realistic and does it show that you have really thought about your app(s) and the specified issues and how they would need enhancing to be ready for live deployment. Do you show insight into the complexities of app development and the challenges of balancing the various constraints involved?
PAGE \* MERGEFORMAT 2