Feb 272009
 

We’ve received a couple of negative reviews due to the application crashing (which I explained in my previous post). I guess you can’t help that. But the good news is that we haven’t really heard of any more reports of it crashing after version 1.1.1 was published.

A couple of days ago, the Lite version of iHappyBirthday was released to the App store. Imagine my surprise when I checked the sales figure this morning and saw that it was downloaded close to 600 times. Only if the same were true of the paid version! I think we need to observe it a bit more to see what kind of effect the Lite version will have, but as of yet, it has had no effect. Hey, at least it didn’t have a negative effect!

We’re trying to implement one, last key feature to SaS before we release it to the general public. But it’s turning out to be a bit of a technical challenge. Hopefully it won’t hold us up for too long!

Edit: Oops. I miscalculated. It was downloaded close to 1000 times.

 Posted by at 5:52 am
Feb 082009
 

Fix and a Solution

Thank you to everyone who has purchased iHappyBirthday. Reaction to iHappyBirthday has been quite positive. However, we’ve been receiving reports of random crashes. We actually know why this happens. In a previous, unreleased version of iHappyBirthday, we displayed an alert message to the user telling him or her that the system is running low on memory; and that continuing without freeing up memory may crash the application.

But we removed this message because according to our tests, the phone did not reach such a low level of memory that it would cause it to crash. However, iHappyBirthday 1.1 uses a little bit more memory than 1.0, and that seems to have pushed it over some threshold which is making it more prone to crashing. We are happy to say that we have solved this problem by drastically reducing the memory usage. We have submitted version 1.1.1 and it should be available soon for download. But in the mean time, please follow the workaround from our support page.

Technical Mumbo Jumbo: iPhone Memory Management System

I’m writing this for the benefit of other developers who may be facing similar memory problems. Or if you are not a developer and just happen to be a glutton for pain, then please read on. Our application was not using that much memory, but when other applications (like Safari) were taking up over 20 MB of RAM, it would cause our application to crash due to the phone running low on memory. The following were my observations while chasing down this problem.

When the iPhone runs low on memory, it will start freeing memory from background applications like Safari. But why then was our application still crashing? This was because the rate at which our application was using up the memory was greater than the rate at which the operating system was freeing up the memory. Ultimately, it comes down to this simple fact:

“Always minimize memory usage.”

It’s not very enlightening, but that’s the fact of the matter. Looking at the Activity Monitor in Instruments, I noticed that the memory used by Safari continued to decrease bit by bit over time as iHappyBirthday was running. And then eventually, Safari was entirely removed and all resources freed. However, if iHappyBirthday was too aggressive in its memory usage, even though the OS was freeing up memory, it could not outpace the rate at which iHappyBirthday was requesting memory. The result? Crash.

UIImage!

For version 1.1.1, the memory use was halved. It was achieved by not using the UIImage’s imageNamed message and by intelligently loading resources. It turns out that if you use imageNamed, the resources are cached into the memory and the iPhone does not do a very good job of releasing the cached memory. For version 1.1.1, imageWithContentsOfFile was used in conjunction with imageNamed. And for the most part, the caching was handled by the application rather than the iPhone SDK.

It was interesting to see how the memory management system behaves on the iPhone. And even more enlightening to learn about the pitfalls of using UIImage’s imageNamed routine. In fact, the documentation for this routine states,

“This method looks in the system caches for an image object with the specified name and returns that object if it exists. If a matching image object is not already in the cache, this method loads the image data from the specified file, caches it, and then returns the resulting object.”

But of course, I never looked at the documentation before using this. Had I looked at it, I could probably have avoided all this mess.

So always remember to RTFM!

 Posted by at 8:53 am
Feb 062009
 

We just go approved for the iHappyBirthday update.  A small drama right before the release, but nothing we couldn’t laugh off.

I just want to let people know that the 24:2 blog post ratio that Min has over me is due to the fact that we’re hard at work with our next upcoming App: codename SaS.  Stay tuned.

 Posted by at 2:33 pm
