SWAMI Page 1 - Start of Day

The main html page that drives the app is the index.html.  It contains the includes to the script files used by AngularJS, the AngularJS related controller JavaScript files and the Worklight related JavaScript files.
The app.js file contains the routing that navigates the application to the relevant html files in the views folder.
(...and of course I had to have a logo that was somehow car/hot-rod related!)

The index.html file itself has very little inside it, just the logo image and the About and Contact Us button.  The html files located within the views folder are presented inside the section shown in the image below:

The app.js has a default routing value to navigate to the main.html file.  As you can see, the main html file contains href links that refer to the contents within the app.js file.  As shown here, the startOfDay link is coordinated by the app.js that will navigate to the html file that is specified.

The declaration of the app.js file includes the references to the routing (ngRoute) and the bootStrapUI (twitter bootstrap UI as AngularJS directives).  As you can see here, the routing defines the related html file in the views folder and the connected controller JavaScript file.


If you recall, we are making a sample that follows the "Day in the Life of...." a Restaurant Mobile Inspector, at the start of their day they synchronise their application to get the To Dos of the day.
The StartOfDay html file is very simple, it contains a button for the user to press and a status field to indicate the success code (or failure code and error message).  The button press action uses the AngularJS declaration to call a specific function in the controller JavaScript file.

The StartOfDay controller declaration includes:
$q - for the defer object that we need for async communications
$scope - needed for two way AngularJS data binding
$window - used to create an alert message for debugging purposes (sometimes it's easier on a device)
$location - used for having hardcoded navigation to a different route

When the user presses the button, the sync function will be executed.  This performs a check to see if the Worklight client can connect to the Worklight Server, if it can then it will then perform the tasks in the function called connected.  The first task in that function is to invoke the Worklight Adapter that is running on the Worklight Server.



You have to specify the name of the adapter, the procedure name and any parameters that are required (for this sample I've included a 'fromDate' and a 'userID' - this is assuming that in v2.0 I'll be creating a login module that onSuccess would have retrieved the userID and userName and stored it for usage on the device)

The Worklight Adapter that has been created has the connection details hardcoded as you can see below.  As I am running this on the same laptop, it's going to connect to 'localhost' and I've defined the ExpressJS inspectionApp.js to be running on port '1212'.

The Worklight Adapter Procedure itself is very simple, it uses the http://localhost:1212/ and then appends the path variable value to call the ExpressJS REST API, passing the parameters as defined.  The data is passed as JSON and a response it returned and passed back from the Worklight Adapter.


As you can see the controller is invoked and if an onSuccess is returned (200) then the returned .todos object is assigned to the $scope.todos are are then passed back to the html UI to be rendered to the user.
We use a deferred object to initialise the JSONStore and when successful using the .then (to make it synchronous) we wipe the existing ToDos that are stored in the JSONStore collection called 'Restaurants', once these have been successfully removed we re-initialise (I don't know why, but I found I had to do an init before every time I wanted to do something with the JSONStore - is this correct?  can I just put this in the JavaScript file to call the init before every function?) I then call to Add the restaurants passing the To Dos object array and this stores the data into the JSONStore.

The Restaurant.js file contains all of the functionality to do with the JSONStore collection.  As you can see there are 6(six) functions contained within and they all perform a variety of WL.JSONSTore.xxxx functions.


As you can see, I found some oddities (well, they caused me to scratch my head for a while) in relation to passing 'id' values that are used by the WL.JSONStore functions, the 'id' fields need to be cast to a Number() for them to work as you would expect.  Also, you can only do a search on a Document in the Collection (Row in the Table for the old skool database people) using the 'id' column that was created rather than a value that you might want to use.


 Now that we've managed to execute the StartOfDay and save the data to the offline data store (JSONStore), we now need to do something with it.  That is what we shall investigate on the next Page.

Comments