ABSTRACT
Over the
last few years, there has been a drastic change in information technology. This includes the various ways in which files
can be shared and stored.
Cloud
computing is publicized as the next major step for all forms of typical
information technology use. From
businesses, to non-profit organisations, to single users, there seems to be
various applications which can use cloud computing to offer better, faster, and
smarter computing. Android Operating System is a relatively new mobile Operating
System which has been steadily taking over more and more market stake. Easy to
use, easy to develop for, and open-source, it has picked up a following of
developers who want to create content for the masses. This project aims to
combine the two, building a cloud based application for Android, offering users
the power of cloud computing in the palm of their hand for file sharing and
collaboration.
TABLE OF
CONTENTS
CHAPTER ONE
INTRODUCTION
1.1 Background
1.2 Aim of the Project
1.3 Application of the Project
1.4 Requirements of the Application
1.5 Report Structure
CHAPTER TWO
LITERATURE
REVIEW
2.0 INTRODUCTION
(i) Removable media
(ii) Centralized servers on computer networks
(iii) World wide web based hyperlinked
documents
(iv) Distributed peer to peer networking
2.1 Android
2.2 Cloud Computing
2.3 Java Programming Language
2.4 A Brief Overview Of Similar Applications
2.4.1 Dropbox Overview
2.4.2 Google
Drive Overview
2.4.3 Icloud Overview
2.4.4 Skydrive
Overview
2.4.5 Sugarsync
Overview
CHAPTER THREE
DESIGN
AND DEVELOPMENT APPROACH
3.0 Introduction
3.1 Design Requirements
3.1.1 Functional Requirements
3.1.2 Non Functional Requirements
3.2 System Architecture
3.3 The Restful Architecture
3.4 Development Approach
3.5 Android Sdk
3.6 Server Side Technologies
3.7 Data Structures For Data Transmission
3.8 Summary
CHAPTER
FOUR
IMPLEMENTATION AND TESTING
4.1 Introduction
4.2 Development Methodology
4.3 Eclipse
4.4 Android Virtual Machine
4.5 Server Side Application
4.6 Client Side Application
4.7 Protocol Buffers
4.8.0 Introduction To Testing
4.8.1 Server Side Testing
4.8.2 Client Side Testing
4.8.3 Real World Testing
4.8.4 Challenges
4.9 Summary
CHAPTER FIVE
CONCLUSION
5.0 Evaluation
5.1 Functional Requirements
5.2 Non-Functional Requirements
5.3 Referring to the Use Case
5.4 Recommendations
Reference
Appendix
LIST OF FIGURES
Fig
1.0 the Diagram for the Client Side
Application
Fig 2.0
the Design Diagram of the Server Side Application
Fig
3.0 A UML Diagram of the Server Side
Architecture
Fig 4.0
A Sequence Diagram showing interactions between the Client and the
Server
Fig 4.1 The
Eclipse plugin toolbars for Android and App Engine
Fig 4.2 The Android Virtual Machine
Fig 4.3 Application Login Screen
The file browser
view of the application
Fig 4.4 The file
browser context menu
Fig 4.5 The view of the
list of boxes the user can access
Fig 4.6 the context menu
for a box
Fig 4.7 The upload file activity
CHAPTER
ONE
INTRODUCTION
1.1
BACKGROUND
Today,
paperless (and even virtual) offices are taking file sharing even further.
Internet users are communicating through sharing entire folders of information
online, and trusting these online platforms as their primary means of document
storage.
During the Internet’s infancy,
before it was named the “Internet” it was referred to as ARPANET and file
sharing was a practice reserved only for the most tech understanding of
computer users. File sharing was also really considered more file transferring,
as it usually consisted of manually transferring files with a technological
medium like a floppy disc.
In 1962, a conference was held
in Ann Arbor, Michigan to bring ARPA researchers together and begin to create
the structure for the ARPANET. In 1972, email was born, allowing
computer users for the first time to send files to one another via the
Internet. It wasn’t until 1978, when smaller personal computers were
introduced and software to connect to the Internet was created, that the
Internet was made available to the general public. [1]
Though it wasn’t around long,
Napster was one of the first major file sharing services that
was not only available to the public, but easy for everyday (non-tech-savvy)
people to understand and use. Napster was a file sharing application that used
a central server to organize file swapping between users.
The
Napster platform was different from file sharing via email in that it served
more as a gathering place for people to share music files with people/sources
from around the world. Though Napster no longer exists, it had a huge impact on
not only the way in which people share files, but it also had an effect on how
the public views file sharing as a practice. [2]
In
2002, the concept of “the Cloud” was introduced. However, it wasn’t until 2007
when Google Docs was launched that remote file sharing and file storage started
to gain some momentum amongst Internet users. 2007 also saw the beginning of mobile file sharing capabilities
with new and popular mobile technologies like the iPhone, and other mobile
devices.
Today's
mobile workforce needs the ability to securely create, view, edit and access
enterprise content from their mobile devices.
1.2 AIM
OF THE PROJECT
The
aim of this project is to design and implement a file sharing application for
Android based devices. This project will allow multiple users to share files to
multiple devices. This project would provide a stable platform to enable
collaboration through file sharing. To this end, files may be uploaded by one
user and available to another, all simplified through an easy to use
application on an Android device.
1.3 APPLICATION
OF THE PROJECT
This
project can be applied in several places or for several reasons. For a better understanding of its
application, let’s take a look at the illustration below:
John
is a lecturer at Lagos-state University. He wakes up late for a presentation he
is giving in the department of Computer Science with his fellow lecturers. He
rushes in to the department, where his group is just about to go up to make a
presentation. He doesn’t have any of his notes with him.
His
team has updated their proposed ideas that morning, and so uploaded the notes
into their shared box on their Android devices. John can open up his box and
bring up the file on his device, so he has a set of hints to follow through for
the presentation. It goes well, and their Head of Department was satisfied.
Now
that the presentation is done, John and his group members need to work on the
rest of their report, they still have a report and poster to complete and
submit. A member of the group is an artist, and says he will design the poster
if the others give him the information to go with it. As for the report, they each pick a
particular topic to cover, and a partner whose work they will check and
edit.
John
continues his research into “the effect of corruption on the Nigerian economy”.
He has all the notes the rest of his team have already found, available in the
shared project box on his Android device. He takes the files and adds his own
research to them, then re-uploads them to the box. His friends all receive a
notification that new files have been added, and they can check them straight
away. The artist takes the research and comes up with a poster.
The
report is the next piece of work to tackle, but it is coming up to the weekend
and so they won't see each other. They agree to work on their topics, and
upload their parts by weekend. Also, if they find anything they feel would be
relevant to any of the others they should upload that too.
John
spends the first few days of the week writing up his part of the report,
checking back to the project shared box folder on his Android device whenever
he gets an update notice from the application. He finds some of the information
his friends upload useful to his section, and updates it as required. He also
uploads a few files he found while researching. By Sunday he is done, and he
uploads his first draft of the section. He then downloads his partner's file
and goes through it, checking the facts he reads and checks if there is
anything she missed. He uploads his edited version so she can see the
differences, and checks his own against the changes she made to his draft.
John‘s
friends from his school days also have a shared box folder between them. They
are part of a music group and have just recorded a new music video. They want
John's opinion on it, so they drop the video file into their shared box folder.
He checks it as soon as it is uploaded, and lets them know he thinks it looks
great.
While
going through some journals in the university library, John found a bit more
information to add to his project, so he copies them over to his team box, so
everyone can access them.
1.4 REQUIREMENTS
OF THE APPLICATION
This deals with what is required of the
application. From the illustration
above, we can find several requirements of this application. Some of which include:
i.
First and foremost is the aim of the
application. It is a data sharing tool. It should share information between the
relevant parties through some form of replication, to avoid loss of the
original. Any updates or changes should fire a notification to other users, so
they are informed immediately.
ii.
As it will also be used by non-technical
users, it should be extremely user friendly. Therefore it should have some form
of graphical user interface, with quick and simple user interactions. To this
end it should follow the Android developer’s application User Interface
guidelines, which will ensure it fits in with the user’s previous experience
with the Android platform.
iii.
With multiple users, and interactions
between users, it is likely some form of unique identification will be
required. This would be to provide security and privacy to users' files, such
that only the owner can share, edit and delete a file, while others should not
see it unless the owner permits them. Users who have been given access to a
file would be able to download and edit a copy, and would have to upload the
edited file under a new name. This would provide a form of versioning, so users
could revert to older copies should they wish.
iv.
From the illustration, we saw the
application being used to send files between users a great distance apart and
also sending from one to many. To reduce data charges on a user's account, and
increase the ability of recipients to gain access to the data, it would be
beneficial to replicate the data first to a server. Recipients would receive
notification of the update and see a flag in their box but would not download
the file until requested, again to reduce data usage charges.
v.
The ability to have more than one box
would be beneficial to users, as it would provide clear separation between
files for one set of contacts and those for another. As this data would end up
replicated on a server, it is likely to have some form of limit or quota be set
on the number and size of files allowed to be stored at any one time, with a
possible extension of said quota with some type of fee or subscription.
vi.
There are a few restrictions that should
be considered. Firstly is the problem of copyright infringement. As data would
be stored on servers owned by Google and assigned to the developer, is there
any way to confirm the data being shared is legally owned by the users sharing
it? As a precaution, there should be some form of disclaimer notice the user
should have to acknowledge when installing the application, to confirm all
files they upload belong to them.
vii.
As stated, some form of quota or limit may
be required as we are using a service with limited free resources. As Google
App Engine is a cloud server, extra resources are added as and when necessary
and servers with unused resources are scaled down. However, access to extra
resources is only granted for a fee, and so this cost would have to be factored
into the distribution of the application, and costs may have to be passed onto
users. This would most likely be done at an extra fee for those wanting to
opt-in, enabling them to share more data than the average user.
1.5 REPORT
STRUCTURE
Chapter
two of this project report covers the literature review of the project. The
focus will be on several other applications that are similar to this. It will also include an introduction to java
language and other tools used for the application.
Chapter
three will focus on the system design. It covers the design of the software
package which is the system description, the key specification, UML diagrams
etc.
Chapter
four focuses on system testing and implementation. This covers the results
obtained from tests carried out on the software.
Chapter
five is the concluding chapter and is used to make possible suggestions and
recommendation for further work on this project.
Click “DOWNLOAD NOW” below to get the complete Projects
FOR QUICK HELP CHAT WITH US NOW!
+(234) 0814 780 1594
Login To Comment