@@ -21,14 +21,14 @@ The scientific research of this project will be the research for an intuitive de
The first part of this document will describe the global information needed for the second part of this document. This division is made for a simple reason. The ones that only care about the global information are served by the first part and the ones that are interested in how this application came to be are served in the second part of this document. Note that an understanding for how this application was made, the information of both parts are needed.
\part{Discovering the needs}
\part{Discovering the subject}
\section{Flood Simulation System}
The \emph{simulation} system already exists and runs in the cloud. That means it does all the calculation for the client and it's not important to know at which physical computer it runs. The system can calculate simulations by providing parameters about a certain area. For instance, the location and how much water you want to simulate. When a simulation is submitted and calculated, the simulation is stored. With http calls(GET or POST) to the system it returns a set of simulations that are present. The important thing to note is that the simulation consists of images that have to be displayed on a map, let's say Google Maps. The flood simulation system performs a complex simulation with the height map of the area. The height map holds detailed information about the height of an area. With this data, the flow of the water can be calculated and turned in to images. These images are used by the client application, this an important part of this project.
Not only does the system calculates the flow of water but it also calculates the estimated route that people take. It can calculate how much people would survive a simulated flood, keeping in mind that this project is all about saving people, this is interesting information.
\subsection{Flood API}
The API is a REST api that return JSON formatted string. It's a client server system where requests are done by the client and the appropriate data is transferred back to the client. With this data, information about a certain simulation can be displayed. The data can be in the form of an image or information in .csv files. The .csv files can be plotted and displayed in as a chart or graph. See part two for more information about the returned payloads.
The API is a REST api that return JSON formatted string. The API functions as an interface to get the data of simulations and to start new simulations. It's a client server system where requests are done by the client and the appropriate data is transferred back to the client. With this data, information about a certain simulation can be displayed. The data can be in the form of an image or information in .csv files. The .csv files can be plotted and displayed in as a chart or graph. See part two for more information about the returned payloads.
New simulations are not done on the same server but done by HR Wallingsford
\section{Flood Simulation App}
...
...
@@ -37,8 +37,9 @@ As stated in the introduction the application is meant for tablets, but not spec
This solution is Titanium Mobile, the Appcelerator \cite{Titanium-Appcelerator}. Titanium Mobile can build mobile applications that are in fact native applications. By programming in Javascript and call functions to create native elements the application can be created. The framework builds semi-native code, in the contrary to previously discussed PhoneGap. The development for this platform is fast and an application for both iOS and Android are quickly of the ground. But there is also a disadvantage by using Titanium. The applications are big, around 11MB no matter what. Because of the fact that the logic will still be in javascript(compiled), Titanium has to ship their javascript engine to the device. But not only do they take a lot of space on the storage device, it also has trouble with memory, see this blog-post\cite{memoryleak}. The blog-post discusses this issue, both developers and users discuss this issue in the reactions. Although this blog post refers to version 1.6 and 2.0 is already out, it's a threat to this project that can pop-up unexpectedly.
Moreover developing and testing on iOS provides expected behaviour and a large part of native elements are supported, for Android the native elements are mostly \textbf{not} the elements you thought they would looked like. To reach cross-platform apps the developer needs to constantly keep track if they're building an element for iOS or for Android. It might be stated that the functionalities of different platforms are not evenly supported. iOS is far out the most supported platform. Which only provides an advantage if the project only meant to run for iOS. The idea of Titanium Mobile is great, it works fine but will delay developing time when you truly want to reach crossplatform.
Moreover developing and testing on iOS provides expected behaviour and a large part of native elements are supported, for Android the native elements are mostly \textbf{not} the elements you thought they would looked like. To reach cross-platform apps the developer needs to constantly keep track if they're building an element for iOS or for Android. It might be stated that the functionalities of different platforms are not evenly supported. iOS is far out the most supported platform. Which only provides an advantage if the project only meant to run for iOS. The idea of Titanium Mobile is great, it works fine but will delay developing time when you truly want to reach crossplatform. Also, keeping in mind that this application needs a map that supports overlays(the simulation images). By searching trough the documentation \url{http://docs.appcelerator.com/titanium/2.1/index.html#!/api/Titanium.Map}, the only thing it supports is adding an annotation. An annotation is only a marker placed on the map with the ability to get de latitude and longitude of the marker. To sum this up, Titanium lacks support for both platform and map object, at the same time it can surprise the developer in an unpleasant way by taking a lot storage and a buggy garbage collection.
Buillding crossplatform and creating native elements could mean a risk for completing the application. A browser is the only thing that ha s the most equality on both device, i.e. both Android's and iOS's native browser is based on the webkit browser. Webkit is an open source web engine that is used by both Safari and Chrome
\subsubsection*{Javascipt frameworks}
As already explained, PhoneGap only provides the possibility to create an app out of a website. This website can be build in any way the developer likes, using web technologies supported on the native device. There are frameworks that can speed up the development to make an intuitive application. Two frameworks that are considered are: jQuery Mobile \cite{jQuery-Mobile} and Sencha Touch \cite{sencha}.
\begin{description}
...
...
@@ -116,7 +117,7 @@ The application will be used on tablets so a lot of space can be used. Working w
\end{figure}
First of all the flood simulations are within different cities. This can typically be a list of cities, also a list is scrollable and can be seen as an "infinite" array of cities around the world. Every city has it's own array of simulations to show. So it makes sense to also show these in a list. When a city is selected, the user has no use of the capability to select other cities and it's simulations. That's why the list of cities are pushed out of the viewport and the list of simulations is pushed in.
It also makes sense to have one Map object in the view, where one city (latitude, longitude) can be shown at a time. The map object is the most important component of the browser. Inspired by Clark(2012) it can be stated that a hierarchy in importance of different view components can result in a different place on the screen. By placing the Map component always in the view and also as the biggest component, the idea of placing objects in a hierarchy of importance in the view is considered. For an example of this, see figure \ref{fig:mockup}.
The list component where cities and simulations are placed is the left side of the view, it could also be the right side but it would not matter. Since two hands are more or less symmetrical, so placing the list object left or right would not be a problem. It does matter concerning controls. Which controls shown in the top bar is not clear at this moment. Controls to change the image placed on the map are definitely needed. A simulation consists of multiple images on different time steps. By giving the user control of which image is seen at which time step is a crucial feature in the browser. Where and when(on which event) to place these controls is discussed in the final document.
The list component where cities and simulations are placed is the left side of the view, it could also be the right side but it would not matter. Since two hands are more or less symmetrical, so placing the list object left or right would not be a problem. It does matter concerning controls. Controls to change the timestep of a simulation are definitely needed. A simulation consists of multiple images on different time steps. By giving the user control of which image is seen at which time step is a crucial feature in the browser. Where and when(on which event) to place these controls is discussed in part two.
\begin{figure}[ht]
\center
\begin{tabular}{c}
...
...
@@ -135,11 +136,10 @@ The list component where cities and simulations are placed is the left side of t
The flood simulation browser that is already build for the multi-touch table has the ability to submit new simulations to be simulated in the cloud. The spot of the simulation can be arbitrary on the map, by simply touching a place on the map and alter some parameters, the cloud service can create a new simulation to be seen. Although this feature can be an seen as an extension of my project, with time left this feature can be build in. That's why it can be considered in the App's design. The controls of these parameters need to be somewhere in view, by placing this in the neighbourhood where the user touches the map could be intuitive. But not if it happens when the user is just navigating over the map, the user has to know that it is in the mode of with picking a place where to create a new simulation. The specification about these controls are discussed in the end report.
Furthermore, it's an important feature to display data of a simulation in certain area. The API provides this data. It holds information about how much water flows in that area over time. The API requests latitude, longitude values, it then returns data of a location that is closest to this point. The application needs to display this data in a clear and understandable way. Charts are great way to display this data. In development of this application there needs to be a clear understanding of what usability is. Only displaying a chart of certain values could not be enough to learn anything or draw conclusions about the flood. The goal is to make use of the Sencha Touch Chart framework in order to provide comprehensive data of a flood in a certain area. See figure \label{fig:sencha chart} for an example of the chart framework.
Furthermore, it's an important feature to display data of a simulation in certain area. The API provides this data. It holds information about how much water flows in that area over time. This data is the volume of water per timestep. The API requests latitude, longitude values, it then returns data of a location that is closest to this point. The application needs to display this data in a clear and understandable way. Charts are great way to display this data. In development of this application there needs to be a clear understanding of what usability is. Only displaying a chart of certain values could not be enough to learn anything or draw conclusions about the flood. The goal is to make use of the Sencha Touch Chart framework in order to provide comprehensive data of a flood in a certain area. See figure \label{fig:sencha chart} for an example of the chart framework.
\subsection{Scalability}
\label{sec:scalability}
A side assignment of the project is to test the scalability of the server. The server address is \url{sangkil.science.uva.nl}. To test this server it is needed to exclude any other parameter of the client. Such as maximum download speed, maximum throughput, latency of the network. The idea is not to test this at a home pc, but test it in a server that is hooked up in the same network as \url{sangkil.science.uva.nl}. More specifically, the connection between \url{mangkus.science.uva.nl}(hosted at the same location as sangkil) and \url{sangkil.science.uva.nl}. If this is the case the exclusion of restricted variables at client side could be possible.
For stress testing the server a tool called siege \cite{Siege} would be of assistance. With this tool it is possible to launch requests to a url with $n$-nodes and $k$-connections executed per second. Siege registers the following data:
\begin{itemize}
...
...
@@ -203,20 +203,41 @@ Ext.create('Ext.List', {
\caption{List of cities}
\label{fig:sencha}
\end{figure}
The store is automatically updated when the values change on the server. When something changes in the store, the list is also automatically updated. The specified fields
\subsection{Creating Mockups in Sencha}
The store is automatically updated when the values change on the server. When something changes in the store, the list is also automatically updated. The specified fields are available in the list, containing the name of the field between brackets \texttt{\{\}}, the field name of record $n$ is placed in list item $n$. Five stores are present in the application. \texttt{SimulationStore.js}, \texttt{SimulationDetailStore.js}, \texttt{LsmStore.js}, \texttt{SimulationsSummary.js}, \texttt{ChartStore.js}.
\begin{itemize}
\item SimulationStore.js \\
Is sync with \url{http://sangkil.science.uva.nl:8003/area/list.json} on the server. Locally the store is in sync with the view List.js. Basically this store returns information of the simulation locations that are available. The most important data are the name, center, visbounds and area\_id. With the name for displaying in the list-item, the center for changing the map's center to the location of the simulation and visbounds are used for the image overlay. The area\_id is used in FloodDetailStore. When the user taps on a location, the data of longitude and latitude information is used to change the center of the map and push a new list over the current list. The second list holds information about which all the simulations available.
\item FloodDetailStore.js \\
Is in sync with multiple urls, \url{http://sangkil.science.uva.nl:8003/area/<area\_id>/info.json}, where the area is the area that is selected in List.js. This store adds information of dikes. The rest of the data is already present in the SimulationStore.js. The dikes consists of eight values, which are 4 corners with a latitude and longitude value. This means that a polygon can be formed from these four locations and displayed on the map.
\item LsmDetailStore.js \\
This store holds information of the population dynamics, meaning how the evacuation of the individuals will proceed.
\item SimulationSummary.js \\
Syncs with \url{http://sangkil.science.uva.nl:8003/drfsm/list.json?summary}. This returns a json string that holds a list of all the simulations.Luckily a store can be filtered on a certain value. All the simulations have an area\_id specified. The store is filtered on the area\_id selected in List.js. Note that filters stay present, so before doing anything the store has to be cleared of all the filters.
\item ChartStore.js \\
This store is used for creating the chart. The chart expects a jsonStore with data and fields to plot. The data is retrieved from the server at run time of the application in \texttt{Api.js}.
\end{itemize}
\subsection{Layouts}
\subsection{Controller}
\subsection{Diving in the code}
The list of cities is a list that is filled with information of the server. In Sencha Touch stores are used
\subsection{Map}
\subsection{Creating Mockups in Sencha}
\section{Scalability}
The server \url{sangkil.science.uva.nl} is tested on scalability. An important part to notice when testing a server is how well it performs concerning how much peers it can serve and how the response time will change if the number of clients increases. By looking at the amount of clients that a server can serve is what scalability stands for. So how do the values change when connections, and therefore client numbers, start to rise.
To test the server, all bottlenecks at client side have to be brought done to an minimum. \url{mangkus.science.uva.nl} is the address of another server with the same specifications. The mangkus server is situated in the same server rack as sangkil. The TCP/IP package do not have to travel around the world in order to reach the destination, so the response time when not in a stress test could be in optimum state.
\subsection{Testing}
So testing the sangkil server is done from the server mangkus. A tool siege is used for testing the server, previously discussed in section \ref{sec:scalability} in part one.
\begin{lstlisting}
$ siege -i -b -f file.txt -c $1 -r $2
\end{lstlisting}
Testing is done by changing the concurrent processes and keeping the repetitions the same, or the other way around. That way a little grid search can be preformed to find a weakness in the server. The results of this search are discussed in the following sections.
