SDK posts

Another Tuesday, another beta...and wait one second! Today's not Tuesday, is it? Regardless, a spankin' new hot beta awaits you at the Apple iPhone dev center (developer credentials needed). As usual, the new release is under NDA. Please consult the dev center for release notes and other details.

And to all you TUAW readers, Irish or not, ERIN GO BETA!

Developers have found further evidence of multitasking support for 3rd party iPhone apps in the latest beta (3.2 beta 4) of the iPhone SDK, and suggest that it will become a reality this summer.

9to5 Mac reports on a new line found deep within the latest iPhone SDK. Specifically, SpringBoard.js has a reference to a "multitasking dialog box" that did not appear in version 3.1.3 of the SDK; it seems that it's new to version 3.2. Of course, there's no assurance that this refers to 3rd party support for multitasking, but it is new.

Additionally, Appleinsider's souces with "proven track records" state that Apple has developed "a full-on solution" for 3rd-party multitasking which will be a part of iPhone OS 4.0. No specifics were given on how it will be pulled off or how it will address the two main concerns: battery life and security.

Let's assume that Apple's plan addresses the security issue, but battery life still presents a problem, one that was supposedly addressed by Push Notifications. Apple's remote notification service allows applications to offload polling processes to web servers. By keeping the update algorithms working off the device, the iPhone's battery is spared. Certainly the iPhone itself must take on the task of keeping all of those apps up and running.

It should also be noted that iPhone OS does not use a paged memory model. That means, multi-tasking applications must compete for the same memory space, making it more likely that apps will receive memory warnings and even crash when they use too much memory. That's not an issue in the one-app-at-a-time space, but a real problem with multitasking

Of course, the iPhone OS is already fully capable of multitasking. In order for non-Apple apps to participate, Apple must lift the current restrictions within the OS. That's something the company won't do until the iPhone engineers have devised the best and safest method. As for iPhone OS 4.0, Appleinsider notes that it's got "a ways to go." Hopefully we'll have an answer in July.

Unit testing refers to a software validation methodology that allows programmers to test individual program units for correctness. It's been an ongoing question in the iPhone developer community as to whether the iPhone's view controller class is testable or not.

In response to these discussions, iPhone developer Jonah Williams has written up a view controller unit testing how-to over at the Carbon Five web blog. His write-up offers examples that show how to incorporate some best practices into your code.

Williams points out how broken NIB bindings are a common problem for iPhone OS applications. To address these issues, he regularly adds simple assertions that test that each IB outlet and action are set properly from inside his view controller class implementations. These assertions check that IBOutlet instance variables are not set to nil and that IBAction targets have been assigned, adding a layer of protection against broken bindings.

Another typical view controller issue involves responding to application memory warnings. To respond, he adds tests that ensure that each view-dependent property gets correctly released and re-created as views unload and then later reload. By building these into test methods, he can execute this behavior on demand, and ensure that the sequence will execute flawlessly in real world conditions.

Finally, Williams discusses view controller interdependencies. Often instances are tightly intertwined, with objects acting as clients for each other. For example, a simple table view controller, living within a navigation controller, might present a detail view via yet another view controller when a row is selected. That's three separate controllers to account for, when you really only want to test one at a time. Williams suggests isolating these view controllers away from their interdependencies to test each component separately and provides examples of how you can do so.

What made Williams' approach pop for me is how he carefully exposes and isolates dependencies for testing. These are features that can otherwise be hard to inspect and validate in the normal course of programming. His write-up is well worth reading through, and provides an excellent jumping off point for investigating view controller unit testing.

Developers who try to log into the iPhone dev center, the Mac dev center or iTunes Connect this afternoon are being greeted with the traditional yellow sticky note or the Sorry! note above, indicating that some sort of update effort is underway. With the on-again, off-again release of the 3.2 beta 3 version of the SDK in late February, and the unconfirmed-but-likely launch of the iPad on March 26th, no surprise that there are fixes and finish to take care of on the site.

When it comes back up, we'll let you know; if you spot anything of consequence when it does, please let us know.

Update: It's back up. The big news is on the Mac side, with the introduction of the $99 price point for ADC membership.

The new beta version of the 3.2 SDK (beta 3, for those of you keeping track) is now available for download. The Apple developer site will likely be getting slammed over the next hour or two, so plan your downloads accordingly. The beta is available to all paid members of the iPhone developer program, with at least the $99/year membership. You will need your credentials to sign in and download the new SDK.

As usual, the new beta SDK is under NDA, so please go check out the details for yourself to get further information about the changes between this beta and the last. Good luck, and happy programming!

Update: 6PM Pacific. It's baaaaaaaack.

