Our Beautiful Faces

Day Job - Bye Bye MLB, Hello Hot Potato

Thu, 22 Oct 2009 16:49:49 -0400

So, it’s been 4 or so years since I started at MLB, and it’s been great. But, it’s over. I’ve been lucky enough to become involved in a new venture with some old co-workers and some new friends.

It’s called Hot Potato and I’ll be working there full time once friday passes, which is my last day at MLB. I’m hoping I’ll be posting here more often, talking about the process we’re going through there to launch our product. I think it’s going to be pretty awesome, and I hope you will too.

Ok, enough for now. Hopefully, I’ll have some good stuff to share here soon.

Day Job - MLB.com At Bat now with Push/In-App Purchases

Tue, 01 Sep 2009 13:22:48 -0400

Just a quick update. MLB.com updated the iPhone app to have Push Notifications and In-App Purchasing to stream individual games. Pretty fun stuff to work on, and big thanks to all the different teams at MLB.com that brought this together, especially Warner, Emily, Mohammad and Tracy who all did some great dev on the actual client.. Great stuff.

TUAW weighs in on it.

iTunes link.

Touch Factory - Update

Wed, 17 Jun 2009 10:52:17 -0400

Things are coming along with Touch Factory. We’re talking 80%. But the last 20% will probably be the hardest. I just wanted to let people know it’s not dead.

Sorry things are taking a while. I want things to be “Just Right”, and if they are not, well, then I don’t want to release it.

Fingers crossed for finding the time.

//jeremy

Day Job - MLB.com wins Apple Design Award :)

Wed, 17 Jun 2009 10:49:13 -0400

Day Job - MLB.com wins Apple Design Award :)

Day Job - NY Times about MLB.com Streaming Video

Wed, 17 Jun 2009 10:48:28 -0400

Day Job - NY Times about MLB.com Streaming Video

The Rentals iPhone app -- in the App Store

Thu, 16 Apr 2009 22:00:52 -0400

The Rentals iPhone app -- in the App Store

Day Job - MLB.com At Bat Reviews Boston

Fri, 03 Apr 2009 10:40:36 -0400

A few reviews so far…

“Why can’t all iPhone sports apps be as good as MLB.com At Bat?”

- Boston Herald

“MLB.com At Bat 2009 hits a home run!”

- TUAW

“The 2009 edition of MLB.com At Bat is out for the iPhone, and it looks great.”

- Daring Fireball

and lots of tweets on Twitter

- Twitter search

Day Job: MLB.com At Bat 2009 in App Store

Sun, 29 Mar 2009 14:36:32 -0400

Day Job: MLB.com At Bat 2009 in App Store

DevTip: Abuse threads

Thu, 26 Mar 2009 13:30:00 -0400

Sometimes your interfaces can become clunky. You hit a button, or slide a slider and things get all stuttery. No good. People hate that and so should you. Usually this is because when your control (button, slider, tab, etc) calls back to your handler, there is too much work going on.

Just start a new thread. This sounds simple, but sometimes people over look it. I ran into this when I was adding the volume control on the new audio stream player for MLB.com At Bat. I thought, yeah, no problem, I can make a call to the audio session and store the value in my user defaults in real time. Easy! But no, it made the volume control sticky, so I had to spawn threads. See below.

In Interface Builder, connect your control to your handler for the given event the IBAction below, and then in that method, start a thread and don’t wait around for the result.

- (void) threadedTargetMethod:(id)object {
   //Do you time consuming stuff
}


- (IBAction) targetMethod:(id)sender {
   [self performSelectorOnMainThread:@selector(threadedTargetMethod:) 
                          withObject:nil 
                       waitUntilDone:NO];
}

Day Job - TUAW loves MLB.com At Bat before it's out.

Thu, 05 Mar 2009 10:44:59 -0500

Day Job - TUAW loves MLB.com At Bat before it's out.

Touch Factory - New OBF project due this summer........

Fri, 27 Feb 2009 15:31:41 -0500

Touch Factory - New OBF project due this summer........

Analysis: CRM Daily Talks Artists Apps

Thu, 26 Feb 2009 21:13:56 -0500

Analysis: CRM Daily Talks Artists Apps

So, update from the day job at MLB.com. It’s the first day...

Wed, 25 Feb 2009 13:38:00 -0500

So, update from the day job at MLB.com. It’s the first day of Spring Training. Go grab the At Bat Lite iPhone app.

Everyone who had At Bat last year should have this as a free update. The Lite version will give you a pretty Scoreboard + Gameday for spring training games and WBC games that have it. In a few weeks, we’ll have At Bat 2009 out there. Gameday Audio + Gameday + In-Game video highlights to make you happy for the whole season.

DevTip: Always check your distribution builds

