Rss

Archives for : c

DVDivvy

So a while back, you might remember me bitching about AV Foundation and presenting as my use-case for where the AVF-based QuickTime Player X comes up lacking, the technique by which I pull individual episode files out of DVD rips that produce a single two-hour title.

After my epic bitch-fest, I wrote:

But I also have a list on my whiteboard of fun projects I’m saving up to do as livestream code-alongs someday, and one is an AV Foundation based episode-splitter that would replace my cut-copy-paste routine from way above. Because really, it would be pretty simple to write an app that just lets me razor-slice the big file at each episode break, and then mass export them into separate files using some programmatic file-numbering system.

So, since writing that, I’ve allowed new anime DVDs to pile up without using my old QuickTime copy-and-paste technique, because I’ve wanted to actually write this app. Which means that True Tears and Lupin the Third: The Woman Called Fujiko Mine are sitting unwatched on the shelf, because they’re just DVDs and not .m4v‘s compatible with iPad and Apple TV. Not cool! I need my tragic schoolgirls and super sexy thieves!

So, on and off over the last week, I wrote DVDivvy

DVDivvy splitting up a ripped title

Continue Reading >>

Pre-announcement: All-day Core Audio tutorial at CocoaConf Columbus

Back in April, I wondered aloud on Twitter:

Wondering aloud: lots of computer conferences have a one-day tutorial beforehand, usually for beginners. Would anyone want an advanced one?

This is something I’ve been thinking about from the arrangement of the Mac/iOS conferences that typically have a beginner tutorial on day one, then eyes-forward sessions and other contents starting the next day. It seems to have the unintended effect of bifurcating the audience: the intermediate and advanced developers roll in on the second day and it changes the composition of the crowd and the feeling of the group. The sense of “we’re all in this together” gets a little lost. What could we do to get those intermediate and advanced developers in on the first day, mingling with the newbies at breakfast and lunch? Well, we could try to have a tutorial on topics sufficiently advanced that it would be worth the time and expense for intermediate and advanced developers to arrive early for tutorial day.

It seemed like an interesting experiment, and Dave Klein of CocoaConf was game to give it a try. But what goes into an “advanced” tutorial? We could do a day’s worth of stuff that you only get into after a year or two of professional development — managing large code-bases, fancy UIKit tricks, expert XCode wizardry, etc. — though it’s likely five different instructors would come up with five different sets of topics to cover.

Another idea: pick a single advanced topic and really dig into it. Maybe something that people are aware of but haven’t had time to tackle. Something that’s so renowned for its challenge that the best way to learn it would be to just sit down with an expert for a day and work through some code.

Something like, Core Audio, you suppose?

Yep, that’s exactly what we’re doing. On Thursday, August 9 — the first day of CocoaConf Columbus — I’m going to do an all-day Core Audio intro tutorial. I haven’t hashed out the schedule, but it will basically be geared to projects that we can bang out in a tutorial setting and that do something interesting. I might draw from the book, but I might throw in some all-new material… just this week, I was working on code for an ADC support incident and realized that a basic web radio client could be explained and written in about two hours, so that’s at least possible (and ironic, considering we chose to leave Audio File Stream Services out of the book). Surely, the afternoon will have to be all about Audio Units.

Pre-requisites: as with the book, you’ll need a reasonable comfort level with C — not expert level, but not afraid of malloc, sizeof, or * either. Not sure if I want to require a device or make everything simulator-friendly. Guess you can watch the CocoaConf page for that.

Anyways, Dave and family are going to be focused on CocoaConf DC for the time being, and probably won’t switch the page to Columbus until July. If you’re interested in a full day of serious Core Audio hackery and slashery, save the date (Thursday, August 9), and start thinking about how you’ll get yourself to central Ohio.

Hope to see you there. I’m looking forward to being able to do a full day of Core Audio.

What You Missed at CocoaConf Chicago (2012)

OK, here’s my usual post-conference blog entry with slides and sample code links. In a break with tradition, I’m actually getting it up the day after I got home from CocoaConf, rather than weeks later.

“Core Audio Cranks It Up” is a talk I first gave at an earlier conference, so the links to slides and sample code are in What You Missed At Voices That Matter iOS, Fall 2011.

New for CocoaConf, I did a talk called Core What?, which started from Twitter discussions with potential attendees about topics including a grab-bag of Core Foundation and other C-level oddities and novelties, and all the gruesome PDF lessons I learned late last year.

