WiPP – Wireless Peer-to-Peer Application for Android

1. WiPP – Wireless Peer-to-Peer Application for Android Jeswin Godwin, Manojprasadh, SaktheeshAjeethaSubramoniapillai, Subha Balaraman, Vijay Dhanraj.

2. AGENDA • MOTIVATION • PROJECT OVERVIEW • NOVELTY IN WORK • UI DESIGN • USE CASES • TEST CASES • CONCLUSION

3. Motivation Sharing Files Problem • Social interaction between peers located within the same wireless network • Should the files be hosted in web? Delays in the network? • Slow and cumbersome Bluetooth Solution – typically how you like it to be: • Share files with the people near you without even cables • WiPP allows multiple Android users connected to the same network to share files at very high speeds in a peer-to-peer fashion

4. Project Overview • “Group” – collection of peers within the same network • Build the “public directory” to drop the files to share • Metadata is stored in the “Index file” for the group is created which contains the Filename, Owner and Timestamp • Index file can be viewed by peers who join the group • To modify files, updation is performed in their own directories and timestamp is modified • Index file is brought to “sync” with other peers to enable downloading of the latest version

5. Novelty in Work LITERATURE SURVEY Frostwire, Limewire for android is a peer-to-peer file sharing service available in android market. WHY WiPP? • WiPP shares nothing by default, invokes user permission to share. Breach of privacy in Frostwire – shares virtually everything on the phone by default • Define rights to each user to prevent illegal intrusion • File updation identified with timestamp, allows users to download latest version after “sync” of index file • Faster approach than hosting files through web or transfer through Bluetooth

6. UI – Design Guidelines • User familiarity • The interface should be based on user-oriented concepts rather than computer concepts. • Consistency • The system should display an appropriate level of consistency. • Minimal surprise • If a command operates in a known way, the user should be able to predict the operation of comparable commands. • Recoverability • The system should provide some resilience to user errors and allow the user to recover from errors • User diversity • Interaction facilities for different types of user should be supported

7. UI – Interaction Style The concept of Interaction Styles refers to all the ways the user can communicate or otherwise interact with the computer system. The following types were used in our design. • Direct manipulation • Users feel in control of the system and are less likely to be intimidated by it. • Form fill-in • Menu System • Users make a selection from a list of possibilities presented to them by the system

8. UI – Layout Components • Button • Buttons are used as command execution units. • Text box • Textbox displays the text “Current Index file”. • Counter • The counter gets incremented for each new group created. • Table • Table lists the users in the group and the files shared. • Icon • Represents the icon of the application • Coloring • Colors indicate grouping of a similar type of component.

9. User Interface – Layout

10. UI - Functionalities • Button • NEW GRP • DEL GRP • BROWSE • SYNC INDX • START SHARE • Table • Users in the group, files and last modified time • Current Index Indicator • Unique value that is used to identify a group.

11. Architectural Overview

12. Use Case Diagram

13. UC 1-Group Creation • Owner creates a new group • Group Name • Group Password • Owner/User Name • Display Name • Email ID • A unique Secret Code(8digit) is generated during creation of a new group

14. UC 2- Join an Existing Group • New User can join a existing group after an invitation email which contains • Group Name • Secret Code(8 digit) and Privilege embedded in the email • New User Registers with • Group Name • User Name • Display Name • User Password • Email ID

15. UC 3-File Addition/Deletion • Registered User logs in into the group • Creates an Index File Table • User adds files from his home folder • Global and Local update of Index file

16. UC 4-View/Transfer the files • Registered User logs in into the group • Registered User can view Index File Table • Transfer/View the files present in the table

17. UC 5- Leaving the group • Registered User can leave a group (or) Group Owner can remove an User • User files in the Index Table are deleted • Global/Loca Update of Index file

18. UC 6- Owner Privileges • Creates a Group • Invites Users with Privileges • Owner Privilege • User Privilege(next slide) • Removes Users • Creates Index File Table • Adds Files to the Table • View/Transfer files present in the Table

19. UC 7- User Privileges • Join an existing Group • Creates Index File Table • Adds Files to the Table • View/Transfer files present in the Table

20. Test Case- Positive Case • Test script to test if registered user can the log the files present in the Index file. • Test script to test if the registered user can download the files present in the Index file. • Test script to test if the registered user can download/modify the files present in the Index file. • Test script to test if the other registered users in the group can download/modify the modified files present in the Index file.

21. Test Cases-Negative Cases • Test script to test the user of group A cannot access the index file of the group B nor the files of the group B. • Test script to test that any unregistered user cannot access the index file of any group nor the files of the any group. • Test script to test if a removed user can access the files in the group he was registered in.

22. CONCLUSION • Proposed a novel file sharing method for Android mobiles • Enables parallel downloads of the latest version • Global and Local updation of the Index file • Secure enough to prevent illegal intrusion