HDSMT Technical Report - X14109824

National College of Ireland
Higher Diploma in Science in Mobile Technologies
2014/2015
Tadhg Ó Cuirrín
X14109824
tadhger87@gmail.com
Supervisor – Dr Arghir Nicolae Moldovan
IWOZERE
Technical Report
1

Table of Contents
1 Executive Summary.............................................................................................4
2 Introduction..........................................................................................................5
2.1Background.................................................................................................5
2.2Aims............................................................................................................7
2.3Technologies...............................................................................................7
3System..................................................................................................................9
3.1Requirements.............................................................................................9
3.2Functional requirements.............................................................................9
3.3Data requirements....................................................................................12
3.4User requirements....................................................................................13
3.5Environmental Requirements ..................................................................13
3.6Usability requirements..............................................................................13
4Design and Architecture......................................................................................14
4.1Implementation.........................................................................................14
5Testing.................................................................................................................23
5.1Tools..........................................................................................................23
5.2 Backwards Compatibility Testing.............................................................24
6Graphical User Interface (GUI) Layout...............................................................25
7Conclusions.........................................................................................................30
8Further development or research.......................................................................31
9References..........................................................................................................32
10Appendix...........................................................................................................33
10.1Project Proposal.....................................................................................33
10.2Project Plan............................................................................................38
10.3Requirements Specification....................................................................38
The user inputs non valid information in one or more fields and must re-enter
the information...................................................................................................43
The user loses data connectivity and is unable to post the messages.............45
10.4 Project Analysis & Design......................................................................47
10.5Project Test Plans ..................................................................................47
10.6Monthly Journals.....................................................................................47
2 Tadhg Ó Cuirrín - X14109824

1 Executive Summary
The main objective of this project is to create a social networking and messaging
application with elements of geocaching, that allows users to share messages by
placing them at real world map locations. Bringing together two of the primary
functionalities of modern smartphones – text based messaging services and
social networking applications, IWOZERE provides an attractive and intuitive
user interface that provides a localised stream of relevant content. It allows
users a platform to express themselves creatively, leave fun or useful messages
and interract with others users anonymously. It situates the user within their
environment in a very tangible way, and hopefully allows users to view their
surroundings in a new light.

2 Introduction
'IWOZERE' (I was here) is a social media and messaging application for Android
devices which allows the user to anonymously pin a short message to a Google
Maps location.
Upon installing and opening the application, the user is presented with a marker
displaying their current location on a map. On clicking on that location the user
may leave a short anonymous message (150 characters) which is then pinned to
that location and never deleted, along with any messages left by other users. The
message is pushed to the devices of any other users who are at that location
(within 10 meters) at the same time. Messages can be upvoted and a user may
view popular messages or the most recent messages. Users can navigate the
map to any other location around the globe to view messages that have been
posted there, but may only post a message themselves at the location they are
currently at. Locations that have had a lot of messages posted there in the past
24 hours are highlighted on the map.
2.1 Background
When approaching this project, I sought to create an application that was simple
in concept and construction but open ended in such a way as to allow for a
myriad of different uses. The basic function of leaving messages at different
locations on a map calls to mind a kind of 'digital graffiti'. By 'graffiti' I refer more
to the kind of strange short messages and self aggrandizing tags found dotted
around the urban environment - on disused walls and bathroom cubicles, as
opposed to large elaborate pieces. Much of the content created in the application
in this way would likely be humorous, entertaining and frivolous, similar to other
social media outlets and indeed graffiti itself. And like graffiti, an important feature
of the application is the permanence and the anonymity of the message
But I feel that while this graffiti aspect could be interesting and popular in itself,
the application could have other uses aside from the kind of throwaway
comments described above. Consider for example how users could use the
application to interact with one another at a public event, say a bar, nightclub, or

party etc. The anonymous nature of the messages could make it well suited to
flirting with other users, and gossiping about other individuals present, or to find a
friend if you have become separated. It could also be used to leave reviews of
different restaurants, businesses and other attractions.
The ability to view messages left at any location around the world adds another
element to the application, namely that it could be used to view first hand
accounts of topical events in the news by those actually experiencing them on
the ground. This is similar to the way that Twitter and other social media outlets
intersect with the contemporary news gathering and journalistic process (The
Guardian – So Twitter is runing journalism ? Really ?, 2013) but the fact that a
message can only be left at a location where a user is physically located could
serve to drown out some of the less relevant voices.
The application could also be used in an open ended and games oriented
manner when one considers the similarities with activities like (geocachingireland
2015)
IWOZERE takes influence from a number of other applications currently
available, while differentiating itself with a number of specific features. Mobile
applications such as Whisper allow users to post anonymous messages to the
service in the form of images overlaid with text, in a kind of greeting card format.
Other users can respond to the message through the service but the application
is not location specific and so content can feel less relavant. PostSecret is an
ongoing community mail art project which follows a similar vein. People
anonymously mail their secrets on homemade postcards. Selected examples are
displayed on the PostSecret website.
YikYak, another anonymous social media app, comes closer to the functionality
IWOZERE seeks to achieve. YikYak is primarily meant for sharing with other
users in close proximity. Users create messages that are shared in a bulletin
board format with other users within a five mile radius.

