I want to walk through the process of updating the Demine project for the iOS 4.0 environment. This procedure is more complex than that associated with retargeting for earlier OSes, largely because iOS 4.0 adds support for multitasking and for high-resolution devices. Although these features don’t demand explicit application support, a developer is well-advised to consider them in his code. Today I’m going to look at the issues raised by high-resolution screens, and next week we’ll consider the implications of multitasking.
Project Setup
Editorial Note: This is directly cribbed from an earlier post. It assumes that you’ve already installed the 4.0 SDK from AAPL.
Let’s get started by grabbing the earlier project. The first thing to do is to update some project settings. (AAPL got very pushy about linking against the most recent SDK with 4.0.) First, open up the Project->Edit Project Settings dialog, select the “General” tab, and set the “Base SDK for All Configurations” to “iPhone Device 4.0″. Next, switch to the “Build” tab, check that the “Configuration” drop-down is set to “All Configurations”, and set the “iPhone OS Deployment Target” (in the “Deployment” section) to “iPhone OS 3.0″. (This will enable your app to run on iOS 3.0, if, like me, you haven’t upgraded your device yet.) Build and run the project, just to ensure the old stuff still works.
High Resolution Overview
This document from AAPL does a good job of describing what a developer must do to support high-resolution screens. The short version is: “not much; things will either automatically render in high-resolution (e.g., text) or be automatically blown up to high-resolution (e.g., user-supplied bitmaps).” There are, however, several recommended steps that will make your application look as good as it can. Let’s go through the checklist in the aforementioned document.
Image Resources
AAPL says:
Provide a high-resolution image for each image resource in your application bundle, as described in “Loading Images into Your Application.”
This is pretty straight-forward; we just need to produce double-resolution bitmaps for every image in our project, name them according to a special convention, and the runtime will take care of the rest. Our project includes these bitmaps:
Icon.png(The app icon)Default.png(The startup screen)back_click.png(Used for “back” buttons)back_norm.png(Used for “back” buttons)bg1.png(Used as a background for new/custom puzzle screens)bg2.png(Used as a background for the store item screen)
Four of these can be addressed trivially here. The Icon.png file is handled in the next section. The back_click.png and back_norm.png files are addressed in this earlier post, and the high-resolution files found there need only be included in the project. The bg1.png file was being used to put a grouped-table-like background on the new and custom puzzle screens; it turns out that a better way to do this is to set the view's backgroundColor to the groupTableViewBackgroundColor UIColor, so we can just drop bg1.png.
This means we need only generate high-resolution versions of Default.png and bg2.png. The former we can get by cropping a screenshot of the iPhone4 simulator, and the latter we can cobble together in Photoshop. We just need to add them to the project, and we’re done with this item on the checklist.
Icons
AAPL says:
Provide high-resolution application and document icons, as described in “Updating Your Application’s Icons and Launch Images.”
This boils down to generating a 114×114 pixel Icon@2x.png file. Since this is a quick-and-dirty demo, and not a “real” app, I just downsample from the 300×300 screenshot that I used to build the original icon. I add the result to the project.
Vector Graphics
AAPL says:
For vector-based shapes and content, continue using your custom Core Graphics and UIKit drawing code as before. If you want to add extra detail to your drawn content, see “Updating Your Custom Drawing Code” for information on how to do so.
Due to the distinction between points and pixels — largely theoretical to this point — all our custom drawing code works just fine as it is. (The setup for that drawing is another matter, but we’ll come to that in a bit.)
Core Animation Layers
AAPL says:
If you use Core Animation layers directly, you may need to adjust the scale factor of your layers prior to drawing, as described in “Accounting for Scale Factors in Core Animation Layers.”
We don’t use Core Animation layers directly in the sense that this item means. (It refers to creating layers independently of any view, and then running amuck.) Therefore, we don’t need to set any scale factors here.
Open GL
AAPL says:
If you use OpenGL ES for drawing, decide whether you want to opt in to high-resolution drawing and set the scale factor of your layer accordingly, as described in “Drawing High-Resolution Content Using OpenGL ES.”
We don’t use Open GL, so we’ve no issues here.
Custom Images
AAPL says:
For custom images that you create, modify your image-creation code to take the current scale factor into account, as described in “Creating High-Resolution Bitmap Images Programmatically.”
Where we use Core Graphics (more specifically, where we use the UIGraphicsBeginImageContext method) to generate bitmaps, the results will not use the full resolution of the device unless we update our code. In general, as discussed previously, we want to replace code of the form:
UIGraphicsBeginImageContext(size);
CGContextRef context = UIGraphicsGetCurrentContext();with something like:
if (UIGraphicsBeginImageContextWithOptions != NULL)
{
UIGraphicsBeginImageContextWithOptions(size, NO, 0.0);
}
else
{
UIGraphicsBeginImageContext(size);
}
CGContextRef context = UIGraphicsGetCurrentContext();There are two such changes needed here, in Playfield.m and UIButton+Glossy.m.
Core Animation Content
AAPL says:
If your application provides the content for Core Animation layers directly, adjust your code as needed to compensate for scale factors, as described in “Accounting for Scale Factors in Core Animation Layers.”
Our app does “[provide] the content for Core Animation layers directly”, but the necessary adjustments for scale factors have already been made. The content we provide is derived from image contexts created with UIGraphicsBeginImageContextWithOptions() calls made with scale arguments of 0.0; this ensures that the bitmaps are of an appropriate size for the device’s scale. So we’re done here.
Next
Next week we’ll complete the iOS 4.0 update of Demine, as we take a look at multitasking. In the meantime, you can download the complete project for this week’s post.
