Background

The MegaMax travelling sales staff have a requirement for a mobile app which has already been given the name ‘MegaMax Sale’ to present product information to potential clients. The information is to include product descriptions, product pictures, and the standard asking price. Through negotiation, sales staff are allowed to give clients a discount for larger orders or for widgets that are being promoted.

Once an order has been compiled and the prices have been agreed, the sales staff can then send in the order to the company. The cost of the order has to include VAT. The order information together with the time and the location of the sale will be sent to MegaMax to be added to their records. A salesperson can review their journeys by reviewing the places where an order was made.

Since MegaMax salespersons bring their own smart mobile devices, some of them running iOS (e.g. iPhones, iPads), some of them running Android (e.g. Samsung, Google Pixel), the mobile app should be developed using Apache Cordova. For the purposes of developing a demonstration prototype, we assume that most of them use Android devices; therefore, you are only required to test the mobile app on the Android platform.

For your development work you may use any text editor and the Cordova command line tools, utilising any of the methods discussed in Block 3 Part 0. Remember that you only need to submit the www folder, which will be the same regardless of which development option you have chosen.

Part 2(a)

Part 2(b)

Part 2(c)

As described earlier, a REST API has been prepared to facilitate the management of MegaMax Sales, so that you do not have to worry about the storage of data. What you need to do is to make use of the API URLs explained in the “EMA Database and API” guide, to implement the required functional requirements.

The Functional Requirements (FR) for this app are as follows:

FR1 The app should make an order as if the salesperson is at a client site with a valid OUCU and password for the salesperson and the client id:
- FR1.1 Validating the OUCU starts with a letter and ends with a number.
- FR1.2 Navigating the widgets catalogue (with Previous and Next buttons) and display of widget images, in addition to the description and asking price.
- FR1.3 Adding the currently displayed widget to the order items, including the amount and the agreed price.
- FR1.4 Displaying the sum of ordered items and adding VAT to the agreed price of each of the order items at 20%.

(12 marks)

FR2 For the salesperson to review their performance:

FR2.1 Displaying a Map for the area around the current location of the salesperson when at the client’s premises and placing or viewing an order.
FR2.2 When clicking on Place NEW Order to start an empty order, displaying the orders along the day’s journey with markers, where the location of client’s addresses are used to place the markers.

FR2.2 could be implemented in a number of ways. We think the easiest way is that when the new order button is clicked, a new order is created in the REST API. And when add to order is clicked the current widget shown is added to the order in the REST API. However you may implement this in other ways if you wish. Describe how you have implemented it in your guide.

There may be other FR you can think of given the supplied interface (for example moving between orders) this functionality is not required. However if you have problems implementing the above some credit may be given by the markers for ‘bonus’ functionality such as navigating orders.

If you are unable to get Cordova working you will get partial marks here for implementing the FR as a web app.

(10 marks)

Once you have completed your implementation you should produce a guide, which covers:

The functionality you have implemented (what the app does). You may well wish to include some screenshots of the app as these will illustrate the functionality you have achieved. This should be written with the end user in mind. If you failed to fully implement some functions then do state this in the guide and you can also outline problems you encountered.
Instructions on installing and configuring the additional plugins that you have used. This description should be sufficient for a third party to take your source code and reproduce your application.
If you failed to fully implement some or all functional requirements then state this in the guide and outline problems you encountered and how you attempted to overcome them including appropriate evidence.

The maximum word count for your report for this question is 500 words. This count includes titles and figure captions. There are no penalties for exceeding the limit, but any words in excess of 500 will not be marked.

(4 marks)

How to submit your solution