IWOZERE differs from these examples in that it seeks to create an even more
localised community of users, and to provide them with a more intuitive and
visually appealing interface. YikYaks lack of a map interface and the grouping
together of messages from a wider radius means it loses a certain amount of
intuitiveness and relavance to the user. By making the map view the applications
primary user interface, users can intuitively scan the familiar Google Maps
interface and at a glance see the map markers signifying where a message has
been posted. A user can then see if the message was posted from their own
current location, a kilometer away, or further afield and judge its relevance to
them accordingly. The ability to receive instant notifications from other users in
your direct vicinity also adds a new dimension to the way the application can be
used. In this way, IWOZERE looks to create a more relevant 'feed' of content to
its users.
2.2 Aims
– An intuitive and responsive user interface
– Effective communication with the Google Maps API to achieve fast and
accurate user location information.
2.3 Technologies
2.3.1. Code and Development Environment
The application is written natively in Java and was constructed in Android Studio
1.2, using a minimum SDK version of 16 (Jelly Bean) Jelly Bean was picked as
the minimum target SDK so that 87.5% of devices registered with Google running
Android could download and use the application (Google, 2015)
Java was chosen as the main programming language as it is a mature
programming language with significant support forums available.

It was decided to use Android Studio over Eclipse or other IDEs as it is now
Googles recommended platform for developers (InfoQ - Android Developers Are
Recommended to Switch from Eclipse to Android Studio 1.0, 2014) and includes
a number of useful features including setting up the correct SDK, optimized
emulators and code templates, multiple APK generation for debug/release, and
integration with Google Cloud Services.
2.3.2. Parse SDK & Parse API
For authentication, databasing and user control, the extensive Android Parse
SDK and Parse API was used. Parse enabled one to “Focus on creating amazing
user experiences and forget complex infrastructure.” (Parse.com 2015)
By utilising the infrastructure provided by Parse, development time that would
have been spent creating the backend was freed up so more time could be spent
implementing the applications most important features.
While there are many other mobile back end services available, such as
AnyPresence, Feed Henry, App42 Cloud API and Kinvey, none of these services
has a free tier or a comparable level of documentation and support.

3 System
This section will detail the requirements for the application and the overall
system design and architecture. This will give a complete picture of how the
different technologies, API’s and components work together to deliver the end
user experience and the applications different functions. Each of the technologies
will be given an explanation with information on how it was implemented into the
project. Finally, how the application was tested and descriptions of the GUI.
3.1 Requirements
The requirements for this application where gathered through online research
and conversations with app users in the 18-30 demographic.
3.2 Functional requirements
Below are the key functional requirements of the application , listed in no
particular order.
3.2.1. Registration
Upon installing and opening the application, the user is presented with a screen
that allows them to register with the application. The user enters their email
address and a password in to the EditText boxes provided. This information is
passed to a Parse database containing user details. On registering the user is
brought to a welcome screen, giving a brief overview of the applications main
functionality. From here they may proceed to the main activity.
While user anonymity is one of the core features of this application, it was
decided that keeping a record of all users would be good pratice, given the
possibility of misuse of the application (cyberbullying etc) In the case of serious
breaches of the terms of use of the application, it would be important to have a
record of the users in question.
If a user has already registered and is returning to the application, there is a link
from this screen to a login activity.

3.2.2. Login
If a user has already registered with the application, they may log in by
confirming their email address and password at the login screen. The system
verifies the users details against the records held in its online database and
returns an error message if the details are incorrect. If no errors are found, the
user proceeds directly to the main activity. The system keeps track of a logged in
user and in most cases there is no need for a user to log in each time they wish
to use the application.
3.2.3. Logout
A user may logout by navigating to the settings menu of the ActionBar in the top
right corner of the main activity, where they are presented with a log out button.
It is envisioned that a user would only wish to log out of the application if they wish
to switch accounts or if they are using another persons device temporarily.
3.2.4. Navigate the map
The map view, as provided by the Google Maps API, represents the main activity
of the application and a foundation from which the other functionalities stem.
On loading the map view, the camera zooms to a marker representing the users
current location. A custom info window displays a welcome message and a
prompt for what the user should do next. The user may browse the area in their
direct vicinity and view messages created at various map locations, as
represented by a marker.
On clicking the marker representing their current location, the user is brought to a
an activity that allows them to create a new message, or view messages that
were created at that location. On clicking any of the other markers the user is
presented with a list of messages that were created at that location.
The user may also choose to use the search bar at the top of the screen, which
utilises the Geocoding API, to search any location on the map to view messages
that have been created there.

