Skip to content

F
FloodSimulation-Browser
Commit 38a1b959 authored by icyrizard's avatar icyrizard
Browse files
Options

worked on scriptie

parent 398ca70b
Show whitespace changes
Inline Side-by-side
Showing with 499 additions and 0 deletions
docs/scriptie/Makefile 0 → 100644
View file @ 38a1b959
scriptie.tex: title.tex fsb.tex area_api.tex references.bbl
%.pdf: %.tex
pdflatex $^
pdflatex $^
%.bbl: %.bib
pdflatex scriptie.tex
bibtex scriptie
pdflatex scriptie.tex
pdflatex scriptie.tex
clean:
rm -f *.aux *.toc *.log *.out
realclean:
rm -f *.aux *.toc *.log *.out *.pdf
docs/scriptie/area_api.tex 0 → 100644
View file @ 38a1b959
\section{Area API}
\label{sec: area_api}
\begin{lstlisting}
# Terms
Map: digital terrain map (DTM)
Projected map: inundation map projected/transformed to WGS84/EPSG:3857
(e.g. Google Maps) projection system
# Area List
GET /area/list.json
response:
{"stat": "ok",
"areas": [
{"area_id": 1,
"name": "Science Park",
"center": [52.347185, 4.9370885],
"corners": [[52.334349, 4.904065], [52.334349, 4.970112],
[52.360021, 4.970112], [52.360021, 4.904065]],
"visbounds": [52.360021000000003, 4.9701120000000003,
52.334349000000003, 4.9040650000000001]}
]}
note:
- "center" is the center point coordinate of the map, in latitude
and longitude
- "corners" contains 4 pairs of numbers showing the WGS84 coordinate of the
four corners of the area, in latitude and longitude
- coordinates in the "corners" correspond to the coordinate of
the lower left, lower right, upper right, and upper left corners
of the area, consecutively
- "visbounds" contains 4 numbers representing the WGS84 coordinate of
north, east, south, west in latitude or longitude for laying out the
projected flooding image
# Area List (query)
GET /area/list.json?bounds=north,east,south,west
# Area Info
GET /area/<area_id>/info.json
response:
{"stat": "ok",
"area_id": 1,
"name": "Science Park",
"center": [52.347185, 4.9370885],
"corners": [[52.334349, 4.904065], [52.334349, 4.970112],
[52.360021, 4.970112], [52.360021, 4.904065]],
"size": [880, 565],
"extents": [[0, 0], [0, 0]],
"projection": "...",
"visbounds": [52.360021000000003, 4.9701120000000003,
52.334349000000003, 4.9040650000000001],
"vissize": [880, 565],
"dikes": [[[lat1, lng1], [lat2, lng2], [lat3, lng3], [lat4, lng4]],
[[lat5, lng5], [lat6, lng6], [lat7, lng7], [lat8, lng8]]]
}
note:
- "corners" contains 4 pairs of numbers showing the WGS84 coordinate of
the four corners of the area in latitude and longitude
- "size" shows width and height of the DTM and Inudation Zones Map
- "center" is the center point WGS84 coordinate of the map, in latitude
and longitude
- "extents" contains 2 pairs of numbers showing the coordinate of
the lower left and upper right corner of the map in its original
projection unit
- "projection" contains projection parameter of the map in WKT format
- "visbounds" contains 4 numbers representing the WGS84 coordinate of
north, east, south, west in latitude or longitude for laying out the
projected flooding image in this area
- "vissize" is the size of projected flooding image in this area.
Because of the projection, the flooding image may have different size
compared to the original DTM/Inundation Zones size
- "dikes" contains a list of closed polygons described by a list of
WGS84 coordinates which shows the region of the dikes in the area
# Digital Terrain Map
GET /area/<area_id>/topography.txt
GET /area/<area_id>/topography.txt.gz
# Inundation Zones Map
GET /area/<area_id>/zones.txt
GET /area/<area_id>/zones.txt.gz
# Coordinate to Inundation Zone id mapping
GET /area/<area_id>/izid.json?latlng=<LAT>,<LNG>
response:
{"stat": "ok",
"area_id": 1,
"latlng": [52.347185, 4.9370885],
"izid": 12345}
\end{lstlisting}
\ No newline at end of file
docs/scriptie/fsb.tex 0 → 100644
View file @ 38a1b959
%\documentclass[10pt,a4paper]{article}
%\usepackage[utf8]{inputenc}
%\usepackage{amsmath}
%\usepackage{amsfonts}
%\usepackage{amssymb}
%\usepackage{listings}
%\usepackage{graphicx}
%\author{Richard Torenvliet - 6138861}
%\title{Flood Simulation Browser}
%\maketitle
\section{Introduction}
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.
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.
The scientific research of this project will be the research for an intuitive design. The question will be, where do buttons, lists, and other important components need to be situated in an application. An other aspect of this project is the research for scalability of the server. This data will provide information about how many users can be handled by a server at once. The important part of this research will be the decision making of which framework or tool to use for the implementation of this application.
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}
\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.
\section{Flood Simulation App}
\subsection{Platform considerations}
As stated in the introduction the application is meant for tablets, but not specific for iOS or Android. How to maintain this demand on the application is one of the subjects of this project. This means that the application is not a native implementation and consists of one code-base and runs on more devices. There is a tool called PhoneGap \cite{PhoneGap} that uses HTML5, CSS3 and Javascript to build the app. In essence the developer builds a mobile website and PhoneGap can wrap this in an application. The native web-engine is used to render the mobile website. PhoneGap can result in a huge speed-up in development time, which is a huge advantage. The speed up can be obtained by the fact that previously gained skills of webdevelopment can be re-used. Therefore there is no need to learn a new programming language or sdk for native apps. For example Objective C for iOS and Java for Android. The disadvantage can be that it feels like a mobile website in stead of a native application. In addition, the end product depends on the support of today's web-standards. Not all browsers have full support for HTML5 and CSS3, which forms the bases of a successful implementation of the application. For a list of supported elements, websites like caniuse.com \cite{CSS3} can be used to determine the percentage of support for a certain element/feature. But does not solve anything. Nevertheless, one disadvantage can be solved, a native feel of an application. For example, frameworks where native-like elements are created for you while coding in a programming language already known by a webdeveloper also exists.
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.
\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}
\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{lstlisting}
<div data-role="page" id='bar'>
<a #href='foo' data-role="button">switch to foo</a>
</div>
<div data-role='page' id='foo'>
<a #href='bar' data-role="button">switch to bar</a>
</div>
\end{lstlisting}
\caption{jQuery Mobile, pages example}
\label{fig:jquery}
\end{figure}
Creating two pages is quickly done, the downside of jQuery mobile is that in order to create an application where views look a like, you have to repeat yourself. You have to create pages with other id's and with the same look/elements but with different information. The conclusion is that jQuery mobile is that it is easy and the developer does indeed use HTML, CSS to create views. But it is not easy to build a modular application. It is always possible to create such a modular application yourself, but when creating an application which is not such a framework the developer will run in to creating a framework in stead of the intended application.
\item [Sencha Touch 2]
Sencha touch 2 is a framework focused on the Model View Controller design pattern. It encourages the developer to use this pattern. The way of developing really differs from jQuery mobile. There where jQuery mobile sets you free to do whatever you like, sencha touch constraints the developer using components that are available in sencha touch. The difference can be easily explained with an example.
In the items array, see figure \ref{fig:sencha}, the items in that array can be anything supported by sencha touch like lists, a tabview, a map, etcetera.
Sencha touch provides a command-line tool to build a starting environment. It creates files where the developer can start from. It's recommended to use this as a starting point. The advantage is an application that is structured out of the box with a design pattern that is the current standard(MVC). With Sencha Touch 2 there is no need for PhoneGap, unlike jQuery Mobile. Sencha Touch 2 provides the possibility to run the code on your simulator or native device with the command line tool. Testing for Android an iOS became much more simplistic resulting in less developing time. Running PhoneGap for Android, needs Eclipse to build, for iOS the developer needs to build in Xcode. When testing on both devices the developer needs to be able to test in both environments, and testing from the command-line is a lot easier than running both environments.
A disadvantage of Sencha Touch could be, as seen in figure ~\ref{fig:sencha}, the syntax of sencha touch is not so easy at first. So the learning curve could be very steep.
The last argument that has a great influence on deciding which framework to use, could be that Sencha Touch provides an add-on that has the capability to create multi-touch charts. The original implementation of the urban flood browser on the multi-touch table has this feature. It would be a great extension of the project if this was possible. So with an eye on the future it could save a lot trouble, and it could add up to a more intuitive design. The next section will discuss this in more detail.
\pagebreak
\begin{figure}[h!]
\begin{lstlisting}
Ext.application({
name: 'foo',
launch: function() {
Ext.create("Ext.tab.Panel", {
fullscreen: true,
items: [
{
title: 'bar',
iconCls: 'bar',
html: 'bar'
}
]
});
}
});
\end{lstlisting}
\caption{Sencha Touch application example. This example creates an application with the name 'foo'. The html can be placed inside the items array. }
\label{fig:sencha}
\end{figure}
\end{description}
\vspace{1cm}
\subsection{Requirements Analysis}
\label{sec:requirements}
In short this involves the question, what does the application have to do? First of all, user needs to be able to see different simulations and be able to distinguish where certain simulations are located. Starting displaying the cities that are available as simulations would be the starting point of where the users can start interacting with the application. For displaying the cities a request to server is needed to for displaying the cities.
The cities are . 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.
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.
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.
\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!]
\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. 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.
\begin{figure}[ht]
\center
\begin{tabular}{c}
\includegraphics[scale=0.3]{mockup1_1.png} \\
\includegraphics[scale=0.3]{mockup2_1.png}
\end{tabular}
\label{fig:mockup}
\caption{Cities list of which simulations are available}
\end{figure}
\begin{figure}[ht]
\includegraphics[scale=0.5]{chart.png} \\
\caption{Example of sencha chart}
\label{fig:sencha chart}
\end{figure}
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.
\subsection{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}
\item Transactions - total hits
\item Availability - percentage of total succeeded hits
\item Elapsed Time - seconds
\item Data Transferred - MB
\item Response Time - seconds
\item Transaction Rate - seconds
\item Throughput - MB/s
\item Concurrency - rate of concurrency
\item Succesful transaction - number of succeeded hits
\item Failed transactions - number of failed hits
\item Longest transaction - seconds
\item Shortest transaction - seconds
\end{itemize}
With this data new insight can be provided. By increasing the number of simultaneous connections, values could start to change. To really give the server a stress test, it's possible to provide a list of urls which can randomly be picked and executed. This simulates a more likely scenario and provides more insight on how the server would behave in a real situation. The expectation is that the response time might grow as the number of clients starts to grow. With more clients to serve, it could take longer if there are more clients active. If processor power is limited, maximum available memory is reached or even the implementation of the server for handling requests could all have an effect in the response time, or any other variable. The research for which variables changes, together with the cause and the solution is a part of this project and will be documented in the end report.
%\section{Conclusion}
%The project will be implemented with the framework Sencha Touch 2. All encountered issues will be discussed in the end report. This %nformation can be used in future projects relating to creating cross-platform applications. Also all data about the scalability of the erver %will be documented. The urban flood project can in turn use this data in future plans to invest in more server power. If they do not need %to invest in more power this is also important.
%This project will ultimately result in a cross-platform application that can be used by the public or government to gain information %about a certain area.
\section*{End of Part one}
Part one describes the questions and some answers on what the approach of tackling this problem is going to be. For an understanding of what global problems are faced in this project, it will be sufficient to have read part one. Part two holds information about how the implementation is made, the problems that where discovered in process, results are displayed and discussed and ultimately ending with the conclusion of this project.
\part{Describing the implementation}
\section{Server API}
A clear understanding of which request have to be done in order to gain the right information is needed first before beginning with any implementation. The full api is referenced in the appendix \ref{appendixA}. The appendix is referenced and used for explanations in the following sections.
\section{Sencha Touch 2}
The decision is fallen on Sencha Touch 2. Sencha Touch provides cross-platform capability and is based on web technology. Although Sencha Touch comes with a whole new syntax, based on Ext (reference!!), the content, look and logic is based on web languages.
Part one section \ref{sec:appdesign} the design of a touch application is discussed. The application is going to be created with the findings described in that section. Also the mockups \ref{fig:mockup} created early on in the project are great for keeping track on what the end goal should look like.
%The requirements of the application discussed in section \ref{sec:requirements} are created in
Sencha Touch is based on MVC with an addition of stores. Stores can hold information of whatever the application needs, more about this in a moment. The model is used for the communication with the database, the controller stands between the model and the view. The controller can steer between views and handle logic. The application has no direct need of models, since there is no database that has to be updated. Stores can handle enough communication between the server and the application.
\subsection{Stores and Lists}
The stores in this application are prominently used for filling the lists. In particular the cities list en simulationslist. A list object is defined as the following. See appendix \ref{sec:area_api}.
\begin{figure}[h!]
\begin{lstlisting}
store = Ext.create('Ext.data.Store'{
fields: ['name', 'corners', 'visbounds', 'area_id', 'center', 'size'],
proxy: {
type: 'rest',
url: 'http://sangkil.science.uva.nl:8003/area/list.json',
reader: {
type: 'json',
rootProperty: 'areas'
},
}
});
Ext.create('Ext.List', {
title: 'locations',
store: 'citystore',
itemTpl: '<div>{name}</div>',
});
\end{lstlisting}
\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}
\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
\section{Scalability}
\subsection{results}
\subsection{analysis}
\section{Conclusion}
\section{Discussion}
docs/scriptie/references.bib 0 → 100644
View file @ 38a1b959
@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/}",
author = "A. Dallera" ,
}
@misc{CSS3,
title = "CSS3 Support, \url{http://www.caniuse.com/}",
url = "\url{http://www.caniuse.com/}",
}
@misc{designing-touch,
title = "designing-touch",
author = "Clark, J.",
year = "2012",
url = "\url{http://www.netmagazine.com/features/designing-touch}",
note = "Retrieved March 31, 2012"
}
@misc{jQuery-Mobile,
title = "jQuery Mobile, \url{http://jquerymobile.com/}",
url = "\url{http://jquerymobile.com/}",
}
@misc{PhoneGap,
title = "PhoneGap, \url{http://www.phonegap.com/}",
url = "\url{http://www.phonegap.com/}",
}
@misc{sencha,
title = "Sencha Touch, \url{http://www.sencha.com/products/touch}",
url = "\url{http://www.sencha.com/products/touch}",
}
@misc{Siege,
title = "Siege, \url{http://www.joedog.org/siege-home/}",
url = "\url{http://www.joedog.org/siege-home/}",
}
%http://www.sencha.com/products/touch
%http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-from-appcelerators-titanium/
%http://caniuse.com/
%http://www.joedog.org/siege-home/
%http://www.netmagazine.com/features/designing-touch John Clark 2012 on February 01, 2012
%http://www.appcelerator.com/
%http://jquerymobile.com/
%http://www.phonegap.com/
%\end{document}
docs/scriptie/scriptie.tex 0 → 100644
View file @ 38a1b959
\documentclass[a4paper, 11pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[margin=2.5cm, nohead]{geometry}
\usepackage{palatino, url, multicol}
\usepackage{amssymb, graphicx, fancyhdr, latexsym, url, verbatim}
\usepackage{algorithm, algorithmic}
\usepackage{hyperref}
%\usepackage{natbib}
\usepackage[all]{xy}
\usepackage{listings}
\usepackage{cite}
\usepackage{makeidx}
\usepackage[english]{babel}
\usepackage[font=small,format=plain,labelfont=bf,up,textfont=it,up]{caption}
\usepackage{xspace}
%\usepackage{subfigure} % has to be loaded after caption to prevent clash Commented, because subfig is the newer (and presumably
% better) version of subfigure...
\usepackage{subfig}
\usepackage{xcolor}
%\usepackage[titles,subfigure]{tocloft}
%
%
%\setlength{\cftbeforesecskip}{0.1cm}
\newcommand{\todo}[1]{\colorbox{red}{\color{white}#1}}
\newcommand{\projectName}{Flood Simulation Browser\xspace}
% xspace only puts a space where we want one!
\addtolength{\footskip}{-200mm}
\addtolength{\headheight}{-05mm}
\addtolength{\headsep}{05mm}
\pagestyle{fancy}
\lhead{\projectName}
\rhead{\small F.S.B.}
%\cfoot{\footnotesize \textit{ \projectAbbreviation}\\[0.1cm] \small \thepage}
%\cfoot{}
%\rfoot{\thepage}
\setlength{\parindent}{0pt}
\setlength{\parskip}{10pt}
\begin{document}
\include{title}
%\thispagestyle{empty}
\newpage
\tableofcontents
\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.
\end{abstract}
\input{fsb}
\bibliographystyle{plain}
\bibliography{references}
\appendix
\label{appendixA}
\include{area_api}
\end{document}
\ No newline at end of file
docs/scriptie/title.tex 0 → 100644
View file @ 38a1b959
\newcommand{\HRule}{\rule{\linewidth}{0.5mm}}
\begin{titlepage}
\begin{center}
\includegraphics[width=1\textwidth]{uva}\\[0.5cm]
\HRule \\[0.2cm]
{ \huge \LARGE \textbf{\projectName}\\[0.1cm]
\vspace{0.2cm}}
\HRule \\[0.4cm]
\Large \today
\vfill
\begin{tabular}{ll}
\textbf{Supervisor:} & \textbf{Executive:} \\
Robert Belleman - U.v.A & Richard Torenvliet \\
& stdnmr: 6138861 \\
& email: Richard.Torenvliet@student.uva.nl
\end{tabular}
\end{center}
\end{titlepage}
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment