This assignment, TMA 03, is associated with Block 3 of the module and consists of two parts: 1.A taxi-sharing app, which you met in Block 3 Part 1 (Questions 1–3). 2.An app of your own invention (Question 4). Part 1: Taxi-sharing app In Block 3 Part 1 you met an idea for a taxi-sharing app, the scenario for which is briefly summarised below. Hundreds of people work at the Open University campus in Milton Keynes, and many of them travel between the train station and the campus. The University puts on a shuttle bus at peak hours – but what happens if you travel outside of peak hours? You either catch a taxi (which is costly), or you try to catch a local bus that takes ages and is pretty infrequent. What if there was an app that would let users travelling to the Open University campus link up with others also travelling there and share a taxi? In Questions 1–3 of this assignment you will explore different aspects of this idea. The questions are based mainly on Block 3, with some material from earlier blocks and some research by you. If you are not able to complete every task you should still do as much of it as possible, and include any code you have written in your solution document, since any parts that are correct will still earn some marks. Question 1 User interface for mobile web app This question is concerned only with the presentational layer of the proposed app: its user interface. At this stage you are not required to implement any business logic. a.As outlined above, employees of the Open University might welcome an app that allowed them to share taxis between the train station and the campus. Most employees have their own mobile devices, some running iOS (e.g. iPhones, iPads), some running Android (e.g. Samsung, Google Nexus) and a few running other operating systems. List five functional requirements for the proposed app, following the format for functional requirements in Table 2 of Block 3 Part 5. For each of your requirements state one possible obstacle, technical or non-technical. Only brief answers are required. (10 marks) b.Save a copy of the provided project TM352-TMA03-Skeleton as TM352-TMA03-Solution. Navigate to this folder in the command prompt and execute the following two commands to ensure that the android platform is properly installed in the project: cordova platforms remove android cordova platforms add android In this project, the file www/index.html is an incomplete skeleton of a form with five actions, as follows. A user can: 1. register to use the taxi-sharing service using their Open University Computer Username (OUCU) (e.g. abc123) 2. volunteer to share a ride by specifying the time slot (i.e. start time, end time) and pick-up address (e.g. train station, Open University campus) 3. request to share a ride by specifying the time slot (i.e. start time) and pick-up address 4. cancel all offers or requests associated with their OUCU 5. start or stop a timer that updates the matching orders at regular intervals. Complete the parts of www/index.html where indicated by the comments. When you have done this, copy the body of www/index.html into your solution document, highlighting your changes. (10 marks) c. Next add a canvas for a Google Map, where indicated by the comments. Build your project and then test the user interface with respect to a Google Nexus 5 phone. Copy the body of www/index.html into your solution document, highlighting your changes. Also include a screenshot showing the results of your test. Note: on some Android phones, the app will request permission to access geolocation, but when that is closed will display a warning stating that the 'application does not have sufficient geolocation permissions'. The problem is that the app does not wait for permission to be granted, but fails immediately. If this occurs, the app should be stopped (which may mean force-stopping it from the Applications Manager on the Android device) and then restarted. Once restarted, it should detect that permissions have been granted and not report the above error. (5 marks) Question 2 Business logic for mobile web app This question is concerned with implementing parts of the business logic for the proposed taxi-sharing app, so that it can be deployed as a Cordova app on an Android device. We have developed a RESTful web service (described in Table 1) that handles all the persistence and storage required for the taxi-sharing app. Table 1 RESTful API Service endpoint and example responses GET POST DELETE http://137.108.93.222/ openstack/ taxi/ users?OUCU=user1 {"status" : "success", "data" : [{"id":"3","oucu":"user1"}] } {"status" : "fail", "data" : [{"reason":"No matching records"}] } On "success", returns the user's id *, otherwise returns "fail". Insert a taxi user with {OUCU}. N/A http://137.108.93.222/ openstack/ taxi/ orders?OUCU=user1 {"status" : "success", "data" : [{"id":"70","start":"2017-01-26 12:30:00", "end":"2017-01-26 13:00:00","type":"1","address":"Walnut Tree"}, {"id":"71","start":"2017-01-26 22:54:00","end":"2017-01-26 23:54:00","type":"0","address":"Open University"}] } {"status" : "fail", "data" : [{"reason":"No matching records"}] } Returns all the offering (type=0) or requesting (type=1) orders on "success". On "fail", 'No matching records' is shown. Insert an order with corresponding fields such as {OUCU, start, end, type, address}. Remove the orders for the given OUCU. http://137.108.93.222/ openstack/ taxi/ matches?OUCU=user1 {"status" : "success", "data" : [{"start":"2017-01-26 12:30:00","hire_oucu":"user1", "hire_address":"Walnut Tree","offer_oucu":"user1","offer_address":"Walnut Tree"}, {"start":"2017-01-27 11:28:00","hire_oucu":"user11","hire_address":"Open University", "offer_oucu":"user1","offer_address":"Open University"}] } {"status" : "fail", "data" : [{"reason":"No matching records"}] } On "success", returns the matched taxi hiring, where "hire_oucu" shows the person who volunteers the taxi, "offer_oucu" shows the person who requests the taxi, the start time of the request is between the offering start and end time, and the hire and offer addresses are the same. On "fail", 'No matching records' is shown. N/A N/A http://nominatim.openstreetmap.org/ search/

