I suppose it was bound to happen eventually. Let me first say that I already knew about the Market hack where users can "buy" your app, then request to cancel within 24 hours for free - but they've already gotten the download! I protect my apps by requiring a registration key even on my paid apps in the Market.

But what I didn't know was, as the late Paul Harvey would have said, the rest of the story. If your paid app is less than $10 the user can request a chargeback which will be automatically approved by the Market - at a $3 expense to the developer!

This is a crazy policy for Google to have. I suppose the upshot of this is that my next app, WordBox, will have to be on sale for $10.01 in order to avoid the automatic approval of the chargeback. If I get a couple more chargebacks on my $0.99 apps I will simply pull them from the market - I have to sell 5 for every chargeback just to break even!

Sitting here with Melanie and waiting for the kids to get done at the state fair, so I thought I'd try blogging from my G-Phone. Last night I started on my port of WordBox to Android. I should have it mostly working in another day or two except for the solve function. My PalmOS version can solve in a couple of seconds but the android version takes minutes. Haven't figured that one out yet.

My brother Kevin is trying to get into WebOS coding for the Palm Pre but so far it has been slow going. He wants to port some of my android apps to that platform but the developer tools for WebOS just don't seem as mature as those for the android.

After the first full day of my first three Android apps being on the Market, here are the stats (Trial versions):

• Firefly - 151 downloads, 86 installs still active
• Foggle - 169 downloads, 66 installs still active
• Taxi Run - 698 downloads, 413 installs still active

While working on Foggle, I came across an interesting but frustrating problem. Google searches turned up some other coders with the same problem, but no real concrete solution. The problem was having a view that wanted to respond to gestures, but was itself contained inside a ScrollView. The ScrollView like to "eat" the gestures, as it turns out. After much trial-and-error, the solution I came up with that worked for me was to extend ScrollView so I could catch it eating the gestures, and then pass them through to my child view under some circumstance. My simple ScrollView class is below (FoggleBrowser is the child vie, and in my case is always the child of this FoggleScroller class):

package twinfeats.foggle;

import android.content.Context;

import android.util.AttributeSet;

import android.view.MotionEvent;

import android.widget.ScrollView;

public class FoggleScroller extends ScrollView {

public FoggleScroller(Context context) {

super(context);

}

public FoggleScroller(Context context, AttributeSet attrs) {

super(context, attrs);

}

public FoggleScroller(Context context, AttributeSet attrs, int defStyle) {

super(context, attrs, defStyle);

}

@Override

public boolean onInterceptTouchEvent(MotionEvent ev) {

boolean rc = super.onInterceptTouchEvent(ev);

if (rc) {

FoggleBrowser b = (FoggleBrowser)getChildAt(0);

b.onTouchEvent(ev);

}

return rc;

}

@Override

public boolean onTouchEvent(MotionEvent ev) {

boolean rc = super.onTouchEvent(ev);

if (!rc) {

FoggleBrowser b = (FoggleBrowser)getChildAt(0);

b.onTouchEvent(ev);

}

return rc;

}

}

About 6 weeks ago I found out about the Google Android Developer Challenge 2. I had read about the first version of the contest about a month after it had ended, and could have kicked myself for not finding out about it in time to enter. So with just 6 weeks notice I told myself I could not let this one pass me by.

Melanie had been wanting me to do a SET-like game for a while, so we settled on trying that first. After finding out about the first content I had already downloaded the SDK and played around a little, but I had a lot to learn. The game we came up with is called Firefly and uses the attributes of color, orientation, and blink rate as the aspects you have to find the same or different, much like in SET.

Firefly took about 3 weeks with all the learning I had to undertake, but once I got it 95% where it needed to be I decided I had time to try another one for the contest. I had always wanted to do a game loosely based on the arcade classic Locomotion (and as evidenced on my Palm software page started but never finished for PalmOS) so that's what I decided to tackle next. My Firefly experience really helped save some time and I got Taxi Run knocked out in 2 weeks. That left me 1 more week before the contest deadline.

Being foolishly optimistic I decided I could crank out a third contest app in a week. I was originally going to do a game similar to Rebound and got started on the physics engine for it. Melanie, however, had other ideas. She came up with a greatly simplified version of a concept for the iPhone we had been kicking around for months. This simpler concept was for simulating drawing on fogged glass - you could blow into the phone's microphone to "fog" up your screen, then draw with your finger. I came up with the name Foggle and started working furiously - and got done over this past weekend.

So all-in-all that leaves me today until about 2:00 am to put on the final touches and get these 3 apps packaged up and uploaded to the contest. It would be way cool to win any of the prizes, but in the end we all love playing the apps I've come up with so that's enough. And of course there is always the Android Market to sell them.

I've started working on my first iPhone application - the lure of the "big money" to be made in the AppStore is just too much to resist. Or something like that.

After reading through the docs and looking at some sample apps, I dove in. Within about 20 minutes I was time-warped back to about 1997, back to when I started doing PalmOS development. The docs sucked, were often misleading or flat wrong, and stuff just didn't work like it should. Deja vu. As I have admitted for years, working in Java has spoiled me to systems in which I have to do my own memory management, like the iPhone. Now doing my own memory management  I can handle, but I've already wasted hours trying to figure out bugs in which adding a copy to the right spot magically fixed the problem.

For you coders out there, here's a little treat:

NSInteger sorter(id s1, id s2, void *context)
{
NSString* v1=(NSString*)s1; 
NSString* v2=(NSString*)s2; 
return [v1 compare:v2];
}
 
- (void)createPicker
{
animationNames = [[[[NSBundle mainBundle] pathsForResourcesOfType:NULL inDirectory:@"animations"] sortedArrayUsingFunction:sorter context:NULL] copy];
CGRect rect = CGRectMake(0.0, 0.0, 320.0, 240.0);
UIPickerView *myPickerView = [[UIPickerView alloc] initWithFrame:rect];
myPickerView.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;

myPickerView.delegate = self;
myPickerView.showsSelectionIndicator = YES; // note this is default to NO

// add this picker to our view controller, initially hidden
[window addSubview:myPickerView];
[myPickerView release];
}

Notice the copy at the end of the first line of createPicker. Without that, the app bombs. In the debugger, animationNames is fine, but by the time the picker delegate gets invoked it's not if I remove that copy. I still don't get that one, and the other two very much like it, although I'm sure it's something incredibly simple and obvious to someone in the iPhone know.