FINAL REPORT 04/25/2015 FINAL REPORT SUNY CANTON MOBILE APPLICATION

Transcription

1 FINAL REPORT SUNY CANTON MOBILE APPLICATION GROUP MEMBERS: Alexander Royce & Luke Harper SUNY CANTON SPRING 2015

2 Table of Contents List of Figures... 2 Research... 4 Programming Language... 4 Android Studio... 4 Database... 4 Guidance... 5 Extra... 5 Resource Gathering... 6 Course Information... 6 Office Hours... 6 System Analysis... 7 System Design... 7 First Activity... 7 Second Activity... 7 Major Activity... 7 Course Activity... 7 Office Hour Activity... 8 Schedule Activity... 8 Other Activities... 8 SQLite Database... 9 Implementation... 9 Economic Study... 9 Development... 9 Probable Profit... 9 Advertisement Space Business Expansion Future Expansions Schedule Notifications Server Connection Payment Notifications Complications GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 1

3 Office Hours Search Engine Gallery Charts Team Organization Product Designs List of Figures Figure 1. Splash Screen Figure 2. Main Menu Figure 3. Major List Figure 4. Course List Figure 5. Schedule Menu Figure 6. Schedule Entry Figure 7. Level 0 DFD Figure 8. Level 1 DFD Figure 9. Context Diagram GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 2

4 Project Description: The ROO APP is a mobile application designed for Android devices. The software would be used as a utility for students on campus. The basic template allows everyone to look up course information including office hours, class times, course descriptions, professor names, and semester availability. It s created in the expectation for future expansions. Time Constraint: 13 Weeks Project Objectives: To give students an easier way to access information without requiring a computer. Hardware: Any Android cellphone will be capable of operating this application. Software: The cellphone needs to be using an Android system. Roo App was developed using Android Studio. Its development process included using Java SDKs and a SQLite Embedded Database. Strategy: We broke down the project into three specific phases, which were represented by a Gantt s chart. Jobs were distributed to each of our group members to develop the product. The phases show the steps taken for product creation, but more details about the whole project can be found in our graphs. Phases: Phase 1 1. Research 2. Gather Resources 3. Download Software 4. Study Required Material Phase 2 1. System Design 2. Visual Representation 3. Economic Study 4. Feasibility Test Phase 3 1. Setup SQLite Database 2. Program Application 3. Create GUI 4. Setup Splash Art GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 3

5 Research Programming Language This project required immense amount of research. We started this project having no background information in mobile application development. The best place to start researching was via YouTube tutorials. Most of our time was spent listening to professors, students, and the workforce explain their experiences via video tutorials. This gave us a great understanding on how to begin our project. We quickly noticed that most mobile application programming consist of either C#, Java, or Javascript/HTML/CSS. Our group had experience in C, Python, and a tad bit of C++. We understood that most programming languages are very similar and just require different syntax labeling. The first approach was to actually work with C#. This language is very close to C and the syntax different could be learnt very easily. We eventually settled on using Java because it was the ideal language for Android Studio. Android Studio We had to do further research than just the programming language. We needed to find an integrated development environment (IDE) that would match our expectations. The two most popular cellphone devices in the world are ran via ios and Android. Throughout our research, we found that most IDEs required access to an apple product to develop an application using their software. We didn t have access to the hardware needed to develop our application for all devices, so we decided to work with Android devices only. Android devices actually have a very powerful IDE which can be used to create application. Its name is Android Studio. This environment has tremendous amounts of documentation and tutorials for new developers. Its user-friendly workspace serenaded us. The programming language commonly used for this IDE is Java. It was decided to learn Java and use Android Studio to our advantage. Database There was plenty more research which was required to make this application possible. We needed to understand how a database worked. Without having experience with server stability and security, we were trying to find other solution to control the information in the GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 4

6 Roo App. It would be ideal to actually run this application with no connection to the internet. We found an amazing database called SQLite database. It s an embedded relational database, which does not require a dedicated database management system. This is literally apart of your code. It is not an outside source. It does not require any additional software on your device. It will store the application s information on your cellphone via the original download. The future information stored manually, using the application, will use your cellphone s storage device via the database. Using this we could incorporate a management system to allow users to keep track of their schedule as a future expansion. There were many other options to use, but we felt like this one would be superior. It s very developer friendly and had a large amount of guidance because of its close connection to Android Studio. It had close connections because it s very common to use both tools to develop software. Guidance Android Studio had vast amounts of documentation, so we had to spend a lot of time understanding it. To learn Java, we used developer tutorials to guide us to the basic concept. At some points, it seemed overbearing to try understanding so much new information without help from professors. Professor Wang, the director of Information Technology at SUNY Canton, guided us through some of the steps. His advice helped us understand key aspects and what we should look for while developing the application. If we d had went to him sooner, we d have actually built the application using a very powerful development kit called Monogame. This software is used to develop products once for all platforms. Extra The technology to synthesize the program was not the only research that had to be done. We were required to research information about the average economics of similar products, basic statistics on related categories, releasing the product to users, and how to gather the resources. We couldn t just create the product without knowing the possible situation that we may run into in the long run. Without that information, we d hit a wall and waste all of our hard work making it operational. GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 5

