deletions | additions       diff --git a/Method.tex b/Method.tex  index 7a7bdf2..578fcbe 100644  --- a/Method.tex  +++ b/Method.tex 
...
\subsection{Method}  \section{Method}  To begin with, information will be gathered about how to use the Android  APIs in the most efficient way for this kind of application. This  will include how to use activities, sensors and maps. Since we're  essentially developing an application to be run entirely on Android  platforms, this part of the research will be of huge importance for  the outcome.  Alongside with the coding-aspects mentioned above, information will  also be gathered on how specific areas (GPS, audio, etc.) work and  how they’re implemented using Java for Android. Most of the information  will probably come from e-books, as well as Android's developer pages  on the Internet.  When information is gathered the structure of the app will be decided.  Here UML-models will be drawn to make the structure clear. After the  modelling decisions are made sketches will be drawn to decide how  the GUI might look.  Then the coding process will start. The parts to be coded will be  the ones mentioned in the subsection Problem/Assignment. Alongside  with the coding testing will be made to make sure that everything  is working as expected. Where it is possible the tests will be made  as test cases, but it will also be important to test with real values,  as going out and running for real and see if it works.  An evaluation will be done when the first BETA-version is done. This  will be done by letting a test group use our app and evaluate it by  conducting an interview.  \subsection{Development}  The Scrum method will be used when developing the application - a  flexible Agile software development framework where the team works  more as a unit opposed to a traditional and sequential approach. The  division of labor will be decided in cycles (sprints). Each job occasion  will begin with a daily scrum - a short meeting where the group talks  about what’s going on, what’s about to happen as well as eventual  problems.  To handle the coding part of the development, Git will be used, which  is a version handling system that makes it easy to collaborate with  others in coding projects. It makes it possible for each team member  to work in the same classes and merge them when needed. Each specific  part of the application (audio, gps etc.) will be implemented in individual  branches.  When it comes to the testing part of the development, both the virtual  phone available in the Android developing environment will be used,  as well as our own phones. Testing is essential for our application  to run as smoothly as possible, so as many test cases as possible  will be covered.  \subsection{Literature studies}  The literature studies will partly involve how the human ear perceives  sound, and how it’s possible to imitate sounds coming from specific  directions using stereo headphones \citet{Roads1996}.  Literature about Android and how to best develop the app will also  be studied. This is necessary to make the app enjoyable for the user  and flexible enough to work on different kinds of phones. According  to the Android API Guide - Fragments , fragments seems like a good  way to decompose the functionality of an app into smaller parts (fragments)  that can be reusable and depending on the screen size show up in different  quantities.  Alongside the audio and Android studies, the sensors considering position  and orientation need to be studied. While GPS is the most natural  way to measure the position \citep{Sood2012}, there are various ways  to measure the user orientation.   The orientation while in motion could be decided through the GPS bearing  \citep*{AndroidDevelopers2014}, which is calculated as the direction  the phone is travelling in. Although, while standing still and only  rotating on the spot, we might be able to use the magnetic field sensor  (compass) and accelerometer to provide an orientation of the phone  itself \citet{Sood2012}. This however has problems since the orientation  of the phone relative to the actual user is not always known (it dependa  on how the user is holding the phone).  Probably, as some initial testing shows, some combination of both  is preferable.