Core What?

For what it’s worth, this is another conference presentation I created entirely on my iPad. This presentation also includes an off-the-cuff reference to Bodacious Space Pirates (although one stage of the build was lost in export to PDF). You’re welcome.

We also did a “Reverse Q&A” panel, in the style introduced by Harmonix’s PAX East 2011 Reverse Q&A. This made it a lot easier to get the discussion rolling quickly, and featured much more insight from the audience than you’d get from a typical panel format. Feedback on Twitter has been positive, including from CocoaConf’s itself, which vows to use the format again in the future. But maybe next time I’ll stick to the handheld mic that I shared with audience members, because I think my super-sensitive lavalier was the source of the feedback whenever I was under a speaker.

Finally, like any good trip, this one included trips to Fry’s Electronics and Ted’s Montana Grill. Because if there are two things I need more of in my life, it’s computer parts and bison-burgers.

CocoaConf, NSBrief, etc.

Miscellaneous updates:

CocoaConf Chicago early bird pricing ends this weekend. I’ll be there, doing the Core Audio on iOS 5 talk (with MIDI and Audio Unit effects), and a new “Core What?” talk about neat stuff I’ve found over the years in the various C frameworks. A big piece of it will actually center on the CGPDF… stuff in Core Graphics, after all the PDF work I did last fall. Drawing into a PDF and drawing a PDF page into your view are common enough tasks, and the parsing of a PDF is another one of those tasks where the API makes absolutely no damn sense until you understand the problem domain behind it. Beyond that… CFUUID, CF-only collections, other curiosities and oddities.

Oh, and there’s a Fry’s Electronics in Downer’s Grove, about 20 minutes from the conference hotel. I have at least $500 worth of stuff on my shopping list (NAS, FCPX-compatible video card, Rock Band drums or Pro Guitar, out-of-print anime…). So that will add to the fun.

Speaking of CocoaConf, Saul Mora (who recorded our panel at CocoaConf Raleigh) had me on as a guest for NSBrief episode #33, in which we discuss audio theory, Core Audio, and AV Foundation for an hour. Plus, I lay out the plan for the “Reverse Q&A” we’re doing at CocoaConf Chicago, inspired by the Harmonix Reverse Q&A Panel at PAX East 2011. I wondered aloud about the idea of doing this in an earlier blog, and I’m glad we’ll have a chance to give it a shot. Hopefully, this will prove to be a good way to shake up the regular old panel format, and be fun and insightful for audience and speakers alike.

Learning Core Audio continues to work its way through Pearson’s production process. This week we signed off on author bios and cover blurbs. Copy-edit was a few weeks ago… admittedly a bit of a disappointment as I discovered all the third-person sentences had been somewhat mechanically rewritten to second-person (i.e., “we” becomes “you”). Sometimes it works, sometimes it really doesn’t, and I was too tired to fix all the cases of the latter. Still, it would have been nice to have been told about this house style two years ago when we started the damn thing.

Taking C Seriously

Dennis Ritchie, a co-creator of Unix and C, passed away a few weeks ago, and was honored with many online tributes this weekend for a Dennis Ritchie Day advocated by Tim O’Reilly.

It should hardly be necessary to state the importance of Ritchie’s work. C is the #2 language in use today according to the TIOBE rankings (which, while criticized in some quarters, are at least the best system we currently have for gauging such things). In fact, TIOBE’s preface to the October 2011 rankings predicted that a slow but consistent decline in Java will likely make C the #1 language when this month’s rankings come out.

Keep in mind that C was developed between 1969 and 1973, making it nearly 40 years old. I make this point often, but I can’t help saying it again, when Paul Graham considered the possible traits of The Hundred-Year Language, the one we might be using 100 years from now, he overlooked the fact that C had already made an exceptionally good start on a century-long reign.

And yet, despite being so widely used and so important, C is widely disparaged. It is easy, and popular, and eminently tolerated, to bitch and complain about C’s primitiveness.

I’ve already had my say about this, in the PragPub article Punk Rock Languages, in which I praised C’s lack of artifice and abstraction, its directness, and its ruthlessness. I shouldn’t repeat the major points of that article — buried as they are under a somewhat affected style — so instead, let me get personal.

