Theodore Richards

Theodore Richards Alex Pacamarra Gary Formisano Xiao Xiao Design VI HW#7 Due: 4/13/12

Moodle Android Application

Our project can be broken up into several ‘black boxes’ of functionality. First, is the graphical user interface that will be employed and coded in native android. This is the part of our application that will be seen by the users and must be as intuitive and simple as possible. The second component to this application will be retrieving the information from the moodle servers and placing it within our GUI shell. This is one of the core components of our application because it will be providing the information to our users. Another component that can be combined with pulling information from the servers is the component of our application that will be responsible for securing a connection to moodle. A last component of this application will be the blog / Facebook component which will be able to provide a social engineering aspect to the application and will give our application an edge over our competitors.

Team Member Responsibilities

In this report information was contributed by each team member. Gary Formisano researched how to set up a server environment with a moodle compatible database and how to set up moodle on the server environment. Setting up moodle for a server environment was further broken down into the different configuration styles of moodle and what configuration is currently used at Stevens. Alex Pacamarra contributed information regarding to how networking would be used within the application. This includes what methods are there to setup networking and what would be the best for this type of application. In addition to this server/networking communication was also discussed. Alex also contributed information about the android market and the steps that are necessary to post an application. Theodore Richards contributed information concerning the realistic constraints that would be experienced by this project. Also, Theodore Richards also was responsible for the compilation of this report. Xiao Xiao was responsible for GUI development information. Xiao also created the block diagram that describes the basic GUI function implementation of the system.

Moodle Application Design Constraints

a. Economic Our project is constrained economically because it needs to be tailored to the current economy. First, it needs to be affordable so that many people will purchase it. Our project should also be a software utility application, which it is, because that would fit the demand in the market. Other than this our project does not face many economic constraints since it is a software venture. There are no raw materials or development costs. The members of the team are not working for an hourly fee so labor costs do not need to be taken into account. b. Environmental Our project does not face any environmental constraints as it is purely software. There is nothing within our project that would have adverse effects on the environment. c. Health and Safety The closest constraint that is applicable to our application is possible flashing lights that may have the possibility to induce seizures in users who have epilepsy. Our project is not designed to have any flashing lights so this should not be a problem.

d. Manufacturability Our project does not face any manufacturability constraints. This is because there is no physical structure for our project. All of the materials are virtual and copies will be made when it is distributed so there will be no manufacturability constraints.

e. Sustainability Sustainability will be a major constraint for this project. This is the ability for something to be easily maintained at some rate. In order for our project to be easily maintained it must be coded simply and clearly. In addition to this it must be heavily commented in order for anyone who is performing upkeep to easily understand it. Also, in order to allow it to be easily maintained our project should not be making use of an archaic coding model. Our project will be coded in Android and eventually Ios. These programming languages will not be deprecated anytime so this should not be a problem.

Professional and Ethical Responsibilities

Data Privacy: The first and foremost professional and ethical responsibility of our application will be to protect user data and ensure that none of their data is stolen. An aggressive data privacy policy will add credibility to our project which will entice more users to purchase it. Data stored by our application will be limited to username and passwords for the user. Reliability: Reliability is also a key professional responsibility that must be upheld by our application. It must be able to give users access to moodle all of the time except in circumstances when the network is almost nonexistent. Users will want to be able to access their moodle account on their own accord. If they can’t access it when they want or need to then there is not point to this application. This will also be a turn-off to potential customers who will not want to purchase our application. Intuitive UI: Our application is providing a service to the user and therefore must be intuitive and easy to use. This is a professional responsibility because users are the focus of our application. An application that is being designed to help users accomplish work must be able to accommodate the user Functionality: Functionality is also a major professional responsibility. We must be able to provide a wide variety of functions to the users in order to help them accomplish their work. These functions must be easy to use and help more than hinder the user.

Multidisciplinary Teamwork Planning

Our project contains system components that can be worked on my Computer Science majors. The system is limited to us working with CS majors because the entire system is composed of software components. The roles of any CS major could span from planning and developing the GUI to writing the scripts that will control the data retrieval from the Moodle Server. As well as CS majors Cyber Security majors could also be brought in on the project. They would be responsible for designing and implementing security scripts that would prevent any application data from being hacked.