3.2.5. Create a new message
On clicking the map marker representing the users current location, the user is
brought to a sliding tabbed interface that allows the user to view messages
created at that location (by other users or themselves), or create a new message.
On the create message tab, the user may input a short message (max length 150
characters) and save this message to an internal SQLite3 database on the
device. The latitude and longitude coordinates of the users current location are
also passed with the message and are used to identify where the message was
created when querying the database. A timestamp is also created representing
the timeat which the message was created. If the user then naviagtes to the view
messages tab, the database is queried and adds the message to the list of
messages using an Async task.
An important functionality of the application is that a user may only create
message at their current location. This helps to create a more relevant and
personal feed of content for users in their present locale.
3.2.6. View messages
On clicking on a marker representing the users current location, or any other
marker representing a message that has been left at a location, the user may
view the messages left at that location. The user is brought to an activity that
lists all these messages in the form of a ListView. The message are retieved
from the database using a method that queries the database for messages with
latitude and longitude coordinates that match those of the marker in question.
3.2.7. Notify user of nearby message
When a user creates a message, any other user within the direct vicinity (100
meters) at the time is notified. This functionality may be disabled if the user so
wishes. The application utilises the Google Geofencing API to create a 'fence'
around the users current location where the message was created and detects
whether there are other users within that fenced area. If there are, and if their
notifications are enabled, the application utilises Parse, which can use Google
Cloud Messaging to receive push notifications. A silent push notification is sent
in the afteSave method of the message class, thus enabling an important

functionality of the application, namely the ability to have real time anonymous
conversations and interractions with other users.
3.3 Data requirements
3.3.1. Local Data Requirements: This refers to the amount of data neede on
the device to download install and run the app correctly. The app is not
data intensive, nor does it have a large file size. It is envisioned that
15MB will be ample space on which to download the application.
3.3.2. SQLite Integration: The application houses an internal SQLite database.
This database is regularly synced with the applications server side
databases, that allows the user to view the most up to date message
information. If the user does not currently have network connectivity,
they may still interract with the application in a more limited fashion.
They can save messages locally, but the data will only be updated on the
server side when the user regains network connectivity, allowing a sync
of data to take place.
3.3.3. Cloud Data Storage Requirement: The cloud storage system will hold all
data on users and messages Parse allows an application instance to
utilise up to 20Gb of storage space.
3.4 User requirements
The user requirement specifies the essential requirements needed by a user to
use this application.

The following is a list of those requirements:
• A phone or tablet running Android 4.1 or higher.
• Google play services installed to download the application from the
Google Play Store.
• Access to the internet through a mobile network or WiFi.
• GPS signal for location data.
3.5 Environmental Requirements
The environmental requirements specify the development software and hardware
needed to create and test the application.
The following is a list of those requirements:
• A computer or laptop running Windows, OSX or Linux
• Android Studio IDE
• An Android Phone running 4.1 or higher.
• Internet access for accessing API resources, communicating with Parse
and testing.
3.6 Usability requirements
The system should provide a simple and attractive user interface, promoting an
instinctive navigation of the application. Where it might not be clear what action a
user should take, the system should provide hints and prompts. Similarly, if there
is an error, on the users, or on the systems side, the system should inform the
user and provide an explanation, making every effort to allow the user to fix the
problem themselves.
The style and layout of the application should keep to the rules given in the
Google Material design specification.

4 Design and Architecture
4.1 Implementation
This section will detail the technologies harnessed during the implementation of
the Android application. Methodologies will also be described.
4.1.1. Sign up and log in with Parse
As an essential part of most applications, and one of the first impressions a user
has of your application, it's vital that the sign up and login activities work as
expected and provide the necessary validations.
Here, we enable the local Parse datastore and initialize Parse with the API key
and the client key.

4.1.2. Login
In the onCreate() of the Login Activity, the class checks if the current user is
already logged in.
If the current user ID is not equal to null then the Welcome activity is loaded
through an intent.
The user enters their details into the editText input boxes and clicks the the login
button, calling the login method below. If a user has not registered yet there is a
link to the sign up activity at the bottom of the login page.
The ParseUser.logInInBackground method is called to authenticate the user
against the online database. It takes both a username and password as its
arguments. The network operations are executed in a background thread so that
the main thread isn’t blocked. If there are no errors then the welcome activity is
loaded. If the username and password combination is wrong or the user does not
exist then the system displays a toast message with an error.
The sign up method is quite similar.

4.1.3. MainActivity/Map
The map view, as provided by the Google Maps API, represents the main activity
of the application and a foundation from which the other functionalities stem. As
such it was vital that this component behave in an optimal fashion, particularly
when updating the users location.
We grant permission to the application to access the devices location data, and
declare the API key, received from the Google Developers Console.
Receiving the users location is handled in the AppLocationService class

And then utilised in the MainActivity to get latitude and longitude coordinates that
the application can work with.
The coordinates are then used to place a marker representing the users current
location. This information is placed in a hashmap with the name allMarkersMap.
The hashmap is used to create hashed pairs of different categories of marker
and their behaviour on clicking them. This will be useful when we want to allow a
user to only create a message at their current location.