7 Resource Gathering Course Information The most important goal of this application was to give details about each course to students around campus in a minutes notice. We needed to get access to majors and course descriptions, in order to store them in our application. The hardest way to get all of them is by copying and pasting sections from the website. Another way is to contact the web administrators of SUNY Canton and to find out if they have them organized in a chart. Throughout our travels, we received information that the web developers only update the website when they re sent s with the descriptions. They don t have a complete list of all the courses saved anywhere. We felt like they probably have a huge workload and we didn t want to rely on them for parts of our project. The application is designed sort of like a template. We re able to add any information when required. It s a simple process, but would require countless hours of gathering the descriptions from the website. Instead, we chose to show a few majors and courses in order to display it works. Office Hours To get the office hours of each professor on campus would take either staff cooperation or weeks of speaking to each professor. Every professor has their own office hours and they change each semester. As students, developing this as a project, there is no reason to take either of these drastic measures. The easiest way would be to send out an at the start of each semester, required professors to back with their office hours. The first semester would be a little time consuming, but it could become an automated task via scripts or a macro. Future semesters would be less tedious because there wouldn t be so many changes. The Roo App is capable of displaying these office hours, once given the information. GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 6

8 System Analysis System Design The system is not very complex. Android Studio has many tools to have develop android applications. We spent time understanding these tools and figuring out how to setup our design. We needed to have multiple activities (pages) to hold information and react to an onclick notification. The pages will display a list of majors or courses which can be clicked. When clicked, they will forward you to another activity or a popup notification. The list are considered listviews within Android Studio as a preset, which can be scrolled up or down with the touch of a mobile device. First Activity When you opening up the application from your mobile device, it will open the splash screen. The splash screen is the first activity with a timer set. The timer is used to close the page and transition to the second activity. Second Activity This page is used to direct you to the proper utility. It s a GUI using a selection process, to allow the user to pick which utility they desire. Each selection is a button placed with an onclick directive. When programming the button, it will respond to being pressed and redirect the screen to its corresponding activity. The first button will be the main objective of this application. Major Activity The first button option is used to display a list of majors. The list of majors will be displayed on the screen. Each one is set to an onclick directive that sends the user to its corresponding course list. Course Activity This page is a little different than the previous two. It will display all of the courses within the specific major. The course will have an onclick response, but instead of re-directing it GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 7

9 to a new activity; it will give a popup menu with further information. The information will provide course descriptions, course times, and semester availability. Office Hour Activity Currently this menu doesn t show much. It s the same build as the Major Activity. It will show the office hours of every professor on campus. This system would require campus assistance. The ideal way of doing this, would be to connect my application to the internet. If it had access to a server-side website, it would work a little differently. I d be able to allow professors to login using their school ID s and change their office hours manually. This would need security and campus assistance to be made possible. It s definitely a possible expansion. This feature may be taken out in the future, due to the scheduling section. The scheduling section allows students to place this information for themselves and keep track of it on their mobile device. We thought office hours could have its own section because students don t only visit professors they have classes with. There are certain professors around campus that have skillsets that students may require assistance from. It would be easier for students to visit the professor if they knew their office hours beforehand. Schedule Activity This is the section which receives the most contribution from the SQLite Database. The scheduling activity requires multiple java classes to make work. It s reliant on the databases information in order to flow properly. Students are able organize their courses with this utility. A student can update this section of the application himself. I ve a table system setup with variables, to interact with the necessary strings attached to each required activity. Other Activities There will be future expansions to this application. The button space is accommodated for these in mind. The transition will be similar, but there would be further programming needed to incorporate the specific expansions. GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 8

10 SQLite Database This is probably the most complex system within our application. It s one of the most basic versions of the more well-known databases. It can be extremely powerful with an application that requires no internet. We re striving to allow the application accessed without any internet access because there will be time in which student s cannot access it. Implementation The database is setup with tables and variables. The variables will connect typed in values to the database categories. When a new user is implemented in the scheduling section, it connects the title or name to a specific onclick command. When multiple inputs are available, it will distinguish which onclick is pressed on the listview. Economic Study Development This project s building cost were minimum. It does not cost anything to place the application on the Android Store. We did the programming ourselves, so it didn t cost anything to develop it. The only money we would have to pay is if we decided to do future expansions into the Apple product line. To produce the same application for Apple products, it would cost around 400 USD for a laptop and $99 USD a year to become a developer. Probable Profit The profit made from this type of project normally varies. It depends on the set price between the developer and consumer. The price normally set for small applications are between $1,000 and $4,000. A database application could range from $8,000 to $50,000. If we include all of our ideas in the project, it could easily become a higher end profit. GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 9

