May 7, 2008

openWIG status report

In short: the fun is over, now begins the hard work.

In longer...
Version 0.2.6, released some two weeks ago, doesn't have it all, but it has most of it: rather reliable zone detection and navigation, support for all basic Wherigo constructs (including Timers) and their events, images (preloaded in the jar file), PlayAnywhere features...

There are still quite a few loose ends in the Lua library, and i'm looking forward to tying them up. But unfortunately, there is a number of things whose priority is much higher.

One, navigation screen.
What we have now is something along the lines of "239,2m northwest". Which is nice, but not really precise. What we need is a graphical display with an arrow pointing towards the destination. Perhaps with some additional info - distance, target/current coordinates, speed, signal strength...
HandyGeocaching has it all, and i'll probably borrow most of the code. But to be honest, i dread the moment when i'll have to open the HG project again. Don't get me wrong, there's nothing with the code ... it's just that it's a Netbeans 5.5 project with visual designers, and it really really dislikes Netbeans 6. Or vice versa. Anyway, it's so ugly it's not even funny.
I'm actually thinking of writing my own navi display from scratch, just to avoid this :e/

Two, preferences and persistence.
This is where it starts to get funny - the midlet reached a level of complexity where some kind of preferences screen is necessary.

  • GPS mode - Manual, Bluetooth, Built-in, Serial port.

    The latter two are not done and i'll again have to dive into HG to fetch them. But that doesn't matter, bluetooth alone is enough fun. Last connection info should be persistent. And Manual mode has a few differences of its own.

  • Navi screen refresh intervals.

    Turns out that some phones of a certain vendor who shall remain nameless (cough cough Nokia cough) (and possibly some others, but that is yet to be seen) take a screen update as an instruction to scroll up. Which is all fun and games until somebody loses an eye, i mean, until you notice that the navigation info is on the bottom. And since the refresh interval is 1 second (synchronized to game engine ticks and presumed GPS ticks), unlucky owners of the affected phones can't really see the navi info.

    If the screen was to refresh at, say, 10 seconds, their direction would not be so precise, but at least it would be readable.

  • Last opened cartridge, information about cartridge directory, logs directory etc.

    All those things that suddenly appear when you load and save files to the filesystem.

Which brings us to...
Three, filesystem access.
Yesterday I checked in a class that can load things from gwc cartridge. It is useful by itself, no doubt about that - at least it will enable people to save their cartridges into the jar without any external tools (apart from a zip, obviously, but everyone has zip today). But to make it really interesting, you have to be able to open things from a memory card.
That means filesystem classes plus browser gui plus persistence (see above) and a whole lot of other minor changes. Such as...

Four, brand new main-screen UI.
Because the current one doesn't really expect to have more than one cartridge. We need file browser (see above), cartridge selector with preview (splash screen, description etc.), Preferences screen (see above) and ability to close cartridge and open a new one.

And the best part is that this all needs to be done in one step, otherwise it won't make any sense.
Well, the navi screen i can release separately. But now i have gwc reading, not navigation. And gwc reading doesn't make sense without filesystem. Et cetera et cetera.


misch said...

Do you really plan to add support for GPS connected via serial conection? It would be nice.

Idea of 60CSx in one hand and mobile in other, both connected by cable, may look strange, but it would be absolutely great (and funny)!

matejcik said...

i'm not sure that would work .e) (of course, if it works in HG, it would work in openWIG)

but serial connection is important for PDAs, because their java VMs often don't support bluetooth api and need to use virtual serial ports

misch said...

I have tried GPS midlets "TrekBuddy" ( and "GPS Track" (, with source code). Both of them work. Or, at least, they try to connect to "com0" and my phone then asks me if I want to allow them access to data cable ...

Which reminds me that I have to take Siemens connector from old handsfree, solder some resistors to it, and test if it will be really possible to connect my old phone to GPS.

misch said...

Tak to opravdu funguje: mobil spojeny pres seriovy port s GPSkou, a komunikujici s midletem.

Koukal jsem se jak to "GPS Track" resi, a zda se to uplne jednoduche -- cela ta seriova komunikace je stejna jako u bluetooth, jen s tim rozdilem ze na zacatku se nemusi pracne hledat zarizeni a zjistovat co ktere z nich umi, ale misto toho se nejakou systemovou fci proste nacte seznam COM portu. Vsechno ostatni se zda byt stejne.

Wherigo se 60CSx a CX65, to bude narez!

BTW: te baterky na obrazku si nevsimej, doufam ze se mi ji v "ostre verzi" kabelu podari zbavit, jinak by kazila dojem :)