Feb 062009
 

I noticed a classmate lugging a huge Dell laptop in an equally gargantuan bag. He told me that due to a recently diagnosed sleep apnea, he was going to record the lectures with a high definition web cam because he was prone to dozing off in class.

What a great idea! My handwriting is horrible to the point that sometimes even I have problems comprehending my own illegibility. And I type so much faster than I write. The Macbook Pro has a fairly sensitive built-in microphone. I won’t go so far as to record the video (because the laptop would have to be facing the professor), but I sure can record the audio while still typing my notes.

So I went shopping for a carrying case for my MacBook Pro. The case had to be sleek and not too bulky. At the same time, it had to be practical and utilitarian. I’ve been eying the MacBook sleeve for a long time, but the absence of a handle or a strap and pockets in which to carry accessories immediately presented problems. I finally settled on the Incase Nylon Sleeve with Handles for 15-inch Macbook Pro.

The case is very compact and sleek with two pockets in the front and a large pocket in the back. The inside is lined with a soft, fur like material that protects the laptop from unsightly scratches. And It has a carrying handle and a shoulder strap. It actually looks better in person than in pictures. Also, I have the brown one, which I think looks much better than the black one pictured here.

As is always the case with anything Apple related, the carrying case does not come cheap. The luxury to carry my MacBook Pro in this fine case cost me $59.95 before the 5% sales tax. I probably wouldn’t have considered spending so much money except for the fact that I had just received a $100 rebate check in the mail from Amazon.com (for the MacBook Pro I purchased).

I love the case. Along with my MacBook Pro, I can conveniently carry around a notebook (notebook as in a real notebook that you write in, not a laptop), a pen, and my charger (with the extension) while maintaining the sleek and compact look. But there is one thing that I loath about this case. In fact, it was such a huge deal breaker that I’m contemplating on returning it even now.

It’s just that the case is a magnet for static! When I use the shoulder strap to carry it, it rubs against my body. And I’m met with that annoying and strangely uncomfortable feeling of a static shock. I hate static electricity. I really, really hate it. It doesn’t take much. A slight rub will cause it to build up static. So I’ve resorted to using the handle and not the shoulder straps, making sure that no part of the case is rubbing against any part of my body. My only hope is that this is only a major problem in winter months, because I’d really like to keep this case.

From a scale of 1 to 10, I would give this case a 8 (-2 for the price), had I been able to live with the static electricity. But add static into the equation, and I would have to rate this a 1. Yes. Static is that bad with this case.

 Posted by at 8:49 am
Feb 052009
 

The update to version 1.1 of iHappyBirthday was rejected by Apple because the application did not meet the iPhone Human Interface Guidelines. The detailed reason for the rejection is because we do not display a checkmark next to a selection in our choose cake screen. Apple says that you must provide feedback to the user so that the user knows something is selected.

It’s kind of funny, because it’s obvious what the user has selected because the item that the user has selected is highlighted. It’s also funny because our version 1.0 behaves exactly the same way and it was approved. This just seems to be a case of having gotten a reviewer who is a bit more thorough (or anal — take your pick). In any case, we resubmitted the application immediately after fixing the issue. But that does delay the release by another week or so because now it’s pushed to the back of the review queue. Boo.

And a final word of warning to anyone releasing an update. Do not set the release date to a date in the future, because that will also affect the release date of your original version. We set the release date of our update to a future date, and that also affected the release date of version 1.0. The net effect being that version 1.0 was taken off of the App store because the availability date was set to future date! We were really perplexed by this one. We thought Apple retroactively took applications off of the App store if the update to the original application is rejected. Who would have figured that the release date of the update was tied to the original version. Apple should really make this clear.

On a more personal note, I am strangely enjoying school. Is it because I’m getting older? My brain still seems to be fairly functional because I am able to soak up new information. Let’s hope this continues.

 Posted by at 3:22 pm