worked on report

docs/scriptie/fsb.tex

@@ -10,10 +10,12 @@
 %\maketitle
 
 \section{Introduction}
+The UrbanFlood is a European project that aims to create an early warning system in European cities. In the today's changing climate, more and more cities have to deal with floods more often. Boek ref. Due to extreme rainfall, rising water or long lasting drought the instruments that protect the civilians of a certain area are negatively influence. The project involves setting up a system that can do estimations on how dikes would behave in the near future. Weak spots have to be detected at all time. To do this they placed sensors in dikes that can be monitored remotely via internet. But this not the only thing they do. They also developed a system that can create flood simulations of a certain area. This is used for testing dikes in a possible scenario but also for educative proposes. This is the part that is covered in this document.
+
 This project concerns the Flood Simulation Browser. The concept of this browser is to illustrate/visualize a flood in a particular area. With this technology people can see the flow that the water will take. When a dike breaks it is important to know where the water will flow. Information about which locations in the area will be under water first can result in a successful evacuation plan. This system already exists, but is build for a multi-touch table only and is accessible by few people. This project aims on making it easier available and accessible. Which makes it more likely that someone with the right authority can take decisions about placing/reinforcing dikes or creating evacuation plans. Moreover, if this system is more accessible, then civilians of a certain neighbourhood that is threatened by water, have the ability to gain knowledge of where the water will go first. They then are able to take the the right crucial decisions based on this knowledge in the hour of need.
 
 The implementation will be on a multi-touch device. In particular iPad and Android tablets. Users can use this application in an intuitive way and get more intelligence about the complex situation at hand. They have the ability to choose from several simulations that were already made for a specific area and also creating new simulations.
-This document covers design choices/options in order to reach that goal. The first step is to get an idea of the existing simulation system of which this application will take use of. This includes a clarification of where this application is situated in the Urban Flood Project as a whole. The next step will be finding out the requirements of the tablet implementation, like which features does it have to contain in order to maintain intuitiveness. Just by showing the data would not be sufficient. The function of this App is to extend the simulation system with a use-ability and above all mobility factor.
+This document covers design choices that where made in order to reach that goal. The first step is to get an idea of the existing simulation system of which this application will take use of. This includes a clarification of where this application is situated in the Urban Flood Project as a whole. The next step will be finding out the requirements of the tablet implementation, like which features does it have to contain in order to maintain intuitiveness and enough options to be a successful application. Just by showing the data would not be sufficient. The function of this App is to extend the simulation system with a use-ability and above all mobility factor.
 
 A side assignment of this project is testing the scalability of the REST server. By testing how much requests the server can handle at ones it helps the urban flood project to estimate how many users can use the application at ones. The original multi touch application on the multi touch table was only one client. It's important to know that an early warning system stays online under the pressure more of clients.
 
@@ -47,7 +49,7 @@ As already explained, PhoneGap only provides the possibility to create an app ou
 \item [jQuery Mobile]
 This Javascript framework is build out of one Javascript file and one CSS file that the developer includes. By giving certain HTML elements a data attribute, which is a HTML5 element, the framework uses this to create views. A page is made by declaring a div adding data-role="page". Such a page can be given a footer like div data-role="footer". 
 Switching frame one page to the other can be as simple as giving a html anchor a href to an id of a page. The figure \ref{fig:jquery} provides an example that will result in two pages, both pages have a button. Both buttons link to the other page (foo, bar), so tapping on one button will change the page to the other page.
-\begin{figure}
+\begin{figure}[H]
 \begin{lstlisting}
 <div data-role="page" id='bar'>
 	<a #href='foo' data-role="button">switch to foo</a>
