OSX Internals

Tablet announced tomorrow?: “

Here’s the post.‘ It basically goes like this:’ Apple has said it is increasing its embedded device list this year.’ Ten-inch touch screens seem to be flying around Asia en route to Apple for late Summer.’

If there is a tablet with higher resolution/independence, developers are going to need a few months to tweak their apps for launch.” What if that $20 minimum Premium App Store happens to be for higher resolution apps?

Also, ARM’s new line of Cotex A8 architecture processors are tablet-worthy.’

Plus, I need something to look forward to…So here’s why we might see a tablet intro tomorrow.

Speaking of which, we’ll have the 9to5mac LivePanel open for the iPhone 3.0 Event.’ Stop by to see all information sources in one page.

‘

“

(Via 9 to 5 Mac – Apple Intelligence.)

iPhone OS 3.0 is coming, preview on March 17th: “

We just got the announcement, iPhone OS 3.0 is coming. Set your clocks, mark your calendars. It’s going down March 17th. Apparently, we’ll get a sneak peak at the new OS, as well as a look at a brand new version of the SDK. Exciting stuff indeed, and we’ll be there live at 10am PST (1pm EST) with the liveblog. Apple’s calling this an ‘advance preview of what we’re building,’ so we’re not expecting anything ready to go as of the 17th, but hopefully this will allow developers to start building toward future functionality (hey, how about some push notifications?), and presumably users won’t have too many months to wait after that for the real deal.

Filed under: Cellphones

iPhone OS 3.0 is coming, preview on March 17th originally appeared on Engadget on Thu, 12 Mar 2009 12:06:00 EST. Please see our terms for use of feeds.

Permalink‘|’Email this‘|’Comments“

(Via Engadget.)

Enable SpeedStep support on any capable Intel CPU: “As described on Wikipedia, SpeedStep ‘is a trademark for a series of dynamic frequency scaling technologies (including SpeedStep, SpeedStep II, and SpeedStep III) built into some Intel microprocessors that allow the clock speed of the processor to be dynamically changed by software. This allows the processor to meet the instantaneous performance needs of the operation being performed, while minimizing power draw and heat dissipation.’

