The final user interface for the project will be an Android (and maybe an iOS) device. However, as I am still studying the Mobile course, I am not in a position to declare formally that this will be so. If I find that I can’t complete the tablet interface in time, I will present to the course Tutor (and to here) what is known as a “wire frame” of the software. This means that I will mock up the tablet pages to demonstrate how it would work.
In the meantime, of course, there has to be something out there that can be used to see what is happening so I have built a no-frills web site where the functions of the software can be tested. This actually isn’t hard or wasted because the tablet will use the same web requests as a browser – albeit that the tablet request will be hidden within the software rather than being seen. The basic request for the Menu page looks like this:
It will look slightly different from the tablet because the tablet will send an encoded password in the payload. This, again, is due in a future iteration.
I have banged on about the various servers but one last reminder will not go amiss. This request is received by the Web Server (as shown by the WS prefix). In spite of what I said about these other servers, the Menu request is managed by the Web Server and doesn’t get handed off. The browser formats the returning HTML as a web page. In the tablet version, the HTML will be parsed out and reformatted for the tablet view. The temporary menu looks like this:
As you can see, the page has been formatted using the railroad name and the railroad logo for the user: demo. The menu is spilt into two parts as there is additional functionality used in the display of the locos, cars, cabooses and coaches. Again, this functionality is due in a future iteration. In the meantime, each of these options presents a list of items stored in the database under each category. Clicking on “Show Locos” will send the following link back to the Web Server
This request will be handed off to the Web Controller (note that the URL has changed to use WC rather than WS) as:
which will format up a further url. This time, for speed, the database request will be for the whole user record. The locos will be extracted from that. This is the call:
OK, so this is different – 192.168.1.94 is the internal address of the Riak server. 8098 is the port that Riak watches. /riak/demo/userdata is asking Riak to return whatever is in the bucket “demo” for the key “userdata”. This happens to be a big Json from which we can strip out the Loco Json. This will be fed back up the chain until the Web Server gets to format the Json into the web page that we require.
Most of this data is obvious. The “On Train Status” and “Single Unit” will be discussed when we get to the Decision Engine in a couple of iterations time. The other static data items look pretty much like this. However, along with the other items below the line, Locos have an item that could be updated outside of the routing schedule. This is the Location field. In the next iteration, we will get to discuss PUT operations. These update data. The use of these will be if we have to change the current location of any loco or car. The entry for each line in the Location column will actually be a drop down list containing all possible locations for this item with the current one selected. It will be possible, once this has been implemented, to change the location by selecting another from the list and then sending a PUT RESTful request back to the server to update the Riak record.
The last item on the Menu page is the “Next Train” link. This is a first pass implementation of the Decision Engine (DE) – albeit a very simple one. Clicking here will give you something like the following (but each click generates the next train so this will change as we go through the available list of trains and the list will repeat itself. Anyway, here is a typical screen:
You can look all of these entries up in their appropriate pages. The lines that need some explanation are:
Cars:This is a list of cars to be attached to the loco, each one separated by the | character.
Caboose: Likewise – the actual car can be seen on the Caboose page.
Destination: This is a list separated by the ; character of the start, intermediate and stopping locations for the train.
(Note to self: Why use | in one place and ; in another – I must fix that!).
The final DE will carry out a complex set of rules to determine a train. For this initial pass the DE just grabs an appropriate loco, a set of cars and a caboose (or a set of coaches if it is a passenger train) no matter where they are on the layout. This is know in the trade as a “quick and dirty fix”! No matter, it gives us some data to play with.
I think that now we are nearly at the end of the first iteration. I will complete the next TMA and then resume describing the next steps forward.