@@ -98,26 +100,26 @@ Ext.application({
 
 \subsection{Requirements Analysis}
 \label{sec:requirements}
-In short this involves the question, what does the application have to do? First of all, the users need to be able to see different simulations and be able to distinguish where certain simulations are located. Starting displaying the locations that are available as simulations would be the starting point of where the users can start interacting with the application. For displaying the locations a request to server is needed to for displaying those. 
-The locations are mostly named by cities. The corresponding simulations have to be retrieved from the server and displayed in a list. Those list-items are the individual simulations, so it makes sense that when tapping on a list item, the simulation of the related item is going to be displayed. The form of these simulations are important. As previously stated, the simulations are in the form of images. These images are images from above and can be placed on the map. In order to display these images, there has to be a map available. Next, the latitude and longitude information is needed in order to place the image on the map.
+The requirements in short involves the question, what does the application have to do? First of all, the users need to be able to see different simulations and be able to distinguish where certain simulations are located. By starting with displaying the locations that are available would be the starting point of where the users can start interacting with the application. For displaying the locations, a request to server is needed to for displaying those. 
+The locations are mostly named by cities. The corresponding simulations have to be retrieved from the server and displayed in a list. Those list-items are the individual simulations, so it makes sense that when tapping on a list item, the simulation of the related item is going to be displayed. The form of these simulations are important. As previously stated, the simulations are in the form of images. These images are images from above and can be placed on the map. In order to display these images, there has to be a map available. Next, the data of where to place the image is needed for creating a map. This data is located in the simulation data of the city. In part two of this document the exact implementation can be found.
 
-As mentioned before, the floodsimulations are in the form of multiple imagery that are placed on the map. A requirement for these simulation images are that the user can control which image it wants to see in chronological sequence but of course does not decide the sequence is going to be. This requirement results in the need for controls for this feature. These controls need to be displayed somewhere in the viewport when the user has tapped on a list item of a simulation.
+As mentioned before, the floodsimulations are in the form of multiple imagery that are placed on the map. A requirement for these simulation images are that the user can control which image it wants to see in a chronological way, of course does not decide the sequence is going to be. This requirement results in the need for controls. These controls need to be displayed somewhere in the viewport when the user has tapped on a list item of a simulation.
 
-The flood simulations contain information about how much volume of water is present in a certain timestep. The simulations are divided in zones and labelled with an id. So a simulation contains information, this information needs to be displayed in such a way that it can be interpreted by the user. This would require a chart of some sort with the timesteps on the x-axis and some other value like volume on the y-axis. To determine the zone which contains the information, a latitude and longitude information is needed again. How this is done is described in part two of this document.
+The flood simulations contain information about how much cubic meters of water is present in a certain timestep in a specific location. The simulations are divided in zones and labelled with an id. So a simulation contains information, this information needs to be displayed in such a way that it can be interpreted by the user. This would require a chart of some sort with the timesteps on the x-axis and some other value like volume on the y-axis. To determine the zone which contains the information, a latitude and longitude information is needed again. How this is done is described in part two of this document.
 
 \subsection{App Design} 
 \label{sec:appdesign}
-The application will be used on tablets so a lot of space can be used. Working with tablets the screen gets larger than mobile phones. Which can result in a bigger travel distance of the user's hands. The GUI design has to be build with the considerations of the interaction capability of the users. For instance, unlike with mobile phones, according to Clark(2012) a leading designer in creating multi-touch applications, people intend to hold a tablet on the top halve of the tablet when holding with both hands, figure \ref{fig:perimeter}. The focus of the user is going from top to down. The top elements of the application will draw the first attention of the user. That's why Clark(2012) advises to place the important controls on the top half of the screen. The components that are important have to be placed in the left or right top of the screen. By taking Clark's advise the Flood Simulation Browser can be inspired.
-\begin{figure}[h!]
+The application will be used on tablets so a lot of space can be used. Working with tablets the screen is larger than mobile phones. Which can result in a bigger travel distance of the user's hands. The GUI design has to be build with the considerations of the interaction capability of the users. For instance, unlike with mobile phones, according to Clark(2012) a leading designer in creating multi-touch applications, people intend to hold a tablet on the top halve of the tablet when holding with both hands, figure \ref{fig:perimeter}. The focus of the user is going from top to down. The top elements of the application will draw the first attention of the user. That's why Clark(2012) advises to place the important controls on the top half of the screen. The components that are important have to be placed in the left or right top of the screen, concerning the perimeter of the thumbs, figure \ref{fig:perimeter}. By taking Clark's advise the Flood Simulation Browser can be inspired.
+\begin{figure}[H]
 \center
 \includegraphics[scale=0.3]{touch.png}
 \caption{Portrait touch perimeter(Clark, 2012)}
 \label{fig:perimeter}
 \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. 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]
+First of all the flood simulations are done 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 kept in mind. 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. 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. Since the list is placed in on the left side of the screen the controls appear on the right side of the screen, in the right top part of the screen. That way the perimeter of the thumbs are concerned.
+\begin{figure}[H]
 \center
 \begin{tabular}{c}
 	\includegraphics[scale=0.3]{mockup1_1.png} \\
@@ -253,6 +255,7 @@ Ext.define("app.view.Main", {
 \end{figure}
 The xtype keyword matches the keyword out of the component where the xtype is defined. It serves as shortcut to the full component. Components that are created can get a unique xtype value and be referred to by other components to call functions or for displaying  of that component, this is widely used throughout the application.
  
+
 \subsection{Controllers}
 Controllers preform the logic in the application. They react on events, fired by the elements in the view. In sencha touch the events are configured in the control configuration. References to components in the view are created in the ref attribute in the config attribute. A reference may consist of a css selector or an xtype name, or both. References are used in the functions below the config field, \texttt{this.getMap()}. Controllers are declared like the following.
 \begin{lstlisting}
@@ -298,6 +301,20 @@ Ext.define('app.view.Map', {
 });	
 \end{lstlisting}
 In the application the Map object extends and uses the Google API. Overlays are used for placing simulations images on the map. When the maprender event is fired, it returns a reference to the Google API and Ext Map component. The Google Maps API specified in the documentation is used for creating overlays and adding markers on a certain Lat, Lng. The most important feature is initializing the first image by calling \texttt{createOverlayImage} function when a simulation is tapped in the list and creating overlays for the rest of the timesteps. These images are stepped through in the nextImage and prevImage function. Which are controlled when a button in the control panel is tapped.
+
+\subsection{Controls}
+The controls to change the simulation step when a simulation is selected, appears in the right top of the screen. The component has four controls; forward, backwards, play forward, play backwards. Because of the fact that the controls take space of the map, the background of the controls is transparent for creating the feeling of more space.
+\begin{figure}[H]
+\center
+\includegraphics[scale=0.7]{ui/controls.png}
+\caption{Controls}
+\label{fig:controls}
+\end{figure}
+By tapping on the upper button, the next image is placed on the map. The right button plays through the simulation automatically. The left and bottom button both do the opposite. Also a pause button stops calling the next or prevImage function out the map object. As previously discussed the controls appear in the right top of the screen. If the user need the controls on the bottom part of the screen, the user can also tap and drag the controls. Because the space of the tablet is limited the user can make the decision of placing the controls somewhere else, note that the controls are constrained to the right side of the screen. The reason is that the controls are meant to be used by the user's right hand.
+ 
+\subsection{Chart Display}
+The chart data is the  
+ 
 \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.
 
@@ -354,6 +371,8 @@ The Throughput is higher than the previous test. This means that the server's ba
 It does not seem to matter how much repetitions are preformed by a certain number of concurrent clients. This suggests that it could mean that only weak spot of the server concerning the response time depends on how much clients at a time are demanding a request. It looks like it does not matter how much repetitions those clients preform, it has no influence on the response time.
 The throughput does rise when the amount of repetitions go up. 
 
+
+
 \section{Deployment}
 For installing the application to a device the sencha's command line tool is used. In the root folder \texttt{packager.json} can be found. In this file the field for building the application has to changed. See below, listing \ref{lst:packager}.
 \begin{lstlisting}[caption={packager.json},label={lst:packager}]
@@ -381,7 +400,11 @@ The deployment can be distributed to other devices. On Android devices it's poss
 Sencha Touch 2 is used in this project for the cross-platform capabilities. One of the research question was to find the best tool to meet the requirement of cross-platform. Let's start with the fact that everything works both on a Asus tf300t Transformer Pad with Android , iPad 2 with iOS 5.1.1 and the browsers Safari and Chrome. Installing an application to the device involves For testing this application on the iPad 2 jailbreaking had to take place. How to jailbreak the iPad to is desribed here \url{http://greenpois0n.com/}. For enabling tp install without a developers account apps without ``Appsync'' has to be installed.\footnote{\url{http://www.ijailbreak.com/cydia/install-cracked-apps-ios-5-0-1-with-appsync-installous/}}
 
 
+
 \section{Conclusion}
 
 \section{Discussion}
+Future research:
+small screenshots with map
+a lot of data
 

docs/scriptie/references.bib

+@article{clientserver,
+  title = "Performance and Scalability of Client-Server Database Architectures",
+  author = "Delis, A., \& Roussopoulos N."  
+}
+
 @misc{Titanium-Appcelerator,
     title = "Appcelerator, \url{http://www.appcelerator.com/}",
     url = "\url{http://www.appcelerator.com/}",
 }
 
 @article{memoryleak,
-    title = "Why you should stay away from appcelerator titanium \\
-    \url{http://usingimho.wordpress.com/2011/0614/} \\
-    \url{why-you-should-stay-away-from-appcelerators-titanium/} ",
-    url = "\url{http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-from-appcelerators-titanium/}",
+    title = "Why you should stay away from appcelerator titanium.",
 	author = "A. Dallera" ,
+    note = "\url{http://usingimho.wordpress.com/2011/06/14/}\url{why-you-should-stay-away-from-appcelerators-titanium/}",
 }
 
 @misc{CSS3,
-    title = "CSS3 Support, \url{http://www.caniuse.com/}",
-    url = "\url{http://www.caniuse.com/}",
+    title = "Check CSS3 Support",
+    
+    note = "\url{http://www.caniuse.com/}",
 }
 
 @misc{designing-touch,
@@ -24,26 +28,30 @@
 }
 
 @misc{jQuery-Mobile,
-    title = "jQuery Mobile, \url{http://jquerymobile.com/}",
+    title = "jQuery Mobile.",
     note = "\url{http://jquerymobile.com/}",
 }
 
 
 @misc{PhoneGap,
-    title = "PhoneGap, \url{http://www.phonegap.com/}",
+    title = "PhoneGap, ",
      note = "\url{http://www.phonegap.com/}",
 }
 
 @misc{sencha,
-    title = "Sencha Touch, \url{http://www.sencha.com/products/touch}",
+    title = "Sencha Touch",
     note = "\url{http://www.sencha.com/products/touch}",
 }
 
 @misc{Siege,
-    title = "Siege, \url{http://www.joedog.org/siege-home/}",
+    title = "Siege",
     note = "\url{http://www.joedog.org/siege-home/}",
 }
 
+@misc{UbanFlood,
+	title = "The UrbanFlood Project",
+	note = "\url{http://www.urbanflood.eu/Pages/default.aspx}"
+}
 
 
 

docs/scriptie/scriptie.tex

@@ -52,13 +52,14 @@
 \newpage
 
 \begin{abstract}
-The end product of this project is an multi-platform application, designed specifically for tablets, that will aid the urban flood project in viewing simulated floods. The current implementation this application is done on a multi-touch table which is not easily portable. To reach to goal of mobility and to be able to reach more public, tablets have the same interaction features as the multi-touch table and are therefore chosen to reach this goal. This project involves an investigation for the best possible tools to implement such an application. A side objective is to test how many peers the back-end server can handle at ones. This will also be reported in this document.
+This project covers the implementation of a cross-platform application, designed specifically for tablets, that will aid the urban flood project in viewing simulated floods. This application already existed on a multi-touch table, which is not easily portable. To reach to goal of mobility and to be able to reach more public, tablets have the same interaction features as the multi-touch table and are therefore chosen to reach this goal.  Sencha Touch 2 was found to be the best option at first but did not suffice the expectations. A side objective is to test how many peers the back-end server can handle at ones, the response time of the server goes up fast which means that a problem can occur when more clients are requesting data.	
 \end{abstract}
 
 \input{fsb}
+\newpage
 \bibliographystyle{plain}
 \bibliography{references}
-
+\newpage
 \appendix
 \label{appendixA}
 \include{area_api}