So I was at work pretty late today. We ran into several flex-related issues, several of which were related to the dreaded “watching a boolean” model. Basically, it seems that flex doesn’t always alert listeners that a bound property has changed. Coupled with my amazingly sparse knowledge of flex, flash and just about everything else Adobe, this made for some fun debugging. We were able to piece things together thanks to three things:
1) Tejus‘ random story some time ago (Appc office, random day) about this phenomena, which I vaguely recalled
2) Some really strange behavior
3) Calvin’s leet global search skills
For the record, this bug sucks. Use binding sparsely since it’s implementation is flaky at best. Also, it wasn’t just on properties of an object but on an object itself, IIRC. Also, we reproduced it in both Flashplayer 9 and 10. All in all, it was actually pretty fun, but it took longer than it should have. Don’t. Watch. Booleans. 
I hope you enjoyed the brief (!) overview of the iPhone SDK at Barcamp 2008. Here’s a link to the source in case you want to tinker or just get some ideas. This demo is just meant to help you get your feet wet. Don’t forget to use async connections for fetching large files — I can’t stress this enough.
Want to show an image on iPhone?
//xpos, ypos, height, width
UIImageView *img = [[UIImageView alloc] initWithFrame:CGRectMake(215,255,120,120)];
[r7logo setImage: [UIImage imageNamed:@"my_img.png"]];
[view addSubview: img];
[img release];
“my_img.png” needs to be imported into your project (just drag it onto your xcode project and tell xcode to copy it in).
“view” is a view — if you’re within the context of a view controller, try self.view instead.
I left Appcelerator a while back, mainly looking for new challenges and the like. Today, I was pretty surprised (read shocked) to find out that Appc closed its Atlanta office and laid off its entire staff there. I received a text message: “decelerated.” That totally sucks (understatement of the day?). Jeff’s public post explained the tough decision the leadership at Appc had to make.
I feel pretty bad for all of the folks from the ATL Appc office. I know that Appc is already talking to local folks to find homes for the affected and that several local companies offered positions to the unfortunate souls. Although I’m generally concerned for my friends (not a McCain reference), the fact is that they’re brilliant people and they’ll be on their feet in no time. I wish them all the best. As Nolan would say, it is what it is (followed by some facetious comment, of course — it’s how he rolls).
You can play AAC+ AAC Streams on iPhone just like a standard MP3 stream (Fetch w/ NSURLConnection, pass filled buffers to the AudioQueue), but pass the AudioFileTypeID “kAudioFileAAC_ADTSType” to AudioFileStreamOpen instead of “kAudioFileMP3Type.” How does one go about checking what type of stream they’re dealing with? Check the content-type (parse it out of headers or the initial response data — that depends on the stream server you’re dealing with):
if ([contentTypeLine rangeOfString:@"audio/aac"].length > 0)
{
audioFileType = kAudioFileAAC_ADTSType;
//Pause and resume so we reinitialize the audio stream with the new file type (AAC+)
[self restartAudioQueue];
}
where restartAudioQueue does something along the lines of the following:
-(void)restartAudioQueue {
[self resetAudioQueue];
AudioFileStreamOpen(&audioState, &PropertyListener, &PacketsProc, audioFileType, &audioState.streamID);
}
and resetAudioQueue calls AudioFileStreamClose, AudioQueueStop and AudioQueueReset as well as cleaning up buffers, etc.
Note that it’s not necessary to cancel and recreate your NSURLConnection — it’s (obviously) independent of the AudioQueue.
Don’t forget to parse out your metadata or you’ll get skips!
Update: AAC+ playback seems to be broken in iPhone 2.1. I’ve filed a bug report w/ Apple about playback skipping w/ 2.1 (same code works great w/ 2.0).