IS480 Team wiki: 2012T2 Viaxeiros Final

From IS480
Revision as of 16:49, 15 April 2013 by Lin.siew.2010 (talk | contribs) ()
Jump to navigation Jump to search
Viaxerios Logov1.png
Welcome to Viaxeiros FYP Wiki Page
Navigation 8.png

Final Term Slides

Coming Soon!

Project Progress Summary

Statistics of our project:

We have altogether:
  • 12 iterations,
  • 3 usability testing and
  • 3 major deployment.

Changes since Midterm

Based on the feedbacks gained from the midterms as well as the user testing, our team has implemented the following changes:
  1. Introduction of Guest Account
  2. Usage of vector offline map (Mapsforge) instead of Raster offline map (OSMDroid)
Project Highlights
Iteration Descriptions / Highlight
4 Increasing Scope to be Done

After the discussions we had with the sponsor, we have decided to implement a few changes in the project scope to provide a more holistic experience of the application. Hence, as mentioned in midterm, more native pages are introduced in the application, which majorly affected the project schedule.
In view of this change, our team has decided to drop one of our additional functionality to better concentrate on the additional functions to be done.

10 Introduction of Guest Function and Change in Offline Map

From the feedbacks received from the midterm presentation and the user testing, our team decided to add in a Guest function to allow users to try out the functions without the need to login. Additionally, many entry points are included to allow users to login.
Furthermore, our team changes our offline map library used to Mapsforge, a library which supports vector maps. The actual map file will be stored within Qiito server, where it can be retrieved when users download their travelogue.
To cater to this, our team decided to drop our additional functionality and instead focus on the new changes.

Project Challenges
Challenge Description
Implementing workable Offline Map
  1. Difficulty getting documentation for OSMDroid
  2. Change from OSMDroid to Mapsforge
  3. Directly changing Mapsforge
  4. Understanding the rendering of maps in Mapsforge
  5. Integrate 2 versions of Mapsforge
Out of Memory Error
  1. Small phone memory causes significant out of memory error
  2. Different phone model has different assigned phone memory and procedures for phone memory release, resulting in differing debugging results
  3. Manage to use lazy loading and other more efficient codes to mitigate the problem
Project Achievements
Achievements Description
1. Customizing of Offline Map Features

Why is it so successful?
There are many ups and downs when implementing the offline map. Our team started off with using OSMDroid as we believe that it will be easy to adopt. However, realizing the limitations in term of functions the library has, we decided to switch to offline vector map Mapsforge which turns out to be more flexible than OSMDroid.
In order to integrate with our SherlockActionBar Library and the manipulation of customized pins in the offine map, it is necessary for us to customize the library directly, which is a great feat for us due to the limited time and expertise in creating a library. Hence, it is a great achievement for us when this implementation is successful ultimately.

2. Implementation of full native application compatible for Android 2.3 and above

Why is it so successful?
The client's requirement for the application is for it to be compatible for Android 2.3 and above. This prove to be a challenging request as many functions and look and feel do not support Android 2.3. Thus, with the usage of SherlockActionBar library, we have managed to provide a standardize outlook throughout the different versions. Additionally, we also learnt and manage to provide support for different phone models, as the display of our application might be skewed due to the different phone size.

Project Management

Project Schedule
Bug Metric
Schedule Metric
Work Stress Metric
Click here for more details on the metrics.
Change Request Log
The purpose of the change request log is to track the change requests of all our clients and users. This will enable us to better manage our project scope and hence aid in scheduling for upcoming iterations. This is a snippet of how the log looks like:

Change request.jpg

Each of the change requests are logged in the change request log first. After which, as a team, we will evaluate and decide if the change should be implemented.
  • Functional Description : provide more information on change request
  • Proposed Decision : Our team's decision if the change is implemented
  • Remarks : provide more information on our rationale in our decision

Click here to view the logs.

Technical Complexity
Complex Feature Description
1. Offline Vector Map (Mapsforge)

Purpose of feature

  • To display and render offline map when users download a travelogue
  • To display pins and navigation to other applications via the map

Complexity of Feature

  • Direct customization of the library source code
  • Changing library source code to fit Sherlock Fragment
  • Integrating 2 versions of source code into 1
  • Find and retrieve the right file type to be downloaded
  • Limited documentation available in the internet

For more information on the complexity of this feature, please view here

2. SherlockActionBar Library

Purpose of the Feature

  • Provide standard view for phone versions 2.3 and above
  • Customize action bar to suit Qiito's business concept

Complexity of Feature

  • Integrate Fragments to Online (Google Map) and Offline Map (Mapsforge) Library
  • Standardization of outlook in each fragment

Product Quality

Project Deliverables
Stage Specification Module
Project Management Minutes
Requirements Change Request Log
Story Board
Analysis Use Case
Design System Architecture
Database Diagram
Testing Usability Test
Handover Documentation
  • Comments of codes
  • Documents on setting up Eclipse
  • Procedure to deploy in Google Play
Quality Attribute Description

1. Improvement in performance in terms of loading speed and minimal crashes

  • Implementation of GZip and Lazy Loading
  • Removal of excess or redundant resources used by clearing bitmap images

2. Improvement in User navigation and look and feel

  • Include guides for users when they first install the application
  • Introduce the guest account to allow users to try out more functions before logging in as users
Qiito has 3 servers used: one for development, another to simulate real data usage, and the live server used for their users.
The compiled apk package is then uploaded into Google Play, where any users can access to this.

  • Deployment Version : v3.0
  • Development Environment : Deployed in Android Google Play Store
  • Database : Used the phone's internal database, SQLite, Qiito Database (via API)
  • Coding Language : Java and XML

Click here to download our latest application version!
Download the application here.

For this project, we have done a total 3 user tests. The first 2 caters more towards testing the functionality of the application, while the last user testing is geared more towards the user experience and interface of the application


Team Reflection
Individual Reflection