As an 80’s kid, my first languages were various flavors of BASIC for whatever computers the school had: first Commodore PETs, later Apple IIs. Then came Pascal for the AP CS class, as well as a variety of languages that were part of the ACSL contests (including LISP, which reminds me I should offer due respect to the recent passing of its renowned creator, John McCarthy). I had a TI-99 computer at home (hey, it’s what was on sale at K-Mart) and its BASIC was godawful slow, so I ended up learning assembly for that platform, just so I could write programs that I could stand to run.

C was the language of second-year Computer Science at Stanford, and I would come back to it throughout college for various classes (along with LISP and a ruinous misadventure in Prolog), and some Summer jobs. The funny thing is that at the time, C was considered a high-level language. At that time, abstracting away the CPU was sufficient to count as “high-level”; granted, at the time we also drew a distinction between “assembly language” and “machine language”, presumably because there was still someone somewhere without an assembler and was thus forced to provide the actual opcodes. Today, C is considered a low-level language. In my CodeMash 2010 talk on C, I postulated that a high-level language is now expected to abstract away not only the CPU, but memory as well. In Beyond Java, Bruce Tate predicted we’d never see another mainstream language that doesn’t run in a VM and offer the usual benefits of that environment, like memory protection and garbage collection, and I suspect he’s right.

But does malloc() make C “primitive”? I sure didn’t think so in 1986. In fact, it did a lot more than the languages at the time. Dynamic memory allocation was not actually common at that time — all the flavors of BASIC of that time have stack variables only, no heap. To have, say, a variable number of enemies in your BASIC game, you probably needed to do something like creating arrays to some maximum size, and use some or all of those arrays. And of course relative to assembly language, where you’re directly exposed to the CPU and RAM, C’s abstractions are profound. If you haven’t had that experience, you don’t appreciate that a = b + c involves loading b and c into CPU registers, invoking an “add” opcode, and then copying the result from a register out to memory. One line of C, many lines of assembly.

There is a great blog from a few years ago assessing the Speed, Size, and Dependability of Programming Languages. It represents the relationship between code size and performance as a 2-D plot, where an ideal language has high performance with little code, and an obsolete language demands lots of work and is still slow. These two factors are a classic trade-off, and the other two quadrants are named after the traditional categorization: slow but expressive languages are “script”, fast but wordy are “system”. Go look up gcc – it’s clearly the fastest, but its wordiness is really not that bad.

Perhaps the reason C has stuck around so long is that its bang for the buck really is historically remarkable, and unlikely to be duplicated. For all the advantages over assembly, it maintains furious performance, and the abstractions then built atop C (with the arguable exception of Java, whose primary sin is being a memory pig) sacrifice performance for expressiveness. We’ve always known this of course, but it takes a certain level of intellecutual honesty to really acknowledge how many extra CPU cycles we burn by writing code in something like Ruby or Scala. If I’m going to run that slow, I think I’d at least want to get out of curly-brace / function-call hell and adopt a different style of thinking, like LISP.

I was away from C for many years… after college, I went on a different path and wrote for a living, not coming back to programming until the late 90’s. At that point, I learned Java, building on my knowledge of C and other programming languages. But it wasn’t until the mid-2000’s that I revisted C, when I tired of the dead-end that was Java media and tried writing some JNI calls to QuickTime and QTKit (the lloyd and keaton projects). I never got very far with these, as my C was dreadfully rusty, and furthermore I didn’t understand the conventions of Apple’s C-based frameworks, such as QuickTime and Core Foundation.

It’s only in immersing myself in iOS and Mac since 2008 that I’ve really gotten good with calling C in anger again, because on these platforms, C is a first-class language. At the lower levels — including any framework with “Core” in its name — C is the only language.

And at the Core level, I’m sometimes glad to only have C. For doing something like signal processing in a Core Audio callback, handing me a void* is just fine. In the higher level media frameworks, we have to pass around samples and frame buffers and such as full-blown objects, and sometimes it feels heavier than it needs to. If you’re a Java/Swing programmer, have you ever had to deal with a big heavy BufferedImage and had to go look through the Raster object or whatever and do some conversions or lookups, when what you really want is to just get at the damn pixels already? Seems to happen a lot with media APIs written in high-level languages. I’m still not convinced that Apple’s AV Foundation is going to work out, and I gag at having to look through the docs for three different classes with 50-character names when I know I could do everything I want with QuickTime’s old GetMediaNextInterestingTime() if only it were still available to me.

