My FITC Mobile Notes pt2 October 24, 2010
Posted by headwinds in Random.add a comment
This is second part of my FITC mobile experience where I attended mainly iPhone and Flash development lectures. The following is a collection of loose notes.
iOS NETWORKING with Jim Dovey who works @ Kobo inc.
Jim discussed Grand Central Dispatch which is the iOS approach to multicore computing and thread management. He talked about asynchronous network development in 10.6 using CFNetwork, NSURLConnection, Reachability, and the new Blocks which provide function closures.
I was also curious about his personal site allanquatermain.net and just who was this Allan Quatermain character?
Media Player Programming on iOS with Adam Hunter who heads up the mobile division @ Rogers
Adam showed us how he was able to stream large media files. He used the short animated film elephant dreams as an example, and was able to stream the film creating 10 second chunks using open source iPhone streaming technology called a segmenter. He discussed other streaming services like encoding.com. He walked us through some sample code that showing that one can now create a video player instance within an app that doesn’t need to take up the entire screen using AVPlayer sharing it with other views.
Adam’s latest success story was the CityTV ipad app which held the number one free app position.
Flash Platform for Mobile and Devices with Mark Doherty
The massive variety of screens make for an unpredictable future and that Flash has at least attempted to remain consistent across these screens. He did encourage developers to test on each device and create different builds depending on how they perform; don’t just build for one device and think it will translate to all Flash devices. He mentioned the move towards the cloud where we can centrally store data and share it among a swarm of screens.
Adobe has a lofty goal of supplying the Flash Player Lite to 1.2 Billion devices: tablets, smart phones and set top boxes. The mobile version of Flash — Flash Lite — is still different from the desktop version of the latest Flash Player 10.1. As Scott Janousek points out, the differences between the two players should be minor and allow for easy porting. It seems we do need different version to support under powered devices.
It was cool to see him demonstrate the papervision 3D site ecodazoo.com on a Froyo android device and see him spin the 3D models showing that it had only a slight loss of performance over the desktop version.
Adobe has started to work on the iPhone packager for Flash CS5 again after Apple decided open up to other third party developers which is an excellent move and renews my faith in the future of both Apple and Adobe.
FINAL THOUGHTS
Where do I stand in 2010 on Mobile Dev? In 2009, I liked the idea that you could in theory develop for multiple devices specifically the big three. Today, I think that generalist approach isn’t practical for the apps that I want to create and not having access to multiple devices is a definite barrier. The differences between the Blackberry, android and iPhone devices are simply too great. By focusing on a single platform, I’ll become a specialist for that device which for me should translate to future iOS projects in 2011. I do know that I need a decent app in the app store before anyone would consider me as serious iOS developer.
I’ve decided to dedicate 2010 to the iOS platform and have buckled down to learn objective-c [as well as C/C++ since they all work on iOS] by reading textbooks, watching iTunes university lectures [the Stanford iphone ones are exceptional!], and chipping away at a side project prototype which should be ready for release in a couple more months.
The more time I put into objective-c dev; the more I discover that I need to know which only re-enforces this specialist approach. So as much as I do admire android, I’m not attempting to learn Froyo just yet but banking on Flash to port any desktop apps to that device so that I don’t have to learn yet another language; the various flavors of C are quite enough for 2010.
My FITC Mobile Notes Pt1 October 11, 2010
Posted by headwinds in Actionscript, iPhone.add a comment
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.