11 Advertisement Space Another way of gaining revenue from the application is to sell advertisement space to nearby stores. If a local organization or company wishes to get their sales to students around campus, we could sell specific sections of the application to them. We could run a small advertisement while loading each section of the application or place them under the buttons on the main menu. This might be annoying to students, but it wouldn t stop them from using the application. The campus could choose to do the same if they take over the application from us. They d have to learn to update the application or compensate us. Business Expansion We were looking into the possibility of developing similar application for various universities. The template is created to be changed easily. The process of setting it up for another college would take some time, but can be done. We re keeping our expectations private, but we d assume proper compensation for the applications to be built. Future Expansions Schedule Notifications It would be very convenient to alert users when their class is starting. They could set their alarms within the application for an important meeting. It could be set to let you know when you ve reached your destination. We believe that it could be an interesting feature to experiment with. Server Connection The application could be connected to the university s server. We could figure out how to connect it to ucanweb or angel in preparation for updating information instantly. This could expand into many more interesting features. GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 10

12 Payment Notifications There could be a feature which allows the campus to send information regarding money owed by students before courses being. It would allow students to keep up with their payments without excuses. In the past, students end up not being allowed back to their next semester due to miscommunication. This would help prevent miscommunication between students and the campus. Complications We came into this project with the understanding of two major complications. There would be trouble with ios users getting access to the application. The university would have to update the database once per semester. While working on the application, we ran into further problems. Most of them could be fixed with cooperation from the campus. They have been briefly explained previously. Office Hours In order to obtain the proper information every semester, professors would have to reply to an giving their new hours each semester. This would be tedious, but very effective. There is already many situations that need to be dealt with each semester, but that s why people get paid. To automate the process wouldn t be too difficult. It can be done multiple different ways. One way that it can be done is by setting a script to gather all replies back into a document. Every time a new reply is received, it will strip the useless information out and place it neatly in a new chart or document. At that moment, it can be transferred to the application s database very fast and efficiently. I d give out strict instructions to reply back with a given form. As long as none of the professors add any additional just to the , it would automate very easily. A section for professor notes could be placed in the form and be automated to a different document for technicians to read if needed. GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 11

13 Search Engine The application was meant to have a search engine incorporated in it. It shouldn t be hard to allow a search engine to look up user inputted words from the database and display the results. The complication that we ran into can be fixed given the time. The complication is that there are multiple ways to add in a search engine. It can be done via the toolbar at the top of the device s pull down menu or through its own icon on each activity. We d prefer the icon on each activity, but it has continuously avoided to work. It seems to crash the emulator every time it s implemented and we continue to strip it out in order to have a working product. The time restraint of the project doesn t allow us to modify it to work, so it would have to be a future expansion. GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 12

14 Gallery Figure 1. Splash Screen Figure 2. Main Menu Figure 2. Major List Figure 1. Course List Figure 3. Schedule Menu Figure 4. Schedule Entry GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 13

15 Charts Team Organization Task Name Duration Start Finish Predecessors Resource Names System Analysis & Design Project 66 days Mon 1/19/15 Mon 4/20/15 Project Proposal 21 days Mon 1/19/15 Mon 2/16/15 Organize Group 3 days Mon 1/19/15 Wed 1/21/15 Alexander, Luke Brain Storming 6 days Mon 1/19/15 Mon 1/26/15 Alexander, Luke Research 11 days Mon 1/26/15 Mon 2/9/15 Alexander, Luke Gather Resources 6 days Mon 2/2/15 Mon 2/9/15 Alexander, Luke Proposal Creation 8 days Mon 2/2/15 Wed 2/11/15 Alexander Proposal Editing 4 days Wed 2/11/15 Mon 2/16/15 Luke System Analysis 26 days Mon 2/16/15 Mon 3/23/15 Project Proposal System Design 6 days Mon 2/16/15 Mon 2/23/15 Alexander, Luke Visual Representation 11 days Mon 2/23/15 Mon 3/9/15 Alexander, Luke Economic Studies 6 days Mon 3/9/15 Mon 3/16/15 Luke System Analysis Created 6 days Mon 3/16/15 Mon 3/23/15 Alexander System Analysis Edited 6 days Mon 3/16/15 Mon 3/23/15 Luke Final Presentation 21 days Mon 3/23/15 Mon 4/20/15 System Analysis Setup SQLite Database 3 days Mon 3/23/15 Wed 3/25/15 Alexander Program Application 19 days Wed 3/25/15 Mon 4/20/15 Alexander Microsoft Presentation 4 days Wed 3/25/15 Mon 3/30/15 Luke Final Report 16 days Mon 3/30/15 Mon 4/20/15 Alexander, Luke Table 1. Gantt Chart GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 14

16 Product Designs Figure 7. Level 0 DFD Figure 8. Level 1 DFD GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 15

17 Figure 9. Context Diagram Figure 10. E/R Diagram GROUP MEMBERS: ALEXANDER ROYCE & LUKE HARPER 16