1

UpdateSystemActivity(OverallAct);

The docs explain that you fire this every 30 seconds. On the surface, this looks like a hack and well, I don’t need a Carbon C call for that, I can fake a mouse event every 30 seconds.

This is out for good anyway, given that it doesn’t compile on Snow Leopard on x86_64. Carbon 64-bit will never arrive.

Turns out that the modern way to disable sleep uses IOKit. Apple has a doc for that too. Here is Listing 2:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#import <IOKit/pwr_mgt/IOPMLib.h>
 
...
// kIOPMAssertionTypeNoDisplaySleep prevents display sleep,
// kIOPMAssertionTypeNoIdleSleep prevents idle sleep
 
IOPMAssertionID assertionID;
IOReturn success = IOPMAssertionCreate(kIOPMAssertionTypeNoDisplaySleep, 
                                    kIOPMAssertionLevelOn, &assertionID); 
if (success == kIOReturnSuccess)
{
 
    //Add the work you need to do without 
    //  the system sleeping here.
 
    success = IOPMAssertionRelease(assertionID);
    //The system will be able to sleep again. 
}

With any sample code that I’m gonna try to use in my apps, I take the time to understand what’s going on, and to read the docs for that with which I’m not familiar. (Don’t you? That’s fine, just throw someone else’s potential garbage in your app. I’m sure it won’t bite until you least expect it.)

I’m getting back an IOPMAssertionID, so I proceed to look that up in the XCode documentation viewer. And there’s nothing to be found. A look in IOPMLib.h tells me it’s a 32-bit unsigned integer and therefore not very interesting.

So, I move on to look up IOPMAssertionCreate() to find that it was introduced in Leopard only to be deprecated in Snow Leopard in favor of IOPMAssertionCreateWithName(). IOPMAssertionCreateWithName() has an extra parameter over IOPMAssertionCreate(), and it’s a name as you might imagine. I don’t care for having deprecated calls in my code so IOPMAssertionCreateWithName() it is. Caveat: IOPMAssertionCreateWithName() is not publicly available in Leopard, so either use IOPMAssertionCreate() in Xcode3.1/Leopard or compile in XCode 3.2/Snow Leopard and IOPMAssertionCreateWithName() will work when run on Leopard.

The sample code from Apple lists two assertion types that you can use: kIOPMAssertionTypeNoDisplaySleep that prevents display sleep, and kIOPMAssertionTypeNoIdleSleep that prevents idle sleep.

My testing indicates that kIOPMAssertionTypeNoDisplaySleep actually prevents both display and idle sleep. The intended use case for this is clearly along the lines of playing a movie or running a presentation.

kIOPMAssertionTypeNoIdleSleep will still allow the display to sleep, but the Mac never sleeps unless it runs out of battery power. Use cases for this fall into the category of ‘computations that may not finish before the computer sleeps’, such as bouncing an mixed audio/video file to disk or rendering a 3D image, etc.

Here is an example project that allows you to test both behaviors. Note: The project uses IOPMAssertionCreate() and not IOPMAssertionCreateWithName() in order to compile on both Leopard and Snow Leopard.

In keeping with good practice, I have filed bug reports with Apple for pieces of the documentation that I see as missing.

Every now and again while doing development you stumble upon something that makes you go, hmmmm. Those are normally the moments at which you have to ask yourself, “is this a bug or a feature”. If it’s a bug, then you should file a radar with Apple, however, what if it’s a feature? You blog about it, of course!

I have done a bit less iPhone development than Marcus, so he was a little stumped while looking through some of my code where I created a view controller using a simple alloc/init. Most interestingly is that fact that the app works. It loads the correct nib and displays the view just fine without any trouble. Notice I said alloc/init and not alloc/initWithNibName. How can this possibly work? How did my controller “know” which view to use?

Well, the answer is pretty simple, but not immediately obvious. I could try to act like I meant to use an undocumented feature because I’m just that cool, but the fact of the matter is I was in band. Marching band, even. Band people aren’t cool. Though the color guard thought we were cool. But I digress. I just inadvertently added the alloc/init code without thinking and never looked back since the view loaded and displayed just fine. After renaming the nib/xib in the project and in doing so causing the view to fail to load properly we were able to determine that there must be some underlying feature of view controllers where it will automagically look for a view based upon its own name.

Say Huh?

Yep. That’s correct. If you create a view controller with the name MySpiffyViewController, for example, and instantiate it with alloc/init in your code, it will assume that the nib you want is actually called MySpiffyView. Spiffy eh? Some people may call this a bug, but the fact that it works this way shows that it was intentional. Now, I recommend that you steer clear of intentionally creating your view controllers this way as Apple may decide it’s a bug after all and change (fix?) it in a future release. It is however an interesting undocumented feature at the moment.

You Can Duplicate It

Here are the steps if you want to try this yourself. Of course, you can just download the example project below if you don’t want to go through the steps.

1. In Xcode, press Command+Shift+N to open the New Project templates and select View-based Application in the iPhone OS category and click Choose….


2. Name the project SpiffyView and click Save


3. The first thing we need to do is change our code in the app delegate (called SpiffyViewAppDelegate.m) to add a UINavigationController.

   1 2 3 4 5 6

   - (void)applicationDidFinishLaunching:(UIApplication *)application { UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:viewController]; [[navController navigationBar] setBarStyle:UIBarStyleBlackTranslucent]; [window addSubview:[navController view]]; [window makeKeyAndVisible]; }

   This will enable us to navigate to the new view we create next.


4. Press Command+N and select View XIB under the User Interfaces category. Click Next. Name the file MySpiffyView and click Finish


5. Press Command+N again and select UIViewController subclass under the Cocoa Touch Classes category. Click Next. Name the file MySpiffyViewController.m and click Finish.


6. Next we need to create an action in the view controller created by the project template called SpiffyViewViewController. Add the following code to the respective .m and .h files as follows.

   1 2 3 4 5 6 7 8 9 10

   // Add this to your SpiffyViewViewController.h - (IBAction)showSpiffyView:(id)sender;   // Add this to your SpiffyViewViewController.m. Make sure you #import "MySpiffyViewController.h" as well. - (IBAction)showSpiffyView:(id)sender; { id controller = [[MySpiffyViewController alloc] init]; [[self navigationController] pushViewController:controller animated:YES]; [controller release], controller = nil; }



7. Now we need to connect a button to the action. In your project under resources, double-click SpiffyViewViewController.xib to open it in Interface Builder.


8. In Interface Builder, drag a button onto the view and change its text to “Spiffy View”


9. Now, Control-Click and drag a connection from your button in the view, to the File’s Owner and select showSpiffyView: in the ensuing menu. Save the file in IB.


10. Now, back in Xcode, double click MySpiffyView.xib to open it in Inteface Builder.


11. Change the File’s Owner class to MySpiffyViewController in the Identity tab of the Inspector.


12. Drag a label onto the view. Double click it to edit it and change the text to “This is the super spiffy view.” Save the file in IB.


13. Everything should be hooked up now. Go back to Xcode and “Build & Go”. Your app should load in the simulator. When you see the “Spiffy View” button, click it and it should show your new view!!

Conclusion

So how is that working? The only answer is there must be some underlying code that the view controller is using to locate its nib. Remember, we never told our controller what nib to use. We simply called alloc/init and voila, it works!!

If you think I ought to register this as a bug with Apple, let me know your thoughts in the comments. Oh and one other thing. I may have been in band, but I married a smokin’ hot cheerleader. Take that all you cool people. ;-) Until next time.


Example Project SpiffyView.zip