We receive the coordinates of all the messages that have previously been saved
in the applications SQLite database. These coordinates/messages are all
assigned a marker, and this category of marker and it's clickable behaviour are
also placed in the allMarkersMap hashmap.
4.1.4. Creating a message
On clicking the marker representing the users current location, we navigate to a
sliding tabbed interface containg two fragments, the AddMessageFragment and
MessageListFragment. The AddMessageFragment prompts the user to enter a
short (150 characters) message in the EditTextView provided and click the save
button on completion. The setMessage method takes the users input and
prepares it to be entered in the database.

4.1.5. Message Database Adapter (MessageDAO)
The applications SQLite Database is defined in the DataBaseHelper2 class which
extends SQLiteOpenHelper
The majority of the applications interractions with the database though, is defined
in the database adapter entitled MessageDAO. This includes the Save method
for the user input messages as outlined above

We also see the query constructed to return the contents of the Message table
We find a similar query method used to return the coordinates of the messages
that have been saved to the table to the MainActivity, where that data is utilised
to create markers on the map.

And another similar query method (getLLMessages) queries the database and
retrieves certain messages based on whether their latitude and longitude
coordinates match the coordinates passed on clicking a map marker. These
values are defined in the selection[]args of the query.
4.1.6. LLMessagesFragment
After retrieving specific messages using the getLLMessages query detailed
above, we display them in a listview in the LLMessagesFragment. On clicking a
map marker representing a message placed on the map, the user is brought to a
single fragment containing a listview of message items. These items are created

dynamically by employing an Async task to getLLMessages from the database
and display them as individual listview items by way of the llMessageListAdapter

5 Testing
This section will detail how each component of the system was tested during the
process of its creation.
5.1 Tools
Android Studio provides a suite of tools that can be used to extensively test out
the applications speed, responsiveness and memory footprint. The 2 most used
tools in the project were the Android Virtual Device emulator and LogCat.
LogCat is essential to debugging and testing the system along the way, providing
a detailed output of any errors that occur while the application is running. One
may add their own error indicators in by calling the following method.
The method prints whatever text is in the method whenever that section of the
code is run. This allows a developer to quickly pinpoint problem areas and to
understand when different code segments are run.
The testing methodology used in this project was simple but effective. All the
testing of the applications functionality and code was carried out using LogCat.
LogCat divides all of its log messages into 6 different categories. Debug, Info,
Warning, Verbose, Assert and Error. LogCat allows a user to filter messages
based on the category.

5.2 Backwards Compatibility Testing
Android Studio has the Android Virtual Device module built in. Together with the
Android SDK manager each version of the OS is downloadable and can be then
ran as a virtual machine. This allowed for easy testing of the application in a
virtual environment with multiple screen sizes and Android versions.

6 Graphical User Interface (GUI) Layout
The user registration screen The user login screen

Login screen with user input validation Welcome screen
message

Initial map view with a green marker representing the users current location, and
blue markers representing messages previously left at those locations.

The message creation fragment

Viewing all the messages that have been created (left), and viewing a message
specific to a given location (righ)

7 Conclusions
7.1 Milestones and Hurdles
Starting from a base of almost no knowledge of Android development less than 4
months ago, this application was always going to face significant challenges in its
succesful realisation. The initial challenge was to harness the Google Maps API
and create a fully functional map view. As the map view makes up the core of the
applications functionality from which all the other features of the application stem,
it was vital that it should work efficiently, particularly in retrieving the users
location at optimal intervals. Once this was achieved, it was necessary to
develop an attractive and intuitive user interface that would form a solid
foundation on which to build the other features.
One of the main challenges was creating persistent application data. It took a
while to get to grips with the process of saving and retrieving data from the
internal SQLite database and then using that data to create markers on the map.
A particularly challenging aspect was allowing a user to only view the messages
specific to a given location, as signified by a map marker. While this was
eventually achieved, I was not able to merge the contents and behaviours of
markers that were very close to, or on top of one another.
A number of options were explored to achieve server side data storage for the
application. Initial efforts had seen the creation of a simple Ruby on Rails API to
handle data storage and retrieval, but without success. A users database was
also developed succesfully using a WAMP server and written in PHP,using the
Volley library on the Android side. In both cases, the results were not wholly
succesful and saw a lot of time and energy being spent in their development,
taking attention away from the applications core functionality. After careful
consideration, it was decided to make use of Parse to fulfill the applications
server side rquirements.

8 Further development or research
I do feel that this is an idea that has legitimate potential to be developed in to a
product that a significant number of people would be interested in using. The
concept is simple to grasp and a number of individuals have expressed an
interest in testin a finished version. As stated at the beginning of this report,
while there are a number of applications that contain elements of similar
functionality, I have yet to find any that do what IWOZERE would do. As such I
intend to develop this application further over the coming months and create
something that can be released for public consumption. Even if the application
does not realise the commercial success I feel it could have, it can serve as a
useful excercise for my own learning benefit.