SWOT Analysis

Strengths The idea of creating an application that is school specific brings the capabilities of a school’s online database to users who are on the move. Implementing Facebook functions with Moodle will create an environment that is both professional and social, encouraging social interaction amongst people within the same classes. This idea is unique to our design project and provides us with a feature that is new and innovative.

Weaknesses A major weakness in our idea for a Moodle application with Facebook features is consistently updating the application, fixing any bugs experienced by users. Since Moodle and Facebook are used by many college students, and applications that do not have significant patch updates for major bugs in programming are not supported by the tech-savvy community, it is of utmost importance to constantly be aware of any issues and address them quickly and accordingly.

Opportunities There are numerous opportunities that could come from a successful production of this application. The market for our application will always be changing and increasing due to the increasing number of students at colleges and universities. The popularity of Moodle may also increase, leading to Moodle to be used by other school. This would open up the opportunities in various colleges and universities across the United States.

Threats Moodle will be the source of our competition and our biggest threat when developing the application. Even though we are working on creating a Moodle application with certain features from Facebook, we would still have to consult Moodle before using their database. It would be important to create a deal between us and Moodle where we receive rights to the production of the application in exchange for some type of payback per application sold. If we are unable to come up with an agreement with Moodle, or if Moodle is already in the process of creating an application similar to ours, it would create a big threat to our idea and our design project.

Application GUI

Moodle login URL: Require the user’s input for the moodle site link. Moodle Login UN PW: Require the user’s input for the moodle site’s account user name and password. . It may also include the version of the moodle site. Decline Screen: If the account information gets declined, then the GUI goes to this screen and then goes back to the UN PW screen again. Success Screen: If the account information gets accepted, then the GUI goes to this screen and then goes to the next screen. Message/Reminder: If the user got any message after the last login or if there are any events (ex. Homework is due or test coming) are going to happen, then this screen shows up. Otherwise skip this screen. Course Menu: This screen shows the course the user is currently enrolled. Click on any course links to the functions menu. Functions Menu: This screen shows all the function included in the app. The user may also be able to customize this screen. Specific Functions: The function screens, depends on what the function is.

Further Application Function Implementation

Application GUI Dispatcher validation: This function should take the URL to the Moodle site and validate it, returning true or false. Secure connection Login: This file should create a secure connection using the username and password inputs provided. If it returns false, the user will be prompted to enter their credentials again. Otherwise, it will proceed to the next screen. Load classes: This function will execute once the login connection returns true. It will gather and set information to a variety of variables, returning textual information and links, as determined by an optimal GUI setup. The users will be able to click their class and proceed to the next screen. Load class: This function will need the string name of the chosen class. It will display the class’s information as simply as possible. The list should contain all of the URL’s contained within a regular computer’s Moodle login. Load homework: This function will allow the user to download the homework link, or display it if the homework is in a usable format (pdf, doc, docx, rtf, etc). Back: Basic back functionality for all screens. Display/Down One Level Script: This script will take the subsection within the class section and display it. There may be additional scripts besides this to display specialized information or sections. For Facebook Facebook Login Prompt: This will allow the users to login to Facebook, requiring their Facebook credentials. This will be optional. Load Facebook: This function will create a group within Facebook and adds the user to the group. It will be a public group, and will be accessible from the Moodle app. Display Facebook: This will display the Facebook layout, as suggested by the GUI design.

For Blog The blog will be used if we decide not to use Facebook. It will require a connection to a separate database. Secure Blog connection: This function simply checks that the blog server is online Display Blog: queries the blog for the selected class and returns the information posted to this blog. The blog will be accessible only once a class has been selected. Write to Blog: This will allow the user to write information and communicate with their peers. It will be a social-media-like setup. Next semester: This will be setup to run at specific time intervals to archive a blog once the semester is over.

Notes* The GUI design needs to be looked at more intimately and designs need to be tested to find an optimal GUI setup. Until that has been tested, it would be hard to determine exactly how some of the methods will show their data, so the display’s description has been left largely untouched. **Also the dispatcher verification was added separately because of poor return codes on the Droodle Application, which could not return enough information to clarify if the server has been reached correctly or if the login was incorrect. This would not need to run every time. Application Function Implementation Block Diagram Obtaining Data from Moodle

