My FITC Mobile Notes Pt1 October 11, 2010

Posted by headwinds in Actionscript, iPhone.
trackback

I recently attended FITC Mobile for their second event. I’m going to post my notes in two parts starting with a quick look at Andspot and then a deeper dive into Streamingcolor games. This year, I’m mainly interested in iPhone and Flash (which I’ll cover in Part 2) software on mobile devices.

What a difference a year makes! From last year where less than an handful of people had apps in stores to this year where half the audience had apps in the stores and basically everyone (including myself) had one in production.

The first presentation that I attended was from the person behind Andspot which is an alternative to the Android Market place something which is outlawed on the iPhone frontier.

While I’m not currently pursuing android development, I was interested to see how android apps are marketed and jotted down some of his figures regarding device sales and why he considers Android as the fastest growing platform:

Windows
15 M in 2009
12 M in 2010

i0S
24 M in 2009
41 M in 2010

Android
6.8 M in 2009
47 M in 2010

Rim
34 M in 2009
46 M in 2010

He had projections into 2014 that had Android as the major player but I won’t include those as I think the market is changing too quickly. The prediction of close to a billion smart phones sold by 2014 is compelling enough to mention though but I think there still will be an immense variety of devices; too many to predict at this point.

Next up, I attended the talk by Owen Goss of Streamingcolour Games. Owen is a solo, indie game developer living in Guelph and he decided to speak about memory managements and leak analysis within iOS.

Owen discussed how iOS has no garbage collection and how memory is allocated through retain and release counts. He pointed out that when you instantiated an instance through self, its retain count grows surprisingly by 2 not 1. Instead, he recommended pointing to a temporary object and releasing it right away.


self.myClass = [[MyClass alloc] init]; // retain count is 2 not 1!

-(void) dealloc
{
[myClass release] // retain is 1 !!!
}


 

MyClass *tempObj = [[MyClass alloc] init];
self.myClass = tempObj; // retain count is 1
[tempObj release];

-(void) dealloc
{
[myClass release] // retain is 0 and will be completely removed from memory
}

 

In order for an instance to be removed completely from memory, its retain count must be zero upon dealloc. He went to on to demonstrate how you can use tools like Build & Analyze and Leaks diagnostic to further troubleshoot memory leaks.

I wasn’t brave enough to ask Owen a question during his session. Instead, I decided to email him afterwards so that I could poise several questions, and he graciously agreed to share his responses with you.

b: Obviously, the goal is to ship games with zero memory leaks. I’m wondering if you happened to ship any of your games with memory leaks?

o: With each of my games I’ve strived to ship with zero memory leaks. Occasionally, fixing a bug at the last minute, you end up introducing a small leak. There are probably a few small leaks in each of my games (a string that leaks once, for example), but not enough to warrant concern. However, my primary goal is always to ship the best game I can.

b: If you had memory leaks, how did you hear about them? Did your users report general bugs which you then tracked down to memory leaks?

o: During the beta testing stages of a game is usually when I dig deep into looking for and fixing leaks. It’s rare that a leak causes a serious problem, but occasionally you might get memory warnings showing up from a beta tester’s log files that can be tracked down to something leaking frequently. If you introduce a bad enough leak, the OS can terminate your app if you run low on available memory and don’t respond to memory warnings.

b: Bugs happen. I know how difficult it is to edit and bug check one’s own code. You are a solo developer on your projects. What simple advice would you give other solo developers in tracking down their own bugs and memory leaks?

o: Yes, I’m a solo developer, so finding and fixing my own bugs is a challenge. I have a great selection of beta testers who help me test my games. I’ve asked friends to help, I’ve asked other developers to help, and I’ve put out public calls for beta testing help on iPhone game forums. The testing help I’ve received has been amazing. Without the 20-30 people I have testing my games, there’s no way I’d ship a game with as few bugs.

o: Tracking down memory leaks is a different problem though. For that I use the Leaks Instrument. Users won’t find memory leaks in you game (they might notice it crash if you run out of memory, but they won’t know why it crashed). The Leaks Instrument is an incredibly powerful tool for tracking down memory leaks in your own code. Every iOS developer should be running it on their own apps (and fixing the leaks they find) before they ship a app.

As I near completion of my first app, I’ll follow this sage advice and make sure I run my app through the Leaks Instrument as well as lean on a few friends and family to assist with bug tracking offering them at least a spot in the final credits.