IKANGAI Solutions. e.u.

Mobile Business Solutions

Posts Tagged ‘Project Tokyo’

Project Tokyo – Q·.:Launcher Videos

January 20th, 2011 by ASE.project No Comments

We, the developer team of project Tokyo, are happy to present the first video of the q.:launcher App for android devices. As shown in the video, we have implemented all requirements of the Apps and hope that this App makes your live a little bit easier. And as you can see, its running smoothly on Android devices and looks just as good as the iPhone App does.

q·.:launcher is our second Android App. The first one, q·.:card, went to release candidate status a few days ago. However, we are not completely satisfied yet, there are still things for us to work on both Apps. This includes fine tuning the performance where ever we can, improving the User Interface to maximize the usability for users and of course lots of testing to ensure correct behavior of the Apps. So far, everyone who tried the Apps was amazed. This gives us motivation boost to make the Apps as good as possible.

We also will work on a presentation of q.:card and q.:launcher at the Ase Day 2011 with a live demonstration of the Apps. This is an excellent opportunity for us to get feedback of an audience full of students and potential customers .

cheers,

Stefan R., Project Tokyo Team

Project Tokyo – Approaching the Finish Line

January 6th, 2011 by Martin No Comments

Project Tokyo is approaching the finish line. Release candidate 1 of q·.:Card is expected to be finished by end of January, just like q·.:Launcher. We’ve postponed the registry feature of q·.:Launcher for a later release in March. We plan to include the registry features into iPhone implementation of q·.:Launcher as well and to update the iPhone version of q·.:Launcher simultaneously.
The Project Tokyo Student development Team did a good job so far – especially since they spent less time than originally calculated. This is certainly highly unusual for projects in the Application development domain. Typically, it’s the other way round. The efforts are underestimated and all takes longer than originally planned.

Project Tokyo Gantt Chart

A lesson that we learned during the project that we obviously need to state our requirements in more detail to prevent misunderstandings. This might sound like a no-brainer, but is rather difficult in reality. Things that we took for granted, because they seemed clear to us, were not clear for our Students.
One example is the use of Twitter for team collaboration. We explicitly stated as a requirement that Twitter should be used for the team communication. During the project, we observed that Twitter was used mainly to communicate with us, but only used occasionally for team-intern collaboration. Thus, we could not monitor how the team worked together, since we were not able to track who did what with who on Twitter. Instead, the students decided to use traditional means like spreadsheets to track their activities. One reason is obviously the lack of tool support: the students needed to report their activities to the INSO group and it seemed more convenient for them to use a spreadsheet tool to log their activities. Another reason was that the students saw in Twitter additional communication overhead and did not think of the Twitter experiment as opportunity to try new things.
One one hand, this is absolutely understandably – better on the safe (conservative?) side and get things done – but on the other hand, a very interesting opportunity to safely try new things for team collaboration has been missed. For example, a very simple communication primitive could have been something like this:

#ase_2010_ 11 @ikangai #workedWith @triggerty on #qcard #parser #duration: 2 hours #activiyList http://bit.ly/cuYoiN
#ase_2010_ 11 @ikangai #meetingWith @triggerty @wokung #duration: 2 hours #protocol http://bit.ly/cuYoiN

This would have provided us with team insights which are now not available for us.
For the next project, we will explicitly state that the student project team needs to come up with Twitter collaboration primitives that reflect their activities. Or put differently: we will explicitly state that they need to be creative and that they must be brave and use their freedom to do some thinking outside the box .

your ikangai team

Project Tokyo QRCode Scanner

December 16th, 2010 by ASE.project No Comments

Time to talk a little bit about the QrCode Scanner implementation for the q·:card and q·:launcher application. The goal was to achieve a continuous scanning process for reading in a QR-code into our applications. Our first approach was to capture screenshots of the entire screen every n milliseconds and to handle the encoding in multiple threads. Since almost every modern android smartphone has an autofocus camera feature, we follow this approach in our scanner. The benefit is the enhanced decoding time: if we feed the decoder with sharp images, it will take less time to extract the QR-code information.

So let us take a look at how this is done: Here you can see a diagram which shows the message passing flow between some components of the QR-code-scanner. AF stands for “autofocus” and PF stands for “preview frame”. Requesting a preview frame means that we simply want to take a screenshot of the entire screen now. So after starting the scanning process, we are calling for an autofocus. When this is done, our AF callback comes into play which passes along a message with the intention to get a preview frame of the (sharp) image. Then the next autofocus request is fired. The Previewframe Callback sends a message to the so-called DecodeHandler which runs in a seperate thread, the DecodeThread, which is implemented as a “piped thread”. That means that the thread offers a “Looper” which runs a message loop for the thread.

In this way, we get a continuous scan until a QR-code is found. When a QR-code has been found by the decoder, all messages will be cleared from the queue, which leads us to the end of the scanning progress.

Actually, this approach works very fine and quick. Nevertheless, optimizations are possible in several areas. For example, we could also request screenshots when there is no sharp image representation in in the hope of getting a sufficient image quality of the QR-code to decode it.

cheers,
Bernd, Project Tokyo Team

Project Tokyo status report

November 4th, 2010 by ASE.project No Comments

Hi,

We, the Project Tokyo developers, would like to provide a brief project status report:

Project management:

The sprint planning has been done according to the guidelines provided by the ASE course administration. Releases (=milestones) have been added to the pivotaltracker project whereas the releases including their deadlines specified by ikangai solutions have been mostly respected but adjusted where necessary. We believe that we will manage to fully implement the feature bundle “remote registry backend” which was marked as an optional feature by ikangai within the given time frame. In contrast, we believe that the feature bundle “registry frontend” which has been specified by ikangai in the Google Doc “Activities ASE” was not agreed on in the initial meetings (at least this was completely new to Bernd and me as we read the document). Also, the sprint schedule suggested by pivotaltracker proves that this feature bundle would not fit into our time frame. For this reason, we would suggest moving this feature bundle to after the ASE project has been finished (Yes, the team will continue to work on Project Tokyo even after the ASE course has ended).

Documentation:

Project definitions for the project Tokyo in general as well as for the two sub projects q-card and q-launcher have been created; the test plan has been started; the Gantt chart has been created; time sheets have been updated. Next steps will be finishing the test document as well as creating the domain model, design document, software architecture and non-functional requirements.

Implementation:

As of now, the q-framework features generators for q·.:card, vCard and meCard. The q·.:card application features a mockup screen which attempts to comply with the actual design specification for the application and shows a QR-code actually generated by the q-framework. Next steps will be the implementation of parsers for q·.:card, vCard and meCard formats as well as the implementation of the QR-code scanner. Also, the q·.:launcher project will be set up and some further investigation concerning Intents, starting apps and passing data on to them will be made.

Testing:

Testing has not actively been done as of yet. Next steps will be testing the q-framework’s generators as well as setting up the test suite and lay the foundation for a , e.g. JUnit tests as well as tests according to the Android test best practices.

Feedback:

As we got some constructive critique from the customer, ikangai solutions, we would also like to provide constructive critique to them so they can improve the collaboration on their end as well:
We have asked ikangai several questions which would have required ikangai’s answers in the past weeks, especially concerning the architecture and design of the q·.:launcher application as well as the remote registry and most of them have as of yet been unanswered. We would appreciate if ikangai solutions would face this project with the same professionality and reliability they demand from us developers whereas we are well aware that this has to be improved on both sides. We are already setting a trend to act more professional and and reliable and would appreciate to see that trend continue on the customer’s end.

Cheers,
Stefan A.

Project Tokyo – ikangai’s perspective as a customer

November 2nd, 2010 by Martin No Comments

Project Tokyo enters its third week and there are some aspects that work quite well, while some others require improvements.

First of all, Twitter communication works very well. It appears that all project members are using Twitter for the exchange of project related communication which allows us to track project related activities.

The overall project documentation is still work in progress – there are some parts that are currently missing or are incomplete (Gantt charts, working lists, overall project plan with milestones). So far, it’s difficult to tell, by looking at the documentation, if the project is on track or lagging behind. Twitter alone does not provide us with the needed information. We believe that a biweekly executive summary (half a page, hours spent, hours left, next milestone) of the activities can us give the information that is needed for us to track the overall project progress.

On a positive note, all project members appear to be able to make their own decisions on a technical level and to have the required technical expertise. However, there are some areas which can be improved. For example, if there are several ways to solve a technical problem, we from ikangai would expect to have a list of pro/cons for each potential solution. Thus, we expect to the team members to work on their own on the problem and to provide potential solutions, which can be discussed with ikangai in order to make a final decision.

All in all, after roughly two weeks of project work, we realize that the project setting (students being paid by ikangai and getting credits from university) requires some additional effort: we need to communicate our requirements and expectations clearer and the project communication between all parties needs to be professionalized – with updated project documentation from all parties.

After all, we invest considerable time and money (at least for startup like ikangai) into this project (which started out of interest) and we want it to be successful .

We currently rate the project on our projectometer as B-.

your ikangai project tokyo team

PS: The projectometer is rating tool which is updated every two weeks and provides a rating (A to F) concerning the project progress and the level of satisfaction from the customer’s perspective.

Project Tokyo – q·.:framework encoder class diagram

November 1st, 2010 by ASE.project 1 Comment

The encoder package of the q·.:framework is handles the generation of the different contact card formats (vCard q·.:Card, meCard) and the encoding of contact information into a QR Code. We’ve finished a first version of the implementation for generating and encoding of the meCard and q·.:card formats (see classdiagram for an overview encoder package).

Transformer classes are responsible for translating the raw user information data into a format-specific format. Currently, we support there are three kinds of formats, each implemented by as separate Transformer class, derived from a generalized Transformer class (which is useful for factory patterns). All Transformers implement the IDataTransformer interface.
The Transformers return an instance of the Encoder class, which is a pixel based representation of the encoded contact information. The pixelmap is in turn used to draw the 2d QR-Code image on the screen.

The TransformationModule Class acts as the “glue” between the Transformer implementations and the Encoder. It works with dependency injection by making use of the lightweight google guice framework. Future extensions with a new format, require this class to “register” the new format.

The Transformer classes interacts with Bean Objects, containing user specific data, which are collected by the q·.:card android app (as shown here). The attributes may change in future because of new user requirements. Thus, it is possible to tell the q·.:framework which attributes are required, and which are not. Required attributes must have a value, otherwise an exception will be thrown by the framework. For this purpose the q·.:framework provides a special marker annotation called Required. Consequently, each field in a Bean which has the @Required annotation, must have a value! To check this, there is a method called validate() in the CardFormat class which works with reflection and takes a look at the various fields of the bean. :) nice, eh?!?

This was a quick overview of the Encoder part of the q·.:framework. In one of the next posts we will take a look at the Decoding part of the framework which will play the game in reversed direction. Parsing and decoding of scanned QR-Codes .

bernd, member of the project tokyo team