After some research, we have established a few ideas of how to obtain information from Moodle and reasons why certain methods are not viable options. Database level connections seem difficult because to be able to connect to the database on a sub-level may require administrative privileges. Also, although we may be able to setup a test environment like this, we would have access to the database level connections, where-as other environments we will not have that access. There are some ways to establish connections to the server using a client, but there sometimes needs to have server installations which are not usually included with the default install. Server managers are not going to want to install additional anything on their server just so our app works. Therefore, it would be beneficial to create a connection in a way that would not require additional server installation. The question becomes, is it possible to achieve this? A possibility would be to parse the html code from the website. This would be a very tedious process and may not be a viable solution when considering many different Moodle setups. We will have to look into and experiment with this method to evaluate the difficultly and accuracy of this task. When logging into Moodle, users use their credentials and information is returned. The information is obtained through a database level. We would rather not code the application if this were the only option because sustaining this application would be next to impossible. The question becomes, will that same user have the ability to access “read only” data that they have permissions for on the server or is this information only obtainable through the parsed html data? The answer to all of these questions is the Web services Moodle API. This API has all of the information and connections needed to connect to Moodle and perform the necessary functionality of the app. We can use the Moodle API and possibly other extended versions of this API to implement our needs. Because extended versions of the API or additional functions will require some addition to servers, we may not want to use extended versions. Instead, we could use the basic API without creating / extending the API platform. It has the basic functionality that we need. The developed Droodle API’s full source code, along with the source code for the application will provide enough information to determine a better way to code the application. This will allow our application to work for a variety of environments and situations, better than this version. Through testing, we should figure out if the Droodle API requires additional server installation or optional components, and why this app fails. Then, we should use this information to either develop an API if Moodle’s API is not functional enough (it should be), or use the existing Moodle API. To recap the research from a high-level design standpoint, the following steps need to be taken: 1. Look into other version of Moodle apps to see if we can use information to help with development and improve the basic functionality and design of the application. (Droodle http://droodle-api.appspot.com/, https://github.com/iVoid/Droodle, https://github.com/iVoid/Droodle-API/tree/master/src, and others http://moodle.org/mod/forum/discuss.php?d=191144

2. Find a working API to begin programming basic functions, as well as connecting the API. 3. Develop a simple GUI and test the app in our established test environment. Securing a Connection to Moodle

In order to receive any information on a mobile device such as a smart phone or tablet, there needs to be a connection to the internet through either Wi-Fi or 3G or 4G networks. All the communication done between the database and the mobile device is done through these connections. The issue lies within making sure that the communication between the secure website and the mobile device is secure and private to the user. Securing a connection with the database from the smartphone device is completed by implementing a username and password that would be distributed or established by the school that is using Moodle for their online class interface. The connection is secured the same way that it is secured when logging into Moodle from a computer on a web browser. The user will implement their information into the given fields and sent to the database via Wi-Fi or 3G or 4G networks. The database will then search for the user’s information and if a match is found, it would then send the appropriate information back to the mobile device containing the specific version of Moodle they are signed up to. After passing security parameters, the actual connection will occur from the mobile device to the school’s Moodle website. This communication will be secure because the mobile device will have already provided the identity and necessary credentials to access the database. The connection will remain secure for as long as the authentication holds between the mobile device and the database. From here, there are a few options to choose on how long to keep the secure connection to the database. The first option uses hardware tokens. These hardware tokens are used to generate one- time passwords that are encrypted and change every minute. Using this option would ensure that the user logs into the database with a secure access. The cons related to this option include keeping track of the hardware token and constantly having to sign into the database every time the app closes, requiring the token to be around every time the user wants to access the database. The second option implements proximity authentication. Using proximity authentication ensures a secure connection because the mobile device would have to be within the specific range set by the database. This would mean that secure connection depends more upon the Wi-Fi connection area. Using this would take out the mobile aspect of the application because the user would have to be within the school’s wireless domain to access the database. Moving outside of this area would not grant the mobile device access because the mobile device would not be found within the proximity set by the administrator. The last option involves using a certificate to keep secure connections for a given amount of time determined by the database owner. Currently, Stevens is implementing this function with their wireless internet access. In order to be granted the certificate to access the database, the user’s identity and credentials would need to be input into the database to establish the secure connection. Once authentication is complete, the database would send a certificate that allows the mobile device to communicate with the database for the allotted time. This option will be the one chosen by the group to implement security within the app and communication to the database because it is very secure and provides benefits such as application interrupts, such as phone calls and other app uses at the same time. In addition to using digital certificate authentication, it would be beneficial to also add a feature to the app that could reapply for a new certificate automatically without having to input the user’s identity and credentials again. This feature would be optional for those who do not think that this type of access is safe on their mobile devices. Integrating a Blog / Facebook Interface

The main application will load the native android interface and functions that will manage the main application. This part of the application will be responsible for retrieving moodle data from the servers and displaying it in an intuitive interface. Another component to displaying the moodle data will be loading a blog or Facebook interface. This will be a secondary functionality that will be added to the application when the moodle component has been successfully tested. A blog or Facebook interface would allow for users to connect with other users of our moodle application. This is important because it provides a great advantage over other competing applications because it does not just allow for an application that will display classes and assignments but one that will allow students to find and connect with other students in their classes. This will be quite useful because if students are experiencing difficulties then they may simply go on their application and seek help from other students. Then this help will be public so if other students are facing the same difficulties then they will be able to look at the same problem and possibly have their solution. The concept seems simple enough but it may be quite difficult to implement depending on the method used. A Blog type interface is the first method that our group is considering. This would be similar to Facebook but would have much less functionality. Its goal would be to allow students to post their problems online so that other students can look online and quite possibly answer these questions. This method would be difficult to implement because it would require extra hardware to be deployed. All of the information that would be displayed on the blog type interface would need to be stored on a server that is capable of handling a decent amount of traffic. Many students will need to access it possibly multiple times a day and in order for this component of the application to be successful this hardware must be top-notch but would also require a lot of extra work and capital. An alternative to this would be to extend our application into Facebook and loading up a custom Facebook type interface. Using a Facebook as an extension of our application would be of much greater use than to simply create our own. First of all, Facebook already has many servers where information is stored so there would be no need to manage our own server which would be a great advantage as opposed to creating our own blog interface. Also, this method may be preferred because students already have existing networks of friends and classmates that can be used. There is no need to create what is already available to us. Integrating our application with Facebook would allow for data to be pulled from Facebook which would automatically construct a blog component of our application. One downside to this however, is that first time users will need to provide login information twice. Once, in order to access their moodle account and twice to access their Facebook account. Also, this would restrict most of the social aspects of this application to those users who have Facebook accounts. This should not be much of a problem considering that most students will have Facebook accounts. Another advantage of this method is that our moodle application could also be linked to twitter accounts as well which enable more flexible and power in using the social aspects of the application. In order to use this method first a GUI will have to be developed to hold the data that will be pulled from Facebook. This GUI will be developed in android and will just be another activity within the application. The data pulled from Facebook will need to be coded in the Facebook API provided by Facebook. Also, Facebook’s consent will probably need to be obtained in order to pull user data. This also poses another problem that will need to be addressed later on, the problem of increased data security. Data from multiple accounts will have to be protected which will increase the importance of needing to protect the data. Another option will be to create a utility application on Facebook that will serve as a liaison between Facebook and our application. Overall, a blog or Facebook interface could be easily implemented using native android code but the choice will have to made between creating our own blog or integrating with Facebook to some extent. Using Facebook’s resources would be much more preferable to deploying our own due to cost and technical knowledge required. Utilizing Facebook’s premade server network and API to simply pull data from the servers is the best possible way to undertake this component of the application.

References http://searchconsumerization.techtarget.com/feature/Establishing-secure-mobile-communication http://searchconsumerization.techtarget.com/feature/Managing-mobile-authentication-methods http://searchconsumerization.techtarget.com/feature/Mobile-device-security-policies-Asserting- control-over-mobile-devices

http://developers.facebook.com/docs/reference/androidsdk/

http://developers.facebook.com/docs/guides/mobile/

http://developers.facebook.com/docs/reference/androidsdk/request/