C is underappreciated as an application programming language. Granted, there’s definitely a knack to writing C effectively, but it’s not just the language. Actually, it’s more the idioms of the various C libraries out there. OpenGL code is quite unlike Core Graphics / Quartz, just like OpenAL is unlike Core Audio. And that’s to say nothing of the classic BSD and other open-source libraries, some of which I still can’t crack. Much as I loathe NSXMLParser, my attempt to switch to libxml for the sake of a no-fuss DOM tree ended after about an hour. So maybe it’s always going to be a learning process.

But honestly, I don’t mind learning. In fact, it’s why I like this field. And the fact that a 40-year old language can still be so clever, so austere and elegant, and so damn fast, is something to be celebrated and appreciated.

So, thanks Dennis Ritchie. All these years later, I’m still enjoying the hell out of C.

The Dark Depths of iOS

CodeMash starts Wednesday in Sandusky, with half-day iOS tutorials from Daniel Steinberg and myself, followed by two days of sessions. My Thursday session is The Dark Depths of iOS, and is a rapid-fire tour of the non-obvious parts of the iOS APIs.

Researching for this has proven an interesting exercise. I had the idea for the talk from the occasional dive into Core Foundation for functionality that is not exposed at higher levels of the iOS and Mac stacks. A simple example of this is the CFUUID, the Universally unique identifier defined by RFC 4122. More than once, I’ve needed an arbitrary unique ID (other than, say, the device ID), and am happy to use the industry standard. But it’s not defined in Foundation or Cocoa, so you need to use Core Foundation and its C API.

Another example I knew about before starting this talk was the CFNetwork sub-framework, which provides a much more complete networking stack than is available in Cocoa’s URL Loading System. CFNetwork allows you make arbitrary socket connections, work with hosts (e.g., to do DNS lookups), accept connections, etc. Basically, if what you need from the network can’t be expressed as a URL, you need to drop down at least to this level. It has an advantage over traditional BSD sockets in that it integrates with the Core Foundation view of the world, most importantly in that its reading and writing APIs use the asynchronous callback design patterns common to Apple’s frameworks, rather than blocking as the traditional C APIs would.

Stuff like those, along with Accelerate and Keychain, are things I knew I wanted to talk about, and did the first few slides on Core Media and Core Services by pointing out reasonably findable information from Apple’s architecture docs.

The eye-openers for me were down in the “System” level of Core OS… the various C APIs that iOS inherits from its open-source roots in FreeBSD and NetBSD (i.e., Darwin). These aren’t substantially documented in Xcode (though they do enjoy syntax highlighting and sometimes code-completion). The documentation for these is in the man pages, which of course makes sense for long-time Unix programmers, but maybe less so today… if I’m writing in Xcode for a separate iOS device, the Mac command-line is a rather counterintuitive location to look for API documentation, isn’t it?

So the trick with calling the standard C libraries is finding out just what’s available to you. Apple has links to iOS Manual Pages that collect a lot of these APIs in one place, but they are largely unordered (beyond the historical Unix man page sections), and being programmatically generated, Apple can only offer a warning that while some APIs known to be unavailable on iOS have been filtered out, the list isn’t guaranteed to be completely accurate. There’s also a consideration that some of these APIs, while they may exist, are not particularly useful given the limitations under which third-party iOS applications operate. For example, all the APIs involving processes (e.g., getting your PID and EUID) and inter-process communication are presumably only of academic interest — the iPhone is not the campus timeshare mainframe from 1988. Similarly, ncurses is probably not going to do much for you on a touch display. OK, maybe if you’re writing an ssh client. Or if you really need to prove that Angry Birds could have worked on a VT100.

Another way of figuring out what’s there — if less so how to actually call it — is to go spelunking down in <iOS_SDK>/usr/lib and <iOS_SDK>/usr/include to get an idea of the organization and packaging of the standard libraries. Had I not done this, I might not have realized that there is a C API for regular expression matching (regex.h), XML parsing with libxml2 (both DOM and SAX), zip and tar, MD5 and SHA (in CommonCrypto/) and other interesting stuff.

On the other hand, there are cases where code libraries are available but don’t have public headers. For example, libbz2.dylib are libtidy.dylib are in usr/lib but don’t seem to have corresponding entries in usr/include. That begs the question of whether you could call into these BZip and Tidy libraries and remain “App Store safe”, given the apparent lack of a “public” API, even though you could easily get the headers for these open-source libraries from their host projects. Heck, kebernet pointed out to me that tidy.h and bzlib.h are available in the iPhoneSimulator.platform path, just not iPhoneOS.platform.

