Design And Implementation Of A File Sharing Application For Android

Computer Science Project Material with Source Code Included

Computer Science Project Material with Source Code Included


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


  • 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

    • (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


  • 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


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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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

  1. 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.
  2. 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.
  3. Chapter four focuses on system testing and implementation. This covers the results obtained from tests carried out on the software.
  4. Chapter five is the concluding chapter and is used to make possible suggestions and recommendation for further work on this project.

Chapter Five


5.0 Evaluation

This project has followed the development cycle of a cloud based Android application, from inception of idea through to implementation and testing. This chapter will discuss the merits and failures of the application. To do this, it will be compared against the list of requirements gathered during the design phase. Further, this chapter will look at any reasons for failures, suggesting improvements, and will examine extensions to the project which could be implemented. First, review the requirements to assess how well they were implemented:

5.1 Functional Requirements

  1. Must have a GUI
  2. Ability to find other handsets
  3. Replication of files
  4. Regular updates of content
  5. Replication to server
  6. Push updates
  7. Individual boxes
  8. Sharing boxes with friends
  9. User logins
  10. Context menus

5.2 Non-Functional Requirements

  1. Must be scalable
  2. Must be accessible by as many Android users as possible

As stated previously, the requirements have been listed in order of most practical and desirable to least. Due to this, later requirements supersede earlier ones in functionality. For example, in the final application, FR2 was not implemented, as it was no longer necessary due to FR5. That is, the client does not connect peer to peer to share files as there is a server application to carry out replication and sharing. Other than FR2, FR6 was not implemented in the final application. All other functional requirements were implemented successfully. The application offers a simple, user friendly touch screen graphical interface. It replicates stored files to the server application, for reliable access by all authorized users at any time. Content is regularly updated on the handset client, using a pull update scheme. Each user can create their own private boxes, and opt to share them with friends. User logins have been implemented to allow authorization and identity checking for security and sharing. Context menus have also been enabled to offer extended functionality, such as opening or deleting a file.

NFR1 has been covered, as the application has been developed in such a way as to be scalable. The client did not need any particular designs to be considered extensible, but the server application has been implemented on App Engine, a cloud based server system. This ensures that should any greater resources be needed while serving the application, the software can be elastically spread to more machines, to cope with increased demand on the fly.
Secondly, NFR2 should also be considered successfully achieved. This is due to the decision to build the application for the Android 1.5 system. This ensures that all commercial handsets available in the market currently can install and run the application, due to backward compatibility. Also, the application adheres to Android Market’s rules and regulations, and so would be a suitable candidate to be released via this portal to the public, enabling users easy access to the program.

5.3 Referring to the Use Case

As another form of assessment, it is important to look back at the use case and discuss whether the application could be used as envisioned. The first use of the application was when John checked the updated version of his group presentation notes. These have been satisfied as users may upload files to the server, and share them with friends.

The next use is uploading each member’s part of the report. John can access research shared by his friends, and can upload his section. His friends would receive the notification, albeit not as soon as it was uploaded, but after some delay while the application counted down to the next pull attempt.

John is able to download and edit his partner’s work, and re-upload it. The box shared with John’s friends from home is available, kept separate from that which he shares with university teammates. He can share files with these friends without risk of access by anyone else who does not have the rights to view them.

As most of the requirements were successfully implemented, and only one piece of functionality not covered fully, this project can be considered a success. All basic functions have been effectively executed, the result being an application offering the ability to upload, store, download and share data between android handsets.

There are many reasons for this successful outcome, one of which is the choice of technologies used. By implementing the server side application on App Engine and using protocol buffers for data transfer, the project was greatly simplified. This was due to the fact that both technologies, along with Android, offered Java based development options, which enabled much more effective interoperability between them.

Eclipse also offered much more efficient development, due to the integration with Android and App Engine toolkits and plug-ins. These extras recommended invaluable technical insights when developing the application, ranging from suggested libraries and objects in code to visual previews of the designed GUI.

The development methodology used definitely contributed toward the timely production of the software. By using an agile, component based approach, implementation time was used much more effectively, and so the requirements were covered as demanded. Following a cycle of implementation and testing of each component, less time was wasted on tying the application together at the end of the development period.

One issue with the application is the lack of push updates. While this is not a greatly functional issue for the application itself, as pull updates offer some form of notification, the context should also be considered. The application will be run on a battery powered device, and so pull updates are likely to drain the battery much more quickly than push. As stated in the implementation chapter, push updates were not considered feasible with the chosen server, due to the lack of access to sockets. However, other cloud based server systems offer socket connections, and so to remedy the situation it would be suggested moving the server application to one of these services, such as EC2.

However, a benefit of not implementing push updates is that the system is not in violation of the RESTful architecture. As such, it is possible for an-other client application to be developed that can access the server, expanding the possible platforms on which user’s could share content.

Overall, as so many of the requirements have been met and the application provides a useful service previously unavailable to Android users, this project can and should be deemed worthwhile and successful.

5.4 Recommendations

There are several expansions to the application which, while unnecessary under the requirements outlined previously, would offer greater functionality to the user and more depth in the application. Some of these are changes to existing code to increase functionality, whilst others are simply adding new components.

First, implementing a file splitting algorithm when uploading and downloading files. Currently, the application takes a whole file and sends it to the server for storage. This only allows for small files to be sent and stored.

By splitting larger files, these could also be stored, allowing the potential for large images and video to be stored and shared. Another extension would be to implement a quota on users. Currently there is no limit, and so users may upload as much as they want. Obviously, this is unsustainable due to the cost of storing data on the server. Further to this extension is another, developing levels of users. By offering a pay-for service with more storage space, users may opt to buy more or use a smaller amount for free.

Virus scanning of files being uploaded would be a useful extension to add. As so many files belonging to many users would be uploaded, scanning them would provide security to all users, as well as the application, by preventing viruses from being shared or stored on the server.

A final idea could be to offer searching and filtering of files. As users begin to own and gain access to several boxes, it is quite feasible they may lose track of where a given file is, or wish to see a list of all files of a given file type that they have access to. By offering some form of searching and filtering, they would be able to access this information.
Of course these are only a few ideas of extensions, there are many more ways to broaden the application and offer more functionality, depending on what is deemed desirable.

In conclusion, this project has been an enjoyable and challenging endeavour. It has given me the chance to work in so many roles throughout the lifecycle of this piece software, and I have learnt so much because of it. It has been especially informative to work with relatively new technologies, such as Android and App Engine, as development with these is very different to well established, well documented systems. Finally, I am very proud of the application produced and hope to see it expanded on in the future.

Project Material Download

5,000 5000

The Complete Material Will Be Sent to You in Just 2 Steps

Quick & Simple…

Step One Purchase

Make Payment (Through Transfer) of ₦5,000 to Any of the Account Below

Access Bank PlcAcc No: 0811003731
Samphina Academy
Current Account
Zenith BankAcc No: 1225513212
Samphina Academy
Current Account
PalmPay Main LogoAcc No: 8143831497
Samphina Academy
Digital Account

Or CLICK HERE To Pay With Debit Card

CLICK HERE To Purchase Material ($15)
Make Payment of 120 GHS to 0553978005 | Douglas Cloud Osabutey | MTN MoMo

Step Two Purchase

Send the Following Details on WhatsApp ( 08143831497) After Payment

  1. Payment Details

  2. TOPIC: Design And Implementation Of A File Sharing Application For Android

The Complete Material Will Be Sent To You On WhatsApp After Receiving Your Details
T & C Apply

  Contact Our Help Desk

Need a Different Topic? Perform a Quick Search

List of Related Works

Click on Any Topic to Preview the Content

Samphina Academy

Samphina Academy is an Online Educational Resource Center that is aimed at providing students with quality information and materials to aid them in succeeding in their academic pursuit.