Difference between revisions of "IS480 Team wiki: 2012T2 Viaxeiros Application Development"

From IS480
Jump to navigation Jump to search
Line 144: Line 144:
| [[https://github.com/JakeWharton/ActionBarSherlock/blob/master/samples/fragments/src/com/actionbarsherlock/sample/fragments/FragmentCustomAnimationSupport.java Fragments]]
| [[https://github.com/JakeWharton/ActionBarSherlock/blob/master/samples/fragments/src/com/actionbarsherlock/sample/fragments/FragmentCustomAnimationSupport.java Fragments]]
| Library that provides multiple interfaces within an Activity.
| [[http://code.google.com/p/osmdroid/ OSMDroid]]
| [[http://code.google.com/p/osmdroid/ OSMDroid]]

Revision as of 22:33, 31 January 2013

Viaxerios Logo.jpg

Welcome to Viaxeiros FYP Wiki Page

Navigation 3.png
User Requirements Analysis

Survey 1

You can find the questions to our survey here
A summary review of the survey could be found here
Summary findings (Charts) could be found here

Feedback (Google Deployment)

Watch out for this space

User Testing

You can find our Test Plan here.

Here are our User Testing results:


You can find our Storyboard here: Version 1

Technical Complexity

1. ActionBarSherlock

An Action Bar is a bar at the top of the screen which is used across the application to identify the application brand and to support navigation. As Action Bar is not available for pre-honeycomb Android devices, we decided to make use of the ActionBarSherlock library, an open-sourced library designed to facilitate the implementation of Action Bar natively across all versions of Android devices using a single API. This library also provides additional features such as Fragments which is currently not present in the standard ActionBar mode.

2. Fragments

To integrate with the Sherlock Action Bar used as a header bar, fragments are used to allow multiple interfaces within a single activity. This allows a better manipulation of functions when users navigate through the application. For example, the navigation between a web view and a native view with differing interface will only require two different fragments, instead of creating a new activity. In addition, due to the flexibility of fragments, each of them can be recycled and used in other activities within the application, reducing the need for repeated codes.

3. Image Loading

To speed up the display of pages and improve user experience, we have made use of “lazy loading” to enable the display of native pages (template) first while images are downloaded and displayed on the pages as and when they are ready. We have been able to do so with the use of the “Asynchronous” feature available in Android development.

4. URL Tracking

The android application that we are building for Qiito is a mixture of Qiito’s current mobile web and pure native pages. Some of the native pages include travelogue listing, travelogues and places. To enable switching between mobile web and native pages, there is a need to monitor the changes in URL. Should a following URL point to a webpage that requires native display, example travelogue listing, travelogues or places, there will be a need to call the native codes for display. Else, the mobile web should be called instead.

5. Different phone models with different OS versions

Since the Android software is offered on many different phone models, our team needs to cater for different image sizes to these phones. This is because phones tend to vary in size, features and user experience. Thus, this further complicates the native design process as additional time is required in resizing images and there is difficulty in ensuring consistency of the application for the rest of the other models. Additional testing is required as different sizes of phone models are tested to ensure that the images are displayed correctly.
Furthermore, older Android OS, which may not be able to support the newer OS, will not have the luxury to enjoy certain functionalities. Thus, extra time is needed to search for the best implementations without reducing usability of the application.

6. Offline Map Display (Pending)

Whilst overseas, users may have difficulty obtaining data connectivity to have access to the full functionalities of Google Maps. With the implementation of OSMDroid (Open Street Map Droid), the application will cache a specific map area pertaining to the user’s itinerary. This allows users to view the touring area on the offline map, complete with zooming features and search function of that particular area. Being an open-sourced package increases the difficulty of implementation, due to lack of proper documentation to explore customized functions. There are also certain restriction of its usage due to it being free, thus algorithms for download are required to be stricter.

7. QBeam – Augmented Reality View (Pending)

Even as locals, users may be surprised to discover unknown places of interest around their town. This is where QBeam comes in to help with the discovery, by displaying places of interests surrounding the user’s current location. This will be viewed through the lens of the phone camera, complete with the direction and distance away from the user. The team will be looking into exploring the Vuforia and Wikitude SDKs for Android in later iterations to deploy the Augmented Reality View function.


Below are the tools are resources our team is currently employing during this project:

[Eclipse IDE For Mobile Developers] Our trusty IDE that provides our coding environment!
[Subclipse] Subclipse is an Eclipse Team Provider plug-in providing support for Subversion within the Eclipse IDE.
[Android SDK Package] Providing the API libraries and developer tools necessary to build, test, and debug apps for our application.
[ActionBarSherlock] This library supports the use of ActionBar across all versions of Android using a single API.
[Fragments] Library that provides multiple interfaces within an Activity.
[OSMDroid] Map library we are exploring and deploying for our offline map viewing functionality.