App-A-Week Challenge: Week 4

Another week, another app! Here’s the one I’ve been working on for a few weeks now. I finally got it all nailed down and it got approved by Apple!

It’s called BrewTime and you can get it right here! Let’s take a look-see:

What did we learn about for this app? UITableViews, NSTimers, UILocalNotifications, etc.

Dear Diary…

…today I made a little thing that detects pitch using the zero-crossing method. I still have to nail down a few things but I’ll post the code when I’m done. Also, I should test it with actual instruments.

Also, dealing with Audio Units is a major pain in the ass. That is all. Love, Jeff.

AVCaptureSession + vImageBoxConvolve_ARGB8888 = FUN;

Hey kids, just a small update today. Here’s what I’ve been playing with:

It’s an iPhone app for devices running iOS 5+ that takes video frames from the front camera and performs a vImageBoxConvolve twice to simulate a gaussian blur. It does this in realtime (well, ~15fps) and the slider sets the blur radius. The code to do this is remarkably small:

You can download and play with the Xcode 4.3 project here. The normal warnings of: this is not production code, it’s not pretty, at least it doesn’t crash, etc. all apply. Have fun!

App-A-Week Challenge Update

Here we are at week #3 in the App-A-Week Challenge! What have we for this week?

Nothing too terribly exciting. Just updates to apps already on the store. Here’s what we have:

• Pizza Pal has been updated to 1.0.1 (adding support for armv6 processors and thus the iPhone 3G and the 2nd Generation iPod Touch
• The Beer Nerd’s Olde Volume Equvilance Calculator has been updated to 1.0.1 adding support for armv6 just like PizzaPal
• MD5 Calculator has been updated to 1.1 adding iAds (a shockingly obscene amount) and customization of the output.

But, next week should be a big week! We’ve submitted the brewer’s countdown timer and are waiting for review. Check it!

Do free apps increase sales of paid apps?

Some of you might remember my crazy idea of pledging to publish an app a week. I thought that this idea would be a good way to force myself to learn a lot about iOS development and actually get things done. And it has!

But one thing I did not consider was how downloads of simple, silly, free apps would affect sales of my paid apps. It’s only been one week but I am pleased to report that there has been some positive influence!

I had two free apps come out last week: The Beer Nerd’s Old Volume Equivalence Calculator came out on Wednesday and Pizza Pal came out on Friday. What you’re about to see are weekly sales figures for last week that cover free iOS apps, paid iOS apps, and paid Mac OS apps.

First, let’s take a look at the free iOS apps:

 

Even though the new free apps didn’t come out until later in the week, we’re seeing a 4-8x increase in free app sales. It was hovering between 10 and 20 a week and shot up to 80 last week.

So, we have users downloading the free silly apps. How might that affect sales of paid apps?

It appears that sales have roughly doubled from 30/week to 60/week. Nice! Is it possible that this increase works for Mac OS X apps as well?

This is not as clear but there appears to be an increase. It might average out to twice as much but I haven’t done any maths on it yet.

It has only been a week but it seems pretty clear that adding free apps to your stable of apps helps increase sales of your paid apps. And increases your skills and experience! LEVEL UP!

Possible bug in UITableViewCell didTransitionToState:(UITableViewCellStateMask)state

I’m putting this out here on the internets because I was pulling my hair out about this problem I had. Let me see if I can explain the problem and how I ended up solving it without turning this into a super long story.

I’m working on a new app that is basically a brewer’s countdown timer. I have a UITableViewController with a UITableView that has some custom UITableViewCells created via subclassing.

In the UITableViewCell subclass I implement:

- (void)didTransitionToState:(UITableViewCellStateMask)state

 So that I can use an animation block to adjust the opacity of cells that transition to state UITableViewCellStateShowingDeleteConfirmationMask. (I also check for UITableViewCellStateDefaultMask so I can turn them back to normal if the user cancels.) The problem happens thusly:

1. Swipe cell to delete. The cell fades with the animation block and the delete confirmation button shows up as we would expect. GOOD!
2. (If we tap away to cancel, the cell returns to normal.) GOOD!
3. If instead, of tapping away, we tap “delete”, the

   - (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath

    gets called and we delete the cell from the table and the data source programmatically. It flies away. SO FAR SO GOOD.
4. The cell directly after the deleted one moves up into the proper place BUT THEN DIMS ACCORDING TO the logic in the

   didTransitionToState:(UITableViewCellStateMask)state

   method. BAD!

The cell directly afterwards should not be getting the didTransitionToState method called on it. This problem persisted if I was using reusable cells or not. Here’s how I solved it:

In

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath

 I added:

tableView.editing = NO;

 right before removing the data source and deleting the rows. Apparently the “swipe to delete” automatically puts the tableView into edit mode and doesn’t bother to get it out of edit mode automatically. It feels like what was going on was that the UITableView cell directly after the deleted one was inheriting the deleted one’s UITableViewCellStateMask and since it was in edit mode, the willTransitionToState got called automatically. Setting the editing property of the tableView before deleting seems to reset the state mask.

Here’s a picture and also a tiny preview of what I’m working on!

New app! Also: Xcode + iOS + iPhone 3G tip. Also: insane idea.

I have a new app on the iTunes App Store! Allow me to introduce The Beer Nerd’s Olde Volume Equivalence Calculator:

It’s a handy little app that lets you compare equivalent prices for different volumes of beer. Interesting? Maybe. In all honesty, I whipped this app up real quick for the following reasons:

1. It uses the new accurate UISlider subclass I’ve been working on (which I will open source soon!)
2. It has an iAd. Ooh or eew? I don’t know yet.
3. I’m trying something new to help increase my skills. It’s kind of like Jonathan Coulton’s Thing a Week. I intend to write and publish a new app every week for the next year. What?

That last item seems like it might be a doozy. Not every app is going to be a winner. Apple may kick me out for generating too much crapware. Most will be free or iAd supported. Some might be decent.

There is a lot of doubt entwined with this idea. But here is something about which I don’t have much doubt: writing and releasing an app a week will stretch all parts of my development skillset, from writing code to understanding design patterns to designing icons to submitting and packaging. We’ll see how this goes. App #1 is done, app #2 is waiting to be reviewed and app #3 is nearing completion. Also, I haven’t forgotten about Lens•Lab! I’ll count an update of that as part of an app a week.

Oh, and the Xcode + iOS + iPhone 3G tip is this: when you create a new project in Xcode 4.2, the plist for your app has a entry called “armv7″ in the “Required device capabilities” section.

If your app targets iOS 4.2.1 and lower, you MUST remove this entry to support armv6 (the processor variant in the original iPhone, iPhone 3G, and 1st and 2nd generations of iPod Touch.) I just found this out this morning and an update to The Beer Nerd’s Olde Volume Equivalence Calculator has been submitted to Apple!