Searching for data on devices with limited input capabilities, such as handheld mobile devices, has largely been ignored as the growth of such devices has soared. The accepted strategy for handhelds replicate the established concepts of index and lookup that are used on desktops. An assessment of this strategy shows the inefficiency of using the same strategies for handheld devices as used for desktops:
- Handhelds lack a universal input method. Some devices have joysticks and 12 keys while others have qwerty keyboards,
which could be physical or virtual touch screens.
- Is it really necessary to bind free flowing infinitely permutable text entry to the inherently finite nature of
searches?
- Traditional lookup is a regular expression match of patterns within the domain of data that the user is interested
in. Does this regular expression match really have to happen in real time while the search is in progress?
- Is it worth creating an interface that transgresses devices and appliances to present a uniform interface to the user
and ease the burden of new devices and learning curves?
- Is there really a need to innovate and disrupt existing technologies? Time and again the industry has shown that
disruption for the sake of ease of use and productivity is rewarded with success.
kannuu aims to create an interface that is easy to use and extremely efficient to incorporate within any native
application, web application or managed application. This shall empower developers to create applications that
transgress devices and operating systems and allow them to give their users a uniform interface for looking up
vast amounts of data.
kannuu addresses the above noted shortfalls in a few different ways:
- kannuu created a data structure from scratch that comes complete with accessors and an extreme prejudice towards
memory and processor cycle consumption. kannuu evaluated every byte of data being consumed and all the flows through
the data structure very minutely. The addiction to standard libraries comes with a price: they don’t always perform
cross platform with the same efficiency. As a consequence, quite a few standard libraries did not make the mark.
- kannuu optimized the indexing and consequent lookup algorithms to emphasize a balance of performance and resource
consumption as the two are usually at odds in the business of crunching and assimilating bytes.
- kannuu made sure that the stack was scalable to be able to address the range of embedded systems to fully redundant
N+M capable service.
- The last piece of the puzzle is the UI, which if it is standard across applications will vastly increase usability,
and hence uptake of the applications being developed.
- kannuu created—and are constantly creating—several new reference implementations of the UI. These provide developers
a template to build on top of current implementations, which include j2ME and JavaScript. kannuu is close to
releasing the iPhone SDK and reference implementation too.
Let’s look at the architecture of the kannuu lookup technology before discussing the individual modules.
Figure 1
refers to the three entities that constitute a complete indexing/lookup solution. It made sense to divide the
technology into three entities based on job function. As an example, an embedded device with no networking options
would have all three entities on the device. Alternatively, on a connected device the Index and Lookup Algorithm could
sit on the server and the UI, with a minimal footprint, would sit on the device.
 | |
|
Figure 1. kannuu Architecture: The kannuu architecture consists of three entities that can live separately or together based on the
indexing, lookup requirement. |
kannuu Index
The kannuu index is the data structure that is created from a list of items that needs to be indexed, e.g., a list of
songs, a catalog of books, or a directory of names and phone numbers. kannuu loves big lists, and the bigger the list
the better the lookup efficiency. The process of creating the Index is very straightforward with the index being
created in memory and then stored to text files. Let's start by writing a functional test file called
kannuu.c.
(see
Listing 1).
To summarize the steps in the createIndex function above:
- Validate your license key.
- Set your UTF8 locale. UTF8 is the encoding of choice@kannuu.
- Initialize the variables on the stack.
- Initialize the File and Memory Index constructors. You need both because you need the memory index to build the
index in memory and you need the file index to write the memory index in its own binary format to a filesystem.
- Iteratively add Items to the memory Index.
- Initialize the Abstract Index constructor and assign the memory Index as an initializer.
- Write the abstract index to file.
kannuu Algorithm
The lookup process is equally simple and has accessor functions built-in to allow you to call them from button event handlers. The following piece assumes that you know something about the trigger-events-handler model of design so prevalent in GUI-based applications.
Obviously, this is not the only model of design that is available (see
Figure 2), but for simplicity this is the design discussed
and hopefully gives you enough insight to extrapolate and be creative in the uses of this technology.
 | |
|
Figure 2. kannuu UI prototype: Usability studies have shown that having four options are a good number of options for the user to digest in one
pass. |
You should have five event handlers that are triggered when one of the five buttons is pressed
(see
Listing 2).
There are many
frameworks that you could use for this model, so the specifics of how the triggering occurs won’t be discussed.
The steps taken above are:
- Initialize the globals on the stack so that they are accessible asynchronously. The options array contains the
options to be painted on the screen on every step of the lookup. The data array would be populated with the final
data to be used for executing some action, e.g., play music at the end of the lookup cycle.
- Initialize the lookup process and paint the first four options on the screen.
- On each button press, call an eventhandler that calls the lookupSelectOption and paint the screen with the
results of the next set of options. If the lookup is complete, then handle the data populated in the data array.
That summarizes the use of kannuu as a lookup mechanism on any device that supports native ANSI/ISO C.
In case the device is thin and cannot support the cycles required to crunch data, the Index and Algorithm can
live on the server side, and the client can be a SOAP/XML, JSON parser that simply reads data remotely to present
the lookup. The details of these modules can be found on the kannuu Developer Network (kDN).