openWIG status report

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

In longer...
Well.
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.