DESIGN AND IMPLEMENTATION OF A FILE SHARING APPLICATION FOR ANDROID
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 update
