EE2800 Mobile Web Application Project Version 3.0 18 November 2019 Mobile Web Applications EE2800/1 College of Engineering, Design and Physical Sciences Digital Design Assignment Course Digital Design BSc, Level 2 Module Code: EE2800
Module Name: Mobile Web Application Project Assignment Code: EE2800/1 Set By Professor Marios Angelides and Dr Paul Kyberd Contribution to Module Mark This assignment contributes 100% to the total mark for the module. Submission Deadline Wednesday, 06 May 2020 (Wiseflow); any work submitted after this deadline is deemed to be late and will be penalised according to the standard published penalties. Aim To develop an understanding of and to develop the necessary skills to design, deploy and integrate client side and server-side technologies for mobile web application development. Objectives • To demonstrate the ability to design and implement a responsive mobile application
• Implement an application such that content, presentation and interaction are separated
• Demonstrate an ability to use the facilities of the client device to enhance the performance of the application
• Documentation the design and technology decision taken in a clear, concise and coherent manner
NOTE: This is an INDIVIDUAL assignment and as such is subject to the University’s rules and regulations on copying and plagiarism, and to the policy on late submission and the ensuing penalties. EE2800 Mobile Web Application Project Version 3.0 18 November 2019 Mobile Web Applications EE2800/1 Learning Outcomes
1. To provide a foundation and understanding of the architecture, the technologies and some of the key issues involved in mobile web application development.
2. To introduce some of the key components used in mobile web application construction and to develop the necessary skills to deploy such components. Brief The requirement is to display photographs held in an external database on a server. The photographs must be stored with suitable metadata. • They should have the date on which they were taken • They should be associated with a comment or description which is a text string • They should be tagged with a type (semantic tagging). The type should be one from a list of possible types. You may choose the categories which you implement examples include: landscapes, cityscape, …; friends, family, …; dogs, cats, flowers, … You should choose categories which correspond to your interests • They should be geo-tagged. In other words, associated with a physical location. That can be using the GPS co-ordinates, the longitude and latitude, Ordinance Survey Grid. We will allow place names, but this will be considered only a partial fulfillment of the requirements • You should be able to view the contents of the database on your mobile device • The mobile interface should be responsive – at a minimum it should display appropriately in portrait and landscape mode, but ideally on different size screens. • You should be able to display the images selected on the basis of the associated meta-data • It should be possible to display images in time order, and display the other metadata • It should be possible to display images from the same location, and display the other metadata • If should be possible to display the images according to semantic type, and display the other metadata • It should be possible to display the images according to semantic type ordered by date, and display the other metadata • It should be possible to display the images by location and ordered by date, and display the other metadata. • It should be possible to take a photograph on the mobile device and transfer it to the server database, along with the appropriate metadata, from within the app. • The database should be sharable with friends, but protected by a username and password combination. Friends can view, but only you can add to and modify the database. • It should be possible to display images from nearby on the basis of location information EE2800 Mobile Web Application Project Version 3.0 18 November 2019 Mobile Web Applications EE2800/1 When implementing the solution, it should work on any device, however you may choose a device whose simulation is available under Chrome and develop for that device, and we will mark the submission primarily on that device. Credit will be given for a solution which is completely device agnostic. We recommend you start by creating and populating the database on the server and only, when that is working, attempt to upload images from the mobile device. The list of requirements follows an order which could provide the starting point for your implementation schedule. There is no need for you to follow any particular order in implementing the features, however by being guided by the order of the list it will be possible to provide intermediate releases of the software which display some of the required functionality. In the marking we will give more credit to an implementation which provides some of the functionality in a complete and usable manner, than an implementation which includes all the points but not implemented correctly. We will give credit for including an implementation plan in the documentation. These are the minimum requirements on which to base your implementation. The application is meant to demonstrate your mastery of the techniques covered in the respective supporting study blocks. It is your responsibility to create an application that demonstrates a full range of techniques, demonstrates comprehension of the course aims and includes a rich solution that addresses a full range of the techniques and technologies covered. Notes on the implementation Please read carefully, failure to respect these requirements will mean you may lose marks Modern mobile devices have a lot of processing power, this means that, as clients, they are able to take much of the computing load when delivering a service to the user. This has obvious advantages over earlier paradigms, it means that as the number of users increases, the amount of processing power available for the service increases. In order to leverage this power, much of the work for the service must be undertaken by the mobile devices and javascript provides a language for this task. The module EE2702 will provide you with the necessary knowledge (in the lectures) and practical experience (in the workshops) to use phones as part of a client-server service and the assessment EE2800 provides you with an opportunity to demonstrate your mastery of these ideas. The description of the task which you need to complete is deliberately left open so that you EE2800 Mobile Web Application Project Version 3.0 18 November 2019 Mobile Web Applications EE2800/1 have an opportunity to demonstrate your creativity and the full range of your skills. However, the module is about mobile devices and your ability to program them and so certain constraints must be observed. Firstly, no credit will be given to any part of the solution which uses PHP, since this is a server-side technology. To be clear a complete solution which uses PHP and not Javascript will be a fail. In addition, students often wish to use one of the frameworks which make creating good looking apps with powerful functionality less time-consuming. Since the object of the assignment is to demonstrate your mastery of javascript, HTML and CSS, we would prefer that you coded simply without a framework. If you use a framework, you should make it clear which framework you have used, with suitable references and you MUST provide an appendix where you describe how the framework achieves the functionality which your application displays. It is probably easier to just to hand code the app. Remember that in a well-designed app, the content the presentation and the interaction should be separate, which means that the CSS, HTML and J
avascript files should be separated for the most part. The submission will penalised if this is not the case, unless you make a clear case for breaking this rule in the documentation. The module EE2701 will provide you with the necessary knowledge and skills in the server-side technologies to complete this assignment. You will need a basic database of 4 relations: user, address, photograph, photographer. You may add more relations as you see fit. This database grants access to the EE2800 user with a password secret. Note that the password field itself is encrypted in the database. The user’s login ‘ID’ is their email address and the associated ‘password’ should be strong (that is contain upper, lower and numeric digits with a minimum length of 8 characters). To support configuration of the web application, our expectation is that data such as database URL, name, user and password will be configurable using an XML document (see below for an example). XML Configuration A typical configuration file would be of the form: someurl anon whoever apassword 10 photographers > EE2800 Mobile Web Application Project Version 3.0 18 November 2019 Mobile Web Applications EE2800/1 Client-Side Assessment In the list below apart from ii) where it says display images it implies you should also display any associated metadata. Not providing the display of the metadata will be considered to be a fault. You may choose not to display the metadata, for some of the selections, if you provide a convincing argument in the documentation. Making metadata display user selectable is an acceptable enhancement. It will not be possible to show all the images simultaneously on the mobile device, so there must be a method for selecting images to display. For location information you can use google maps, open maps, or any other method you choose. Functionality Marks i. Responsive 5% ii. Display an image downloaded from the database 15% iii. Display an image with metadata 10% iv. Display images in date order 5% v. Display images on the basis of location 5% vi. Display images on the basis of semantic tagging 5% vii. Display images on the basis of sematic tagging and/or location ordered by date 5% viii. Take a photo and upload it to the database with time, semantic and location information. 20% ix. Make the database accessible to two classes of user, you and friends. You can upload friends can only view 5% x. Allow an option to show images from “nearby” 5% xi. Quality 20% We are happy to answer any questions on acceptability of design and technology decisions. We see this as the equivalent of discussing requirements with the client. Questions and their answers will be posted on Blackboard Learn. When asked to provide something by a client you will be given a list of requirements, but in the final analysis, the client will respond to the overall quality of the product. To cover this, we have included 20% for overall quality; you will note that you may get an A without gaining any marks for quality, but anything you provide under any of the headings, which shows particular imagination or technical mastery will attract quality marks. You may get quality marks, even for an app which does not provide all the requested functionality, if some of the functionality is of high quality. If you make an early start in considering the assignment you will be able to tackle problems of (client-side) implementation in the workshops where assistance is available. The assistance will of course be the identification and solution of a general problem and not help completing the assignment. Server-side Assessment The implementation must separate content (HTML) from presentation (CSS) and from behaviour (JavaScript). The server-side implementation uses PHP EE2800 Mobile Web Application Project Version 3.0 18 November 2019 Mobile Web Applications EE2800/1 scripting and employs MySQL as the database layer. The five use cases at the end of this document demonstrate a typical (not exhaustive) basic implementation: Login, Photographers, Pictures, Upload, Photographer. These five use cases are not independent, they operate collectively as part of an integral HTTP workflow. The user starts with a list of photographers, from which specific image lists can be requested. Images in the ‘public’ domain can be directly ‘viewed’, whereas those categorized as ‘private’ can only be viewed by first login into the system. Subject to login constraints new images can be uploaded onto the system and new photographers may be defined as necessary. Server-side Implementation Marks Database Layer 50% PHP layer 50% Submission Information The deadline for submission without penalty Wednesday, 06 May 2020 (Wiseflow). After that date the current published guidelines for penalty will be applied. You are required to submit a single archive file (i.e. a ‘zip’ file) via Wiseflow. Your archive should contain the following: 1. Two separate reports, one each for the server-side and the client-side that clearly and unambiguously address the implementation in terms of how you have met the requirements.
Each report should contain an introduction, an architectural overview and details of the application you have built from the respective points of view. The operation of the application should be clearly, but succinctly described, and while small code ‘snippets’ may be used within the reporting, their size and usage should be limited to simply documenting your engagement and to help show how you have used client-side and server-side scripting in the implementation.
If external frameworks etc. are used as part of the solution, their usage must be acknowledged in the documentation. This is particularly the case if using a responsive web development framework, any customisation of the framework must be clearly documented.
2. A working copy of the project folder for the developed application that includes all source code and any third-party frameworks etc. if used. Credit will be given for achieving a working system, which demonstrates a good grasp of the principles of software engineering.
The script and CSS in the source files must be appropriately EE2800 Mobile Web Application Project Version 3.0 18 November 2019 Mobile Web Applications EE2800/1 commented to explain their function and to demonstrate your understanding of the technologies involved and their operational usage. Instructions on how to install the application must be included in the submission Finally The application is meant to demonstrate your mastery of the techniques covered in the respective supporting study blocks. It is your responsibility to create an application that demonstrates a full range of techniques, demonstrates comprehension of the course aims and includes a rich solution that addresses a full range of the techniques and technologies covered. EE2800 Mobile Web Application Project Version 3.0 18 November 2019 Mobile Web Applications EE2800/1 Login Use Case Client-side Server-side The client clicks on a login link or button located in the photographer’s page (the applications ‘index’ page) and is presented with a login form with entries for the ID and password. The form itself is required to support the necessary client-side validation to ensure the entries are required and meet the expected requirements of email ID and strong Password. The user enters data and submits the validated form. The form is submitted using a JSON based AJAX request. The system harvests the HTTP request parameters submitted by the form, constructs an SQL query and validates the ‘ID’ and ‘Password’ against the database table using the secure prepared statement: If the user does not exist: A JSON login failure object is echoed to the response. Otherwise: The user’s details, their name as a minimum are persisted in the session; the existence of these details in the session indicates that user is
logged into the system. A JSON login success object is echoed to the response. 2. On successful login, The login status in the Photographers page is updated and persisted in session Storage. When logged in additional functionality is made available to the client in terms of ‘upload photograph’ and define ‘new photographer’. The buttons controlling this functionality in the page are made active and or made visible. Finally, the form is ‘hidden’. Photographers Use Case Client-side Server-side 1. The client requests the photographer’s page; this page is the applications index/home page. The system firstly checks if configuration data exists in the session and if not loads it from the XML configuration file and persists it in the session for use with database connectivity. The system then queries the database to obtain a result set containing no more than 10 photographers. Based on these results the script formats a list of photographers where each photographer is represented by an anchor link that targets the script associated with the images use case, this link contains a query string identifying the photographer. This link supports an AJAX enabled ‘onclick’ handler that is subsequently used to add picture related content to the page. To accommodate that content, each link is followed by a photographer specific hidden empty div element. This div will be subsequently populated when the client clicks on the ‘photographer’ link in the page. 2. The client is presented with a list of photographer specific link. EE2800 Mobile Web Application Project Version 3.0 18 November 2019 Mobile Web Applications EE2800/1 Pictures Use Case Client-side Server-side 1. The user clicks on a link in the ‘photographers’ page associated with a photographer of interest. The links ‘onclick’ handler first checks if JSON content associated with this individual is available in the browser sessionStorage and if so: The div associated with that Photographer is located and the JSON is used to dynamically format a series of ‘display’ anchor links that target the specific image file. These links contain URLs that directly access the file and display it in a separate tab or perhaps one of the many JavaScript image libraries could be used. If a image is private and the user is not logged in, then the display link is ‘greyed’ out and not available. You may wish to toggle the visibility of this image content when clicking on the photographer link. 2. If the photographer specific content is not in sessionStorage then a request is submitted to the server side using AJAX. The system harvests the ‘photographer’ request parameter, builds an SQL query that uses a prepared statement to selects the images associated with that individual and queries the database to produce a result set of image data. The image data is formatted as JSON and echoed to the browser. 3. The AJAX call-back function locates the div associated with that individual and uses the JSON to format a series of ‘display’ anchors as described above. Finally, the JSON content is cached in the browsers sessionStorage using the photographers as the key. EE2800 Mobile Web Application Project Version 3.0 18 November 2019 Mobile Web Applications EE2800/1 Upload Use Case Client-side Server-side 1. The user clicks on a ‘upload’ link in the ‘photographers’ page and is presented with an image ‘upload’ form with entries for the Title, Number, Date image was taken, Location where image was taken, description of the image and a flag indicating if the image is free or not and finally a file input. The form itself is required to support the necessary client-side validation to ensure the entries are required and meet the expected requirements The form is submitted using a JSON based AJAX request. This operation is only available to clients who are logged into the system; the system checks the login status in the session and if not, returns an appropriate error (see below). The uploaded file type is checked to see that the type conforms to jpeg. If conformant the system harvests the image related HTTP request parameters, builds the file location path (that depends on whether the image is free or not) and builds a SQL query that uses a prepared statement to insert the image record into the images table and finally moves the file to the new location (i.e. public or private). Depending on the success or otherwise of the operations an appropriate JSON status message is echoed to the response. 2. The AJAX call-back function updates the interface with the ‘upload’ status message and hides the form. Photographer Use Case Client-side Server-side 1. The client clicks on a new photographer link or button located in the photographer’s page (the applications ‘index’ page) and is presented with a form with entries for the First Name, Last Name and Date of Birth. The form itself is required to support the necessary client-side validation to ensure the entries are required and meet the expected requirements. The user enters data and submits the validated form using a JSON based AJAX request. This operation is only available to clients who are logged into the system; the system checks the login status in the session and if not, returns an appropriate error (see below). The system harvests the HTTP request parameters submitted by the form, constructs and executes an SQL query to insert the photographer in the photographer table using a prepared statement. Depending on the success or otherwise of the operation an appropriate JSON success object is echoed to the response. 2. If successful the AJAX call-back function refreshes the page – it reloads the index page thereby adding the new photgrapher to the list. Otherwise it updates the interface with the ‘photographer’ status message and hides the form.
