Embed Size (px)
Citation preview
Carleton University COMP 4905 – Honours Project
Android SMS Web Administration
Evan McEwen Dr. Dwight Deugo August 20, 2012
Acknowledgments
Special thanks to Blake Mesdag; a Computer Science Major at Carleton
University and employee of Shopify (www.shopify.com). His knowledge
of Ruby, the Rails framework, and Git helped quickly solve numerous
questions of mine as I attempted to learn all these technologies on the
go.
Table of Contents
1.0 Introduction .................................................................................................................... 4
1.1 Problem ........................................................................................................................................ 4
1.2 Motivation .................................................................................................................................... 4
1.3 Goals ............................................................................................................................................... 5
1.4 Objectives ..................................................................................................................................... 5
1.5 Outline ........................................................................................................................................... 6
2.0 Background ..................................................................................................................... 7
2.1 Minor Definitions for Systems and Frameworks ............................................................ 7
2.2 The Android Platform .............................................................................................................. 8
2.3 Android Cloud to Device Messaging Framework ............................................................ 9
2.4 Ruby on Rails ............................................................................................................................ 10
2.5 The Git Revision Control System ........................................................................................ 10
2.6 Server Hardware for Web Hosting .................................................................................... 11
3.0 Approach .......................................................................................................................... 12
3.1 Initial Research ........................................................................................................................ 12
3.1.1 Android Cloud to Device Messaging Framework ................................................................ 12 3.1.2 Android Framework and SDK ..................................................................................................... 13 3.1.3 Ruby on Rails with C2DM .............................................................................................................. 14 3.1.4 Front-‐end Development Choices ................................................................................................ 15
3.2 Design Decisions & Implementation ................................................................................. 18
3.2.1 Web Application Back-‐end (Rails) ............................................................................................. 18 3.2.2 Web Application Back-‐end (JavaScript) .................................................................................. 24 3.2.3 Web Application Front-‐end .......................................................................................................... 26 3.2.4 Web Application Model Diagram ............................................................................................... 31 3.2.5 Android Application Back-‐end .................................................................................................... 32 3.2.6 Android Application Front-‐end .................................................................................................. 38
3.2.7 Android Application Software Diagrams ................................................................................ 42 3.3 Development Challenges ....................................................................................................... 45
3.3.1 The Android SMS Database .......................................................................................................... 45 3.3.2 Keeping Sync ....................................................................................................................................... 46 3.3.3 Dynamic Content Updates ............................................................................................................. 47
4.0 Results ............................................................................................................................... 49
4.1 Web Application ....................................................................................................................... 49
4.1.1 Signing Up and Logging In ............................................................................................................. 50 4.1.2 Conversations ..................................................................................................................................... 51 4.1.3 Search ..................................................................................................................................................... 53
4.2 Android Application ............................................................................................................... 54
4.2.1 Signing In .............................................................................................................................................. 55 4.2.2 Syncing Events ................................................................................................................................... 56
5.0 Conclusion ........................................................................................................................ 57
5.1 Self-‐assessment ........................................................................................................................ 57
5.2 Final Product ............................................................................................................................. 58
6.0 Future Work .................................................................................................................... 59
6.1 Security and Encryption ........................................................................................................ 59
6.2 Web Application Usability .................................................................................................... 60
6.3 Android GUI ............................................................................................................................... 60
6.4 A better Synchash .................................................................................................................... 61
7.0 References ........................................................................................................................ 62
Appendix A – HTTP Verbs .................................................................................................. 65
Abstract
This paper describes a web site that interfaces with an Android application on a
cellular device to allow for text messaging within a web browser. Modern web
technologies such as Ruby on Rails and Twitter’s Bootstrap will be utilized to build a
fully modern Web 2.0 application. Design considerations will be shown in detail
along with all developmental challenges and successes encountered. A final proof-‐
of-‐concept version will be demoed with a discussion on the future improvements
necessary to bring the entire application into a more realized form.
4
1.0 Introduction
1.1 Problem
The purpose of this project is to create an easily used web application that
will allow anyone with an Android device connected to a cellular network to send
SMS (Short Message Service, more commonly known as ‘text messages’) messages
from the web browser. When working at or near a computer it is far easier to send a
text message with a keyboard than it is to pick up the phone and interrupt your
workflow. With a web interface it will also be easier to search through existing text
history.
1.2 Motivation
For those who are near a computer most of their workday it is very
disruptive to workflow when a text message is received. Attention is drawn from the
current task to the phone in order to respond. The speed at which one can respond
is also drastically reduced when compared to an instant message received on a
desktop due to the nature of the mobile device itself; most phones are small with
virtual keyboards increasing the likely hood of wrong key presses. If there was a
way to both receive and respond to text messages on their computer without
touching their phone, disruptive workflow may cease to exist. If a computer with a
keyboard is easily accessible, it should be able to respond to the text message on the
phone.
5
1.3 Goals
A website will be created that communicates with an Android application
and sync all SMS messages from the Android device to the web application. This
includes those messages present at the initial sync and any further messages
received. If possible this is to be done in real-‐time. The web application should then
be able to view each SMS conversation and send messages via forwarding them onto
the Android device. Since all SMS’s are stored locally on the web server it should be
possible to search for keywords to find specific messages.
1.4 Objectives
The goal of this project is to create a web application that can interact with a
mobile Android device and its text messaging abilities and storage. The Android
device will itself have an application to interact with the web application. The web
application will be able to receive and display the incoming texts received on the
Android device in near real-‐time. The web application will be able to send responses
limited only by the speed of the push-‐notification service provided by Google’s cloud
messaging service.
Other features such as searching will be possible on the web application once
it has a local copy of the Android device’s text messages. The web application should
support multiple users and possibly multiple devices per user.
6
1.5 Outline
Section 2, the next immediate section, will be detailing all the relevant
background information related to this project. It should give the reader a good
basis to understand the rest of the report. Section 3 discusses the entire
developmental approach I took to this project. I begin in Section 3.1 with all my
initial research and findings on the various technologies needed. 3.2 discusses the
design and architectural decisions that were made in building the project along with
the implementation and section 3.3 details some of the major developmental
challenges encountered when attempting to implement the technologies discussed
in 3.2. Final walkthroughs of the application are given in section 4 along with the
results received from the application. Section 5 details my ultimate conclusions
including an important lesson learned and a self-‐assessment. The report concludes
with section 6, which is a discussion on the future work that could be applied to this
project. A single appendix and references follow this section.
7
2.0 Background
A brief overview of the major technologies and hardware utilized will be given.
2.1 Minor Definitions for Systems and Frameworks
In the following sections major systems and frameworks are discussed. Some
minor knowledge is needed to explain these concepts. Some minor systems,
frameworks, and definitions are below:
SDK: Software Development Kit. A collection of tools and program code used by
developers to create extensions or new features for existing programs/hardware.
Java: A programming language. See (Oracle, 2012) for more details.
Javascript: A scripting language used on the World Wide Web. Allows for greater
dynamic functionality within websites. Used extensively in web applications.
IDE: Integrated Development Environment. A piece of software that includes many
tools that help developers create and maintain code.
Eclipse: An IDE written in Java. (The Eclipse Foundation, 2012)
GUI: Graphical User Interface. What the user interacts with on screen.
API: Application Programming Interface. A series of documented code functions that
can be used by a developer to communicate with a piece of software. Usually
included in an SDK.
SMS: Short Messaging Service. The technical name for “text messaging” on mobile
devices.
8
SQL: Structured Query Language. A programming language used to manage data in a
relational database.
MySQL: The world’s most used open source relational database management
system. Used by web sites to store large amounts of data. (Oracle, 2012)
HTTP: Hypertext Transfer Protocol: The protocol used for transferring information
over the World Wide Web.
JSON: Javascript Object Notation. A programming language independent string that
encodes simple data structures. Mostly used in the HTTP protocol. (Crockford,
2012)
AJAX: Asynchronous Javascript. A technique used to make HTTP requests hidden
from the user. Usually called by Javascript, it allows for the dynamic updating of
page content.
2.2 The Android Platform
The Android platform is a Unix based operating system used on mobile
devices. It currently is installed mostly on mobile phones however there has been a
recent increase in the number of tablets running the Operating System as well.
Applications are developed in a platform based in Java. This SDK framework written
in Java allows for the rapid development of applications thanks to both Java itself
(Object-‐Oriented, Automatic Garbage Collection, and more time saving features) and
the tools provided with the SDK such as the Eclipse plug-‐in. This plug-‐in has a
variety of features that allows smooth development within the Eclipse platform
9
(which, based in Java itself means it’s platform independent) such as the visual GUI
editor.
For the purposes of this project some features of the Android API are
undocumented/unsupported, which created difficulties in the implementation of
some features. In particular the SMS database has numerous API’s for accessing
messages as they arrive on the device and sending them. Accessing the database
outside of these use-‐cases however is not officially supported. More information will
be given on this and the challenges encountered later in the report.
2.3 Android Cloud to Device Messaging Framework
The Android Cloud to Device Messaging Framework (C2DM) is an API
available to Android developers to send “push” notifications to registered devices. A
push notification is a method of sending relatively small amounts of data to a mobile
device. Due to the nature of mobile devices with their limited battery power and
possible data connectivity losses it is impossible for a developer to guarantee a
consistent connection from their application to any real-‐time service for long
periods of time. Google attempts to solve this issue by providing the C2DM service
to developers. Google maintains a consistent connection to each device with a
proprietary algorithm that keeps power and bandwidth consumption minimal. The
developer sends a small amount of data to the Google C2DM servers along with the
unique addresses of device’s registered to receive these messages. These unique
addresses are both device and application specific allowing one device to have
10
multiple applications all registered for their respective push notifications. The
C2DM servers then pass this data to intended recipients with no guarantee of
delivery or order of delivery. It is however rare to have a message lost although
there certainly can be delays in receiving a message. (Google Inc, 2012)
2.4 Ruby on Rails
Ruby on Rails or “RoR” (Hansson, 2003) is a combination of the Ruby
programming language (Matsumoto, 1995) with a framework called Rails laid
overtop. Rails is an all-‐purpose framework designed to make the development of
web applications smooth and streamlined. It separates the major components of an
application into the Model-‐View-‐Controller framework. Rails covers up all SQL
interactions into the Model which keeps low-‐level queries and object maintenance
out of the programmers mind. The Model defines an object to be used, which creates
a table in a database. Each row in the table then corresponds to an “instance” of that
object. Rails provides many helpful generators to automate the process of adding
new models, controllers or views. Many successful large-‐scale web applications use
Ruby on Rails at its core including an Ottawa native e-‐commerce solution, Shopify.
(Shopify Inc, 2006)
2.5 The Git Revision Control System
Git is an open-‐source revision control system. (Git, 2012) It can be used in
conjunction with a central hosting site such as github.com (Github Inc, 2012) to
allow the system to become distributed among many people. Git, like all revision
control systems, allows incremental development of software to take place in a
11
managed and monitored framework. A user will edit/create code to fix a bug,
complete a feature or create similar progress. The user is then able to commit the
changes to git. Git automatically finds the differences between the last commit and
this new commit and saves the changes as a point in the projects history. In this way
if mistakes are made or bugs are found and old code needs to be accessed only a few
commands are needed to go back to an older point in the project’s history. More
complicated endeavors such as branching are also possible as well as merging
branches. This style of development allows for collaboration more easily as
numerous programmers can all work on specific features in their own code
“branches” and then merge into a final production branch.
2.6 Server Hardware for Web Hosting
I share ownership of a custom built dedicated server located in a Montreal
datacentre. This is the server that will be used to host my web application. It is
running Ubuntu 11.10 (Canonical Ltd, 2012) and connected to the Internet at
100Mbit. It is using Apache (Apache Software Foundation, 2012) as its webserver
with the Phusion Passenger (Phusion, The Computer Science Company, 2012)
module to handle Ruby HTTP requests. It is using MySQL as its database. I use git as
my code deployment.
12
3.0 Approach
3.1 Initial Research
3.1.1 Android Cloud to Device Messaging Framework
First and foremost the capabilities of the C2DM framework needed to be
known along with its limitations. This system would be responsible for the sending
of messages from the web application to the mobile device itself.
An excellent source that helped immensely in regards to this framework was
a talk given and recorded live in San Francisco at “AnDevCon” in March of 2011. This
talk entitled Mastering C2DM: The Android Cloud to Device Messaging Framework is
available online for free. (Gargenta, 2011) This online resource provides the full 1
hour 17 minute video along with the presentation slides and source code demoed.
In combination with the official Google documentation (Google Inc, 2012) this was a
wealth of information to get started using the C2DM system.
The C2DM framework allows for messages of up to 1024 bytes in size. There
is a limitation on the number of messages someone could send in aggregate or per
device but this limit is not public. This is to prevent spam and overloading the C2DM
servers. In most typical use scenarios this limit won’t be reached according to
Google. If it is Google can be contacted to have a higher quota enabled. For the
purposes of this project no such upgrade is needed since only three users will be
testing the application at most (including myself). The web application will only be
13
sending messages with a few bytes as payload; combined with the limited user
count (for testing purposes) the web application will fall well within the C2DM
limitations.
3.1.2 Android Framework and SDK
Setting up a proper development environment was the first priority. Google’s
official SDK website provides all the necessary information along with step-‐by-‐step
troubleshooting should something go wrong. This wasn’t a complicated process and
more information can be found at the official site. (Google Inc, 2012)
A critical component of this project is accessing and manipulating the SMS
database on the phone. Luckily there were those before me who figured out how
this all worked and compiled a three part tutorial. (Jang, 2009) This guide gave
examples on how to send, receive, and access the internal SMS database. The pitfalls
however of the Android SMS database are numerous and eventually effected the
design of my application. A brief explanation of Android’s Broadcast Intents is in
order before I continue.
In order for certain processes or applications to communicate with each
other Android uses a process called “Broadcasts”. These broadcasts are exactly what
they sound like; a message sent to every process in the operating system that is
registered to “hear” these broadcasts. This can get more complicated but this
explanation will suffice. One such Broadcast that an application can hook into is an
14
“SMS Received” broadcast. This is sent when the phone receives a new text message.
The broadcast contains the message itself along with the message details including
time of arrival and phone number. This makes it incredibly easy to catch text
messages as they arrive and deal with them. There is no similar broadcast for
outgoing text messages. When a user sends a text message from the phone there is
no way to capture this event. Since my application was supposed to keep sync with
the phone’s text messages this caused a challenge in my design. The solution to
which will be discussed later on.
Finally the SMS database itself has no “official” documented support for
access. There are various undocumented ways to both read and write to the
database but since they are unsupported Google strongly discourages the use of this.
They warn that at any new version it’s possible this database might change without
warning and previous unsupported code used to access it will stop working. Not
only this, but the database itself is not standardized. Those who build their own
customized versions of Android for their phones (Motorola, Samsung etc.)
sometimes use a customized database. This means that an application that can read
the SMS database on one phone may not work on another; at least not without
customized code for that platform.
3.1.3 Ruby on Rails with C2DM
Being able to send information from my web application to the Android
C2DM servers is of vital importance. It is the main piece of infrastructure used to
15
allow the sending of text messages from the website. The official documentation
gives detailed information on how the request is to be performed from a personal
server. Ruby and its community however are known for their extensible modules
called “gems” which allow additional functionality to be easily used within a Ruby
project. A quick search revealed that someone had created an open-‐source gem
specifically for contacting the Google C2DM servers and sending data to them.
(Mousa, 2012) This gem provided a significant reduction in development time since
no original code had to be developed for this one well-‐defined task.
3.1.4 Front-‐end Development Choices
Since the web application itself is the main user-‐interface an easy to use, and
if possible, quick to develop site was needed. In recent years various frameworks
have been developed by both individuals and corporations to assist in the rapid
prototyping and design of websites. CSS (cascading style sheet) is the scripting
language used by websites to style their look. These frameworks that have come
about are attempts to standardized the most common attributes of website layout
into a CSS file that is both cross-‐browser and device compatible. A few options
including my final choice are below.
Blueprint is a very robust and open source framework that allows total
customization of a website given that you provide your own graphics. In this way it
is the absolute bare minimum of frameworks. It will organize your content into rows
and columns easily. It has very minimal inherent styling other than a good-‐looking
16
typography set. Any other choices such as header styles, shadows or rounded edges
have to be created manually. This would be an excellent choice of framework if a
project had a dedicated graphics team. (Blueprint, 2011)
Foundation by Zerb is an extremely advanced framework. It incorporates all
the basic features of Blueprint and then adds its own unique features, which bring it
up to par with current Web 2.0 standards. Web 2.0 is a buzzword used in the web
design industry to indicate a style of design. This usually involves things like
colourful buttons, simple intuitive layouts, flexible layouts based upon screen
resolution and in-‐page dynamic content to give the feeling of a real application.
These features are exactly in-‐line with the requirements of this project. In particular
it features automatic resizing based upon screen size. In this way the site will look
the same and function well on both mobile devices and desktops without the need
to have separate designs. It comes with a beautiful default look with everything
styled including headers, buttons and wells (content which is highlighted in what
visually looks to be a sort of pressed-‐in style). (Zurb, 2012)
Bootstrap by Twitter is another excellent and highly praised framework. It is
very similar to Foundation. Where Bootstrap excels is its visual design and
JavaScript plugins. Like Foundation, Bootstrap has a custom style and design that is
visually very appealing. It is colourful, has rounded edges on elements and generally
gives off a very good Web 2.0 feel. It is used in practice by the official Twitter
website and as such is a proven technology. Its JavaScript plugins are similarly
17
themed and integrate very well into a websites design. They give enhanced
functionality such as pop-‐ups and tabbed navigation. Its default style is also easily
customizable for those who wish to give their Bootstrap site a different look.
(Twitter, 2012)
In the end I chose Twitter’s Bootstrap framework for its visual appeal and
rigorous screen and browser support. Highly customizable style information also
allows for a unique design, which while unnecessary for this project, allows for
future visual development. It is the most commonly used framework for new web
applications and as such has a very good support community. Their tutorials are
also very intuitive with live visual examples.
18
3.2 Design Decisions & Implementation
3.2.1 Web Application Back-‐end (Rails)
The back-‐end of the website is the core of the entire application and as such
required much attention. Since it was being coded in Ruby on Rails (RoR) I could
apply the inherent structure of RoR, which is the Model-‐View-‐Controller (MVC)
architecture, to my design. MVC design is based upon separating the three
important components of an application: the models, the controllers, and the views.
The models represent the raw data. In this application a model could be the actual
text messages themselves and all their associated data such as telephone number
and time received/sent. The views are the graphical front-‐ends that the user
actually interacts with. In this case it would be the various web pages within the site.
The Controllers are the middlemen. They sit between the models and views and
determine how to access the data from the model and then give it to the view in a
meaningful way so that it may be displayed. They also handle the reverse: sending
data back from the view, perhaps an update to a message, and then handing it off to
the model after whatever modifications are needed. I will begin with a listing of the
models and their properties, followed by the controllers and end with the views. In
section 3.2.4 a diagram is shown which explains the interrelationships between the
models.
19
The Models
User: The user model contains all information relating to a user account on the web
application. The username itself, a password and links to other models which the
user “owns”. These links are to many Devices, many Messages and a single
Synchash. The user has to have a unique name and if they so chose can add a unique
e-‐mail address. Unique meaning no other User model in the database contains it.
Device: The device model contains two strings, one for the unique registration
identification within the C2DM system and another for the unique identifier of the
mobile device itself. Each phone has its own unique identifier built in. A device
model belongs to only one unique User model.
Message: The message model contains the following strings: “origin” representing
the phone number of the message’s origin, “message” containing the actual message
itself, “timestamp” which is a Unix measurement of time (the number of
milliseconds since January 1st, 1970), and the destination phone number of the
message. A message also belongs to only one User model.
Outmessage: The outmessage model represents a message created on the web
application that is waiting to be sent by the actual mobile device. It is completely
identical to the regular Message model.
20
Synchash: The synchash model is unique in that there is only one per user. It
contains two strings the “in_hash” and the “out_hash”. Both of these are md5-‐
encrypted strings based upon the latest sent and received text messages for a user
in the database.
The Controllers
ApplicationController: This controller contains functions pertinent to the entire
web application. All the logic related to logging in and displaying pages based upon
logged in status is here.
AuthController: This controller contains three functions, login, mobile_login and
logout. Login takes the parameters submitted by the Auth view and hands them over
to the ApplicationController to process the login information. Logout simply erases
all information in the browser relating to the user effectively logging them out.
Mobile_login handles login requests from the Android application.
DevicesController: This controller is responsible for the adding of new devices to
the database. The Android application will send its registration ID and unique
device ID along with the associated username to this controller. It then attempts to
save this to the database and returns a success/failure result. No views are
associated with this controller.
21
HomeController: This controller has one function, get_conversations, which
gathers all the text messages relating to a specific telephone number and user who
is currently logged in and packages them into a variable called “conversations”
which is available to the Home view.
MessagesController: This controller is responsible for creating new messages in
the database and retrieving them. The two main functions here are “show” and
“create”. “show” is responsible for any HTTP GET (See Appendix A for information
on HTTP verbs) request to /messages. It accepts two separate URLs:
/messages/########## is used by the web application to retrieve all messages
associated with the telephone number entered and /messages/#.json is used to
retrieve a single message by the Android application where # is the actual database
number of the associated message.
When an HTTP POST request is sent to /messages the “create” method is
invoked. The only time an HTTP POST request happens is during a sync event from
the Android client. A JSON encoded string is expected containing the number of new
messages along with the messages themselves. The JSON Object is parsed and the
new messages are created in the database. More detail on the structure of this JSON
object will come after the discussion on the “views”.
22
OutmessagesController: This controller has two main functions “show” and
“create”. “create” is invoked when an HTTP POST request is sent to /outmessages.
This happens as an AJAX request during use of the web application. The new
message is created and stored as an Outmessage object. The C2DM gem (Mousa,
2012) is then invoked to send a push notification to the associated device.
“show” is invoked when an HTTP GET request is made to
/outmessages/#.json with the # representing the outmessage ID requested; this
request only takes place from the Android application after a push notification has
been received containing the pending message ID to be sent. The pending message
is deleted from the Outmessages database and is recreated in the Messages database
indicating that the Android device has handled it successfully.
SearchController: This controller contains only one function “lookfor”. This
function is called when an HTTP POST request is sent to /search. This simply
packages a list of messages, which contain whatever keyword is being search for,
into a variable called “results”. This variable is then used by the Search view.
SynchashesController: This controller contains two functions, “create” and “put”. It
is only ever called from the Android application. “create” is invoked when an HTTP
POST request is made to /synchashes. It expects either one or two strings (in_hash
or out_hash), which contain the md5 hash of a text message and the username this
request is being made for. This hash is then compared with the hash stored in the
23
local database and if either one is different a flag is set to indicate this. A JSON
encoded response is then created which contains the flag(s) and hash(es) stored
locally. This is used by the Android application to determine how many messages to
sync.
“put” is invoked when an HTTP PUT request is made to /synchases. It expects
a username to associate with and either one or two strings (in_hash or out_hash). It
then performs an update to the local database with the sent hash(es).
UsersController: Used by the User view. It is involved in creating new user
accounts. It simply takes the HTTP POST request from the signup form and creates
the new user account. “create” is invoked for this purpose.
The Views
Views are separated logically in Rails via their associated Controllers. The “layout”
view is associated with the Application controller. This houses the layout that has
common attributes to all views (namely the navigation bar, stylesheet information
etc.) Therefore any other view is rendered “inside” of this view by the Rails
command <%= yield %>. The views listed below are invoked by this command.
Auth: This view houses the main login screen. It has a form which POSTs to /login.
Home: This view renders the main screen after logging in. It renders the sidebar
with the “conversations” variable that the Home controller has setup. It also sets up
24
an initial skeleton (invisible to the user at this point in time) framework for the text
messages to be placed into once a conversation from the sidebar has been selected.
Messages: This view renders a text message conversation with the variable
“messages” setup by the Messages controller. It is called by an AJAX request in the
Home view.
Search: This view renders the results of a query made to the Search controller. The
results are placed in a variable called “results” which are used by this view to
populate a table.
3.2.2 Web Application Back-‐end (JavaScript)
Apart from the MVC logic contained in section 3.2.1, the JavaScript written
along side it provides much of the interactivity needed for the application to work as
intended. It is mostly AJAX calls to dynamically update content on the page and
minor functions to change the GUI as certain dynamic updates are applied. jQuery
(The jQuery Foundation, 2012) was selected for its ease of use and built-‐in AJAX
functions. Only one JavaScript file is used, conversation.js, and it’s this file that
provides all the functionality for the Home view. It contains three functions that I
will briefly explain below.
25
switchConversation:
This function is called when a user clicks on a new telephone number in the
sidebar, which indicates that the user is attempting to view a different text
messaging conversation. The function gets passed a variable indicating the
telephone number they clicked on. It handles some minor GUI cosmetic changes
associated with this activity and performs an AJAX call to load the new messages
into the Home view.
refreshConversation:
This function is called on a timer set originally in switchConversation. This
timer is on an interval of five seconds. Once called an AJAX request is performed to
update the current conversation with any new text messages (sent or received) that
may have occurred in the timespan since the last call.
sendMessage:
This function is called when the user clicks the send button in the
conversation window. It gathers the message and performs an AJAX POST to
outmessages.
Finally the JSON object used to transfer text messages is defined as follows:
{ “total_in_messages” : #, “in_messages” : JSON Object #1, “total_out_messages” : #, “out_messages: JSON Object #2 }
26
JSON Object #1 and #2 are defined identically but contain either the incoming or
outgoing messages to be synced respectively. That definition is as follows:
{ “sms1” : { “message” : string, “number” : string, “timestamp” : string }, “sms2” : {….} }
The individual messages are labeled as “sms#” where # represents a unique
identifier. This in combination with “total_in(out)_messages” allows the web
application to know how to iterate through the JSON object and extract the text
messages.
3.2.3 Web Application Front-‐end
The front-‐end technical development was fairly rapid and smooth thanks to
the Bootstrap (Twitter, 2012) framework I decided upon. There’s not much to say
here on the technical side so I’ll dive into the actual conceptual design.
Any GUI should have two distinct parameters defining and driving its design:
intuitive functionality and visually pleasing simplicity. Most modern Web 2.0 web
applications embody this philosophy in one form or another. I wanted my
application to follow these principles. The following figure is what I came up with:
27
(Figure 1: “Abstract Layout”)
Figure 1 represents an abstract overview of the general top-‐level layout of
the application. This layout will take up the entire available display area in the web
browser. An explanation of the elements follows:
1) Navbar:
This will be present on every single page. It provides links back to the main
Home view and other important pages.
2) Sidebar:
This represents navigation for the current task. Anything to do with the
current task that involves switching between information will be located here. If the
current task requires no such navigation, the sidebar will not appear and instead the
space will be used fully by the main content.
28
3) Main Content:
This is where main content for the current task is displayed. If a sidebar is
present, any navigation selected in it will be reflected here.
This is a fairly generic layout used by many “full-‐screen” web applications
and is even found in applications that appear on tablets. I chose a fluid, full-‐screen
layout for maximum compatibility among devices. This webpage can be viewed on
mobile, tablet and higher resolution displays. Thanks to Bootstrap it will
automatically resize itself for maximum usage of the available display area. After
this general layout was decided upon, more application specific design decisions
had to be made. Figure 2 represents these changes.
(Figure 2: “Detailed Layout”)
29
The navigation bar now contains the Application title (which is also a link
back to the main Home view), a search field, and the name of the user currently
logged in. This will also be a drop-‐down menu to logout. The sidebar will contain a
listing of text messaging conversations that are selectable. Upon selecting a
conversation the main content area will fill with the specified text messages.
Finally I had to decide on how the actual text messages themselves would be
displayed (and how to fit in the sending of text messages). Figure 3 below shows a
final production screenshot of the application. Telephone numbers have been
blurred to protect privacy.
(Figure 3: “Final Production Layout”)
30
In keeping with the intuitively simple design principle, the text messages are
displayed with a colour coded system. Incoming text messages are red and left
justified. Sent text messages are green and right justified. The green is coordinated
with the “Send” button to remind users that green messages are their own. The left
vs. right justified allows the “flow” of the conversation to be seen. In the Western
world, reading is done from left to right; since the messages the user is most
interested in are those he/she has received I decided they should be left justified to
minimize eye travel across the main content area.
The text message sending area itself is also very simple and intuitive. A small
envelope icon identifies the text field immediately to the right of it as an area to
enter a message. The send button is a prominent green corresponding to the users
own messages in the history above it. This area is separated from the text messages
themselves by a small two pixel horizontal line. This allows the main text content
area above the line to scroll through messages while the text field below remains on
screen.
Finally it should be noted that some very minor cosmetic changes were
made to the base Bootstrap theme. These mostly involved lightening or darkening
some elements and changing text justification. Other than this it is essentially the
stock Bootstrap theme.
31
3.2.4 Web Application Model Diagram
(Figure 4: “Web App Model Relationships”)
Figure 4 above shows the relationships between the models. A line with an
arrow indicates a ‘has_many’ relationship and a straight line indicates a ‘has_one’
relationship. The User model owns an infinite amount of devices, messages and
outmessages. It only needs one synchash model however to keep track of the latest
incoming and outgoing message. Every attribute is a string and wherever there is a
star there is a uniqueness constraint. For example the username in the User model
must be a unique string not present elsewhere in the database.
32
3.2.5 Android Application Back-‐end
The Android application itself was probably the hardest part of the design
process. Due to my lack of knowledge with the Android framework and its abilities
and limitations I couldn’t actually plan out ahead of time how the application was to
function. I literally learned and coded on the fly. For this reason there is much to say
in the Future Work section about potential improvements.
Even with these limitations however a logical overview of the functions
needing to be performed could be created and grouped. The following components
were apart of my original design (which was mostly mental):
C2DM:
At some point the application was going to have to interface with Google’s
C2DM network. It would have to register itself for push notifications and then send
this registration ID to my own web server.
Login:
The application would have to take user input, namely a username and
password, and validate it against my web server. It would then have to store some
piece of identity information to send later when making other requests to my web
service.
33
Running as a Service:
The application itself would have to be running in the background or at least
watching for certain events. The application shouldn’t have to be “active” in the
foreground to be working. It should be seamless. A service of some sort would seem
best.
Syncing:
Syncing should happen at every new received and sent text message. It
should happen in the background or have a short duration message indicating a
successful sync. If the user should chose to open the application to the foreground
there should be a way to forcefully start the sync manually.
With these ideas in mind I began the creation process. I will give a brief
outline of each class below and the function it serves. A more detailed look at the
interrelationship between these classes can be found in 3.2.7. For detailed
knowledge of the functions themselves the original code can be viewed as it has
been commented.
Depending on the type of class needed from the Android framework to
perform a certain task, I categorized the java files into different packages.
34
emcewen.websms:
This package contains three classes, two of which are Activities and one is a
BroadcastReceiver. This package is unique in that it’s the only one where classes of
different types mix. This is because of an expectation present in the Android
framework. The BroadcastReceiver that is registered to receive events from the
C2DM network has to be located in the main package.
C2DMReceiver.java
This file contains all the logic pertaining to communication with Google’s
C2DM service. It’s a subclass of BroadcastReceiver and intercepts any global
broadcasts relating to the C2DM service (with relation to this application). It’s also
called when a push notification is received from the C2DM service.
ConfigActivity.java
This is an Activity (it appears as the ‘running app’ on screen) that is called
once a successful login has been accomplished. It is simply a black screen with one
button that allows manually syncing to be performed at anytime. On first launch it
also sets up the 15-‐minute timer that calls the syncing function.
WebSMSActivity.java
This is an Activity and the main entry point for the application. If the user has
not had a successful login attempt this activity is shown. It has two text fields for
username and password entry. There is also a submit button. Upon clicking submit
35
an instance of LoginTask.java is created which handles the asynchronous network
communication with my web application. If the user has successfully logged in the
activity closes automatically and starts up an instance of ConfigActivity.java.
emcewen.websms.receivers:
This package contains all the logic dealing with Broadcasts sent within the
Operating System that are pertinent to the application except for
C2DMReceiver.java as it must reside within the base package due to specifications.
All classes are sub-‐classes of BroadcastReceiver.
AlarmReceiver.java
This is called when the timer event is fired. This happens every 15 minutes. It
starts an instance of SyncTask.java which handles SMS syncing with the web service.
SMSReceiver.java
This is called when a new text message arrives on the device. The important
information about the message is extracted and sent to an instance of
SMSService.java which handles the syncing of newly arrived text messages to the
web service.
emcewen.websms.services:
This package contains only two classes both of which are sub-‐classes of
IntentService. These classes handle multiple scenarios related to whichever domain
36
they cover. This mostly involves some work that has to be done in the background
involving network communications.
C2DMRegistrationService.java
This is called on four separate conditions all of which have to do with the
C2DM framework. It can be called upon to actually register with the C2DM servers
and unregister with them. When either one of these events’ responses gets triggered
in C2DMReceiver.java it will call this service again to either register with my web
service (by sending the received registration ID) or unregistering with it.
SMSService.java
This is called in two different scenarios. When a push notification is received
by the device indicating that a new SMS message is ready to be retrieved, this
service is called and starts an instance of NewSMSSendTask.java which handles the
networking involved. If a new SMS has been received on the device itself the service
creates an instance of NewSMSTask.java which handles the networking involved in
syncing the new SMS to the web service.
emcewen.websms.tasks:
This package contains the most classes by far totaling six. Each class is a sub-‐
class of AsyncTask. AsyncTask contains functions for performing networking related
activities in the background. Most of these tasks are called directly from a Service
with a few being called from Activities.
37
LoginTask.java
This task is called from the WebSMSActivity class. It has references to this
class so that it may create status dialogs to show that there is network activity in
progress. It sends an HTTP POST to /mlogin and parses the JSON output it receives.
If there was a successful sync it sets a global preference indicating a successful login
and stores the username for later use.
NewSMSSendTask.java
This task sends an HTTP GET request to /outmessages/#.json where # is
replaced by the variable it receives upon instantiation. A JSON encoded text message
is parsed which contains the SMS message to be sent. An SMS send event is invoked
which both sends and stores the new SMS on the device.
NewSMSTask.java
This task send an HTTP POST request to /messages with a JSON encoded text
message. This is used when a new text message is received.
SyncTask.java
This task is the first step in syncing a number of text messages with the
server all at once. It first queries the server for its local stored hashes. It then builds
a list of text messages from the device UNTIL it hits the hash received by the server.
If no hash is received or it can’t be found on the phone, all text messages will be sent.
38
After the text message bundle has been created (in JSON) it starts SyncPostTask.java
to actually start the transmission.
SyncPostTask.java
This is the second step in syncing a number of text messages with the web
application. Upon its instantiation it has received a bundle of both incoming and
outgoing text messages that are to be sent to the web application for storage. After
the messages have been set, an instance of UpdateHashTask.java is created to
update the web application with the hashes of the newest messages sent.
3.2.6 Android Application Front-‐end
Much like the back-‐end design for the Android system, the front-‐end design
was also created on the fly as I learned how the GUI is created programmatically.
There is much to be improved here and I will go into this later in the Future Work
section. Considering most of the interaction with the application overall is done on
the web side, the current front-‐end design of the Android application is purely
functional. As such I will simply demonstrate what I have created for the few use-‐
cases of the application.
39
(Figure 5: “Android App Login Page”)
Figure 4 above shows the login screen. A text prompt along with two text
fields and a login button is all that is required to start the application on its way.
40
(Figure 6: “Login Incorrect”)
(Figure 7: “Checking Credentials”)
41
Figure 6 above shows what the application looks like as it is negotiating
login credentials with the web application. If everything is validated, Figure 7 below
is shown. If, however, the login information is deemed incorrect Figure 5 above is
shown. A quick prompt is created letting the user know the login information was
rejected and the username and password fields are emptied for a new attempt.
(Figure 8: “WebSMS Configuration Page”)
After successful login a “configuration” page is shown. I had ideas to add a
logout button and whatever other configuration details were needed; perhaps a
status section indicating number of texts transferred etc. I did not have time to
implement this so as it stands this page has a manual sync button. This is the view
that is shown should the user minimize the application and then attempt to return.
42
3.2.7 Android Application Software Diagrams
(Figure 9: “UML for SMS Processes”)
Figure 8 above shows the hierarchy and flow of the three separate events,
which lead to the syncing of new text messages to the web server. Dotted lines
represent an actual instantiation of the class being pointed to and a solid line means
a variable that is referencing the class it is pointing to. Section 3.2.5 explains what
each class does internally however for the sake of explaining the flow I will reiterate
some of the important concepts. There are only three situations in which SMS
messages need to be synced: 1) A new SMS has arrived, 2) A push notification has
43
been received indicating a new SMS has to be sent, 3) The 15 minute timer has
elapsed and it is time for a periodic sync.
In scenario 1) the SMSService starts a new instance of NewSMSTask with a
reference back to itself. This reference is required so that the task itself has a
“context” (See Android SDK in references for more details) and knows whom it is
doing this task on behalf of; this is a requirement of the Operating System. The task
has access to the new message, which was sent by the SMSService. Finally after a
successful sync the web server’s incoming hash needs to be updated with the new
message
In scenario 2) the SMSService starts a new instance of NewSMSSendTask.
This is identical to NewSMSTask except that instead of syncing a new SMS received,
it retrieves an SMS waiting to be sent from the web server, sends it, and then
updates the outgoing hash on the web application.
In scenario 3) the AlarmManager is called by internal system processes
indicating the 15 minutes have elapsed. This starts a new process called SyncTask
which unlike scenarios 1) and 2) does not need a reference back to AlarmManager
for context as the AlarmManager has a reference to a context which it can then pass
as a variable during instantiation. SyncTask handles the logic of retrieving the
hashes from the server and building a list of messages to be synced. It then passes
these onto an instance of SyncPostTask, which handles the actual transmission to
44
the web server. Finally, like all SMS syncing events, the hashes need to be updated
and UpdateHashTask is called.
(Figure 10: “SMSService Calls”)
Figure 10 above shows what actually starts the SMSService itself. This can
be thought of as the initial event, which eventually turns into Figure 9. When a push
notification is received in C2DMReceiver it instantiates the SMSService to handle it.
Likewise when a new SMS is received on the device, SMSReceiver is fired which then
passes on the message to SMSService.
45
3.3 Development Challenges
3.3.1 The Android SMS Database
Based upon initial research, I found (see section 3.1.2) that the SMS database
wouldn’t be as accessible as needed for the objectives of the application. In
particular the most pressing issue was the lack of standardized access to the SMS
database. There is no official way to access outgoing and stored text messages. Many
developers had found ways to access this database but this was widely frowned
upon by Google’s own development team. They warned that these improvised
methods to access the database could become obsolete or change drastically in any
API update. To further complicate matters the lack of standardized access meant
that device manufacturers such as Motorola, HTC, Samsung etc. could decide how
the would implement their own SMS database should they chose to. This would also
break the same improvised access methods although theoretically they would be
able to have their own improvised methods of access. This is not a good solution
however as an application developer may have to have many different solutions to
access text messages just so their application is compatible with a wide variety of
devices.
I decided that for the purposes of this project to only support reference
Android devices. Other non-‐reference designs can be added as support later. The
purpose of this project was to show that the core idea of sending text messages from
46
a web application was indeed possible. With reference Android devices supported
this would be enough to accomplish the task.
A secondary problem relating to the lack of official API’s for the SMS database
is related to outgoing text messages. When a text message arrives an event is sent to
notify any interested applications. With this event comes access to the message
itself and all its details. The same cannot be said for outgoing messages. This is a
problem for one of the key objectives of the application: automatic real-‐time syncing
of text messages. With this knowledge comes the realization that only incoming text
messages can be synced in real-‐time. A decision had to be made regarding the
outgoing messages.
Interval sync was used as a compromise. The application will automatically
sync incoming texts as expected and a timed event goes off every 15 minutes
syncing all un-‐sent texts since the last timed event fired. I chose 15 minutes for no
particular reason other than it seemed like a reasonable limit (4 syncs per hour). In
practice I have seen no downside to this. In case a user did want to sync, I have a
button on the Android application that performs an immediate sync.
3.3.2 Keeping Sync
One of the key features of the application is keeping the local web database
in sync with the users mobile SMS database. When the mobile application is
communicating with the web server there has to be an agreement of some sort on
47
what needs to be synced. This should happen quickly and efficiently considering the
constraints on mobile devices.
To accomplish this I decided to have the web server keep track of the last
incoming and outgoing message received. Before every sync happens, the Android
application queries the server for its stored hashes and then builds a list of
messages until it reaches that hash. In this way it knows when to stop collecting
messages from transmission to the web application. After a new sync has been
performed, the Android application creates a new MD5 hash from the text message
itself to identify it. This hash is then transmitted to update the database on the web
application. This works well in practice but has its own downfalls. These will be
discussed in both the Conclusion and Future Work section.
3.3.3 Dynamic Content Updates
An important feature of the web application is the ability to update the page
without a visible refresh taking place. This gives the web site a feeling of being a
responsive real-‐time application. In order to accomplish this AJAX calls were
implemented with jQuery and whatever result was returned was dynamically
inserted into the page. Upon first implementation everything appeared to be
working fine with regards to loading the content however the oldest text message
would show up first. I had to programmatically scroll the area holding the text
message to the bottom where the newest message resided. This appeared to fix the
issue but created another. If a user were reading an old text message as the AJAX
48
refresh was being performed it would automatically scroll to the newest message
again disrupting the user. A solution was needed that allowed a refresh to be
performed without disrupting a user who happened to be scrolling to view old
conversations while still allowing new messages to automatically appear and be
focused (i.e. auto scrolled to).
My solution was a compromise. I would programmatically remember the
value in pixels of the vertical scroll when it was at the bottom. If a user was less than
this, they must be scrolling and I would not automatically scroll to the bottom when
a new message arrived. If the user returned to the very bottom or greater than the
remembered bottom value (say when a new message has appeared) then it would
indeed auto scroll to the newest message upon arrival. This compromise seems to
balance both possible cases perfectly.
49
4.0 Results
4.1 Web Application
In general the web application performs its duties quite well. Messages are
usually very fast and responsive under the right circumstances. When these
circumstances are not met however a real-‐time conversation becomes less possible.
This is out of my control. Android’s C2DM service does not have a guaranteed
delivery time. This means, in some cases, when attempting to send a conversation
the push notification will take longer then a few seconds to reach the device
(upwards of five minutes sometimes!). This makes a real-‐time conversation
completely impossible. There may be workarounds to this, which will be discussed
in section 6.0.
50
4.1.1 Signing Up and Logging In
(Figure 11: “Signup Page”)
The signup page shown in Figure 11 is reached from the main login page
(Figure 12). Upon filling out the fields and clicking “Sign up” the user is brought
back to the main page to login.
51
(Figure 12: “Login Page”)
4.1.2 Conversations
(Figure 13: “After Login”)
52
After logging in the user is presented with the screen shown in Figure 13.
Telephone numbers have been blurred for privacy. This is the main page of the
application before a conversation has been selected. The left sidebar shows all the
text message conversation the user has synced to the web site. The sidebar is
scrollable if there are to many conversations to fit at once. Selecting one of these will
populate the main content area that is currently blank. See Figure 3 repeated below.
(Figure 3: “Final Production Layout”)
Sending a message works by typing in a message in the textfield and hitting
“Send”. The message will automatically insert into the conversation window with a
timestamp of “Waiting For Device To Send…”. This lets the user know a message has
yet to be sent by the Android device itself. Once this happens the timestamp is
53
changed to the time it was sent. Figure 14 and Figure 15 show this process from
the users point of view. Note the timestamp difference.
(Figure 14: “Waiting to send”)
(Figure 15: “Message Sent”)
4.1.3 Search
Searching is accomplished by typing in a keyword or phrase in the navigation
bar search field. Upon hitting enter a search is performed. Figure 16 shows the
results of a search performed with the keyword “hey”.
(Figure 16: “Search Results”)
54
After searching, a table listing all the messages found is displayed. If a user
wants to view that particular conversation, they can click on the green “View
Conversation” button. This will open up the entire text message history for that
telephone number as seen in Figure 17 below.
(Figure 17: “View a Single Conversation from Search”)
4.2 Android Application
The Android application appears to be performing all its duties quite well. I
had it running on both an Android Gingerbread (version 2.3.7) device and Jelly Bean
(version 4.2) device. Minor program crashes were reported that I have yet to track
down however in a timespan of two weeks only three crashes were reported
cumulatively between two test users. The configuration page definitely needs to be
improved upon to allow things such as logging out and statistics for data used and
55
text messages synced. The core functionality however, of syncing messages and
sending them (via the web application) works perfectly.
4.2.1 Signing In
(Figure 5: “Android App Login Page”)
Login is accomplished from the main screen. Upon entering the correct
information the configuration page is shown which has only a single button. This
button performs a manual sync on demand. To review the various scenarios the
Android application encounters please see section 3.2.6.
56
4.2.2 Syncing Events
(Figure 18: “Sync Message”)
Figure 18 above shows the small message that appears at the bottom of the
screen every time a text message is synced. This lets the user know the application
is working as intended since it is mostly a silent background process.
57
5.0 Conclusion
5.1 Self-‐assessment
Above the superficial goals of trying to create this web application I had a
personal goal, which was always my primary concern: to experience what a large-‐
scale (relative to my academic career) multi-‐platform project is like to develop. It
exceeded my expectations in this regard. I can now look back at the entire
development process and see where I excelled and where I fell short. This sort of
information is invaluable moving forward with my professional life.
The single most important thing I learned from this is to have a detailed plan
or roadmap beforehand. As much as is possible, a list of use-‐cases should be thought
out and organized. This allows for a more “high-‐level” overview of the entire project
and how various parts are to interact with each other. Of course in my case I was
also learning a lot on the fly, but in a situation such as that the model should
continually be updated; it should grow organically with the development itself. I did
this but only to a very limited degree. I had a rough idea in my mind of how I wanted
things to work and during the development process I sometimes wrote down little
notes to remind myself of where I was and what needed to be accomplished next.
When I didn’t do this I found myself wasting time trying reorient and decide on
what needed to be done next. A development plan would also integrate quite nicely
with revision control systems such as Git where code commits can be lined up with
the developmental milestones inherent to the plan itself.
58
5.2 Final Product
This project was never to become a “production ready” piece of software that
is ready to be released. It was more proof-‐of-‐concept along with a learning
experience goal as discussed above. If quantified, I’d say the project as is stands at a
closed-‐beta stage. All core features were implemented and work in most situations.
The concept of having a text message conversation from a web application has been
validated. As is inherent to a piece of beta software there is much work still to be
done if this were to be developed into something for public consumption. Section
6.0 will discuss this.
The ability to have a text message conversation from your computer with a
proper keyboard is incredibly satisfying. For the few beta users I had testing the
product, they informed me that it was a lot faster to respond to messages meaning
they could continue focusing their attention on their work. I have no doubt that as
smart phones evolve they will have far greater connectivity with the other devices
in their environment. Rogers Wireless already has their own service that allows you
to text from a computer (Rogers Communications, 2012) along with video calls.
Although specific to this network, it does show that consumers want the ability to
use their telephone from their computer.
59
6.0 Future Work
There are many improvements that can be made upon this project, frankly to
many to list. However there are a few key important features that should be
implemented above all else first.
6.1 Security and Encryption
Currently the web application does not store text messages with any kind of
encryption; they are stored as plain text. If this were to ever become a public piece
of software this would need to be address immediately. If the database were ever
comprised somehow all text message details would be completely visible. An
encryption method is needed that secures each text message to its owner, perhaps
based upon their password somehow. In this way if the database was compromised
and someone managed to gain access to an account, it would only be to that account.
I have very little experience in security and encryption so I can’t recommend much
other than saying it needs to be done. This goes as well for the Android application.
The login is merely a superficial function which checks that the user does actually
exist. After a successful login, the username is remembered internally and sent with
all transmissions to the web application. If someone were to reverse-‐engineer the
HTTP calls (not difficult at all) they would find a very easy and spoof-‐able API.
60
6.2 Web Application Usability
There are two major issues in terms of usability that concern the main web
application. Firstly, there is no way to start a new conversation. Unless a user has a
current conversation going on their phone that was transferred to the web
application there is no way to start a new conversation by typing in a telephone
number. This would be a fairly easy fix; a button of some sort that prompts the user
for a telephone number would suffice. Secondly, conversations are labeled only by
their telephone numbers. In an age where everyone relies on his or her phone to
remember what identity goes with what telephone number this is hardly ideal. An
impressive solution would be to have the user sign into their Google account on the
web application and have it match up the telephone numbers with their Google
contacts. This would allow for seamless contact management as well. Alternatively,
the Android application can be changed to access its internal phonebook and send
the relevant information to the web application.
6.3 Android GUI
The Android application currently has a barebones GUI; it really is only
functional for the purposes of this project and nothing else. It only supports the
resolution of the Samsung Galaxy Nexus (1280x720). This means on smaller devices
some elements will appear bigger or possibly shifted around. This can easily be
remedy by creating unique views for each of the different Android resolutions
common to popular devices. The Android SDK provides tools to accomplish this.
Aside from the above, a general colour scheme could be introduced to make it more
61
visually appealing. The configuration page as is contains only a single button for the
user to perform a manual sync. This should be changed to have a logout button and
perhaps some statistical information on data usage and text messages synced. An
indicator showing the current connectivity status to the web application might also
be useful.
6.4 A better Synchash
Currently the method of keeping track of the messages synced is by storing
the newest sent and received MD5 hash generated from the text messages
themselves. This has a potential flaw. If a user happens to delete these messages
from their phone and then a sync is performed old messages will be synced again
creating doubles in the database. This occurs because the Android application can’t
find the stored hashes and therefore has no idea where to stop when packing a list
to be synced. A potential solution would be to take the MD5 hash of every single
message and store it. This method would allow two-‐way syncs to also be performed.
A user could “download” all their messages from the web application onto a new
phone. Regardless of the solution the current implementation must be changed for a
production ready version of this application.
62
7.0 References
Zurb. (2012, June). Foundation: The Most Advanced Responsive Front-‐end Framework
from ZURB. Retrieved June 2012, from Foundation: http://foundation.zurb.com/
Apache Software Foundation. (2012). Welcome to the Apache Software Foundaion!
Retrieved August 2012, from The Apache Software Foundation:
http://www.apache.org/
Blueprint. (2011, May). Blueprint: A CSS Framework. Retrieved June 1, 2012, from
Blueprint: http://blueprintcss.org/
Canonical Ltd. (2012). Home | Ubuntu. Retrieved August 2012, from Ubuntu:
http://www.ubuntu.com/
Crockford, D. (2012). JSON. Retrieved August 2012, from JSON:
http://www.json.org/
Gargenta, A. (2011, March). AnDevCon: Android C2DM. Retrieved May 1, 2012, from
Marakana: http://mrkn.co/s/andevcon_android_c2dm,272/index.html
Git. (2012). Git. Retrieved May 2012, from Git: http://git-‐scm.com/
Github Inc. (2012). GitHub. Retrieved May 2012, from Github: https://github.com/
Google Inc. (2012, April). Android Cloud to Device Messaging Framework. Retrieved
May 1, 2012, from Google Developers:
https://developers.google.com/android/c2dm/
63
Google Inc. (2012, March). Installing the SDK | Android Developers. Retrieved May 1,
2012, from Google Developers:
http://developer.android.com/sdk/installing/index.html
Hansson, D. H. (2003). Ruby on Rails. Retrieved May 2012, from Rails:
http://rubyonrails.org/
Jang, Y. (2009, March). Frontpage/Tutorials/SMS Messaging -‐ Mobdev Wiki.
Retrieved May 20, 2012, from Mobdev Wiki:
http://mobdev.olin.edu/mobdevwiki/FrontPage/Tutorials/SMS%20Messaging
Matsumoto, Y. (1995). Ruby Proramming Language. Retrieved May 2012, from Ruby:
http://www.ruby-‐lang.org/en/
Mousa, A. (2012, June). amro/c2dm. Retrieved June 30, 2012, from Github:
https://github.com/amro/c2dm/
Oracle. (2012). Java. Retrieved August 2012, from What is Java?:
http://www.java.com/en/download/whatis_java.jsp
Oracle. (2012). MySQL :: The world's most popular open source database. Retrieved
April 2012, from MySQL: http://www.mysql.com/
Phusion, The Computer Science Company. (2012). Overview -‐ Phusion Passenger
(a.k.a. mod_rails / mod_rack). Retrieved August 2012, from Phusion Passenger:
http://www.modrails.com/
Shopify Inc. (2006). Ecommerce Software, Online Store Builder, Website Store Hosting
Solution. Retrieved August 2012, from Shopify: http://www.shopify.com/
Stack Exchange. (2012, April). Retrieved June 4, 2012, from Stack Overflow:
http://stackoverflow.com/
64
Rogers Communications. (2012). Wireless Rogers One Number -‐ Rogers. Retrieved
August 2012, from Rogers:
http://www.rogers.com/web/content/wireless_ron#,Tabset-‐-‐0
Twitter. (2012, June). Twitter Bootstrap. Retrieved June 2012, from Boostrap:
http://twitter.github.com/bootstrap/index.html
The Eclipse Foundation. (2012). Eclipse -‐ The Eclipse Foundation open source
community website. Retrieved April 2012, from Eclipse: http://www.eclipse.org/
The jQuery Foundation. (2012). jQuery: The Write Less, Do More, Javascript Library.
Retrieved August 2012, from jQuery: http://jquery.com/
65
Appendix A – HTTP Verbs
HTTP Verbs are used to describe the type of HTTP requests that can be made
from a browser. When you visit a website your browser sends a GET request. This
indicates to the server that is serving up the web page that you are requesting
material. When a POST verb is sent, the web server knows you are sending some
sort of data to it for storage. This happens most commonly when you submit a form.
There are a few others; PUT usually means your updating an already existing piece
of data and DELETE indicates the a request to delete a specific piece of information.
The most commonly used verbs by far are HTTP GET and HTTP POST.