Fri, 20 Feb 2009 10:33:34 -0500

Old post, but very useful, Craig Hockenberry walks you through testing your distribution builds. Do this to make sure you know exactly what you are submitting to iTunes Connect. Sometimes build settings vary between targets/build configs, and the only way to know what you have is to run what you submit.

Shut Up Review - Just Another iPhone Blog

Tue, 10 Feb 2009 14:01:32 -0500

Shut Up Review - Just Another iPhone Blog

Death Cab for Cutie iPhone App featured on Apple’s App...

Tue, 10 Feb 2009 13:25:13 -0500

Death Cab for Cutie iPhone App featured on Apple’s App Store.

Designed and Developed by Our Beautiful Faces.

Gameday Audio in MLB.com's At Bat

Mon, 09 Feb 2009 10:39:20 -0500

So, more news from the day job. Our CEO, announced in NY Times that At Bat will include Gameday Audio and be less than $10. Take that, baseball fans.. :)

Bob Bowman, chief executive of MLB.com, said the company was also adding to its offerings for mobile phones, including bringing radio broadcasts to its applications for Apple’s iPhone and Research in Motion’s BlackBerry. That will let iPhone and BlackBerry users who buy the At Bat application, which MLB.com says will cost less than $10, to listen to any game, anywhere they get cellphone coverage.

from NYTimes.com

DevTip: Don't always recycle UITableViewCells

Sat, 07 Feb 2009 12:36:00 -0500

So, Our Beautiful Faces is one thing, and my day job is another. During the day I work for MLB.com, mostly working on their iPhone app At Bat and other mobile stuff. Anyway, I am in the middle of refactoring At Bat for this season, and have been trying to optimize certain things.

One thing that always needs to be optimized is table scrolling. Choppy is bad. Real bad. Drives people crazy. And it inevitably happens. You have add a lot of subviews because there is a lot of data to display in each UITableViewCell, and eventually, you get to a point where rendering these cells take a little too long.

There’s lots of things you can do for this. You can stop using subviews and just draw everything to the cell’s contentView when drawRect is called. Sounds like a lot of work. You can make everything opaque. This does render faster, but I’ve never noticed it making much of a difference visually. You can only update subViews if they’ve actually changed. If you have a UIImageView as a subview, don’t blindly call setImage on it over and over, unless that image is actually different.

But there’s something else you can do which is a little less obvious. Cell reuse is awesome and for the most part, should always be used. Especially for UITableView’s of arbitrary length. However, if you always have a reasonable number of cells, let’s say 5-50, and you know you will never really need more than that, then why not have all of them in memory? It’s not gonna break the bank to have them all ready so why keep making it render all the new information each time?

So, what do you need? Not much. Basically, instead of trying to dequeue cells from the UITableView, keep track of them yourself in a dictionary. See in the following code snippet.

NSMutableDictionary *myDictionary;

...

- (UITableViewCell *)tableView:(UITableView *)tableView 
         cellForRowAtIndexPath:(NSIndexPath *)indexPath 
{

    NSString *cellId = [NSString:stringWithFormat:@"id_%d_%d];

    UITableViewCell *cell;

    if ([myDictionary objectForKey:cellId]) {

        cell = (UITableViewCell*)[myDictionary objectForKey:cellId];
        //update cell if necessary

    } else {
        cell = [self createYourCell:indexPath];
        [myDictionary setObject:cell forKey:cellId];
    }
    return cell;

}

Obviously, if you have too many cells, this won’t work. Also, make sure your prepareForReuse method on your cell isn’t wiping things out. The only reason this helps out at all, is because it doesn’t need to redraw all the subviews. So, if you wipe them all out by resetting them in your prepareForReuse, then you are defeating the purpose.

One thing, the first time you scroll, it may still be a little choppy. This is because we are still creating the cells as we scroll. Yuck. So how do we get around this? Easy, after the UITableView loads, or maybe after you have loaded your data from the network and parsed it, iterate through all the cells manually. Create an NSIndexPath for every cell you will need and then call your method that is creating the actual cell. In the example above that method is [self createYourCell:indexPath]. Then store the result in the NSMutableDictionary. Done.

This is a simple way to make scrolling fly when developing on the iPhone SDK if you have a reasonable number of cells that don’t change too often.

Hopefully I’ll have more developer tips as time go on, but I found this particular thing to really help me out, and hopefully it will help you as well.

//jeremy

soundsvicio.us weighs in on Artist Apps

Thu, 05 Feb 2009 13:01:11 -0500

soundsvicio.us weighs in on Artist Apps

Shut Up

Thu, 05 Feb 2009 10:39:52 -0500

So my stupid novelty app hits the App Store today.. 99 cents.

iTunes Link

YouTube demo video