Update: Here then gone? Readers report that Apple seems to have pulled Beta 3 for the moment and when I returned to Apple's iPhone developer site, I saw the same. Watch this space. We'll update as we find out more.

Update: This was not an accidental upload, per Michael Jurewitz, the Mac and IPhone Applications Frameworks and Developer Tools Evangelist:

UPDATE: Engadget confirms video support, file downloads and local storage, plus more text tools (user entries in Dictionary, for example), location-aware ads in Maps, the ability to draw to external displays and prototype support for a "handwriting keyboard." Neat!

9to5Mac reports that it has found both icons and code in the iPhone 3.2 SDK that could be indicative of video chat functionality coming to future iPads and/or iPhones. Specifically, there are icons labelled "AcceptVideo" and "DeclineOrEndVideo" complete with camera icons reminiscent of those already used by iChat, as well as a text string in the TelephonyUI which reads: "setButton2:_updateButtonSettings:_buttonWidthinitForVideoChatWithFrame"
-- both of which are indicative of at least the embryonic beginnings of coding for video chat.

This isn't the first hint we've heard of video conferencing coming to some future iDevice. Apple-issued replacement parts for the iPad's frame contain a slot identical to the one used for iSight cameras on the MacBook, and another repair company has recently issued pics of what it claims is the next-gen iPhone's front face, complete with a mysterious hole that could be used for a front-facing camera. Many have cited the lack of any kind of camera and therefore the impossibility of video conferencing as one of their biggest disappointments concerning the iPad. General consensus among analysts is that even if Apple doesn't include a camera in the first-gen iPad, it almost certainly will next year; 9to5Mac's unearthing of video chat code in the iPhone 3.2 SDK is only the latest bit of evidence in support of that theory.

[Via MacDailyNews]

iPhone developer Jonathan "Schwa" Wight offers a great little trick for creating pixel perfect glassy buttons: using the unofficial UIGlassButton class in the simulator to build your art. In his code paste, he shows how to build a button and render it to a PNG, which you can then save to your desktop.

It's a great little trick, and one worth adding to your development arsenal. Be aware that UIGlassButton is a private class, and one that has long since been relegated away from the official SDK development path. Although it continues to work on the Simulator, it's not for use on the iPhone itself or in App Store projects.

Continue reading on to find the code. Don't forget to substitute your own user folder into the code (in my case, "ericasadun") for Jonathan's ("schwa").

Approximately one hour after uploading his new application update to iTunes Connect, Bristol-based iPhone developer Rob Jonson of Hobbyist software got the surprise of his week: an official Apple green light. His latest update to his VLC Remote application had been approved and was ready for sale. VLC Remote allows you to control a Mac- or Windows-based VideoLAN playback client from your iPhone, basically duplicating many of the features you'd get from a standard Apple Remote.

His update wasn't complicated. "It was a simple problem," he told me over the phone this morning. "One of the buttons stopped working because of a stupid error. I missed a break in a case statement." So he uploaded his bugfix at about 11 PM local United Kingdom time.

Just before midnight, he checked his e-mail before heading off to bed. The Apple approval was sitting in his in-box. A recent update, submitted last week, had taken only a day to receive approval. "With 24 hours, I was very impressed. But one hour? I couldn't believe it. Clearly Apple has changed the game."

Update: This picture speaks a thousand words. Courtesy of Tom Harris of InsiderApps. This is a different app from Jonson's

We first heard about the Parrot AR.Drone, an iPhone-controlled RC quadrocopter, back when it made such a big splash at CES, but unfortunately, since we weren't there, we didn't get to see it in person. Fortunately Parrot did come by Macworld, and the day before the show, we finally got to see their iPhone-controlled, dual camera-equipped, high tech toy in action.

So what's the verdict? It's not super easy to fly (we crashed it into the walls, the ground, and even their marketing guy), but it's the real thing -- the extremely light (3/4 of a pound, as our own Steve Sande estimated with remarkable accuracy) quadricopter is packed with all kinds of fun gadgets, including variable speed rotors, the ability to lift off, hover, and land on its own, and super-sensitive touch controls along with two 640x480 VGA camera feeds running back to the iPhone via 802.11G Wi-Fi. We're not sure how ready it actually is for market (or what it'll cost yet), but the AR.Drone does what it says on the not-yet-designed box: Allows you to control a real quadricopter with and through your iPhone.

Read our impressions of the hands-on below, and don't forget to stay tuned -- we'll have video of our demonstration later on.

Just a quick heads up to all your iPhone and iPad developers out there. The new version of the 3.2 SDK is now available for download. The Apple developer site is getting a bit slammed right now but it looks like a really exciting new update. Can't wait to start playing with it myself.

As per last time, the new beta SDK is under NDA, so please go check out the details for yourself to get further information about the changes between this beta and the last.

Apple's excited about mobile advertising (and it certainly seems like they're setting up a plan for local ads), but to devs, they say, "not so much." Apparently they've sent out a message that says location services should only be used to provide "beneficial information," not targeted advertising. Any apps that include ads targeted to where you and your iPhone are will be rejected posthaste, says Apple.