9 Bibliography
“Dashboards.” Dashboards. N.p., n.d. Web. 15th
May 2015.
<https://developer.android.com/about/dashboards/>
“Google Design.” Google Design. N.p., n.d. Web. 15th
May 2015.
<http://www.google.com/design/>
“InfoQ” Android Developers Are Recommended to Switch from Eclipse to Android
Studio 1.0. N.p., n.d. Web 15th
May 2015
<http://www.infoq.com/news/2014/12/android-studio-1>
Clune, Bronwen, “The Guardian.” So Twitter is ruining journalism? Really? 13th
November 2013. Web. 22nd
May 2015
<http://www.theguardian.com/commentisfree/2013/nov/13/so-twitter-is-ruining-
journalism-really>
“Parse - Pricing Plans.” Pricing. N.p., n.d. Web. 4th
May 2015.
<https://parse.com/plans>
“Post Secret” Web. 4th
May 2015
<http://postsecret.com/>
“Whisper” Web. 4th
May 2015
<https://whisper.sh/>
“YikYakApp” Web. 4th
May 2015
<http://www.yikyakapp.com/>
“GeoCaching Ireland” Web. 4th
May 2015
<http://www.geocachingireland.com/>

10 Appendix
Attach all your partial submissions as appendices.
10.1 Project Proposal
IWOZERE
Tadhg Ó Cuirrín, X14109824, tadhger87@gmail.com
Higher Diploma in Science in Computing
Mobile Technologies
05-02-2015
10.1.1. Objectives
'IWOZERE' (I was here) is a social media Android application for mobile devices
which allows the user to anonymously pin a short message to a Google Maps
location.
Upon installing and opening the application, the user is presented with a pin
displaying their current GPS location on a map. On clicking on that location the
user may leave a short anonymous message (150 characters) which is then
pinned to that location and never deleted, along with any messages left by other
users. The message is pushed to the devices of any other users who are at that
location (within 10 meters) at the same time. Messages can be upvoted and a
user may view popular messages or the most recent messages. Users will also
have the option to upload a photo taken on their devices camera, and will also be
able to choose from a large range of emojis in their message. Users can navigate
the map to any other location around the globe to view messages that have been

10.1.2. Background
When approaching this project, I sought to create an application that was simple
in concept and construction but open ended in such a way as to allow for a
myriad of different uses. The basic function of leaving messages at different
locations on a map calls to mind a kind of 'digital graffiti'. By 'graffiti' I refer more
to the kind of strange short messages and self aggrandizing tags found dotted
around the urban environment - on disused walls and bathroom cubicles, as
opposed to large elaborate pieces. Much of the content created in the application
in this way would likely be humorous, entertaining and frivolous, similar to other
social media outlets and indeed graffiti itself. And like graffiti, an important feature
of the application is the permanence and the anonymity of the message
But I feel that while this graffiti aspect could be interesting and popular in itself,
the application could have other uses aside from the kind of throwaway
comments described above. Consider for example how users could use the
application to interact with one another at a public event, say a bar, nightclub,
party etc. The anonymous nature of the messages could make it well suited to
flirting with other users, and gossiping about other individuals present, or to find a
friend if you have become separated. It could also be used to leave reviews of
different restaurants, businesses and other attractions.
intersect with the contemporary news gathering and journalistic process, but the
fact that a message can only be left at a location where a user is physically
located could serve to drown out some of the less relevant voices.

manner when one considers the similarities with activities like geo-caching.
10.1.3. Technical Approach
The application shares functional similarities with other well know applications,
from the micro posting and instant messaging of Twitter, to the peer review of
Yelp and FourSquare, amongst others. The pinned messages feature is one I
have come across more recently in the Dublin web based multimedia project
Storymap. I hope to research the best features and concepts of these
applications and how they are implemented, and apply them in my own
application.
10.1.4. Special resources required
I assume I will at some stage make use of different online code and software
libraries. Also of use will be Ruby on Rails Tutorial (3rd Ed.) Learn Web
Development with Rails by Michael Hartl.
Android 4.4 App Development Essentials by Neil Smyth,
10.1.5. Project Plan
A Gaant diagram for the project can be viewed here
10.1.6. Technical Details
The application will be constructed in Java and XML with access to a
Heroku backed Rails back end server which will be used to store database
information such as the comment histories of various locations. Since the
application is anonymous it need not necessarily store any information about the
users.

Figure 1. Welcome screen Figure 2. Initial screen – your location
Figure 3. Write message or view messages at location Figure 4. Write message

Figure 5. Message sent Figure 6. View messages already posted at this location
10.1.7. Evaluation
I will employ an iterative evaluation process and all best practice testing methods
in the completion of my application. The application will also benefit from some
real user testing given the social networked nature of the application.
_____________________
Tadhg Ó Cuirrín
05-02-15

