CALIFORNIA STATE UNIVERSITY, NORTHRIDGE

Transcription

1 CALIFORNIA STATE UNIVERSITY, NORTHRIDGE The Design and Implementation of Web Based Expense Tracking Application By Bao Vu A project submitted in partial fulfillment of the requirements For the degree of Master of Science in Computer Science May

2 The thesis of Bao Vu is approved: Robert McIllhenny, PhD Date Michael Barnes, PhD Date Son Pham Chair, PhD Date California State University, Northridge ii

3 TABLE OF CONTENTS Title Page i Signature Page ii Abstract iv 1 Introduction Focuses Adaptation to Change Developer Customizing Users interface customization Mobility, Accessibility and Portability Browser Based application for accessibility and mobility Native Application on different Mobile OS for software portability and accessibility Multiple platform Development flexibility Development Life Cycle Best Practices Tools...18 Sencha Touch Framework ( 18 Android Development Toolkit PhoneGap Cordova Project PHP MySQL Database Apache Web Server CentOS Operating System Reason for the choice of tools Cost Break Down Architecture Overview: General Application 3-Tier Architecture: User Interface MVC Architecture: Data Access Component Based Architecture: Design Interface Model Interface View: Interface Controller: Data Access Layer: Login Module Database Schema: Database Use Case: Application Use Case Procedure: Screen Shots Reference...50 iii

4 ABSTRACT The Design and Implementation of Web Based Expense Tracking Application By Bao Vu Master of Science Degree in Computer Science As Mobile application development has become one of the fastest growing trends in the last few years, this thesis will investigate the development of a mobile application. This paper proposes a design and architectures that would accommodate the users need of mobility and accessibility, as well as developers need of flexibility, robustness and scalability. It would also show why selecting an appropriate architecture and design is essential to the success of a mobile software project. In the mobile software development environment, many factors effect the decision of what and how to implement. The selected combination of design and architectures takes into consideration the rapid changes during the project development cycle, as well as ease of collaboration among developers. Correct decisions will turn into best practices that make future project more adaptive to change, easier to manage and more cost effective. This paper emphasize on a combination of number of well known architectures and designs to make it easy for developer to apply scope changes during an agile development cycle, while making it easier to manage work load and resource. At the end, a successful mobile application is an application that is useful for the users by increasing mobility and accessibility of the application. In addition the architecture and design of the application need to take into consideration future developing and maintenance. iv

5 1 Introduction Handheld computing devices or mobile devices (Android Phone/Tablet, ios devices ) have changed the world of computing significantly. The popularity of mobile computing devices also created a new form of software application, referred to as mobile application or simply app, that is designed for a smaller screen, and can be used with simple fingers gestures. There are roughly 600,000 Android mobile applications ( 700,000 ios applications ( available for download to mobile device users. With an average of 15,000 applications are introduced into the Google Play market each month alone, the choices are almost limitless. By investigating the rating distribution of Android Application ( almost half of the application has no rating. This means the applications are never downloaded and/or used. A large number of these applications have rating of less than 3 stars and by reviewing comments from user we can see that either they are not well written, poorly designed, buggy or non operational. This could be the result of developers rush to push applications onto the market, focus on the application s functionality as well as aestheticism, but forget about the process of making the application. There was possibly little or no thorough design, or wellwritten architecture for these applications. The vast number of available app brings a surprise outcome; a large number of applications are not maintained or abandoned by the developers. One of the reasons for an application to be abandoned is that it cannot be taken over by another developer to maintain, or it is just a buggy, bad product that it would be more cost effective to write another one. What makes an application popular and well received by both users and developers is the fact that it is well design, thoroughly thought out, easy to maintain and improve by other developers. There are two major concerns when developing a mobile application: accessibility, the ability to access the same data multiple ways, and mobility, the ability to use the application on the go with different type of handheld device (smart phone, tablet). Smaller, lighter devices that can be carried easily are replacing personal desktop and laptop computer. As on-the-go users increasingly take advantage of their mobile devices for day-to-day task, more and more mobile applications are introduced to help users increase their mobility. Most computer users have more than one device (mobile phone, tablet, laptop, desktop ), access to their application and data from different devices is crucial. Any application should not limit where and how user can access it. Today successful application is an application that user can use on their smartphone, desktop, laptop or anything in between. In addition to the two major concerns above, portability and adaptation to change have major impact on the user s reception and popularity of the software. Today mobile application needs to be able to function on different mobile platform and OS. The portability of an application from one platform to another will expand the application exposure to different type of users on different devices and therefore increase its popularity and success. The constant changing in software market and users expectation means the 1

6 application will be constantly changed and updated. An outdated application is a doom application and will be forgotten. Frequent update and quick adaptation to requirement change will be critical. The design and architecture of the application again play an important role to make this happens. We propose creating a mobile application called Mobile Expense, an expense tracking application, to demonstrate the development of a mobile application using Multi-tier Model View Controller architecture, Agile Development Cycle. Individual component s architecture and design in this system is not considered to be new, but by choosing the appropriate combination, we could satisfy the most important aspects of mobile software development mentioned above: mobility, accessibility, portability, adaptation to change. Top two applications yielded by Google Search for expense tracking are Tracker Suit.Net ( a C#.Net solution, and Mind Salt Time & Expense ( These web applications are built for the web, can only be accessed through a web browser. Both Tracker Suit and Mind Salt can run on a web browser, which satisfy our definition of accessibility. The advantage of Tracker Suite.Net is its model: integrated and modular applications as well as the utilization of non-proprietary, established Web technologies, including LDAP, SOAP and XML. Even though Tracker Suite is a feature rich and well architects application, it has one disadvantage over Mind Salt Time and Expense. That is there is no touch sensitive mobile version of the application. Mind Salt will give user on mobile device a much better user s experience with the implementation of touch sensitive design. User of Tracker Suite.Net will have a much harder time using the application on a mobile device. Therefore Mind Salt has the advantage of better mobility. Since both solutions above are 100% web based, Internet connection plays in important part. Both solution will fail partly or completely if there is any interruption to Internet connection. If there is an installed standalone version, that would work without or limited internet connection, we can eliminate the internet issue. An offline solution is needed along with a web-based solution so that we can have the best of both worlds. Many expense tracking applications on Android Market are built exclusively to be installed on the device (i.e. Android Expense Manger, Expense Manager, Toshl Finance & Budget). These applications and their data are installed and stored on the device. Although using stand-alone install application would eliminate the dependency on Internet connection, users are now completely dependent on the availability of their devices. Let s say the user left his phone at home and still wants to see what he spent last week. At this point, the user would not be able to access his application and data. Combining the two approaches can solve the above problem. We propose developing two applications: a web based application and an installed application. This combination would be ideal for this situation, which gives user the mobility and speedy load time of an installed app and the accessibility of a web app. In any environment, users will be able to have access to the application and data. 2

7 In order to build this application, we will utilize as many established Web technologies, and open source solution as possible to minimize cost and development time. This application was developed with changes, customization, portability, mobility and accessibility in mind. As we will use the development of this application to validate the choice of software architecture, design and life cycle, it is worthwhile to illustrate the approaches that were taken to make this into flexible, robust and scalable software. An appropriate design choice will also make it extremely easy to manage changes as well as resources during the development cycle. Many different architectures were investigate before a solution is picked. One of these architectures is the original way of building web pages; which consists of different div, tables, row and column. This design is easy to implement and turn around time would be rather quick. This is the most basic web application there is. However, when data needs to be represented in different way, a different page is required to be loaded since different components are not well defined and cannot be replaced quickly on demand. This is a very impractical approach since all scenarios will need to be thought of and all the pages will have to be pre-built. This approach was quickly eliminated because of the inflexibility to change and the inability to modularized components. Furthermore, this is a web application; it cannot be a simple HTML web page. We also need to satisfy the requirements of a mobile application mention earlier: mobility, and accessibility. A web application architecture and design are appropriate choices. We need to investigate how popular web applications are designed. Tracker Suit.Net, or Mind Salt Time and Expense provide features rich web site that user can keep track of their expense online. Such online applications cannot be completed with simple HTML pages. They need to be built with tools and plan that are made to accomplish such tasks. More sophisticated web language and tools were considered such as PHP, Perl, JSP, ASP and C#. The application would follow the basic dynamic web design: user request, server process request, server compose a new web page, server send back newly formatted page to browser, browser display it to the user. This seems to be a very decent approach. The technology is well tested, matured and known by a lot of developers. To satisfy the portability requirement, Mobile Expense application can not only be on the web, user should be able to install it on their mobile device. As mention above, an offline version will eliminate the need for loading the web page every time per users request, instead only transfer the data needed. Users now have the choice of using an install mobile app or using a web system. However, problem arises when a stand-alone install application is considered using Dynamic Web Architecture design. With a dynamic web page solution, all components must be served from the web 3

8 server, including web pages. We would be unable to build a stand-alone application that would be able to cache all different dynamically generated pages, so that it could be installed on a mobile device. Even if we are able to completely cache all generated web pages permutation, we are not at a better position then we would be with the original basic web page building method. This is when N-Tier approach was considered. N-Tier or Multi-tier is client-server architecture in which presentation, application processing, and data management functions are logically separated ( The separation of tiers gives developers the option of modifying and/or adding a specific layer, without having to modify the entire application. By separating the Graphical user Interface, Data Access Script and Data Storage into individual layer, we now have a 3-Tier System. The layers are loosely coupled. They do not depend upon each other to function, but they do feed each other data and command so that it can become the interaction between the system and the user. The presentation and data layers are in communication with tightly predefined data model. Structures and functionality of each layer can be changed, but the data model should not. Graphical User interface will be built independently for the web and install application. However both will share the same architecture and design. The open source community has been very generous with different tools that make cross platform developing easier. PhoneGap Cordova and Sencha Touch is a great combination that would create a HMTL5 touch sensitive web application that can be wrapped into and application that would run natively on Android OS, ios, Windows Phone, BlackBerry and different mobile platform. We now able to design and implement one application, and use the wrapper to create native application for different OS. The main concern at the moment is to create a design and choose an appropriate architecture to be used in this layer. Server fetch Dynamic Web page is out of consideration because of the reason mention above, but we still want the flexibility and dynamic of the application. In addition modularization and Lego like features is expected from a developer standpoint. These expectations are the response to the need of quick adaptation to change from customers and end users. Derived from the 3-Tiers system, we chose to use the Model View Controller (MVC) architecture. MVC makes it easy for customization and maintenance as well as modularize the components (MVC detail is explained in later section). MVC is similar to 3-Tier System where View = Presentation, Controller = Business Logic (Data Access), Model = Database. As we move further down into the lower layers, we need to examine how to build the data access layer. Many considerations need to be taken in place. One is the ability to take and process connection from different sources, not just from same site (same origin) request, but also from cross-site (different origin) request. Another consideration is what component is being accessed per request, and for each of those component, which sub component is accessed. 4

9 For example: user sends a request from a mobile device to retrieve data for an expense. The analysis of the request is as follow: Cross-Site Origin request Remote Interface controller Database Class Access Expense Class access function abc() Each individual component on this list is abstract enough that they can be modified without affecting other components. Each of them is a separate black box that would produce the result without the other box knows what it is doing, as long as the APIs are clear and strongly typed. Even though the system architecture is 3-Tier, we can now see clearly the similarity with MVC. While the whole system can be represented as a bigger MVC architect, this layer is the Controller; Graphical Layer is the View. The database is the last piece of the puzzle. It is simple and straight forward enough. Normalized database tables with key indexes are implemented in this layer. This layer is the Model in the bigger MVC architecture. Later sections will describe why the choices of architectures and design are appropriate in creating an application that satisfies both developer and users. In Summary, this application will use a modified 3-Tier architecture with individual tier has its own architecture. This 3-Tier is client-server architecture with User interface/business logic (web page), data access (PHP script) and data storage (database). - User interface employs Model View Controller architecture for easy of customization and maintenance as well as modularize the components. - Data access layer employs Class based architecture where ach class is responsible for one aspect of the application. Multiple level of abstraction is also implemented to maintain portability and flexibility in future changes. - Data storage uses normalized database tables. While it may not the most important aspect of this project, the tools that were used is critical to make this project feasible while maintain relatively low to no start up cost. The development of this application is completely based on open source software. Graphical user interface will use Sencha Touch 2.0 framework ( a high performance HTML5 mobile application framework 5

10 based on JavaScript. Server side technology will used proven PHP and MySQL Database. The application will be hosted on Apache web server. This application will also utilize third party component such as Google (or Yahoo, MSN, Facebook) for OpenID provider and other services. Now that we have researched and selected the appropriate design and architecture, determining the functionality of the application itself is the next important task. Would you like to be able to keep track of your expenses on the go using your mobile device? The idea of an expense tracking application is not new, but most existing applications limit user of what information they can track, and how they can track it. This application is generic enough that any user could use it out of the box, but it will be dynamic enough that it can be customized to fit individual need. Using the web-based application will not require user to install, update or maintain the app. By installing the stand-alone application, user is responsible to run update if there is any changes to the application. Android Google Play or Apple App Store usually does this automatically. The application will record user s expense in a database, run reports, analysis, print or reports as user request. The data is available anywhere, any time on any device. All though, the application will not be able to invoke the camera on a mobile device to take a picture, it can allow the user to upload a picture of the receipt and store it just as it was taken with the camera. Additionally, most expense tracking applications restrict what can be recorded for an expense. We ve decided to implement an exclusive feature of Mobile Expense. The feature includes the ability to create and record custom fields for individual expense. By using custom fields, users will be able to customize how and what to record. If necessary, user will be allowed to make any previously entered custom fields into a permanent field of the expense that will always show to be inputted. It would be worthwhile to see what sets this application apart from other applications that have already been on the market. The following list provides a quick glance at what can be expected from the application: - Dynamic of the application: this application must be able to allow user to customize what being entered as well as the function of what is being enter. - Mobile technology: mobile devices are become more popular than ever before. Most are equipped with Internet access, GPS or locating device method. By taking advantage of GPS feature, we can provide suggestion of where the purchase was made by provide a list to choose from. Internet access through Wi-Fi, 3G, 4G is a must have for this application to work. - Reporting services: since all expenses for an individual is stored, user can always use the data to run analysis on their spending. They can use the report to improve or break their spending habit. - Utilize the open source software library and web technology to minimize cost and learning curve. 6

11 For the following examples, we will have a hypothetical user, who create an account and set up his default fields as: Date, Price, and Description. Examples #1 : The user bought a $200 camera and wanted to keep track of the expense for later analysis. - The generic application setting allow the user to keep the following information of the purchase: o Date. (required) o Price. (required) o Description. (optional) - The user also wanted to keep track of where the purchased was made, what model the camera is, and what the camera will be used for. The user will create 3 custom fields on the expense he just created. o Purchase from (custom) o Item model (custom) o Purpose (custom) - The user can decide whether or not make the custom fields permanent. Examples #2: The user received a bill for his cell phone use and wanted to keep track of the expense once it is paid. However the user does not want to make the payment immediately, but want to put a reminder and the expense will only be recorded on the date. - The generic application setting allow the user to keep the following information of the purchase: o Date. (required) : the user will enter future date here o Price. (required) o Description. (optional) o Due Date (custom field) o Bank Used (custom field) - The user also decide to make Due Date, Bank Used fields into permanent field so that it can be used without reentering the field every time. Example #3: At the end of the year, the user wants to run a custom report on how he was spending during the year. The system will generate the report based on the criteria provided; the user will retrieve the report by download the file or . Below is a feature comparison between Mobile Expense, Tracker Suit.Net and Mind Salt Expense Mobile Expense Tracker Suite.Net Mind Salt Expense 7

12 Tracking Expense x x x Periodic Report x x x Custom Report x Custom Fields x Permanent Custom Field x Web Based x x x Mobile Web App x x Native Installed App x Open Source x x HTML5 x x Local Storage x (phase 2) Remote Storage x x x Non-web based multi OS x 8

13 2 Focuses. 2.1 Adaptation to Change Developer Customizing There are aspects of this project that make it very customizable. First is the use of MVC architecture for designing and developing the user interface. This answers the question: how do you modularize the user interface of a web application that allows you to easily modify individual parts in the future? Secondly, by separating the entire application into a multi-tier system helps abstracting the interaction between components. Lastly, the predefined data model contract help avoid confusion, miscommunication and mistake between change cycles. After all, the major advantage of a web application is that it can change frequently without the need to update and/or reinstall MVC Architecture: Figure 1: MVC Architecture Data Flow Diagram The purpose of any web-based application (or any software application) is to retrieve data, present it to the user, have the user manipulate it and store the modified data. That is what we will be using MVC architecture for. Data will be presented as model. The presentation of data to the user is called view. How user interacts with the data is called controllers. In this application there is an extra component. Data is retrieved, stored and updated in a component called store. So far the question may be: how does this help with customizing the application easier? The answer may not be simple yet. However we can see that in current web application, the user interface changes a lot more frequent then the data model. By separating the views from the data models, we can change the design as frequent as in agile development or as infrequent as traditional water fall cycle, while still maintaining data integrity and contract between systems layers. With the same concept, we can change how user interface logic handled in a separated controller without actually changing the associated view or the data store. If any of these component are merged together, changing anything will likely cause error and required retesting the merged component as once. For example, if a view object and a controller object are 9

14 combined, any modification to the controller part of the resulted object will likely cause error on the view part and vice versa. Designing a flexible, efficient user interface requires a different skill set then developing complex business logic, or developing a normalized data model. By separating the application, a project manager can allocate different resource to tackle different tasks and take advantage of the resource most valuable skills. This project is small enough so that it doesn t requires the collaboration of multiple developers, but we always need to look at the grander picture and what this may turn into in the future. Let s say we decide to take this application to the next level and hire multiple developers with different skills. Now we can allocate one group of developer to change the view, another group to work on the business logic (controller) and another group would handle data modeling. All the change can be done separately, independently as long as there is agreement among the groups. At this time the system is extremely customizable and allow for rapid deployment. Furthermore, the design of this application follows object-oriented approach. Views are developed as objects so that it can be reused and refactor quicker, more accurately and easier. At the current stage of the application, there is very small amount of object reusing. However in the future, similar views may be used in different instances and reusing view objects will come in very handy. The application looks and feels are collections of different views. This is where the users interact directly. This is also where changes happen the most. As mentions before, the design of this application breaks down what a user sees on the screen into multiple pieces. How the screen is broken down is based on how frequent that one piece will be reused in other screen. However, with future development in mind, a screen is broken down into individual view object as much as possible. Think of this application as a Lego store where individual view object is Lego piece or building block. Developer can use those building blocks to build bigger piece. In coding language, developer initializes different views objects and put them onto a bigger object. How pieces are changed, interact with one another and response to user input relies on controllers. The controller is designed as one controller class with different references to different views. Each reference would be responsible for an action on the view. This way, if view is added, new controller reference will be added. If view change, controller does not need to be changed as long as the functions and references are the same. Controllers would be the glue that binds all views and data model together Users interface customization. A good application would be able to accommodate the need of user to change it. At this stage of development, user would be able to use the app as is or has a few options to extend the functionality. The 10

15 main functionality of this application is to provide a tool for user to keep track of daily expense. Therefore, the most critical pieces of information would always be present and are required. Needs come up every now and then for some extra information to be stored. For example: due date for payment, tax amount, who the expense was spent on. Or user would like to keep track of the detail items on the expense. 1. Expense Items: - Each expense can have no item recorded or it can have many item added to it. - Each item has its own information - User can run report and see what item was put on the expense - User can add an item to the expense and can remove it before saving. - There is a one to many relationship between an expense and items 2. Custom Fields - Each expense can have no or many custom field - Custom fields can be of type text, number or date field - Each custom field is store in a table and has a unique id - User can run report based on custom field value - When running report, user will be presented with all the custom fields name previously used. Sample Scenario: A plumber shows up for a job at a customer house and wants to use the app to keep track of the work. The total cost of the job is $200. Labor is $100, $50 for pipe, $20 for valves, $10 for connectors and $20 for pipe insulation. He also wants to keep a promise to the customer to bill on Nov 30 and there will be a 10% discount. On the expense screen he can enter: - Store: Customer Name - Amount: total bill (or enter individual item and hit the total up button) - Date: the date the work was performed. - Add individual item in the item list: Labor $100, Pipe $50, $20 valves, connector $10, insulation $20 - Now he can add a custom field that is a text field (default type) with the name: discount and value 10% - Another Custom field for Due Date with type date (or leave at the default text field) and value Nov 30, Save the expense or in this case a job. As future development, more customization will be allowed in the application. This can be accomplished without much effort since the application itself is designed to be flexible and easily customizable. 11

16 2.2 Mobility, Accessibility and Portability Browser Based application for accessibility and mobility Desktop browser for accessibility This application is not designed for use on a desktop browser. However, it can be run under a WebKit Browser such as Google Chrome, Apple Safari and many more. Why would it not displayed correctly on non-webkit browser is explained in detail in the next section. Desktop browser provides an alternative way for user to access Mobile Expense. Users may not have their mobile devices ready at all time, but access to a computer would give them access to the application and their stored data Mobile Devices Browser for mobility WebKit browser is important for rendering this app. Sencha touch library was used to make this application feels as much as a native app as possible. In order to do that, the library take full utilization of HTML5 and handheld device touch sensitivity. This application was designed to eliminate the need of a desktop computer. It was meant to follow the user to where he or she needs to use it. In order to do that, it must display well on a phone or tablet screen. It also needs to response to human touches naturally. WebKit is a browser engine that is responsible for render webpage and display it on. Almost all mobile web browsers use WebKit engine. Sencha touch is written and focus on running under WebKit. That is the reason why browser such as Firefox (running Gecko engine) would not be able to render this application correctly. Up to now, Gecko engine does not support HTML5. Figure 2 explains how the different layers in Mobile Expense 3-Tier architecture interact in a webbased environment. In this design, all components of the application will be installed on a web server. Request from the Graphical User Interface will be sent down to the next layer, the Data Access Layer. The data access layer will act as the business logic tier, which is responsible for requesting, manipulating data from the database layer and responding to the GUI. Database layer is responsible for storing the data and response to data access layer queries. Although, all components are installed on the web server as one application, the separation of layers will make it possible to take individual layer and install it on different host (server, mobile devices ). This leads us into the next section where we will create a stand-alone Android application by extracting the GUI layer and install it on a device. 12

17 Figure 2: Web Server 3-Tier Architecture Native Application on different Mobile OS for software portability and accessibility There has been instance where a need for native application overpowers the advantage of a web application. There are also multiple reasons why a user would like to be able to install the application on the device instead of visiting the web site and using a web application. Some of the reasons include security, privacy, speed, and instant app access. The biggest concern is that data transmit between the website and the web server can be intercepted and personal information maybe lost. Even though this can be solve by implement SSL and HTTPs, some users would feel more comfortable if the data stay with in the device. Therefore the solution is to port this web application to a native application. Below are some pros and cons of different approaches Approach 1: Native Application with remote data storage (Implemented) As the application is designed to be multi-tiers, the only tier that will be ported in this approach is the User Interface tier. However, that does not mean the other tiers can stay completely intact without any modification. The current Data Access tier (PHP script) will have to be transformed into a web service in which it can accept incoming request from different sources and be able to authenticate, and validate the connection. This approach would be the simplest way to create a native app and reuse the most components. There are tools that would wrap any web application user interface and create cross OS operational application. As long as our data contract and function name remain the same, retesting will be kept to a minimum. In this implementation, we decide to use PhoneGap Cordova, an open source tool, to wrap the GUI layer code into an Android native app. Since the interface 13

18 between layers and their protocol/data do not change, there is no need for any interface rewrite and extensive testing. Figure 3 explains how the layers are separated, but still communicate and function correctly. However, this approach may not satisfy user with privacy concern, it only answers the access problem. Figure 3: Remote Application with Web Service Access Approach 2: Native Application with local data storage. If the native application stores its data onto the internal device storage, the data access and database tier will have to be rewritten with the same design on different operating system. This approach will be the costliest since we are essentially rewrite the entire application. In this design, we will duplicate the entire web-based application, and create an install application. The design and architecture of a web-based Mobile Expense can be reused. This approach will definitely satisfy any security concern since all data and application will stay locally on the device. However data is not back up and/or sync to the server and there is no guarantee that user can recover any data in case of loss. Update to the application also requires user s action on the device. Most mobile OS allows automatic update but that all depends on user s preferences. 14

19 Approach 3: Native Application with local data storage and sync Approach 3 is not really a different approach but a combination of the other two. This approach is only feasible if entire Approach 2 and part of approach 1 are developed. In this approach, once a complete native application with local storage is developed, there will be an extra function added. The function is sync data. This function will use the data store locally, call the web service developed in the first approach and sync data periodically. This approach allows user to keep the application data securely on the device, but also give him an option to back up the data on the remote server. In case of loss, or device inaccessible, user with backed up data can continued to access, view, update and/or modify his or her data with the web application and the synced data Multiple platform Development flexibility As we continue further into the project, the importance of modularization and separations of components become clearer. One of the benefits of this approach is the ability to create multiple different applications that would runs on different platforms while reuse as many components as possible. The development of a completely web based app and an installed android app (or ios) is a good example. While the GUI layer for these two platforms are developed to run on two different OS (Linux web server / Android OS), they have the same design and architecture. The data model remains the same in both applications, meaning it would be understand by the Data Access layer no matter where it comes from. Even though a new class was created (Remote Controller class) in the Data Access Layer to accept web service call, everything else remains the same. The GUI now communicates with the Data Access Layer via web service call instead of Html POST method. As the result of layers separation, the three layers of this application can technically be installed on three different systems running three different OS, as long as the communication between the different layers are guaranteed. 2.3 Development Life Cycle During the development of this project, there was never a clear requirement as of what features need to be there. The reason for this decision was to see how an appropriate design and architecture make it easier for developer to make quick change after receive feedback from customer about the change in a shorter amount of time. As explain above, modularized all components makes the application extremely robust for changes. If customer wants a new feature in the application, that feature can be developed completely separate. The feature user interface will be develop by one team, while the controller is developed by another as well as PHP script and database changes. This project implemented an Agile Development cycle (prototype feedback change repeat). 15

20 Examples below illustrate the effectiveness of modular design, Model View Controller Architecture and Agile Development Cycle. Example #1: Adding Custom Fields feature. Originally, this application does not have a custom fields feature. The steps involve in adding this features include GUI Team: - Create a Custom Field Panel Objects. - Adding a Custom Field container object in the Expense Input Object. - Create a controller that would add a custom field object into Custom Field Container Object. - Modify Save controller to also send in Custom Field Object data. PHP Team - Modify Expense Class to read extra Custom Field Object Data and Save to database table. - Notice that the Main Controller class remains the same as the data object (now include the Custom Field Data) is encapsulated and presents no change. Database Team - Create new database table to house Custom Field Data. What we can see from this example is that each of the bullet point above can be developed separately while maintaining system integrity. If one of these bullet point is not complete the new feature will not work, but all existed components are still functioning as expected. As integration meeting, all steps need to be verified and validated to function correctly before all new changes are committed. This change was done within 16 hours. Example #2: Allow user to mark custom fields as permanent Later in the project, customer decides that they want to make some or all custom-fields as permanent fields on the input screen. The steps involved are GUI Team: - Create a new Custom Field Management Panel Object - Create a controller to update individual custom field - Create new controller to modify the Custom Field Container Object to load permanent custom fields PHP Scripting Team - Create new controller to update Custom Fields Object - Create new controller to retrieve Custom Fields 16

21 Database Team - Add new column Permanent in the Custom Field tables Custom Field Management Panel was developed completely separate and only appears on the app as a new Panel. Update Controller also was developed completely separate. The application was up and running even during integration, since the existing features are not modified at all. All components for this feature are new and integrate seamlessly. We can see that using MVC and Multi-Tier architecture helps achieving the result more efficiently. So how did MVC contributed to the success of Agile Development cycle? While agile development emphasizes quick iteration without expensive planning, MVC emphasizes a well-built architecture. These two concepts seems unable to be applied together. Another way of asking the question is: can an agile project have a solid architecture? The answer to this question is absolutely. Agile development can always start with the core components. First iteration is usually unclear, has small scope and also can have very few number of views, unsophisticated controllers and no data model. The separation of components and layers in MVC does not necessarily means that you have to plan out all the detail out at once. Agile also does not mean developer write code as its come to mind, but ready to change as requested. The combination of these two techniques means you start out with the core components, add components (views, controllers, model) during each iteration. As long as you maintain the separations of concerns, an agile cycle will produce a solid MVC architecture project. The Lego like concept of MVC also helps in the fact that you don t have to keep what you have in the previous iteration, an agile characteristic. Component can be dropped, replaced, added and refactor easily because of good separation. 2.4 Best Practices With all the focuses describe above, we can derive a list of best practices for mobile development as follow: - Separation of Layers allows flexible development in different OS/Platform. - Modularize components make application more flexible for changes. - Agile Development cycle is easier with module and layers. - Obtain feedback as frequent as possible in Agile. - Separate development teams by layers then components. 17

22 3 Tools As mentioned above, tools may not be considered an important aspect of a project; it is critical for the feasibility of the completing the project. Sencha Touch Framework ( Sencha Touch 2.0 is used in this application. Sencha Touch is a HTML5 web application development framework. Sencha Touch provides built in component that would make it easy to create user friendly, powerful mobile application that work on Android, iphone, Blackberry or any WebKit mobile browser Sencha Touch provides easy to use API with built in Model View Controller Architecture. Couple with Sencha Architect (GUI building tool), developer will have a powerful, intuitive set of tool without the restriction of an IDE. Customize code and logic can be developed easily after the GUI is built. Sencha Touch is built for speed. Users don t care if it is a native application or a web application as long as it is easy to use and fast. Sencha Touch blurs the line between a native and a web app by providing responsive, incredible application no matter what browser on what platform the application is running on. Sencha Touch also makes it easy to retrieve data from the server with built in Ajax, JSONP and web service calls. Data can be modeled so that it is uniform across different layers and portable between components. Android Development Toolkit This is a collection of tools that allows developer to develop application for Android OS. Android SDK is a modified version of Java and developers are very familiar with the platform. Android is an open source product and widely used by different hardware manufactures. PhoneGap Cordova Project. PhoneGap Cordova is a wrapper platform that turns any HTML5 project into an application that runs on different mobile OS. The choice of using PhoneGap is to limit the number of different version of the application that need to be developed for different platforms. PhoneGap will wrap any Sencha Touch client side project into a fully functional application that would run on Android, ios, Windows phone, Blackberry Although, Sencha touch can mimic a native application with a web based app, Internet connection plays an important part in accessibility of the application. PhoneGap makes the web apps readily available on the device as an installed application. PHP PHP 5 is used in this application. PHP is a proven technology for the web. However, in this application, PHP is used primarily as a way to provide, validating and authenticating data. Most PHP script is developed to retrieve data from database tables as well as processing data for database table inserts and 18

23 update. Another important used of PHP here is to serve up the JavaScript that is compiled by Sencha Touch. MySQL Database MySQL 5 is used in this application. Data is the blood of the application. Without data, this application servers no purpose. As one of the important aspect of this project is to create an application using only open source software and technology, there is no better choice for a database engine then MySQL. Apache Web Server Since this is a web application, it needs to be hosted on a web server. Using Open Source web server seems to be the logical choice. Apache provides what we needed: a simple, lightweight, easy to configure and reliable tool CentOS Operating System Last but not least, all the above tools will have nowhere to run under if we can t put them on a computer. CentOS provide the reliability and robustness of a Linux environment while maintain the Open Source aspect. Free Web Services This project takes advantage of free web services provided by different online providers. OpenID is used as the authentication mechanism for Mobile Expense. By using free web services, we can cut down on development time and cost by reuse products that have been developed and popular among Internet users. For instance, the use of Google, Yahoo, Facebook as OpenID providers does not only eliminate costly development but also let users use existing accounts allow them to start using the application quickly without the hassle of signing up for an account. Future development of Mobile Expense will include more free web services such as: free Map service from Google to locate surrounding business, integration with different web mail for report delivery and many more Reason for the choice of tools. All the above tools and software are open source software. The choice of tools allows any individual or group to start a software project with minimum or no cost. Open source software also has a large support community that questions and problem can be answered quickly and correctly. It is not easy to combine multiple open source software project to create a collection of tools that work well together. But if you are able to find that combination, such as the above, you would have a powerful, robust, flexible, but yet very cost effective set of tools. This project s cost is close to zero, except for some mistake that cost some minimum amount. This project is a great example of using free tools to start up a software business and can still produce a powerful, scalable and reliable product. 19

24 Cost Break Down - Sencha Touch : $0 - Android SDK: $0 - PhoneGap: $0 - PHP: $0 - Apache: $0 - MySQL: $0 - Amazon EC2 Server: $0. 20

25 4 Architecture 4.1 Overview: This application is broken into multiple architectures: i. General Application Architecture is using 3-Tier implementation which consist of Interface tier, Data Access Tier and database Tier ii. Graphical User Interface Tier is using Model View Controller Architecture iii. Data Access Layer: Class based component Architecture iv. Database: normalize database schema 4.2 General Application 3-Tier Architecture: Communication between Interface Tier and Data Access Tier will take advantage of AJAX Technology. Web page will not be reloaded per click but views will be changes based on the data that come back and forth. Figure 4: 3-Tier Application System Diagram The separation of tiers gives developers the option of modifying and/or adding a specific layer, without having to modify the entire application. This architecture is particularly useful in the development of Mobile Expense for satisfy the decision of building two separate applications: a web based and a native application. The communication between tiers was designed similar to a web service (see appendix for web service definition) so that they do not have to reside on the same server. Each layer now can reside on different devices and communicate via the World Wide Web. GUI layer was separated and transform into an Android Native app while still be able to communicate to the Application / Business Logic Layer to request data and response to command via web protocol. The separation of the GUI layer allows us to create native application for different mobile OS, which increase the software portability from one platform to another. The 3-Tier architecture is closely related to Model View Controller architecture that was used in the graphical user interface layer of the application. The next section provides a closer look at MVC architecture. 21