Design And Implementation Of A File Sharing Application For Android

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:

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.

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.

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.

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.

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.

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.

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.