Project: Shared directory for Android

1. Company:  Qualcomm  Supervisor:  Constantine Elster Project: Shared directory  for  Android By: Efrat Zentler & Talel Atias.

2. 1.      Goals • Make a shared folder for Android.

3. Goals cont’ • The folder should be synchronized between the Android devices to the server and vice-versa. • The synchronization should be without the user intervention. • The application should be economy from the user point of view(battery save and Wireless usage)

4. 2.Methodology • Eclipse was used in order to write the application and debug it. • Android SDK was used in order to simulate the application at first and afterward a real Android device. • An activity(View) was made in order to configure the application’s behavior and enable its sharing.

5. 2.Methodology cont’1 • “Preference-Manager” - The Activity should have a consistent state of configuration hence a persistence storageability should have been added. • “Alarm-Manager” - The application should need to run in some intervals. • “FTP-protocol” is done in order to communicate between the server.

6. 2.Methodology cont’2 • “Synchronization-Algorithm” – an algorithm was needed to be made in order to enable multi request to the server via many devices – the algorithm was made from the idea of “exponential-back-off” algorithm which is actually a DATA-LINK protocol from the network communication world – NOTE THAT THIS IS NOT A TRIVAIL ISSUE NOR SOMETHING THAT IS “KNOWN”.

7. 2.Methodology cont’3 • “Dead-lock-mechanisem” – in case of some error which can be cause during the operation(although very rare it may happen) a dead lock can occure when one of the devices did not free the lock. The lock is taken and some details are saved in order to know when a dead lock occure – such as time of lock(INCLUDING GMT+-), MAC, UserName,….

8. 2.Methodology cont’4 • “Logs” – due to the fact that this application will be running for a long time a need came to some log mechanism which will be consistent over time and over processes(unlike the DDMS-logcat) hence a log ability was added – two logs file are created – one is the MMS and the other is a verbose log file. Also there is a third log file which keep track of the file which were uploaded/downloded.

9. 2.Methodology cont’5 • “Logs” – due to the fact that this application will be running for a long time a need came to some log mechanism which will be consistent over time and over processes(unlike the DDMS-logcat) hence a log ability was added – two logs file are created – one is the MMS and the other is a verbose log file. Also there is a third log file which keep track of the file which were uploaded/downloded.

10. 2.Methodology cont’6 • “Exchange-Logic” – which is the logic which identify the files which should be downloaded/uploaded. • “Version-Control” – at first we thought to use simple timestamp or even “trust” the local device clock in order to know which files should be exchange. But due to the fact that the devices might not be set to the correct time or even in different time zone we had to make a version control for each version file – which is saved in the manifest file.

11. 2.Methodology cont’7 • “Manifest file and History file” – a kind of data base which was design to support the application purpose. • “User-Notification” – The server is notified when ever the folder has synchronized and with some status for the files that were uploaded/downloaded.

12. 3. Achievements • We have achieved a fully functional sharing application which can be directly used to share folders such as images, documents, music, movies and much more. • The application can be used as a sub-contructor for other applications and help in developing various type of applications whithout taking care of the “connectivity” part – for example one can create a new email application. And much much more…

13. 3. Achievements • A fully configurable application which can be set from a simple and intuitive UI. • An application which can be modified from many point of view. This is properly exist due to the design which took into consideration all those aspect – such as – Interface for the connection part that can be easily replaced by some other connection protocol without harming the integrity of the program! (and some more – compression, encryption, many many little replaceable methods which can change the application)

14. Conclusions • Research – it is very profitable to have a deep research on the issue that you intend to solve, you can learn new things and get new ideas from others experience. • Design – this is very important when building a big program, due to the fact that we made a very detailed design we were able to solve most of the problems even before they occur and fix them in a very low “price”. • QA – this is a very important part of every phase of building a big program – you can never know what might go wrong until you try it, the extensive QA process that we made for each part was profitable.(we build some side application which “talked” to the AVD)

15. Milestones • Install AndroidSDK.[week 1] • Make “Hello World” application. [week 2] • Make an application beyond hello world(use sockets, file transfer, operating system event and etc) [week 4] • Fully analyze the server which will be used.[week 6] • Install and set up a server(maybe find some free one? Technion’s maybe?) [week 7] • AndroidSDK and server communication.[week 8] • File transfer from AndroidSDK to server and vice-versa.[week 10] • End-to-End communication of AndroidSDK to another AndroidSDK. [week 11] • End-to-End communication of Multiple AndroidSDK.[week 13] • Fully seamless synchronization between multiple AndroidSDKs.[week 14] Total 14 weeks

16. Summary • This course gave us the opprotonity to make a large scale program and to learn a lot of new technologis. • Thanks.