High-Level Design

Challenge Your Friends

High Level Design

COP4331 Processes in Object-Oriented Programming | Fall 2014 | Group 12 - Project 17

Modification history:

Version	Date	Who	Comment
v0.0	10/23/14	Alan Birmaher	Template
v0.1	10/23/14	Christopher Kovaleski / Oscar Hedblad	Upload of the Design Issues
v1.0	10/23/14	Alan Birmaher	Added High Level Architecture, updated Design Issues. Finalized.
v2.0	11/16/2014	Alan Birmaher	Overall update and clean up to the page

Team Name: The Spungos' Turbo Wallhacks

Team Members:

Alex Berliner; alexberliner@knights.ucf.edu
Christopher Kovaleski; ckovaleski@knights.ucf.edu
Oscar Hedblad; oscarhedblad@gmail.com
Luis Duque; luisduque23@gmail.com
Alan Birmaher; abirmaher@knights.ucf.edu
Jimmie Potts; jimmie.potts@knights.ucf.edu

Contents of this Document

High-Level Architecture

Design Issues

High-level Architecture:

All user driven functionality is handled via the Android device’s touchscreen capability. The user picks from different options within the android application to control the actions of that application. From the main menu, the user is able to perform actions that either manipulate the application’s internal databases or pull data from Twitter. If the user attempts to access their challenges then the Local Challenge List Database will be accessed, which stores all challenges that the user is aware of. If the user attempts to perform actions that are friend related such as simply viewing their list of friends then the Local Friends List Database will be accessed. Finally, actions that require outside data such as pulling new challenges from the internet use the Twitter Handler API which interfaces with Twitter directly.

Design Issues:

Reusability

Essential to this project is accessing the Twitter API. Using public code and libraries such as Twitter4J already written can streamline the process of getting the main functionality of the application working. Also, reusing and repurposing code for similar jobs such as sending a tweet when creating a challenge and sending a tweet when completing a challenge.

Maintainability

Upon completion of the project, the application should be maintained without too much effort or difficulty. Any fixes or updates required can be completed most efficiently with the proper commenting of code and well written documentation. Unless there are major changes to the OS or Twitter API, maintaining the application past the release should be attainable.

Testability

To ensure the application is working properly in the final build, we will test functionality of all features throughout the development. Most testing will be performed on the Twitter API functionality (logging in, posting tweets, etc.). Testing functionality outside of Twitter interaction will revolve around locally keeping track of completed challenges and the friends list on the Android device.

Performance

The application relies on the performance of Twitter for logging in and posting tweets. If Twitter has any performance issues, the Challenge Your Friends application will also perform poorly.

Portability

The main goal is to have the Challenge Your Friends application accessible and running on the mobile Android platform. Porting the application to further devices and operating systems is a secondary goal that will be attempted time permitted.

Safety

The Challenge Your Friends application will not be storing any passwords or sensitive information in the application itself. Users will log into Twitter to submit challenges to their friends. Inherently, the idea of creating “challenges” for your friends to complete can prompt some users to create challenges that are high in risk. We will have a warning viewable to all users advising them against creating such challenges.

Issue Relevance:

Testing-related issues will be evaluated while in the testing-stages of the process of development. We are making sure that no interfaces require excessive time consuming data generation in order to complete the testing.
Safety issues are next to minimal. The only safety concerns that we could think of are physical, such as people uploading dangerous challenges. However, we expect all users to follow common sense protocols while using the Android application.
Portability to other devices. A goal is to get our application to run on iOS, BlackBerry, and Windows.
Issues related to maintainability will mostly come from possible changes in API implementation and database structure.

Prototyping:

Prototype on various services we could potentially use
Prototype evaluating multiple design layouts
Prototype evaluating different database solutions
Prototype evaluating different cloud server possibilites

Technical Difficulties Expected

Getting the API to work properly might take more effort than planned. Framework may prove to be an insufficient fit for some specific scenarios due to deficiencies within the features, or even unnecessary features.
Libraries and frameworks might need to be switched out in order to maximize compatibility and efficiency. All members of the group do not share the same technical skills, and further learning is required from all of us in order to successfully complete the application.
Having the users upload videos directly to YouTube brings in YouTube-related risks, such as something being wrong with their server, etc.

Solutions to Technical Difficulties:

Choosing the framework correctly will maximize the compatibility and minimizes unnecessary features. The application should also be stable when in between updates.
All members of our development group will be expected to learn any new necessary skills in order to complete the project

Design Trade-Offs:

As Java is a very high level interpretive language and comes with performance implications. We selected Java as the language of choice as Android already supports it, which eases the process of development. With Java, as many other languages, comes technical risks, which can include improper coding syntax as well as code security. Coding the application improperly could potentially lead to the application crashing the Android device.
We chose not to have any media databases connected to our application. Instead, we’ll be allowing the users to directly send the video to their friends via YouTube. The user takes a photo or records a video, the application lets the user then upload the clip to YouTube. Upon being uploaded, the application sends a link addressed to the YouTube clip, to the receiving user.
We have also decided to make the application fairly obvious to use. We will have a starting menu-screen where the user will be starting when running the application. On this main-page there will be a few options, like connecting to Twitter. Synchronizing with the Twitter social media lets the application access the users friend-list, which allows the user to select between various friends. Once a friend is selected the user can record a video or take a photo which then can be sent to a (or multiple) friend(s).

Template created by G. Walton (GWalton@mail.ucf.edu) on October 8, 1999 and last modified on Aug 15, 2000

This page last modified by Alan Birmaher; (aBirmaher@knights.ucf.edu) on 09/18/14.