IKANGAI Solutions. e.u.

Mobile Business Solutions

T F G+ E

Posts Tagged ‘Android’

Android on the Rise

January 16th, 2013 by Martin No Comments

Our friends from MBA Online provided us with an interesting info graphic on Android that we would like to share with you.

Android

m°°Di – Your mini Status Update App

October 7th, 2012 by Martin No Comments

m°°Di is spreading around the world :-) . As you can see on the infographic below, we have downloads in more than 20 countries since m°°Di became available in the iTunes Store exactly one month ago.

We plan to make an Android version of m°°Di and for this endeavour we simply need funding. So, if you know people that are interested in funding m°°Di, just let us know :-) . In the meantime you can download m°°Di for free and tell your friends about m°°Di: the more people m°°Di use, the more fun it is (and the

your m°°Di ikangai team

Observations

June 1st, 2011 by Martin No Comments

I recently read a book on immersion called The art of Immersion by Frank Rose. It’s a good book and it’s entertaining. In a nutshell, it describes the changes that hit the “content industry” (film studios, publishers and – related to it – advertising) when the Internet emerged as a global communication means. It discusses some of the attempts to include “the Internet” in the way how stories are told in movies and books and how some companies tried to involve fans for commercial purposes.
It is no surprise, however, that the industry at first struggled (and some companies sill do) to understand phenomena like fan-movies, web sites dedicated to a TV series and so on. After all, they wanted to control “their product” which they sold to their customers. This is easy to understand from a purely commercial point of view: if you own something, you can easily sell it. But this has changed: (some) customers just do not want to be told how and what to consume. They want a different experience and are not passive consumers anymore. They want to be immersed into stories by actively participating and thus changing them. They desire influence and control over the content they are confronted with.
Similar things can be observed – on a different level of “immersion” – with users of mobile phones: some just want to have complete control over their device and to do whatever they please. But it seems that carriers have something against this: they lock the devices and provide pre-installed software (and no way of changing this). Especially on Android, it’s common to have a carrier-customized phone. While this is understandable from a commercial perspective (is it really?), lots of power users are frustrated: they bought a device for several hundreds of Euros and – by making an analogy to cars – cannot even open the hood to take a look “inside” or remove some of the pre-installed software. It’s a matter of control (and money): a carrier has contracts with software companies and the latter pay to have their software installed on the devices of the users. Having software on a device that you own which you don’t want strikes me as strange: after all you don’t go into a supermarket, pay for milk and get tea instead.
Filmmakers have begun to understand that you have to give up control to have something of real value for the people to like. I think that this is something carriers need to learn: let the user have (full) access to their phones and thus give them something they want. Obviously, this is not suited for every user, but eventually it will create satisfied customers and isn’t this what carriers want?

your ikangai team

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 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 – 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