It would be nice if there were better visibility into these libraries, though their nature as unrepentant C probably scares off a lot of developers, who will be just as well off scouring Google Code for a nice Objective-C alternative (provided the license they find is compatible with their own). My takeaway is that there’s even more functionality at these low levels than I expected to find. I’ll probably at least consider using stuff like libxml2 and regex.h in the future.

Secret APIs

Discussing Apple’s Java deprecation, Java creator James Gosling blogged about the background of Java on the Mac, saying “the biggest obstacle was their use of secret APIs. Yes, OS X has piles of secret APIs. Just like the ones that Microsoft had that contributed to their antitrust problems.”

In a recent Q&A at Google, available on YouTube, he elaborates further, around 43 minutes in (embedded YouTube clip will take you right there, otherwise read the blockquote):

[youtube=http://www.youtube.com/watch?v=9ei-rbULWoA&start=2575]

At Sun, we had worked with them to try to take it over. But there were all kinds of issues, and it was mostly things like, you know, to integrate properly into the Mac OS, there were a bunch of secret APIs. And in their integration, there were all these secret APIs, and they wouldn’t tell us what they were, we just knew they were there. And then, you know, it’s sort of like half their brain wanted to give us the code, half their brain is like “no no no no no, we can’t”. So, nyah, that was all kind of spastic.

The fact that Dr. Gosling brings up “secret APIs” repeatedly when talking about the subject makes me think that he really wants to make this point that Apple’s use of secret APIs and its intransigence has been a major problem for Java on the Mac.

But… is it true? How big a deal are secret APIs in OSX and iOS anyways?

Nobody denies that there are undocumented and otherwise secret APIs throughout both OSX and iOS. They are easily found through techniques such as reverse-engineering and method swizzling. On OSX, they can be called, provided you can figure out their proper usage without documentation. Technically, this is also possible on iOS, although use of non-public APIs will get your app rejected by the App Store, so it’s largely pointless.

The benign explanation for secret APIs is that they’re used internally but haven’t been fully vetted for use by third-parties. We’ve all written code we’re not proud of and wouldn’t want others calling, or at least written utility functions and methods that were only thought through for certain uses and aren’t known to be appropriate for general use. An interesting example is iOS’ UIGetScreenImage function. As a devforums thread indicates, Apple started allowing use of this private API in 2009 because there wasn’t a good public alternative, with the proviso that its use would be disallowed once a suitable public API was released. This occurred with the arrival of AV Foundation in iOS 4.0, and direct calls to UIGetScreenImage are again grounds for App Store rejection.

Aside from technical grounds, another reason for secret APIs is legal entanglements. There was an example of this in one of my earliest blogs: Apple licensed AAC encoding for OS X and for its own apps on Windows (iTunes, QuickTime Player), but not for third-party apps on Windows. According to Technical Q&A QA1347, a developer who wanted to provide this functionality on Windows would need to license the AMR encoding separately from VoiceAge, then provide proof of that license to Apple in order to get an SDK that would allow their code to make the secret call into QuickTime’s encoder.

But what can we say about Dr. Gosling’s complaints about secret APIs and Java? Certainly it plays well to the passions and politics of the Java community, but I’m not yet convinced. We know that most of Java actually ports to the Mac pretty easily: Landon Fuller’s “Soy Latte” project ported JDK 6 to the Mac in just a few person-weekends, and was later incorporated into OpenJDK’s BSD Ports subproject. But that left out some hard parts with intense native entanglements: sound, and the UI (Soy Latte, like most vanilla Java ports, relies on X11). Gosling acknowledges this in his blog, saying of these secret APIs that “the big area (that I’m aware of) where these are used is in graphics rendering.”

However, does this seriously mean that porting the Java graphics layer — Java2D, AWT, and Swing — is impractical or impossible without access to these secret APIs? It can’t be. After all, SWT exists for Mac as well, as a third-party creation, and it does the same things as these missing pieces of OpenJDK. In fact, SWT is more tightly-coupled to native code, as its whole approach is to bind Java objects to native peers (originally in Carbon, later in Cocoa), while Swing is all about avoiding native entanglements and instead painting look-alike widgets. Furthermore, I think Java’s rendering pipeline was switched over to an OpenGL implementation a while back, and that’s a public API that exists on OSX. So this kind of begs the question: what does Java need that isn’t provided by a public API? It doesn’t seem like graphics can be the problem.

The conspiracy theorists could argue that Apple has its own APIs that are more performant than the public APIs. Maybe, but what would be the point? Microsoft was roundly criticized for this in the 90’s, but Microsoft had more cases where their own products competed directly with third parties, and therefore could have incentive for their OS team to give a secret hand to the applications team. With Apple, software is their second-smallest revenue segment, and there are fewer cases where the company competes directly with a third-party rival (though there are clearly cases of this, such as Final Cut versus Premiere). Often, Apple’s software serves a strategic role – iLife may be more useful for selling Macs than for selling itself on DVD to existing Mac owners. So sure, Apple could be using secret APIs to give itself a leg up on competitors, but it’s hard to see how that would really be in their self-interest.

Having said all this, I’m still thwarted by a private API I needed this Summer: the “suck into a point” animation isn’t exposed by a Cocoa API on OSX, and asking for help on cocoa-unbound didn’t turn up an answer. Apparently, it’s possible on iOS, but via an undocumented method. Why this isn’t public on OSX or iOS, I can’t imagine, particularly given that Apple’s apps have made it a fairly standard behavior, meaning users will expect it when you use the round close button on a free-floating view. Oversight? Not ready for public consumption? Apple just being dicks? Who knows!

Of course, that brings up the last point about secret APIs. At the end of the day, they’re almost always conveniences. If something is possible at all, you could probably just do it yourself. I don’t know exactly what transforms are involved in the suck-to-close animation, but it’s surely possible to create a reasonably close approximation with Core Animation. Similarly, instead of calling QuickTime’s secret AAC encoder on Windows, you could license some other library or framework, or write your own. It might not be easy or practical, but if Apple can move the bits in some specific way, it must at least be possible for a third-party to do the same.

Already thinking about a next book

I’ve been away from the blog on a pretty grueling day-job contract. It’s actually been positive for my work on the Core Audio book: nothing encourages a side project like disliking your day job.

Squirreling away some morning hours between 5 and 9 AM over the last two weeks, I’ve managed to get first drafts of the first two chapters done (admittedly with a helpful start from the fragments left from Mike and Kevin’s initial work on the book). I actually surprised myself by finding a concretization of the Nyquist theorem, which (basically) says that to reproduce a frequency, you have to sample at at least double that rate. In chapter 2’s digital audio intro, I added an example to get readers looking at raw samples, writing out their own waves as PCM samples. An inner loop uses a samplesPerWave value, and it occurred to me that something interesting happens at the Nyquist point. If you’re sampling at 44100 Hz, then for a 22050 Hz frequency, samplesPerWave is 2. That’s the minimum for a perceivable, repeatable pattern: at a higher frequency, you have less than 2 samplesPerWave and therefore no more repeating pattern, no wave.

Not a big deal, but it was a nice little “aha” moment to stumble across.

I’m enjoying having momentum on Core Audio, and since I wrote that never-published series of articles (yep, the publisher is still wedged) on low-latency use of units and OpenAL, I’ve already worked through some of the conceptually-hardest material, so there are fewer unknowns looming ahead than normal. Which I wouldn’t have expected for Core Audio, surely the hardest topic I’ve ever written about.

I’ve found myself wondering what would be a good topic to pitch and hopefully write about in late 2010, time and budget permitting (writing for anyone other than the Prags is a financial indulgence… it most certainly does not pay the bills).

Here are a few things I’m thinking about.

  • HTTP Live Streaming – The only choice for streaming video to an iPhone OS device, and a compelling choice for streaming media in general. Would probably cover setting up your own server, working with CDNs that support it, writing your own client (if QTX or MediaPlayer.framework doesn’t work for you), encryption and DRM, etc.
  • Core Services – all the C functions that none of the introductory Cocoa books tell you you’re going to need for a serious iPhone or Mac application. Core Foundation, CFNetwork, Keychain, System Configuration, Reachability, stuff like that.
  • C for iPhone – I’ve mentioned this before, how I wrote about 100 pages of this for the Prags, and everything was fine until it wasn’t. With all the people getting into iPhone OS development without a C background and the problems of applying the very dated K&R to modern C development (especially for beginners, who won’t follow its Unixisms or its analogies to Fortran and Pascal), I still think we badly need a C intro that can serve as a prerequisite to all the iPhone books (including ours) that assume C experience. Plus, I find it a perversely fun topic to speak about (see the slides of my CodeMash session).
  • OpenAL – There’s, like, next to nothing to get beginners started with this audio technology, and what’s out there is frequently wrong or outdated (for example, some “getting started” type blog entries use the deprecated loadWAVFile that isn’t even present on iPhone OS). I’m actually thinking of a radically different format for this book, but don’t want to give it away just yet.

I was going to make this a poll, but I don’t think I have enough readers to make that viable, and all the poll plugins for WordPress suck anyways. So if you’d care to vote for one of these options, please post a comment. Besides, I’d love to have new registered users who aren’t offshored spammers.

There will likely be an update to iPhone SDK Development as well, when SDK changes warrant, but that hasn’t happened yet. Let’s see when we get a 4.0 and what’s in it.

CodeMash 2010 wrap-up

CodeMash continues to be one of my favorite conferences to speak at and attend, both because of its convenient location — the Kalahari indoor waterpark in Sandusky, OH, just a four-hour drive from Grand Rapids — and because of its unconventional mix of topics. The concept is to bring together a variety of development styles and platforms: .NET/Java/scripting, server/client/mobile, open-source/commercial, etc. In the last few years, there’s been an increasing Mac/iPhone presence, maybe not enough to count as its own track, but certainly enough to draw attendees from some of the other technologies. And that’s the point of CodeMash: sharing ideas, and seeing what the other guys and girls are up to.

Aside: based on multiple trips to CodeMash, WWDC, JavaOne, and miscellaneous other conferences, I’m struck by how the Microsoft technologies attract far more female developers than Java or Mac/iPhone do, with the open-source scripting languages (Ruby, PHP, etc.) a distant second. Absolutely no idea what’s up with that, but suffice to say if you see a woman at CodeMash, and she’s not Dianne, then she’s quite likely a .NET developer.

This year, three of the four members of the Java Posse were in attendance at CodeMash, doing an atypically-listless panel on Wednesday night, and a bunch of sessions. I felt I should go see all my friends’ sessions, so I went to Dick Wall’s on “Funky Java” and Scala, Carl Quinn’s on tools, and Joe Nuxoll’s on Photoshop for engineers. I came away from these interested in Dick’s company’s DNA science, reminded of Hudson’s value to well-managed teams, and sadly weary of Photoshop bling and what it takes to achieve it in code. Maybe I’m just burned out by the App Store shininess arms race.

I also assisted Daniel Steinberg with his 4-hour Cocoa tutorial, built around a big example project that he wisely saved off as 20 “stages” that attendees could download and review. Daniel also did a 1-hour Cocoa session which served as outreach to developers looking at the Mac platform and not yet ready to jump in.

Attending friends’ sessions filled up most of my dance card, but I did hit a few other things. Probably the most valuable one I went to was Jim Weirich’s “Source Control for People Who Don’t Like Source Control”. The gist of this was to present the design of a hypothetical source control system with modern features and clever ideas… that turns out to be Git. Given that I have a natural aversion to anything loudly and obnoxiously touted by the Linux community as superior (usually based only on the fact that it is from the Linux community), I’ve never really given Git a serious chance, and this was an eye-opener. Git may, indeed, not suck. FWIW, his talk is available as a Pragmatic Screencast.

As for my own talks, I did a half-day iPhone tutorial that ditched the slides entirely and worked entirely from Xcode. It’s a sensible, hands-on approach that I’ll be using from now on. I did three projects: a trivial web browser, a tab-based collection of converters (since those are so damn popular in the App Store), and a conference session browser (as a navigation app). I chose these because of a conscious desire to focus on the repeated creation of view controller classes and their corresponding GUIs, which is the bread-and-butter of iPhone development. It’s good exercise to really get used to creating views in IB, wiring everything up, setting the File’s Owner class, etc. Lots of beginner problems come from missing connections, particularly VCs that aren’t wired to views, so I thought it would be good pedagogy to focus on that stuff first, even at the expense of rhapsodizing about Obj-C or covering more iPhone frameworks.

I also did a session on iPhone tricks and tips that was a mixed bag: I pulled it together kind of late, so some of the media tips were kind of pedestrian (like setting your audio session category to adjust mixing and ring/silent behavior). Still, there were a couple wows worth remembering, specifically using multiple targets to build “lite” and “full” versions, and using keychain to persist data in a way that survives wipes. Slides here

The session I think I was happiest with was “Oh Crap! I Forgot (Or Never Learned) C!” This was actually the last gasp of a book I was writing last year called Just Enough C To Program the iPhone, a language book that used the iPhone SDK as a workbench. The idea of the book was to help the scripters and Flash developers who got lost in the pointer stuff in our iPhone book, as well as first-time programmers who wanted to develop iPhone apps right away, even if they had never programmed before. In short, it would serve as the prerequisites for our, or anyone else’s, iPhone book. But it’s not happening: it’s one of those projects where everything was fine until it wasn’t.

Still, I sometimes find I enjoy the directness, the concreteness of programming in C.

So that’s something I tried to bring out in this presentation: not just that you might have to use C for some reason, like calling into native code from your higher-level language, but that C’s performance, popularity, and even its primitiveness are traits to be admired and enjoyed. The last third of it really got into the traditional C “hard parts”: pointers, malloc()/free(), pass-by-value, arrays as syntactic sugar over pointers, when struct members take the dot versus the arrow operator, memory math, etc. Slides here.

The iPhone tutorial is a consistent big draw, but I just might propose a half-day “C re-education camp” tutorial for next year, to fully immerse attendees in the C way. Maybe with some OpenGL (which is called from C) so it’s not all about the command line. Any takers?

Conferences 2010

I’m speaking at two conferences in early 2010, as indicated by the badges in the right side column.

First is CodeMash in Sandusky, OH, January 13-15. I’m doing one four-hour “precompiler” tutorial on iPhone programming, and two sessions.

No, of course they’re not done yet. But here’s a bit of what I’m planning:

  • Introduction to iPhone SDK – I’ve decided that rather than put up some slides to walk through the basics, I’m going to teach the entire tutorial in Xcode and Interface Builder. This means I need to not only write my examples in advance (duh), but to pull together a bit more of a script so I know where to stop and explain things: “Objective-C uses square braces for method calls, which are really better thought of as message dispatches”, “IBAction is synonymous with void, but tells Interface Builder it’s OK to accept a connection to this method”, etc. I’m also thinking about how to cover the most truly useful material in four hours. I think I’d like to do the trivial browser in the first hour to do basic project building, IB, coding, etc., a tabbed app in the second hour to play with multiple view controllers, and a navigation app in hours 3 and 4, since those are so bread-and-butter. The nav app might use the webservice of the conference’s session list… if I think we can really pull off tables, networking, and XML parsing in two hours. Gonna have to rehearse to convince myself it can be done in a group setting in that kind of time.
  • How Do You Do That on iPhone? – This is just going to be a grab-bag of non-obvious techniques that you can’t get from the docs and instead have to learn from forums, programming guides, word-of-mouth, etc. Things like custom table cells and building the “full” and “lite” versions of your app with one Xcode project (hint: understand how “targets” work).
  • Oh Crap! I Forgot (or Never Learned) C! – In a way, this is the last gasp of a book that I wrote 100 pages of before it just ended up not happening. My thesis was that for all the developers who never learned C, or did but forgot, it’s a real bitch to be thrown into the world of pointers and malloc and life without objects, especially when the premier guide to the language was last updated during the Reagan administration, and contains no-longer-helpful analogies to Fortran and Pascal. The idea of the book was to be a C primer that you’d work through with the iPhone SDK, not in order to learn the iPhone APIs right away (we already wrote that book), but so that there would be a specific workbench, freely and easily available, for learning the C language (this is where K&R basically says “use cc on the command-line and if that doesn’t work, go ask a sysadmin.”). The session is going to survey the language from the point of view of scripters and other modern-day programmers, with particular attention to memory-management concerns, and idioms that are unique to C (things like setting up “context objects” for callbacks, because you don’t have closures).

Then, in April, I’ll be at 360iDev in San Jose (register with my special link), speaking on the topic of Core Audio. The talk, Core Audio: Don’t Be Afraid To Play It LOUD is one where I’m going to try to play up the fun factor a little more, and embrace the fact that Core Audio is a goddamned hard API to master. If you can do anything in Core Audio, you should feel awesome, and I’ve found that small successes in this API make you want to learn more. Oh, and bonus points if you catch the reference in the session title.

BTW, more news on the Core Audio front in an upcoming post…