1. Project Rickshaw SEARCH - FIND - GO

2. Project Rickshaw TEAM MEMBERS KEVIN AUGUSTINO – MATT FOX – DAVID MOORE SPONSORS KARASU TECHNOLOGIES - ERIK PAUL - MARK HORN - ADAM NUTT

3. Project Description  Goal – develop a mobile and web application that…  Allows customers to easily find food trucks in their area that interest them  Provides truck owners the tools they need to effectively market themselves to their customers  Ability to input and manage trucks/menus/schedules  Ability to push to social media (Facebook)  Data warehousing  Easy and intuitive to use

4. Requirements  Users should be able to search for nearby food trucks.  Users should be able to filter search results/refine search.  Users should have the option to create an account.  Add a food truck vendor to their favorites  Rate a food truck/food or post reviews  Selecting a food truck on the search results map would show information such as  Name  Their menu  Their current location (and predicted locations, if the food truck owner has submitted a schedule)  Their ratings/reviews  A description

5. Requirements  Food truck owners should be able to make an account that functions differently from regular user accounts.  Vendor accounts should allow the owner to input a menu, a description of their truck/food, and a schedule.  Social media (Twitter, Facebook...) should be integrated into the app.  For example, when a food truck owner adds a new item to their menu, the application could automatically send out a tweet letting the public know about this new food.  The application should also collect data for future analysis.  The application should at least run on Android devices.  Ideally, there would also be a web page users can visit that provides the same functionality as the application.  No search should take longer than a second or two to execute.  *The system should be able to handle thousands of concurrent users.  *Searches should have search suggestions (e.g., typing “Bu” in the search bar suggests “Burgers”), and should have a “Did you mean” that accounts for misspellings/synonyms (e.g. searching for “Brugers” should display results for “Burgers”)

6. Requirements  The application’s business list feature should be able to handle at least 500 businesses and sort them into lists according to distance from the user.  The application’s business mapping feature should be capable of handling at least 50 locations within a specified geographical fenced region.  Business accounts should be able to contain multiple food trucks  Food truck map/list feature should be able to locate and sort trucks within a 200 mile radius.

7. Division of Tasks  Mobile application  Matt  mySQL  Initial implementation by Kevin  Now populated using Hibernate, handled by David  Web Portal  Kevin  API  David

8. Project Structure/Technologies Used

9. Design  Design consists of  An Application layer  A Service/API layer  A Database layer  Application will send and receive data to and from service layer  Service layer will  Handle user authentication and authorization  Facilitate CRUD operations to and from database  Database layer will handle object and session persistence

10. Appcelerator  Titanium Studio IDE  Cross-platform  Ability to easily port to iOS devices  Coded in JavaScript  Simple for designing UI’s  Compiles to native code  Apps run more efficiently  Built-in HTTPClient API  Allows simple communication to our web service

11. Web Portal  jQuery  BootStrap  Framework for HTML/CSS/JS  Consistent look and feel across devices  FullCalendar  jQuery plugin  Provides a full-sized, drag and drop calendar  Used for schedule editor  HandsOnTable  Provides an easy-to-use data grid editor  Used for menu editor  All plugins available under MIT license One framework, every device

12. API Components  Sponsor’s experience informed decisions  Java  Tomcat for Execution  Apache CXF/Jax-RS for Web Server Development  Hibernate for Object/Relational Mapping  MySQL for data storage  Spring for Dependency Injection  Swagger for documentation generation  Hibernate Search for advanced query capabilities (Spatial)  Chosen for simplicity and compatibility with current choices

13. API Design  Endpoints are provided to allow CRUD operations for each object type  Service produces and consumes objects in JSON format  Additional endpoints created to allow for developer/debug-only functions as well as advanced search queries

14. Mobile Application Difficulties  JavaScript  No prior experience  UI Navigation  Issues  Slide Menu Creation  No native module  Not always fluid Successes  Google Maps Android API v2  Simple implementation  Appcelerator support  Web Service Communication  Built into Appcelerator’s JavaScript libraries  Simplified calls

15. API Difficulties  Initial difficulty in configuration/understanding of technologies Successes  The technology choices have, so far, been more than sufficient  Post configuration implementation has been smooth and relatively rapid

16. Budget  Server  Provided by sponsors  Mobile Development  Appcelerator  Titanium studio – free  Not using any custom modules  Code hosting  Bitbucket – free and private  Google Maps JavaScript API v3  Free as long as we do not exceed usage limits  Total expected cost - $0

17. Project Rickshaw SEARCH - FIND - GO