10.2 Project Plan
10.3 Requirements Specification
10.3.1. Project Scope
The scope of the project is to develop a social media application for Android
devices.…………….The system shall have a ……………
As part of the second semester of the Higher Diploma in Science in Computing
(Mobile Application Development) I was required to specify, design, implement
and document a medium to large scale mobile or web application in a chosen
area of specialisation.
'IWOZERE' (I was here) is a social media Android application for mobile devices
which allows the user to anonymously pin a short message to a Google Maps
location.
Upon installing and opening the application, the user is presented with a pin
displaying their current GPS location on a map. On clicking on that location the
user may leave a short anonymous message (150 characters) which is then
pinned to that location and never deleted, along with any messages left by other
users. The message is pushed to the devices of any other users who are at that
location (within 10 meters) at the same time. Messages can be upvoted and a
user may view popular messages or the most recent messages. Users will also
have the option to upload a photo taken on their devices camera, and will also be
able to choose from a large range of emojis in their message. Users can navigate
the map to any other location around the globe to view messages that have been

10.3.2. Background
When approaching this project, it was hoped to create an application that was
simple in concept and construction but open ended in such a way as to allow for
a myriad of different uses. The basic function of leaving messages at different
locations on a map calls to mind a kind of 'digital graffiti'. By 'graffiti' we refer
more to the kind of strange short messages and self aggrandizing tags found
dotted around the urban environment - on disused walls and bathroom cubicles,
as opposed to large elaborate pieces. Much of the content created in the
application in this way would likely be humorous, entertaining and frivolous,
similar to other social media outlets and indeed graffiti itself. And like graffiti, an
important feature of the application is the permanence and the anonymity of the
message
But while this graffiti aspect could be interesting and popular in itself, the
application could have other uses aside from the kind of throwaway comments
described above. Consider for example how users could use the application to
interact with one another at a public event, say a bar, nightclub, party etc. The
anonymous nature of the messages could make it well suited to flirting with other
users, and gossiping about other individuals present, or to find a friend if you
have become separated. It could also be used to leave reviews of different
restaurants, businesses and other attractions.
intersect with the contemporary news gathering and journalistic process, but the
fact that a message can only be left at a location where a user is physically
located could serve to drown out some of the less relevant voices.
manner when one considers the similarities with activities like geo-caching.

10.3.3. Project objectives
 To develop this project within the time frame and parameters outlined in
the project brief.
 To achieve at least a minimum level of functionality in the application.
 To then build on that level of functionality to include improved and more
advanced functionality.
 //
Succesful criteria of the project
The project will be deemed succesful if it fulfills a minimum set of criteria
 The mobile application features all requisite user interfaces and navigates
between them succesfully.
 The maps api functions correctly and displays the users location
accurately.
 The users messages are succesfully stored in a database using Google
Cloud Messaging, on a Rails backed server with geo-location coordinates
corresponding to a map location.
 Messages can be retrieved from the database and displayed at their given
location in the map view of the application.
10.3.4. Project expectations:
 It is expected that the project will be completed to the level of functionality
defined above
10.3.5. User Requirements Definition
The system should provide a simple and attractive user interface, promoting an
instinctive navigation of the application. It will allow users to see in the map view
all the locations which hold messages. This will be achieved through small icons
pinned at said locations that when clicked, reveal a pop up window showing the
messages that have been left there, organised by most recent and most popular.
Given the small quantities of data involved in the messages, it is envisioned that

the posting and retrieving of messages should be achieved speedily.
It is important for the user that the application should be visually appealing and
easy to navigate. A simple interface should allow the user to be able to see at a
glance of the map interface where messages have been left (achieved through
the use of small icons marking the locations) The messages should be accurate
in their correspondence to a given location. The system must also allow for
speedy posting and retrieval of messages from the server to optimally facilitate
the pushing of messages to the devices of other users within their location radius.
It is hoped that given the small data quantities of the messages it should be
possible to achieve this speed of sending and receiving messages from the
server.
10.3.6. Requirements Specificiation
All requirements should be verifiable. For example, experienced controllers shall
be able to use all the system functions after a total of two hours training. After this
training, the average number of errors made by experienced users shall not
exceed two per day.
10.3.7. Functional requirements
1. Registration
2. Post messages to a map location.
3. View messages at a map location.
4. Upvote other users messages.
5. Post images and other media as messages.
IWOZERE is mobile application for Android devices and as such is soley
supported on Android powered devices. All messaging is handled through the
IWOZERE server. The application is developed for Android 2.2 (Froyo) and all
versions therafter. Android supports push and pull messages to synchronise
data between the application and server and information will be sent and
received using TCP/IP and HTTP protocols.

It will be developed using the Java JDK and Android SDK. It will have a Ruby on Rails,
web based network server that will store and retrieve message information in a
database. A HTTP push protocol will push notifications of new messages from other
users to a users device via the server in real time, when they are within a specific
proximal radius of those users. Similarly, a pull protocol will be used to retrieve and sync
new messages for locations when the user opens the application.
10.3.8. Use Case Diagram
10.3.9. Requirement 1: User Registration
10.3.9.1 Description & Priority
The user registers an acoount with the application. This is the first requirement
of the system.
10.3.9.2 Use Case

