Apples and Nuts

15 days into the tracking, patching, testing, cussing loop from hell. Familiar whining this. It pretty much epitomizes the life of a hacker.

The iPod Touch remains in its original box, untouched, waiting for the next (Palm OS) release of ninerpad (will it? ever?).

But I like to peek. So I waded, again, through the iPhone SDK (hush hush Apple may be listening) docs. Things are becoming clearer.

But then, this very interesting post by Michael Ash. It helped put things back in perspective.

Yes, the iPhone oasis may beckon, but you may want to reconsider drinking from its pool. The process of getting an app on the iTunes store is not as simple as it is for Palm (mobireach, my cart provider, makes the process a google times simpler). But that's not the main issue for me. Learning has its curves, like many good things, so it can't be that bad.

No, my main beef is that Apple will not remit royalties to participating developers until their net reaches 250$. Granted, if your paid app is hugely popular, that may come fast and easy. But if it is not -- and that is the most likely (just do the math) scenario "for the rest of us" -- , it may take months before you see that first payment. Nice? Not.

But I'll try anyway. After all, nobody likes to miss a boat, any boat, no matter how small.

Still, just to keep things on an even keel, I think I'll stick around for a while with the Palm OS and with my friends at mobireach.

And now, back to our regular programming: cussing at Palm OS 5.

Palm developer vacation spot du jour: iPhone SDK

ninerpad 1.1R2 is out, at last. Time to take a short break and open that iPod Touch box...

Links of interest:

• iPhone GUI PSD will come in handy for UI mockups
  
• Hand Picked iPhone Application Development Resources

Ideas:

• ninersim...

Christmas in August

I bought an iPod Touch yesterday. I justified the purchase as a necessary investment in my career as a wannabe independent software developer.

At the same time, though, another voice spoke, much louder this time. It was the kid in me, and he said: "Cool. A new toy!"

The iPod Touch (iTouch) looks like an expensive toy. It's cute, and sleek, and eye candy jumps out at you as soon as you turn it on. How can one resist? And I thought to myself "Ah, Apple design..." And as I did, Venice came to mind; not the city as much as the feel of it; the way I would have said "Ah, Venice..." if I had been there (as I have).

One could say that there's a little bit of Venice in every Apple product.

Later, I skimmed through the developer documentation, trying to get my bearings and preparing the ground for my next -- and first iTouch -- project. By the time I was finished, my inner developer too was feeling the rush: "... so many cool APIs... so many possibilities... so much... nerd candy".

And no wonder today was a special day. Three significant fragments of my personality were in agreement, for once. Pleasure delayer that I am, I still haven't opened that box, though. It sits there in my bag, waiting for that moment when fragment #1 says "okay boys, let's open the presents and start coding".

I can't wait.

Shortcut #2317

About that ninerpad background color preference... It seemed like an easy-to-do feature request at first. People asked for a way to set note backgrounds to a color other than white and I was going to give it to them.

(this post courtesy of Palm OS 5's non-support of alpha channels by the way)

ninerpad works in 8 bit screen depth mode. This means that you only have 256 colors to play with, upside being that the drawings take a lot less room to store, and can thus be commensurately larger or numerous. Good for note taking, that.

Now, to store a drawing, I need to give every pixel a value. I mean, there is no such thing as a non-value. So, 4 months ago, at version 1 design time, the answer came easily: fill blank drawing data with zeroes, one for each pixel (compressed data actually, hence fewer bits, but that discussion is for later).

And therein it lies: zero happens to be the only index for the color "white" in the Palm system palette. No other color well in that palette gives us that.

So, if I want to let users draw in white over, say red, I have a problem. I can let them draw in color zero (white) over red, sure, but what about those other empty pixels then, those that they did not draw over and yet that need a storage value?

The answer lies at the bottom of the ninerpad's BG color selector (inside Preferences). You will notice that one of the color wells down there is also set to white. That well, #254, is a cheat. It was reconfigured from its default color, black, to white.

Now, when you draw in white, you are actually setting those pixels you draw over to hold color value 254, instead of 0. When I read back the data, I overlay non-zero-index data over the BG color and presto, you can now even draw in white over white, if that strikes you as shiny. The drawn data will still be there.

Somewhere a bug lies in ambush, waiting for that right moment. I know this. And when it does, it will likely appear as some kind of display glitch, i.e., something appears in white that should have been some other color.

ninerpad restores the system palette to its default values when it exits, so other apps are safe. But if some 3rd party application pops something up over ninerpad while the later is active, the bug may show its ugly (white) head.

Waiting for that day, and asking: must every shortcut come at a price?

Life Lesson #6247.5: On Fighting Reason

You've been sitting at your desk all day, consumed with the determination to release your product on time. The "good life" awaits and not a minute shall go to waste.

And then you realize that it's gotten dark outside and that the minutes of that other day that could have been have passed you by.

And you ask: is regret the bed partner of passion?

Feature Quandary #1

See, there's this feature that at least one ninerpad user -- that would be me -- would like to have right now. It would be useful for getting things done, that, since it would let me reorder my scribbled Palm notes.

I could code it in tomorrow. in time for the next release. Approximate cost: 20 minutes of my time, testing included.

But if I do this now, I also know that I will have to replace its current interface, a menu item, with another, completely different one -- dragging and dropping of image thumbnails -- at a later date, in a later version. And at that time, anyone using the original feature might grieve for its loss when it is in fact still available, but in another place. Hence, confusion.

So I decided to postpone introduction of the feature, at a possible detriment to my current user base, and definitely to myself.

And I ask: is it better to give something now and (appear to) take it away later than to not give at all?