In your code, where you have implemented a functional requirement please insert a simple comment. The marker will search for this to validate your work. E.g. // FR1.1 Validating the OUCU starts with a letter and ends with a number. Service endpoints and example responses GET POST DELETE http://137.108.92.9/openstack/api/widgets?OUCU=user1&password=password “status” : “success”, “data” : [“id”:”8″, “url”:”http://137.108.92.9/openstack/images/widget1.jpg”, “pence_price”:”10″, “description”:”General Purpose Threaded Coach Bolt Bright Zinc-Plated M10 x 180mm”, “id”:”9″, “url”:”http://137.108.92.9/openstack/images/widget2.jpg”, “pence_price”:”12″, “description”:”Coach Screw 10 x 50mm”] “status” : “error”, “message” : ” 401 – invalid username or password” On “success”, returns the widget id, image url, price and description; otherwise returns “error”. N/A N/A http://137.108.92.9/openstack/api/orders?OUCU=user1&password=password “status” : “success”, “data” : [“id”:”6″, “client_id”:”2″, “date”:”2017-01-05 00:00:00″, “latitude”:”99.00000000″, “longitude”:0, “id”:”8″, “client_id”:”1″, “date”:”0000-00-00 00:00:00″, “latitude”:0, “longitude”:”-20.00000000″] “status” : “fail”, “data” : [“reason”:”No matching records”] Returns all the orders placed by the user with the given OUCU with the order id, “client_id”, date and location on “success”; otherwise, returns a message why it has “failed”. Note that when the order was created without specifying the value of latitude or longitude, they may be stored as “null” instead of floating point number. To avoid this problem, you can simply make sure to only create orders with actual values for latitude and longitude, e.g., 0 and 0. Insert an order with corresponding fields such as client_id, date, location. On deletion, the order will be marked as not confirmed. http://137.108.92.9/openstack/api/order_items?OUCU=user1&password=password “status” : “success”, “data” : [“id”:”10″, “order_id”:”6″, “widget_id”:”3″, “number”:”12″, “pence_price”:”45″, “id”:”2″, “order_id”:”6″, “widget_id”:”4″, “number”:”10″, “pence_price”:”111″,”id”:”8″, “order_id”:”10″, “widget_id”:”10″, “number”:”1001″, “pence_price”:”599″] “status” : “fail”, “data” : [“reason”:”No matching records”] On “success”, returns the matched order items, where “order_id” refers to the order’s id, “widget_id” refers to the widget’s id, “number” refers to the number of items and “pence_price” refers to the agreed price. On “fail”, no matching records are shown. On success, create a new order_item if the widget has not been added, otherwise the order_item will be added to the order. http://137.108.92.9/openstack/api/clients?OUCU=user1&password=password “status” : “success”, “data” : [“id”:”7″, “name”:”fred bloggs”, “address”:”45, something road”, “phone”:”01234 567 89″, “email”:”fred@bloggs.com”, “id”:”8″, “name”:”Fred Bloggs”, “address”:”55, something road”, “phone”:”01234 567 89″, “email”:”fred@bloggs.com”, “id”:”9″, “name”:”Fredina Bloggs”, “address”:”45, something road”, “phone”:”01234 567 89″, “email”:”fred@bloggs.com”] Returns the detailed id, name, address, phone and email of a client. Add a client, where the address will be updated by the GPS location. N/A
Please also paste this code (from the comment to the end of the implementation of the FR) into your Solution document.
The report should follow your code in your Word document. The report is required to gain the marks allocated to the other parts of the question. By documenting the functionality of the app (and any limitations, etc.) and how to run your app, you are assisting the marker in evaluating and testing your app and understanding the challenges you faced.
Note there are few if any marks for submitting a solution from TMA03 with minor alterations if it does not satisfy the new requirements. We are looking for you to demonstrate your understanding by using the new API provided as part of this question. You may also make use of the code provided to you in TMA03 if that helps you.

The Database and API

Before implementing the functional requirements read the EMA Database and API guide and then return here to look at the examples of API calls below.

RESTful services (responses are in JSON format)

The call listed below is to an API called Nominatim (http://nominatim.openstreetmap.org/). This mapping application can be used to generate detailed information on the location of a client. In general a call should have the form:

http://nominatim.openstreetmap.org/search/

?format=json&countrycodes=gb

Given the

this returns the detailed address information, including the latitude as “lat” and longitude as “lon” attributes:.

[“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,…]

So, for example, the address of the client with id of ‘1’ in the clients table is given as “555 Silbury Blvd, Milton Keynes MK9 3HL”. Using this address in a URL, the Nominatim application will return a JSON structure with more information. So the call

http://nominatim.openstreetmap.org/search/”555 Silbury Blvd, Milton Keynes MK9 3HL”?format=json&countrycodes=gb

returns the structure:

[

“place_id”:”71155256″,

http://www.openstreetmap.org/copyright”,

“osm_type”:”way”,

“osm_id”:”32144305″,

“boundingbox”:[“52.0441649″,”52.0445506″,”-0.7567538″,”-0.7558532″],

“lat”:”52.0445506″,

“lon”:”-0.7558532″,

“display_name”:”Silbury Boulevard, Central Milton Keynes, Milton Keynes,

South East, England, MK9 3AG, United Kingdom”,

“class”:”highway”,

“type”:”unclassified”,

“importance”:0.5

]

You can find out more about Nominatim at http://wiki.openstreetmap.org/wiki/Nominatim.

In the other API calls in the table, 137.108.92.9 is a server at the Open University preconfigured using an OpenStack instance.