Scope
The scope of this use case is to a register a new user within the system
Actors
User
Description
This use case describes the process of anonymously creating a short text based
message, to be associated and pinned with the users current location on Google maps
which can then be viewed by other users.
Flow Description
Precondition
The user must have succesfully downloaded and installed the application on thewir
device.
Activation
This use case begins when the user opens the application
Main flow
• The user clicks the register button
• The system acknowledges that the user wishes to register
• The user inputs a valid username, email address, password, and other required
information.(see A1)
• The user completes the process and clicks the “Complete registration” button
• The user is succesfully registered (see E1)
Alternate flow
A1: Invalid input
◦ The user inputs non valid information in one or more fields and must re-enter
the information

Exceptional flow
E1: Loss of data connectivity
 The users device suffers a loss of data connectivity and the user is unable to
complete the registration proccess.
Termination
Registartion is succesfully completed
Post condition
The users registration details are stored in a database on the applications web server
10.3.10.Requirement 2: Create message
10.3.10.1 Description & Priority
The user creates a message that is then connected to a given map location. This
is one of the main functionalities of the application.
Scope
The scope of this use case is to create a message on the map at the users current
location
Actors
User
Description
This use case describes the process of anonymously creating a short text based
message, to be associated and pinned with the users current location on Google maps
which can then be viewed by other users.
Flow Description
Precondition
The users location must be available to the system via GPS or other location service.
The users must have data connectivity.
The user must be currently present at the location at which they wish to post a message.

Activation
This use case begins when the user clicks on the 'Post message' button
Main flow
1. The system acknowledges that the user wishes to post a message
2. The user inputs their message using the keyboard and presses the 'Submit'
button (see A1)
3. The comment is pinned to that location and can be viewed by other users (see
E1)
Alternative Flow
A1: Create a message using other media
◦ The user opts to create a message using other media (image or sound) to
this location alongside or instead of a text based message.
Exceptional Flow
E1:
◦ The user loses data connectivity and is unable to post the messages
Termination
The message is submitted and appears on the system at that location and is visible to
other users.
Post condition
The HTTP push protocol sends the messages to a database on the applications
web sever. The message is also pushed via the server to the device of any other users
within a proximal radius.

10.3.11.Requirement 3:View messages
10.3.11.1 Description and priority
The user views messages from other users at a given location. This is one of the key
functionalities of the application.
Use Case
View messages at a location
Scope
The scope of this use case is to view messages posted at a location
Actors
User
Description
This use case describes the process of viewing messages posted at a location, either in
chronological order, or in order of most popular messages.
10.3.12.Non Functional Requirements
Performance requirements
 As the applications server queries will all involve small pieces of data, it is not
envisioined that the performance should be an issue. It is hoped that this will
allow the application to function quickly and contribute to the users ease and
enjoyment of use.
Security requirements
 The user will be required to register with the application on succesful installation.
While messaging will be anonymous, the system will keep a record of the users
messages to provide a degree of accountability in the event of misuse of the
application or issues of cyber bullying for example.
 The application will not affect other applications on the users device and will not
affect data stored outside of its server.

10.1.1. Performance/Response time requirement
10.1.2. Availability requirement
10.1.3. Recover requirement
10.1.4. Robustness requirement
10.1.5. Security requirement
10.1.6. Reliability requirement
10.1.7. Maintainability requirement
10.1.8. Portability requirement
10.1.9. Extendibility requirement
10.1.10.Reusability requirement
10.1.11.Resource utilization requirement
10.1.12.GUI
Include mock-ups of the key pages or stages of the system. Explain how they are
linked. Explain how you addressed above requirements in the design. It is
important that the mock-ups are in line with the functional requirements above,
e.g., if one of your requirements is “user registration” then one of the screens
listed in this section should show a registration page.
10.2 Project Analysis & Design
10.3 Project Test Plans
10.4 Monthly Journals
10.4.1. Monthly Journal #1
Month: February
My Achievements

This month, I continued to develop the UI of my application during March. I had
to try a few different configurations to find a settup that was suitable for what I
was looking for and so have taken longer developing this aspect of the
application. I now have a succesfully functioning map fragment activity that links
to a viewpager containg a swipeable tab layout. The first tab asks the user to
create a message which is then sent to and SQLite3 database and is (nearly!)
retrieved in the next fragment in a listview.
My Reflection
I've begun to realise the limits of my understanding of Android development. In
the first month of term I was able to get to grips with the basics relatively easily,
but as I have progressed I've found it considerably more difficult to complete
more difficult activities. The nature of the course feels like there is little time
available to cultivate a good uinderstanding of various concepts. This is just
something I must accept and deal with as best I can.
At the same time, it's still quite possible that I will be able to complete the project
on schedule with most of the apps main functionality in place. Once the SQLite3
database is set up and receivining data and in turn poulating the list view with
this data, the information can be used to assign markers to the map view. On
clicking these markers we can then view the messages there. This is the main
functionality of the project and if I can implement this, I can spend any additional
time adding other functionality, improving the UI and adding other validation. I
also hope to be able to set up and link to databases on the server side too,
although this may prove too difficult. We shall see!
However I still feel like there are big gaps in my knowledge for how I am going to
implement my desired features in to this application. I particularly am unsure as
to how information will be stored and retrieved from a web server database and
how that information can be 'layered' over the map and other user interfaces. I
feel right now, that I need to speak more to lecturers to help figure out a broader
overview of the areas I should be thinking about and researching, and coming up
with a clearer plan as to how things will fit together.
Intended Changes

