-
Notifications
You must be signed in to change notification settings - Fork 15
Mobile dev
See below the numbered points as how best to build out the Android app interface. The implicit workflow and views/tabs will be revised as per Carolien's user-based design brief.
We can evolve this intreface iteratively, my comments below are directed at kicking off feedback and ideas for your app. I look forward to Carolien's comments and ideas as we move forward.
1. Until we work further with Carolien and her user studies, the focal point of the app development should not be From/To routing, aka point-to-point search. It should be exposing the ChaloBEST database in the most flexible and non-sequential way possible, taking advantage of GPS or wireless location.
2. Users should not be required to type or enter text to find the information they need. They should just be able to tap or click. Hence we should expose as much data as possible without asking users, and let them find their way through it.
3. The key to this is making the app location-based, whether via GPS or wireless network location. As soon as the app starts, I want to see my nearby stops and routes and useful local data without making any queries. I don't have time fiddle with text entry, especially when I'm running to catch a bus I see coming at me.
4. Users should also never have to solely use the back button to return to a previous view/window/session. Every discrete view and function should be embedded in a tab, which is always present for overall navigation. This is the main shortcoming of nearly every Android transit app out there, including OneBusAway http://onebusaway.org/
5. This master navigation is best implememented with native Android tabs, such as the default Android dialer, which has Phone, Call Log, Contacts and Favourites tabs, all of which perform discrete functions and define specific views around the same database. This is a good metaphor to generally follow until we implement Carolien's user-driven design.
6. Given the constraints of screen space and difficulties of switching between windows/views/tabs on a phone, we need vertical swipe (up and down in a window/view/tab) and horizontal swipe (between windows/views/tabs). We can have long location-based lists of nearby stops and routes which scroll vertically, and switch between discrete views/tabs horizontally.
7. For now, we can configure these tabs/views are one each for Stop, Route, Area, and Road, since they derive from the structure of the BEST database and once we know the user's location, we can do a spatial query to find out the rest. We can sit to figure out how to pipe these via GTFS or give you other data to simplify these tabs/views.
8. The From/To (point-to-point) search and routing should be available across all these four tabs, either floating topmost on each tab or invoked by pressing the Android search button or menu button with an option to search. Just like you get a URL bar floating above the stock Android browser, your routing query should be available across tabs and anywhere in the app by pressing the search button.
9. If no From/To search strings have been entered for From/To search, default to the user's current location for generating lists in tabs. On Stop tab, I want to see all nearby stops; on Route tab, nearby routes (positioned via my nearby stop within around 200 metres); on Road tab, nearby Routes; and on Area tab, routes and stops in my Area.
10. When a point-to-point search has been performed, then the four tabs (Stop, Route, Area and Road) constrain their results to the text entered in the From and To fields. On Stop tab, only list the stop entered in From/To; on Route tab, list the busses between the From/To stops entered; on Road tab, list the busses between the roads of From/To stops entered; on Area tab, list the busses between the areas of From/To stops entered.
11. If only From stop is entered as a query, constrain as with nearby Stop in 9. above. If only To stop is entered, assume the current location as the From stop and show the same results as if From/To were are both entered.
Android App by MGTech http://chalobest.mgtech.in/chalobest.apk
Currently it holds some Madrid GTFS data; the following are example searches:
- Start: Martin Fierro - Obispo Trejo
- Destination: Dario Aparicio - Tapia Casariego
- Start: Ramirez de Prado - Bustamante
- Destination: Av. Cdad. Barcelona - Seco
- Start: O Donnell - Saliente
- Destination: Hacienda Pavones N 240
Will contain code on information for GIS extensions in sqlite (http://code.google.com/p/spatialite-android/); this is best built on Debian. This is useful to do more complex routing locally on the device. This may be compiled and incorporated in the APK as a shared object; and called at run-time through JNI. One disadvantage of this is the application is then bound to a given instruction set (ARM); one may check supported instruction set using the APP: 'Know CPU'; most Android devices use this.
sqlite create file. This is the DB schema. Currently; we have used some scripts to approximate the trips and imported from GTFS Madrid data. Some thought needs to be given to this schema. We will either need to export directly to this schema or use GTFS as an intermediary. When ever it is the right time as per the team; we can sit and design this properly. With GIS extensions we can do pretty good routing locally on the device (with multiple interchanges).
This is the Android application; once the SDK is setup; please adjust the 'local.properties' to point to your SDK and run the app in debug mode with ant debug. We should have a sit down and build this for you guys on your PC; that will be a good idea. Then we can (once we have established the best way to map the data to the mobile DB); setup a simple automated means to build the application with the latest data whenever ready. This way whenever a new data-set is ready; it can easily be imported into the mobile application and deployed (OTA) by anyone who is working with the Data. We will look to establish a relatively seamless processed to do this.
Once the online Web API is ready; we will integrate the application to the online API; to create two versions of the App.
This is a J2ME project. Currently this is incomplete and only contains bits and pieces to test the waters. The basic idea here is as follows to store a text file zipped in the application resources. The first time the application runs on a given device; we will read all the data and store it as appropriate in the available data structures. Then we may attempt to serialise these structures in the resource and then delete the original data from the resource. Next time the application starts we will unserialise. However this process is tricky and not sure it is the right way to go; to achieve serialisation on each platform we will need to implement serialisation for each given unique environment and use Java pre-processor directives; to achieve this. We need to give some thought in how to create a good offline app which runs on as many types of phones as possible.
This is some trial run stuff; just trying and testing a few things. One thing here is looking at routing calculations to be finally done offline on a mobile device. Nothing fancy; basic idea was:
Input: Determine route from Geo to Geo at a given Day and time.
1) Get all bus stops walking distance from Geo. 2) Get all trips which depart from any of the stops in (1) withing 15min of departure time on departure day for the applicable services. 3) Get all stops which are reachable in these trips where the stop comes after the departure stop in the trip sequence; ordered by distance from the Destination Geo. 4) If any of these stops are walking distance from the the Destination; then consider the Trip as viable. 5) Further take each stop closest to the destination from this list in turn (with some limit); and pass each of these stop's Geo and trip arrival time, back to step (1); keeping track of the stop-trip stack. One would need to monitor the recursion level and maybe limit it to no more then 3. 6) Then sort the results by something meaningful (such as shortest distance or time).
This is one way to do this in a brute force fashion; with a fast enough DB and system; and with a limited amount of data. This algorithm would need to be tweaked to consider other modes of transport; but works decently for Buses only.
Please let us know if you have any trouble with running the application; and please provide any advise on the direction we should follow.
As per our conversation and meeting with the ChaloBEST team on Saturday I am sending these consolidated points about what we expect from the ChaloBEST mobile platform in native J2ME and Android which you are building.
1. Both the Android and J2ME apps will access their data in GTFS format, and refresh and sync locally using the ChaloBEST API and GTFS feed. Responsibility for mapping and parsing CB data into GTFS will be with Sanjay, GN and Johnson. Please make sure you see and study the project links to OneBusAway, OpenTripPlanner, and other GTFS APIs on the wiki: http://wiki.chalobest.in/index.php?title=Web_Services
2. For maximum speed and performance and to conserve data bandwidth and cater to non-data plan mobile users, the apps will have an offline data store which can be manually refreshed when a data is available.
3. The apps will allow for user registration and authentication framework unified with our web site and services. This should most probably be employing the oauth framework which will work fine with django and our API. Registered app users should be able to see logs of their app activity, sms queries, and location on the web, and all this should be cached locally and synced online.
4. Users can opt-in at registration to share their activity logs and GPS location with ChaloBEST and permit tracking and uploading/annotation of waypoints when their GPS is on. This will be available on the device for upload to ChaloBEST in GPX format.
5. Both the Android and J2ME apps should utilise wireless network/geo-location by IP address, or via GPS if it is available and on. All aspects of the app interface and display should be location-aware to the extent possible.
6. The Android app should utilise the OSMDroid framework as well as the OpenGPSTracker app library for rendering maps inside the app, and tracking and uploading data in GPX format from the app to ChaloBEST servers.
7. The apps will have separate views for Stops, Areas, Roads, Landmarks and Routes, which are the basic framework of our database API. The interface design around these basic data structures should follow the templates and design schema on the main ChaloBEST website and be integrated with its frontend API, optimised for mobile displays.
8. You and MGTech will maintain regular/nightly builds of the app in a private repo online which can be accessed over http on an Android or J2ME device for easy download and frequent updates against bug fixes and feedback. This should be behind a password, and builds will be versioned and numbered. The name of the app will be ChaloBEST and use the existing icons and logo.
9. You and MGTech will respond on a weekly basis to testing feedback, bug reports, tweaks and requests. a pool of 5-10 users who can give us feedback, These Android and J2ME users should have diverse backgrounds and commuting habits. This feedback will be channeled via a ticketing and bug reporting system such as trac, which also links to your code repo.
10. With Sanjay's advice we will decide on a shared code repository and ticketing system where all code and app builds are pushed and noted. This could be svn, bzr or github. Right now we are using http://code.camputer.org/chaloBEST on bzr, we will explore trac and svn integration or move to github.