Mobile Client Server Application Assignment 2 | Mobile Application

Home Recent Questions Mobile Client Server Application Assignment 2 | Mobile Application

Drone logs view

When the Show logs button in the drone's page header is pressed the current date/time and latitude/logitude are added to the data structure used to store the drone log values being recorded, as in assignment 1. The log entries are saved in the device's localStorage . The drones logs page is shown with all the locally saved logs listed, as shown in Fig. 1. Note the view now has a Get … button on the left of the header bar. Also note the button on the boom is now a Back button. Pressing this should take the user back to the previous page (Drone view).

Send button

When the Send… button is tapped all the drone logs are sent to the local server (and saved in the file logs/logs.dat. The drone data is also saved to the cloud mongolab mongdb database set up for this purpose. You should provide a success or failure alert. In the success alert, show the data that has been sent. When a response is received another alert should indicate success or failure. When a drone's logs have been sent the drone local logs should be cleared from localStorage so that the drone page will not show the sent logs.

If the Yes button is pressed the Send logs dialog shown in Fig. 2 is presented and we return the drone view.

If the No button is pressed we just return to the drone's view page.

Get logs button

The Get logs button is used to search the mongolab mongdb database for all database entries that match the day for the drone records (Day 1 in the figure). The entries returned are shown on a new page as shown in Figure 3. The entries are to be shown below the Cloud drone log entries: label as shown in the figure 3. Again appropriate alerts need to be made when the request is sent and when a response is received. The Back button takes the user to the previous page and Home takes the user to the home page.

Server Side: node+packages and JavaScript server script

Our user data scheme has the following fields:

•day – one of {Day1, Day2, Day3, Day4, Day5}
•date –date and time stamp of log
•latitude –latitude of drones starting location
•longitude – longitude of drones starting location
•serial_no – drones ID
•pilot drone pilot
•key – key used for encrypting communication with drone
•contract_no– contract number for drone
•category – user of drone

This data is to be stored in the mongolab mongdb database in a drone_logs collection. Entries are also to be echoed (written) to a file in the ./logs directory of the local server in a file called logs.dat.

The server will have the following URL that provides requested services. The URL is based on

Your web service API will support these actions:

search/:query– searches for users in the mongoLabs database and returns all logs with that :query value. :query will be one of the day values {Day1, Day2, Day3, Day4 or Day5} to search for.

:drone/log – appends the drone entry to the local server file ./logs/logs.dat and to the mongoLabs drone_log mongdb databases logs collection.

Fig 4. Message flow from App to local disk storage and Cloud database

Fig. 4 shows the message streams in the application. Ideally the mobile device POST’s requests to the

BWand receives responses from the WWW. The node server listens for requests on a port. The requests data will be routed to the local mongdb database at mongoLabs. Requests for the information in the mongdb database would be returned to the node server for POST’ing back to the mobile device. The server should produce meaningful output each time a request is received or sent.

Your node server code will consist of a number of files; server.js will contain your business logic, common.js and config.js contains common utility functions and network configuration information. The server.js file will use express middleware to create a server and router to route the web service API to the handler code that writes the JASON data to your mongdb mongoLabs database, and returns data from this database to the mobile device. A sample of the kind of responses the server should produce is given in fig. 5