Next month, I will try to begin to piece together the different areas I am learning
about and get a better understanding of how thing s will fit together. I hope to be
able to complete the essential functionalities of the application and only leave
myself with non-essential extras to work on, as well as all the required
documentation.
Month: March
My Achievements
This month, I continued to develop the UI of my application during March. I had
to try a few different configurations to find a settup that was suitable for what I
was looking for and so have taken longer developing this aspect of the
application. I now have a succesfully functioning map fragment activity that links
to a viewpager containg a swipeable tab layout. The first tab asks the user to
create a message which is then sent to and SQLite3 database and is (nearly!)
retrieved in the next fragment in a listview.
My Reflection
I've begun to realise the limits of my understanding of Android development. In
the first month of term I was able to get to grips with the basics relatively easily,
but as I have progressed I've found it considerably more difficult to complete
more difficult activities. The nature of the course feels like there is little time
available to cultivate a good uinderstanding of various concepts. This is just
something I must accept and deal with as best I can.
At the same time, it's still quite possible that I will be able to complete the project
on schedule with most of the apps main functionality in place. Once the SQLite3
database is set up and receivining data and in turn poulating the list view with
this data, the information can be used to assign markers to the map view. On
clicking these markers we can then view the messages there. This is the main
functionality of the project and if I can implement this, I can spend any additional
time adding other functionality, improving the UI and adding other validation. I

also hope to be able to set up and link to databases on the server side too,
although this may prove too difficult. We shall see!
However I still feel like there are big gaps in my knowledge for how I am going to
implement my desired features in to this application. I particularly am unsure as
to how information will be stored and retrieved from a web server database and
how that information can be 'layered' over the map and other user interfaces. I
feel right now, that I need to speak more to lecturers to help figure out a broader
overview of the areas I should be thinking about and researching, and coming up
with a clearer plan as to how things will fit together.
Intended Changes
Next month, I will try to begin to piece together the different areas I am learning
about and get a better understanding of how thing s will fit together. I hope to be
able to complete the essential functionalities of the application and only leave
myself with non-essential extras to work on, as well as all the required
documentation.
Month: April
My Achievements
After finding myself stuck in a relatively stationery position for much of March, I
managed to make some steady progress during April. Having developed the
main components of the UI already, during April I implemented an internal SQLite
database to save user input messages from the application. This allowed a
users message to be saved along with the latitude and longitude coordinates of
the users location from which the message was created, and also a timestamp to
display when it was created. I was then able to use this information to populate a
listview containing all the messages, and to then populate the map with markers
displaying where various locations had been saved. With these markers in place
I was then able to pass intents to direct users to separate activities depending on

which marker had been clicked and whether or not the user was currently at that
location.
I also began to implement geoding and reverse geocoding to allow the user to
use text input to a search bar at the top of the map activity to search for a
location on the map. I have thus far been unsuccesful in implementing an
autocomplete function for this search bar.
My Reflection
While good progress has been made during April, I still realise there is much to
be achieved. My main focus at this point in time is related to the different
functionality of different classes of map marker. When a user clicks on a map
marker, it should only display the messages that were left at that specific location
and no others. It should alos only allow a user to create a message at their
current map location. I am trying different approaches to implemtn this
functionality, including conditional queries of the database, and using additional
database tables to better filter the information. None have been succesful up to
this point, though I feel that the challenge is not insurmaountable and I could in
fact be close to a solution. Were I to achieve this I would have the core
functionality of the application in place and would be able to demonstrate an
application that does most of what I had proposed in my initial proposal.
Intended Changes
With the final deadline for the project fast approcahing, I know my time is limited.
If I can resolve the issue above, I will then look to implement data persistence on
the server side and allow the application to get and post data to a server. This
may be challenging enough in itself though there seems to be a lot of information
available on the topic online so it is potentially achievable. I would also ideally
look to to implement google cloud messaging to the application to allow different
users to 'communicate' in real time, though again this may be a challenge in and
of itself. I will also complete the written report aspect of the project.

HDSMT Technical Report - X14109824

Recommended

Recommended

More Related Content

Similar to HDSMT Technical Report - X14109824

Similar to HDSMT Technical Report - X14109824 (20)

HDSMT Technical Report - X14109824