Apple implements SpeedStep on certain Macs, but not all of them (and if you’ve built your own Mac, you may not have any SpeedStep support). Here’s how to enable SpeedStep on any Mac: Use the xnu speedstep kernel extension. Just download IntelEnhancedSpeedStep.kext.1.4.5.zip, then copy IntelEnhancedSpeedStep.kext into /System/Library/Extensions. Don`t forget to repair permission (in Disk Utility) when done, then reboot your…










“

(Via MacOSXHints.com.)

Core Animation for Mac OS X and the iPhone: “I think this book excellent at explaining the concepts and taking you from novice to understanding and applying Core Animation techniques in your next application. If you are new to Cocoa and the Mac then I would not recommend this be the first book you read, but for anyone who is serious about Cocoa development, then this book should be on your bookshelf.“

(Via Mac Developer Network.)

TUAW Bookshelf: iPhone in Action: “

Filed under: Analysis / Opinion, iPhone, iPod touch, TUAW Bookshelf

I’ve never found book reviews to be terribly helpful — technical book reviews even less so, as how one learns differs from person to person. Some iPhone devs out there learned simply by poring over Apple’s copious documentation. Others have been poking at the iPhone’s innards since pre-SDK days, learning as they went from forums and good old hacking. But once the NDA lifted, the floodgates of iPhone dev books opened.

Each book and each publisher has a different angle both in content and presentation. Each book may appeal to different people and different learning styles with different backgrounds (not to mention the numerous sites, blogs and video resources out there beyond what Apple provides). Over the course of 2009 we’ll be taking a look at some books in a new series called TUAW Bookshelf. We won’t just be covering developer resources, either. There’s a wide world of Apple-related reading out there, so stay tuned as we pull from our personal libraries and share our thoughts on what’s available.

To kick things off I read iPhone in Action by Christopher Allen and Shannon Appelcline, published by Manning. I wound up reading this first because one of the authors threw a few copies at me while at Macworld (sorry, I don’t know who you are and I can’t seem to find your business card!). We’ve got a few to give away, but look for that in another post this month.

iPhone in Action is designed to be a soup-to-nuts intro to almost everything you can develop for the iPhone. This includes web apps, which was the book’s main focus until the SDK was announced while they were writing. I don’t think shifting focus to the SDK is a bad thing, and as near as I can tell it didn’t hurt the content. In fact, I thought this book would make an excellent primer to Apple’s mobile platform efforts. Having taught technology for six years, I can say this is the book I’d use for a 100-level course in developing for the iPhone. I’m not saying it will make you into an expert overnight, and I’m not saying you can’t come to the table with zero dev experience, but as a starting point, it is wonderful. To find out why, keep reading…

Continue reading TUAW Bookshelf: iPhone in Action

TUAWTUAW Bookshelf: iPhone in Action originally appeared on The Unofficial Apple Weblog (TUAW) on Wed, 04 Mar 2009 18:00:00 EST. Please see our terms for use of feeds.

Read‘|’Permalink‘|’Email this‘|’Comments“

(Via The Unofficial Apple Weblog (TUAW).)

Debug Cocoa with DTrace Guide & Embedding DTrace into Xcode Video: “Debugging Cocoa with DTrace GuideFinally today I can finally reveal my Debugging Cocoa with DTrace guide to you. I had originally meant that this be a quick article on this site, but I kept adding and adding to it and finally by the time I knew what I had gotten myself into it was 40+ pages long. This guide isn’t as comprehensive as I would like even at the length that it is. It covers many”

(Via Cocoa Samurai.)

Understanding Flipped Coordinate Systems: “

Flipped coordinate systems always seem to confuse people, myself included. After working things out with pen and paper or handpuppets, I always feel like they’re not quite correct so I thought I’d resolve things here. If anything, I can refer back to it whenever I forget this stuff (which happens every couple years). First a refresher in case you need it: Cocoa Drawing Guide: Flipped Coordinate Systems.

The main thing to keep in mind is that while a flipped coordinate system is basically translating the origin to the top left and flipping things vertically, semantically it doesn’t mean that everything is upside-down. Images, text and other elements are supposed to render right-side-up. The flipped coordinates should affect where those elements are placed, not how they are rendered. Being flipped is a higher level notion and is separate from the
CTM. While setting something as flipped will flip the CTM, modifying the CTM without setting the graphics context as flipped results in everything being entirely upside-down, which is different. Many of the Cocoa classes and functions take flipped coordinate systems into account and will draw right-side-up for you but it gets tricky with images.

There are two sets of methods in NSImage to render it in a graphics context: the -composite... methods and the -draw... methods. I’ve put together an interactive example app to help illustrate the differences. It might help you to download it now so you can follow along. The figures included in this article are from that app

The -composite... methods actually seem to work in the sense that the image is always right-side-up. The problem is that it draws ‘upward’ from the draw point regardless of the coordinate system. The result is you have to calculate the compositing point at the upper left corner of the image instead of lower left. This is the result of these methods not taking the CTM into account in terms of scaling and rotation. That also means that if you scale your view up, the images won’t scale with it. While you can use this to your advantage in some cases (like rendering resize handles or labels which you want to stay the same size regardless of zoom), it’s usually not the right way to do it.

View scaled at 2x. Notice how the composited version does not scale.

The -draw... methods on the other hand follow the CTM properly. That also means that if the view is flipped, so is the image, so you need to adjust accordingly. So while these methods obey the CTM, they do not take into account the flipped flag of the context which would be the cue to draw things right-side-up.

The draw... routines follow the CTM, but not the flipped flag.

Now, to complicate things even further, NSImage’s themselves can be flipped. The reason for this isn’t to make the images upside-down. It’s there to provide a flipped coordinate system for whenever you draw into it (i.e. lockFocus on it, draw, then unlockFocus). It’s useful for when you want to tell a flipped view to draw into an NSImage, for instance. It’s basically like a flipped view; you don’t expect a flipped view to draw upside down, no matter which view you set as its superview. A subtlety to be aware of is that flipping an image loaded from a bitmap does not make too much conceptual sense (you are changing the coordinate system after the content has already been ‘drawn’) but it does have the practical effect of flipping the image vertically, which seems to be an implementation detail. Yes, flipping the image will work to ‘correct’ orientation problems in most cases but, depending on where your image gets its data (for instance if it has an NSCustomImageRep like the example app – see below) and whatever implementation-specific details lurk in NSImage, you may end up with undesired or inconsistent results.

As mentioned above, I’ve put together a little interactive example app (Leopard-only) to show how the different methods behave. In addition, I’ve written methods in an NSImage category (-drawAdjusted...) which will render the image correctly regardless of the flipped status of the coordinate system it draws into. As suggested in Apple’s docs, it does a transform reversing the flip, draws the image, then reverts the coordinate system back.

The image itself is drawn by code, not loaded from a bitmap. The reason for this is that I also wanted to illustrate using flipped images. It draws an arrow and some text to indicate the proper orientation. When flipped, the drawing code is exactly the same in that no coordinates are recalculated. The text content is changed to compensate for the new orientation. Notice how the text renders right side up no matter the flip state of the image; an indication that the NSString drawing methods are ‘flip-aware.’ Also, it shows how to check the graphics context to get its flipped status so you can make your own drawing routines flip-aware as well.

Unfortunately, not everyone draws flipped images correctly. One place in particular is NSView’s/NSWindow’s -dragImage:at:offset:event:pasteboard:source:slideBack: method which will draw flipped images upside-down. Since you can’t control how the image is drawn, you can instead draw your flipped image into another non-flipped image and pass that in. I’ve added a method to the NSImage category to do this and you can check out the result in the example app (you can drag the image out of the views though only the last one has the corrected version).

And what if you actually want to draw everything upside-down, you irrepressible nut? Well, apply your own transforms using NSAffineTransform or CGAffineTransform. Just remember to concat the transform and not set it (a good general rule when using affine transforms). As long as you don’t tell any classes that you’re flipped, it should work out.

Hopefully this didn’t make things even more confusing (and also, hopefully, my interpretation of all this is correct). If you are still lost then just follow these rules:

1. Do not set images as flipped unless you know what you are doing.
2. Use the -drawAdjusted... methods in my category (or similar technique) to do all your image drawing.
3. If you didn’t listen to rule #1 and you have a flipped image and it is showing up upside-down even when following rule #2, then use the -unflippedImage method in my category to get an unflipped version of the image and use that instead.
4. Never go in against a Sicilian when death is on the line.

That should handle most cases you run into. And trust me on rule #4.

“

(Via Noodlings.)

Dropping NSLog in release builds: “

NSLog() is a great tool that helps debugging efforts. Unfortunately it is expensive, especially on the iPhone, and depending on how it’s used or what you’re logging, it could leak sensitive or proprietary information. If you look around the web, you’ll find a few different ways to drop NSLog in your release builds. Here is what I’ve put together based on those.

First add the following to the <AppName>_Prefix.pch file in your Xcode project:

#ifdef DEBUG
# define DLog(...) NSLog(__VA_ARGS__)
#else
# define DLog(...) /* */
#endif
#define ALog(...) NSLog(__VA_ARGS__)

Right-click on your target and click Get Info. Select the Build tab. Make sure Configuration is set to Debug. Add -DDEBUG to the Other C Flags of your target.

And that’s about it. When you want to log only in debug builds use DLog(). In release builds DLog() will be compiled as an empty comment. Otherwise use ALog() for logging in both debug and release builds. (A as in always.)

I like this approach for a few reasons:

1. Some approaches comment out all NSLog() statements when compiled. This approach lets me keep some logging if I want.
2. Using ALog() and DLog(), I make a conscious choice about which builds I’m going to log in.
3. There is very little setup.
4. There is no overhead. Because DLog() is defined as NSLog(), executing DLog() is no different than executing NSLog()

If you’d like to replace NSLog with DLog in your source files, here’s a quick sed command that you can run in Terminal:
$ sed -i '.bak' 's/NSLog/DLog/' *.m
FYI, this will make a backup of each of the .m files whether it changed them or not.

Logging Sample Application

“

(Via Cocoa Is My Girlfriend.)