?format=json&countrycode=gb [{"place_id":"96368024","licence":"Data © OpenStreetMap contributors, ODbL 1.0. http:\/\/www.openstreetmap.org\/copyright", "osm_type":"way","osm_id":"141734330","boundingbox":["54.5963713","54.5965609","-5.9236627","-5.9233236"], "lat":"54.59646635","lon":"-5.92349534474763","display_name":"Open University, May Street, Town Parks, Belfast, County Antrim, Northern Ireland, BT1 3JL, United Kingdom", "class":"building","type":"yes","importance":0.201},…] Given the

, returns the detailed address information, including the latitude as "lat" and longitude as "lon" attributes. N/A N/A * The user's id is just the database key for the user's record and should not be confused with the OUCU. These services can be used by invoking HTML methods on the appropriate URIs (i.e. service endpoints). The responses from the services are in JSON format. Here 137.108.93.222 is a server at the Open University preconfigured using an OpenStack instance. We have also included a third-party service from OpenStreetMap that provides a map. If you want, you can try a few of these services out from a browser to get a feel for how they work. To send a GET request you simply need to point your browser to the URI concerned. If you want to try POST or DELETE we suggest using a browser plugin, such as the RESTClient add-on for Firefox, or the Advanced REST Client for Chrome. If you copy and paste the URIs above, ensure that no escaped space characters (%20) get inserted. The task in this question is use these RESTful services to implement a number of functional requirements described below. To get you started we have already implemented two of them, illustrating how to send HTML POST, GET and DELETE requests. You should not begin to answer the question until you have studied these examples. As you implement each functional requirement, you should copy the code you have written for that requirement into your solution document. There is no need to copy the entire file: only the relevant code and a few surrounding lines so that your tutor can see where the code was added. Highlight the parts you have written. The functional requirements (FR) for the taxi-sharing app are as follows. Those in italic have already been implemented in the skeleton file. FR1 The app shall register, volunteer, request, and cancel taxi sharing for an employee with valid a OUCU FR1.1 Registering by posting a user OUCU (already implemented) FR1.2 Volunteering a taxi by posting an order with OUCU, start time, end time, address, and type=0 FR1.3 Requesting a taxi by posting an order with OUCU, start time, address, and type=1 FR1.4 Cancelling all taxis by deleting orders associated with a OUCU (already implemented) FR2 For an employee, the app shall list available matching taxi locations on a Google MapFR2.1 The matching taxi can be found by getting from the matches interface FR2.2 The Google Map location (latitude, longitude) can be found by posting a REST service request to the OpenStreetMap FR3 For an employee, the app shall notify when a taxi location is available within 10 seconds (already implemented). To help you with the tasks, in the www/js/index.js file of the skeleton project (note this a different file from the one you used in part (a)), you can already see the implementation of FR1.1 and 1.4, showing you how to use the jQuery JavaScript library to call RESTful services with GET, POST and DELETE requests. 1 // Implementation of FR1.1 2 this.register = function () { 3 /* Fetch the user ID from the "name" input field */ 4 var oucu = get_name_value('name', 'user1'); 5 if (oucu == "") return; 6 // Post the user OUCU using the "users" endpoint 7 $.post('http://137.108.93.222/openstack/taxi/users', { 8 OUCU: oucu 9 }, function (data) { 10 var obj = $.parseJSON(data); 11 if (obj.status == "fail") { 12 alert('User ' + oucu + ' is already registered.'); 13 } else { 14 alert('User ' + oucu + ' has been successfully registered.'); 15 } 16 } 17 ); 18 }; The function get_name_value on line 4 fetches the OUCU from the value of a name input field. Line 7 uses jQuery method $.post to create a POST request to the service endpoint http://137.108.93.222/openstack/taxi/users, which takes one argument, OUCU, and returns an argument data for the call-back function. On receipt of the data, which is a string value in JSON format, the jQuery method $.parseJSON is used to parse the string into a native JavaScript object obj. The structure of the object depends on the returned value. According to the example in Table 1, you can tell whether the response is a success or failure by looking up the attribute obj.status. To illustrate the use of GET and DELETE methods, we use the implementation of FR1.4 as an example. 1 this.cancel = function () { 2 var oucu = get_name_value('name', 'user1'); 3 if (oucu == "") return; 4 $.get('http://137.108.93.222/openstack/taxi/orders?OUCU=' + oucu, 5 function (data) { 6 var obj = $.parseJSON(data); 7 if (obj.status == "fail") { 8 alert(obj.data[0].reason); 9 } else { 10 $.each(obj.data, function (index, value) { 11 var url = "http://137.108.93.222/openstack/taxi/orders/" + value.id + "?OUCU=" + oucu; 12 $.ajax({ 13 url: url, 14 type: 'DELETE', 15 success: function (result) { 16 // alert("Deleted: " + result); 17 } 18 }); 19 }); 20 } 21 }); 22 }; Similarly to the earlier example, line 2 gets the OUCU id from the input field and line 4 gets the orders data using the GET request and $.get jQuery method on the orders RESTful API. Note that the response data is in JSON format, which will be parsed by line 6 as a JavaScript object. The data field of the object obj.data will be an array; each element of the array represents an order record. To delete the order, we use a loop $.each to issue a delete operation with the DELETE request by calling the $.ajax jQuery method, which has a slightly different syntax from the predefined $.post and $.get methods, in that 'DELETE' is passed in as an argument type, and the URL of this request needs to be parameterised by the order's id field (see line 11). The remainder of this question uses code from Block 3 Part 5. You are advised to study Part 5 (when available) before tackling this part of the question. For the implementation of FR2.2, you can adapt the code from Activity 13 in Block 3 Part 5 by positioning the geolocation markers on the latitude/longitude obtained from the GET method of the third-party OpenStreetMap RESTful service in Table 1. The implementation of FR3 largely reuses the code you are familiar with from Activity 6 of Block 3 Part 5. Here the function timer() at lines 6–8 calls updateMatchingStatus, which will be implementing FR2.1. The function start() at lines 12–16 defines the timer with an interval of 10,000 ms, i.e. 10 seconds; the function stop()at lines 20–22 clears the timer. 1 /** 2 * Use a second-by-second timer to update the matching status 3 * @returns {undefined} 4 */ 5 var timerId = null; 6 function timer() { 7 updateMatchingStatus(address); 8 } 9 /** 10 * Callback function to start the timer 11 */ 12 this.start = function () { 13 if (timerId) 14 clearInterval(timerId); 15 timerId = setInterval(timer, 10000); // every 10 seconds 16 }; 17 /** 18 * Callback function to stop the timer 19 */ 20 this.stop = function () { 21 clearInterval(timerId); 22 }; When you have finished this question, build and test the app. As well as including the code for each functional requirement in your solution document, you should include a screenshot of the running app. Your TMA submission should also include your completed solution project. Question 3 Using a plugin In this question we explore the possibility of enhancing the functionality of the taxi-sharing app by the use of Cordova plugins. Note that it is possible to earn marks on both parts of this question even if you were not successful in getting all the features to work in Question 2. a. Think of a way in which the functionality of the app could be enhanced with the aid of a Cordova plugin. Do some brief market research to provide evidence that the enhancement you propose is useful. Specify the additional functional requirement, which we will call FR4. Record the market evidence you have found and the design rationale for the enhancement. (6 marks) b. Document the process of selecting a suitable plugin, describing what possibilities you considered and the choice you made, explaining the reasons for your decision. (6 marks) c. Write the code that would be needed to implement the new feature as part of the existing taxi-sharing app. Include the code in your solution document, along with an explanation of how the code works and how the user would use the feature. (6 marks) d. Build your project and then test the app with respect to a Google Nexus 5 phone. Explain briefly whether or not the app worked as expected, and list any problems you observed. (2 marks) Part 2: Invent a possible app Question 4 In this question you are asked to think of an idea for a possible mobile app, investigate where it would fit into the market place, carry out an initial analysis of requirements, and do some informal market research. The question is based mainly on Sections 3.1 and 3.2 of Block 3 Part 5. Note that you are not asked to write any code for this question. a. Spend a little time thinking of an idea for a potential app. Then investigate the Android app market place for similar apps and create a feature table to look for any gaps that could be filled by the app you have envisaged. If necessary, think of an additional feature to give your app so that it does something that rival apps don't. (5 marks) b. Having identified the market gap, draw up a list of functional requirements for your app, in a similar format to the one in Question 1(a). (10 marks) c. Write a description of your app, telling potential purchasers what its purpose is and what features it offers. (5 marks) d. Sketch a wireframe of your app's user interface. This does not have to be a finished design, just a rough initial draft. You can produce it in anyway you like: you might use a software program of your choice, or simply sketch it on paper and scan or photograph the result. (8 marks) e. Carry out short interviews with two or more potential users, either face-to-face or electronically, to discover if they would consider purchasing the app, having seen its description and the mock-up of its interface. In your solution document include two short quotes, from different interviewees, to illustrate what feedback they gave on your app and its preliminary design. Say whether or not the response to your app was broadly favourable. (7 marks)