There's a few things going on here -- Mobile Entertainment wonders just what "beneficial information" means. Certainly apps like Foursquare and MyTown provide business information based on your iPhone's location, and Foursquare especially is working on local deals with places that you've checked-in to -- is that considered advertising?

And a few developers, including our friend Craig Hockenberry (MacNN messed up Chock's name in their post) say that Apple wants location-based ads for themselves. Kind of a jerk move by Apple, but if that's where the money is, I guess you can't blame them.

Are you doing production work and beta work at the same time? Need to install more than one SDK at once? If you've downloaded the 3.1.3 SDK and need to install it on the same system as the 3.2 beta SDK, you'll want to use the Xcode installer's destination chooser.

When given the option of where to install, click on the Developer folder to reveal the pop-up shown here to the right. To create a new folder/location choose "Other..." and use the standard file browser to create and select that location.

I personally use a named folder for all beta installs. My 3.2 beta is located in /Developer32 and I used the standard /Developer path for my 3.1.3 SDK update. Both SDKs coexist in peace with each other, although I did have to assign separate key macros (I'm a Quickeys addict) for normal Xcode and Interface Builder (in /Developer/Applications) and the beta versions of the same (in /Developer32/Applications for me). Having both SDKs available and separate will help you make sure you can test and code in both environments quickly and easily.

In pixel-terms, the iPad offers a much larger workspace to develop on than the iPhone but in terms of the human experience, it's not that very far away from iPhone programming. The two share an underlying operating system and a large overlap in human interaction realities. Here are just three of those overlapping iPhone development realities. Consider taking these ideas into account as you're building your new and updated applications for the iPad.

Human fingers are big. Although the iPhone has a much smaller screen than the iPad, the size and shape of the typical human finger does not change between the two devices. Do not design interaction elements for the iPad smaller than, say 40-by-40 pixels in size.

When in doubt, design larger rather than smaller. The iPad with its larger screen is more likely to be held further away during use than the iPhone, which is often raised fairly close in during use. Build your on-screen objects accordingly. With its 1024x768-pixel screen, the iPad has the room for clean, large interaction elements. Use that space to better compliment the human finger.

Attention spans are short. Like the iPhone, expect your users to approach the iPad in a sporadic netbook-style fashion. Design your applications around short interaction periods and prepare for your application to be cut off as a user stands up to grab his next Orange-Cranberry Frapaccino.

Always save your application state between sessions, as much as you possibly can. A well designed app should relaunch quickly and, upon relaunching, approximate the same task your user was performing the last time the program was run. This can demand diligence on the part of the programmer, but is worth the time investment due to the payoff in user satisfaction.

One more tip after the break!

Thanks Scott Lawrence, |Agent

Time to update your iPhone SDK to 3.1.3! It's a required update, otherwise Xcode will not recognize or work with your 3.1.3 device. Head on over to the iPhone dev center (developer credentials needed to log in) to download the latest version.

As always, the iPhone SDK includes Xcode, the iPhone simulator, and other tools for developing applications for iPhone and iPod touch. If you want to develop for the iPad, you'll need to join the $99/year developer program and download the 3.2 SDK instead.

It's been nearly a week now since Apple lifted the restrictions against using VoIP over 3G to place calls on the iPhone. Within hours of the withdrawal of restrictions, iCall [iTunes Link] and fring [iTunes Link] both updated their backend to allow users to place calls over a 3G connection. In neither case was it even necessary to download an updated version of the app from the App Store; both iCall and fring basically just "flipped a switch" behind the scenes that allowed VoIP over 3G. After almost a week, neither app has been pulled from the App Store, so it seems VoIP over 3G is here to stay.

What about Skype? Skype is apparently "awaiting clarification" from Apple. They want to make sure the updated terms of the iPhone OS 3.2 SDK also apply to the 3.12 SDK before they submit an update. This caution from Skype is somewhat puzzling considering at least two other apps have been merrily humming along with VoIP over 3G enabled for almost a week without any punitive measures taken against them; fring even allows users to place VoIP calls over 3G through a Skype account. We contacted Skype three days ago to get some clarification of our own, but they haven't got back to us.

Here's the thing, Skype guys: if the state raises the speed limit on your local highway to 70 mph, changes all the signs, and stops pulling people over when they drive faster than 60, it's a pretty safe bet that you can drive 70 mph now. How much more clarification do you need? In the immortal words of Alan Shepard, "Why don't you fix your little problem and light this candle?"