博客园_不及格的程序员-八神

Webkit CSS Effect Example

2012-05-31T07:36:00Z

2012-05-31T07:36:00Z2012-05-31T07:36:00Z不及格的程序员-八神http://www.cnblogs.com/ioriwellings/

本文链接

Device tokens

2012-05-31T07:16:00Z

Generated by APNs for each device
Different from UDID entered into Program Portal
Device token value may change
- App is restored to a new device
- Same device is erased then app is reinstalled without restore uniquely identifies device
Call registration API at each app launch and then send to server every time
Development device token != production device token

本文链接

illustrate ARC with graphs

2012-05-31T07:03:00Z

2012-05-31T07:03:00Z2012-05-31T07:03:00Z不及格的程序员-八神http://www.cnblogs.com/ioriwellings/

本文链接

Including QuickTime Movies In A Web Page

2012-05-30T06:22:00Z

Including QuickTime Movies In A Web Page
Now that you've finished compressing your movie, you can deploy it to the web.
QuickTime movies can be included in a web page allowing visitors to your website to experience media seamlessly inside their browser. This is accomplished by adding some HTML to your web page that tells the QuickTime browser plug-in to display the media. See the Including QuickTime In A Web Page Tutorial to learn more.

Specifying Multiple Movie Targets using Reference Movies
If you have more than one target, you should compress your movie more than once. Compressing multiple versions of a movie takes time, and posting multiple versions uses disk space. But it makes a better experience for your users. If you can spend the time and have the space, compress different versions and target them using what is called a reference movie.
A reference movie contains pointers to alternate data rate movies--that is, multiple versions of the movie designed for downloading at various data rates. These alternate data rate movies do not typically all reside in the same reference movie file (although you may optionally "flatten" any of these movies into the reference movie so that they are all contained within the same file); any others are included by reference only.
For example, a QuickTime movie can contain a list of references to movies having different data rates, allowing an application to choose the best-looking movie that can play smoothly as it downloads over the Internet, based on the user’s connection speed.
Here's an example: to target iPod Touch and iPhone over EDGE/Wi-Fi you could create two versions of your movie with different data rates as shown in Table 10 and then create a reference movie that targets them based on connection speed:
Table 10  Creating Multiple Versions of a Movie to target iPod Touch and iPhone over EDGE/Wi-Fi.
Movie Size
Device
Total Bit Rate
400 X 225
iPhone/iPod Touch over Wi-Fi
714kb
400 X 225
iPhone over EDGE
112kb
You can use the MakeRefMovie tool to create a reference movie.
See the Reference Movies Tutorial to learn how to use the MakeRefMovie tool to create a reference movie.
The alternative is to optimize compression for one delivery medium at the expense of the others; you can compress for delivery over a slow connection, for example, with lower quality than you could provide to people with faster connections, and let people with slower connections wait a bit longer to see the movie. Some people would rather wait however long it takes to get the best-quality movie, so if you use alternate movies, you might want to include a way for people to download the high-bandwidth version, regardless of their connection speed.
For example, when targeting Apple TV you can provide a separate download to allow users to get the high bandwidth version of your movie as shown here:
Table 11  Movie Download for Apple TV.
Movie Size
Device
Total Bit Rate
1280 X 720
Apple TV HD
5Mb
Here's the download for iPod:
Table 12  Movie Download for iPod.
Movie Size
Device
Total Bit Rate
640 X 480
iPod
1.5 MB

**Table 10** Creating Multiple Versions of a Movie to target iPod Touch and iPhone over EDGE/Wi-Fi.
Movie Size	Device	Total Bit Rate
400 X 225	iPhone/iPod Touch over Wi-Fi	714kb
400 X 225	iPhone over EDGE	112kb

**Table 11** Movie Download for Apple TV.
Movie Size	Device	Total Bit Rate
1280 X 720	Apple TV HD	5Mb

**Table 12** Movie Download for iPod.
Movie Size	Device	Total Bit Rate
640 X 480	iPod	1.5 MB

本文链接

IEEE printf specification

2012-05-22T06:12:00Z

败家苹果参考直接引用http://pubs.opengroup.org/onlinepubs/009695399/functions/printf.html 文档来说明格式化的使用，可该文档没有微软的MSDN说的清楚明确，看看下面MSDN给出的格式说明可以说明一切。

%[flags][width][.perc] [F|N|h|l]type

1.type 含义如下：

d 有符号10进制整数

i 有符号10进制整数

o 有符号8进制整数

u 无符号10进制整数

x 无符号的16进制数字，并以小写abcdef表示

X 无符号的16进制数字，并以大写ABCDEF表示

F/f 浮点数

E/e 用科学表示格式的浮点数

g 使用%f和%e表示中的总的位数表示最短的来表示浮点数 G 同g格式，但表示为指数

c 单个字符

s 字符串

% 显示百分号本身

p 显示一个指针，near指针表示为：XXXX

far 指针表示为：XXXX：YYYY

n 相连参量应是一个指针，其中存放已写字符的个数

2.flags 规定输出格式，取值和含义如下：

无右对齐，左边填充0和空格

- 左对齐，右边填充空格

+ 在数字前增加符号 + 或 -

一个空格只对负数显示符号

# 当type=c,s,d,i,u时没有影响

type=o,x,X时，分别在数值前增加'0',"0x","0X"

type=e,E,f时，总是使用小数点

type=g,G时，除了数值为0外总是显示小数点

3.width 用于控制显示数值的宽度，取值和含义如下n(n=1,2,3...) 宽度至少为n位，不够以空格填充0n(n=1,2,3...) 宽度至少为n位，不够左边以0填充 * 格式列表中

4.prec 用于控制小数点后面的位数，取值和含义如下：

无按缺省精度显示

0 当type=d,i,o,u,x时，没有影响

type=e,E,f时，不显示小数点

n(n=1,2,3...) 当type=e,E,f时表示的最大小数位数

type=其他，表示显示的最大宽度 .*格式列表中

5.F|N|h|l 表示指针是否是远指针或整数是否是长整数

F 远指针

n 近指针

h短整数或单精度浮点数

l 长整数或双精度浮点数

再来看看官方网站如何说的,明显没有上面的直观。

The format can contain either numbered argument conversion specifications (that is, "%n$" and "*m$"), or unnumbered argument conversion specifications (that is, % and * ), but not both. The only exception to this is that %% can be mixed with the "%n$" form. The results of mixing numbered and unnumbered argument specifications in a format string are undefined. When numbered argument specifications are used, specifying the Nth argument requires that all the leading arguments, from the first to the (N-1)th, are specified in the format string.

In format strings containing the "%n$" form of conversion specification, numbered arguments in the argument list can be referenced from the format string as many times as required.

In format strings containing the % form of conversion specification, each conversion specification uses the first unused argument in the argument list.

^[CX] All forms of the fprintf() functions allow for the insertion of a language-dependent radix character in the output string. The radix character is defined in the program's locale (category LC_NUMERIC ). In the POSIX locale, or in a locale where the radix character is not defined, the radix character shall default to a period ( '.' ).

Each conversion specification is introduced by the '%' character ^[XSI] or by the character sequence "%n$", after which the following appear in sequence:

Zero or more flags (in any order), which modify the meaning of the conversion specification.
An optional minimum field width. If the converted value has fewer bytes than the field width, it shall be padded with spaces by default on the left; it shall be padded on the right if the left-adjustment flag ( '-' ), described below, is given to the field width. The field width takes the form of an asterisk ( '*' ), described below, or a decimal integer.
An optional precision that gives the minimum number of digits to appear for the d, i, o, u, x, and X conversion specifiers; the number of digits to appear after the radix character for the a, A, e, E, f, and F conversion specifiers; the maximum number of significant digits for the g and G conversion specifiers; or the maximum number of bytes to be printed from a string in the s ^[XSI] and S conversion specifiers. The precision takes the form of a period ( '.' ) followed either by an asterisk ( '*' ), described below, or an optional decimal digit string, where a null digit string is treated as zero. If a precision appears with any other conversion specifier, the behavior is undefined.
An optional length modifier that specifies the size of the argument.
A conversion specifier character that indicates the type of conversion to be applied.

A field width, or precision, or both, may be indicated by an asterisk ( '*' ). In this case an argument of type int supplies the field width or precision. Applications shall ensure that arguments specifying field width, or precision, or both appear in that order before the argument, if any, to be converted. A negative field width is taken as a '-' flag followed by a positive field width. A negative precision is taken as if the precision were omitted. ^[XSI] In format strings containing the "%n$" form of a conversion specification, a field width or precision may be indicated by the sequence "*m$", where m is a decimal integer in the range [1,{NL_ARGMAX}] giving the position in the argument list (after the format argument) of an integer argument containing the field width or precision, for example:

NSLog(@"%1$d05d:%2$.*3$f:%4$.*1$d", 2, 0.5555756, 6, 3); // 00002:0.555576:03

本文链接

Core 's Framework

2012-05-17T01:33:00Z

Core Graphics Framework
The Core Graphics framework (`CoreGraphics.framework`) contains the interfaces for the Quartz 2D drawing API. Quartz is the same advanced, vector-based drawing engine that is used in Mac OS X. It provides support for path-based drawing, anti-aliased rendering, gradients, images, colors, coordinate-space transformations, and PDF document creation, display, and parsing. Although the API is C based, it uses object-based abstractions to represent fundamental drawing objects, making it easy to store and reuse your graphics content.
Quartz 2D is an advanced, two-dimensional drawing engine available for iOS application development and to all Mac OS X application environments outside of the kernel. Quartz 2D provides low-level, lightweight 2D rendering with unmatched output fidelity regardless of display or printing device. Quartz 2D is resolution- and device-independent; you don’t need to think about the final destination when you use the Quartz 2D application programming interface (API) for drawing.
The Quartz 2D API is easy to use and provides access to powerful features such as transparency layers, path-based drawing, offscreen rendering, advanced color management, anti-aliased rendering, and PDF document creation, display, and parsing.
The Quartz 2D API is part of the Core Graphics framework, so you may see Quartz referred to as Core Graphics or, simply, CG.

Quartz Core Framework
The Quartz Core framework (`QuartzCore.framework`) contains the Core Animation interfaces. Core Animation is an advanced animation and compositing technology that uses an optimized rendering path to implement complex animations and visual effects. It provides a high-level Objective-C interface for configuring animations and effects that are then rendered in hardware for performance. Core Animation is integrated into many parts of iOS, including UIKit classes such as `UIView`, providing animations for many standard system behaviors. You can also use the Objective-C interface in this framework to create custom animations.
The Quartz Core framework (`QuartzCore.framework`) implements two important system technologies for graphics and imaging, Core Animation and Core Image.
Core Animation
Core Animation is a set of Objective-C classes for doing sophisticated 2D rendering and animation. Using Core Animation, you can create everything from basic window content to carousel–style user interfaces (such as Front Row’s), and achieve respectable animation performance without having to tune your code using OpenGL or other low-level drawing routines. This performance is achieved using server-side content caching, which restricts the compositing operations performed by the server to only those parts of a view or window whose contents actually change.
At the heart of the Core Animation programming model are layer objects, which are similar in many ways to Cocoa views. As with views, you can arrange layers in hierarchies, change their size and position, and tell them to draw themselves. Unlike views, layers do not support event-handling, accessibility, or drag and drop.
You can manipulate the layout of layers in more ways than the layout of traditional Cocoa views. In addition to positioning layers using a layout manager, you can apply 3D transforms to layers to rotate, scale, skew, or translate them in relation to their parent layer. In Mac OS X v10.7 and later, you can create a layer tree in one process and display it in another.
Layer content can be animated implicitly or explicitly depending on the actions you take. Modifying specific properties of a layer, such as its geometry, visual attributes, or children, typically triggers an implicit animation to transition from the old state to the new state of the property. For example, adding a child layer triggers an animation that causes the child layer to fade gradually into view. You can also trigger animations explicitly in a layer by modifying its transformation matrix.
You can manipulate layers independent of, or in conjunction with, the views and windows of your application. Cocoa applications can take advantage of the Core Animation’s integration with the `NSView` class to add animation effects to windows. Layers can also support the following types of content:
Quartz and Cocoa drawing content
OpenGL content
Quartz Composer compositions
Core Image filter effects
For information about Core Animation, see Animation Overview.
Core Image
Core Image extends the basic graphics capabilities of the system to provide a framework for implementing complex visual behaviors in your application. Core Image uses GPU-based acceleration and 32-bit floating-point support to provide fast image processing and pixel-level accurate content. Its plug-in–based architecture lets you expand the capabilities of Core Image through the creation of image units, which implement the desired visual effects.
Core Image includes built-in image units that allow you to:
Crop, composite, blur, and sharpen images
Correct color, including perform white-point adjustments
Apply color effects, such as sepia tone
Warp the geometry of an image by applying an affine transform or a displacement effect
Generate color, checkerboard patterns, Gaussian gradients, and other pattern images
Add transition effects to images or video
Provide real-time control, such as color adjustment and support for sports mode, vivid mode, and other video modes
Apply linear lighting effects, such as spotlight effects
You can use both the built-in and custom image units in your application to implement special effects and perform other types of image manipulations. Beginning in Mac OS X v10.7, Core Image supports face detection; this feature detects faces in an image, yielding for each found face its bounds within the image and eye and mouth positions.
For information about how to use Core Image or how to write custom image units, see Core Image Programming Guide and Core Image Reference Collection. For information about the built-in filters in Core Image, see Core Image Filter Reference.

Introduction to Core Image Programming Guide
Core Image is an image processing technology built into Mac OS X v10.4 and iOS 5.0 that leverages programmable graphics hardware whenever possible to provide near real-time processing. The Core Image application programming interface (API) provides access to built-in image filters for both video and still images and provides support for creating custom filters.
Important Although this document is included in the reference library, it has not been updated in detail for iOS 5.0. A forthcoming revision will detail the differences in Core Image on iOS. In particular, the key difference is that Core Image on iOS does not include the ability to create custom image filters.To use Core Image in Xcode, you need to import the Quartz Core framework.

Quartz
The Quartz umbrella framework includes the following subframeworks. You should not link directly with any of the subframeworks; instead link with (and import) `Quartz.framework`.
Image Kit
The Image Kit framework is an Objective-C framework that makes it easy to incorporate powerful imaging services into your applications. This framework takes advantage of features in Quartz, Core Image, OpenGL, and Core Animation to provide an advanced and highly optimized development path for implementing the following features:
Displaying images
Rotating, cropping, and performing other image-editing operations
Browsing for images
Taking pictures using the built-in picture taker panel
Displaying slideshows
Browsing for Core Image filters
Displaying custom views for Core Image filters
For more information on how to use Image Kit, see Image Kit Programming Guide and Image Kit Reference Collection
PDF Kit
PDF Kit is a Cocoa framework for managing and displaying PDF content directly from your application’s windows and dialogs. You can embed a `PDFView` object in your window and give it a PDF file to display. The PDF view handles the rendering of the PDF content, handles copy-and-paste operations, and provides controls for navigating and setting the zoom level. Other classes let you get the number of pages in a PDF file, find text, manage selections, add annotations, and specify the behavior of some graphical elements, among other actions.
For more information on PDF Kit, see PDF Kit Programming Guide.
Quartz Composer
The Quartz Composer framework (`QuartComposer.framework`) provides programmatic support for dealing with Quartz Composer compositions. It enables applications to load, play, and control compositions, including those in Core Animation layers.
For more information, see Quartz Composer Programming Guide.
Quick Look UI
The Quick Look UI framework (`QuickLookUI.framework`), introduced in Mac OS X v10.6, defines an interface for implementing a Quick Look preview panel, which displays the preview of a list of items. In Mac OS X v10.7, the framework added the capability for embedding a preview inside a view.
For an example of an application that implements Quick Look preview panels, see QuickLookDownloader.
Quartz Core
The Quartz Core framework (`QuartzCore.framework`) implements two important system technologies for graphics and imaging, Core Animation and Core Image.
Core Animation
Core Animation is a set of Objective-C classes for doing sophisticated 2D rendering and animation. Using Core Animation, you can create everything from basic window content to carousel–style user interfaces (such as Front Row’s), and achieve respectable animation performance without having to tune your code using OpenGL or other low-level drawing routines. This performance is achieved using server-side content caching, which restricts the compositing operations performed by the server to only those parts of a view or window whose contents actually change.
At the heart of the Core Animation programming model are layer objects, which are similar in many ways to Cocoa views. As with views, you can arrange layers in hierarchies, change their size and position, and tell them to draw themselves. Unlike views, layers do not support event-handling, accessibility, or drag and drop.
You can manipulate the layout of layers in more ways than the layout of traditional Cocoa views. In addition to positioning layers using a layout manager, you can apply 3D transforms to layers to rotate, scale, skew, or translate them in relation to their parent layer. In Mac OS X v10.7 and later, you can create a layer tree in one process and display it in another.
Layer content can be animated implicitly or explicitly depending on the actions you take. Modifying specific properties of a layer, such as its geometry, visual attributes, or children, typically triggers an implicit animation to transition from the old state to the new state of the property. For example, adding a child layer triggers an animation that causes the child layer to fade gradually into view. You can also trigger animations explicitly in a layer by modifying its transformation matrix.
You can manipulate layers independent of, or in conjunction with, the views and windows of your application. Cocoa applications can take advantage of the Core Animation’s integration with the `NSView` class to add animation effects to windows. Layers can also support the following types of content:
Quartz and Cocoa drawing content
OpenGL content
Quartz Composer compositions
Core Image filter effects
For information about Core Animation, see Animation Overview.
Core Image
Core Image extends the basic graphics capabilities of the system to provide a framework for implementing complex visual behaviors in your application. Core Image uses GPU-based acceleration and 32-bit floating-point support to provide fast image processing and pixel-level accurate content. Its plug-in–based architecture lets you expand the capabilities of Core Image through the creation of image units, which implement the desired visual effects.
Core Image includes built-in image units that allow you to:
Crop, composite, blur, and sharpen images
Correct color, including perform white-point adjustments
Apply color effects, such as sepia tone
Warp the geometry of an image by applying an affine transform or a displacement effect
Generate color, checkerboard patterns, Gaussian gradients, and other pattern images
Add transition effects to images or video
Provide real-time control, such as color adjustment and support for sports mode, vivid mode, and other video modes
Apply linear lighting effects, such as spotlight effects
You can use both the built-in and custom image units in your application to implement special effects and perform other types of image manipulations. Beginning in Mac OS X v10.7, Core Image supports face detection; this feature detects faces in an image, yielding for each found face its bounds within the image and eye and mouth positions.
For information about how to use Core Image or how to write custom image units, see Core Image Programming Guide and Core Image Reference Collection. For information about the built-in filters in Core Image, see Core Image Filter Reference.
QuickTime Kit
The QuickTime Kit (`QTKit.framework`), or QTKit, is an Objective-C framework for manipulating QuickTime-based media. This framework lets you incorporate movie playback, movie editing, export to standard media formats, and other QuickTime behaviors easily into your applications.
本文链接

The Mac Application Environment

2012-05-03T03:09:00Z

The Mac Application Environment

Mac OS X incorporates the latest technologies for creating powerful and fun-to-use apps. But the technologies by themselves are not enough to make every app great. What sets an app apart from its peers is how it helps the user achieve some tangible goal. After all, users are not going to care what technologies an app uses, as long as it helps them do what they need to do. An app that gets in the user’s way is going to be forgotten, but one that makes work (or play) easier and more fun is going to be remembered.

An Environment Designed for Ease of Use

Mac OS X strives to provide an environment that is transparent to users and as easy to use as possible. By making hard tasks simple and getting out of the way, the system makes it easier for the user to be creative and spend less time worrying about the steps needed to make the computer work. Of course, simplifying tasks means your app has to do more of the work, but Mac OS You should consider providing your users with an immersive, full-screen experience by implementing a full-screen version of your user interface. The full-screen experience eliminates outside distractions and allows the user to focus on their content; see “Implementing the Full-Screen Experience” (page 66).

Support trackpad gestures for appropriate actions in your app. Gestures provide simple shortcuts for common tasks and can be used to supplement existing controls and menu commands. Mac OS X provides automatic support for reporting gestures to your app through the normal event-handling mechanism; see Cocoa Event-Handling Guide .

Consider minimizing or eliminating the user’s interactions with the raw file system. Rather than expose the entire file system to the user through the open and save panels, some apps, in the manner of iPhoto and iTunes, can provide a better user experience by presenting the user’s content in a simplified browser designed specifically for the app’s content. Mac OS X uses a well-defined file system structure that allows you to place and find files easily and includes many technologies for accessing those files; see “The File System” (page 13).

A Sophisticated Graphics Environment

High-quality graphics and animation make your app look great and can convey a lot of information to the user. Animations in particular are a great way to provide feedback about changes to your user interface.

Low-Level Details of the Runtime Environment

When you are ready to begin writing actual code, there are a lot of technologies available to make your life easier. Mac OS X supports all of the basic features such as memory management, file management, networking, and concurrency that you need to write your code. In some cases, though, Mac OS X also provides more sophisticated services (or specific coding conventions) that, when followed, can make writing your code even easier.

Based on UNIX

Mac OS X is powered by a 64-bit Mach kernel, which manages processor resources, memory, and other low-level behaviors. On top of the kernel sits a modified version of the Berkeley Software Distribution (BSD) operating system, which provides interfaces that apps can use to interact with the lower-level system. This combination of Mach and BSD provides the following system-level support for your apps:

Preemptive multitasking—All processes share the CPU efficiently. The kernel schedules processes in a way that ensures they all receive the time they need to run. Even background apps continue to receive CPU time to execute ongoing tasks.

Protected memory—Each process runs in its own protected memory space, which prevents processes from accidentally interfering with each other. (Apps can share part of their memory space to implement fast interprocess communication but take responsibility for synchronizing and locking that memory appropriately.)

Virtual memory—64-bit apps have a virtual address space of approximately 18 exabytes (18 billion billion bytes). (If you create a 32-bit app, the amount of virtual memory is only 4 GB.) When an app’s memory usage exceeds the amount of free physical memory, the system transparently writes pages to disk to make more room. Written out pages remain on disk until they are needed in memory again or the app exits.

Networking and Bonjour—Mac OS X provides support for the standard networking protocols and services in use today. BSD sockets provide the low-level communication mechanism for apps, but higher-level interfaces also exist. Bonjour simplifies the user networking experience by providing a dynamic way to advertise and connect to network services over TCP/IP.

Concurrency and Threading

Each process starts off with a single thread of execution and can create more threads as needed. Although you can create threads directly using POSIX and other higher-level interfaces, for most types of work it is better to create them indirectly using block objects with Grand Central Dispatch (GCD) or operation objects, a Cocoa concurrency technology implemented by the NSOperation class.

GCD and operation objects are an alternative to raw threads that simplify or eliminate many of the problems normally associated with threaded programming, such as synchronization and locking. Specifically, they define an asynchronous programming model in which you specify only the work to be performed and the order in which you want it performed. The system then handles the tedious work required to schedule the necessary threads and execute your tasks as efficiently as possible on the current hardware. You should not use GCD or operations for work requiring time-sensitive data processing (such as audio or video playback), but you can use them for most other types of tasks.

For more information on using GCD and operation objects to implement concurrency in your apps, see Concurrency Programming Guide .

The File System

The file system in Mac OS X is structured to provide a better experience for users. Rather than exposing the entire file system to the user, the Finder hides any files and directories that an average user should not need to use, such as the contents of low-level UNIX directories. This is done to provide a simpler interface for the end user (and only in places like the Finder and the open and save panels). Apps can still access any files and directories for which they have valid permissions, regardless of whether they are hidden by the Finder.

When creating apps, you should understand and follow the conventions associated with the Mac OS X file system. Knowing where to put files and how to get information out of the file system ensures a better user experience.

A Few Important App Directories

The Mac OS X file system is organized in a way that groups related files and data together in specific places. Every file in the file system has its place and apps need to know where to put the files they create. This is especially important if you are distributing your app through the App Store, which expects you to put your app’s data files in specific directories.

Table 1-1 lists the directories with which apps commonly interact. Directories preceded with a tilde (~) character indicate a path inside the home directory, which can be either the user’s home directory or the app’s container directory if the app is in a sandbox (as described in “App Sandbox and XPC” (page 18)). Because the actual paths can differ based on the conditions, use the URLsForDirectory:inDomains: method of the NSFileManager class to retrieve the actual directory path. You can then add any custom directory and filename information to the returned URL object to complete the path.

Table 1-1 Key directories for Mac OS X apps

Directory

Description

Applications directory

This is the installation directory for your app bundle. The path for the global Applications directory is /Applications but each user directory may have a local applications directory containing user-specific apps. Regardless, you should not need to use this path directly. To access resources inside your application bundle, use an NSBundle object instead.

For more information about the structure of your application bundle and how you locate resources, see “The Mac OS X Application Bundle” (page 81).

Home directory

The configuration of your app determines the location of the home directory seen by your app:

For apps running in a sandbox in Mac OS X 10.7 and later, the home directory is the app’s container directory. For more information about the container directory, see “The Keychain” (page 20).

For apps running outside of a sandbox (including those running in versions of Mac OS X before 10.7), the home directory is the user-specific subdirectory of /Users that contains the user’s files.

To retrieve the path to the home directory, use the NSHomeDirectory function.

●

Library directory

The Library directory is the top-level directory for storing private app-related data and preferences. There are several Library directories scattered throughout the system but you should always use the one located inside the current home directory.

Do not store files directly at the top-level of the Library directory. Instead, store them in one of the specific subdirectories described in this table.

In Mac OS X 10.7 and later, the Finder hides the Library directory in the user’s home folder by default. Therefore, you should never store files in this directory that you want the user to access.

To get the path to this directory use the NSLibraryDirectory search path key with the NSUserDomainMask domain.

Directory

Description

Application Support directory

The Application Support directory is where your app stores any type of file that supports the app but is not required for the app to run, such as document templates or configuration files. The files should be app-specific but should never store user data. This directory is located inside the Library directory.

Never store files at the top level of this directory: Always put them in a subdirectory named for your app or company.

If the resources apply to all users on the system, such as document templates, place them in /Library/Application Support. To get the path to this directory use the NSApplicationSupportDirectory search path key with the NSLocalDomainMask domain. If the resources are user-specific, such as workspace configuration files, place them in the current user’s ~/Library/Application Support directory. To get the path to this directory use the NSApplicationSupportDirectory search path key with the NSUserDomainMask domain.

Caches directory

The Caches directory is where you store cache files and other temporary data that your app can re-create as needed. This directory is located inside the Library directory.

Never store files at the top level of this directory: Always put them in a subdirectory named for your app or company. Your app is responsible for cleaning out cache data files when they are no longer needed. The system does not delete files from this directory.

To get the path to this directory use the NSCachesDirectory search path key with the NSUserDomainMask domain.

Movies directory

The Movies directory contains the user’s video files.

To get the path to this directory use the NSMoviesDirectory search path key with the NSUserDomainMask domain.

Music directory

The Music directory contains the user’s music and audio files.

To get the path to this directory use the NSMusicDirectory search path key with the NSUserDomainMask domain.

Pictures directory

The Pictures directory contains the user’s images and photos.

To get the path to this directory use the NSPicturesDirectory search path key with the NSUserDomainMask domain.

Directory

Description

Temporary directory

The Temporary directory is where you store files that do not need to persist between launches of your app. You normally use this directory for scratch files or other types of short-lived data files that are not related to your app’s persistent data. This directory is typically hidden from the user.

Your app should remove files from this directory as soon as it is done with them. The system may also purge lingering files from this directory at system startup.

To get the path to this directory use the NSTemporaryDirectory function.

Listing 1-1 shows an example of how to retrieve the base path to the Application Support directory and then append a custom app directory to it.

Listing 1-1 Getting the path to the Application Support directory

NSFileManager* fileManager = [NSFileManager defaultManager];

NSURL* appSupportDir = nil;

NSArray *urls = [fileManager URLsForDirectory:NSApplicationSupportDirectory

inDomains:NSUserDomainMask];

if ([paths count] > 0) {

appSupportDir = [[urls objectAtIndex:0]

URLByAppendingPathComponent:@"com.example.MyApp"];

}

For more information about how to access files in well known system directories, see File System Programming Guide .

Coordinating File Access with Other Processes

In Mac OS X, other processes may have access to the same files that your app does. Therefore, when working with files, you should use the file coordination interfaces introduced in Mac OS X v10.7 to be notified when other processes (including the Finder) attempt to read or modify files your app is currently using. For example, coordinating file access is critical when your app adopts iCloud storage.

The file coordination APIs allow you to assert ownership over files and directories that your app cares about. Any time another process attempts to touch one of those items, your app is given a chance to respond. For example, when an app attempts to read the contents of a document your app is editing, you can write unsaved changes to disk before the other process is allowed to do its reading.

Using iCloud document storage, for example, you must incorporate file coordination because multiple apps can access your document files in iCloud. The simplest way to incorporate file coordination into your app is to use the NSDocument class, which handles all of the file-related management for you. See Document-Based App Programming Guide for Mac .

On the other hand, if you're writing a library-style (or “shoebox”) app, you must use the file coordination interfaces directly, as described in File System Programming Guide .

Interacting with the File System

Disks in Macintosh computers are formatted using the HFS+ file system by default. However, Macintosh computers can interact with disks that use other formats so you should never code specifically to any one file system. Table 1-2 lists some of the basic file system attributes you may need to consider in your app and how you should handle them.

Table 1-2 Attributes for the Mac OS X file system

Attribute

Description

Case sensitivity

The HFS+ file system is case-insensitive but also case-preserving. Therefore, when specifying filenames and directories in your code, it is best to assume case-sensitivity.

Path construction

Construct paths using the methods of the NSURL and NSString classes. The NSURL class is preferred for path construction because of its ability to specify not only paths in the local file system but paths to network resources.

File attributes

Many file-related attributes can be retrieved using the getResourceValue: forKey:error: method of the NSURL class. You can also use an NSFileManager object to retrieve many file-related attributes.

File permissions

File permissions are managed using access control lists (ACLs) and BSD permissions. The system uses ACLs whenever possible to specify precise permissions for files and directories, but it falls back to using BSD permissions when no ACLs are specified.

By default, any files your app creates are owned by the current user and given appropriate permissions. Thus, your app should always be able to read and write files it creates explicitly. In addition, the app’s sandbox may allow it to access other files in specific situations. For more information about the sandbox, see “App Sandbox and XPC” (page 18).

Tracking file changes

Apps that cannot use the File Coordination interfaces (see “Coordinating File Access with Other Processes” (page 16)) to track changes to files and directories can use the FSEvents API instead. This API provides a lower-level interface for tracking file system interactions and is available in Mac OS X v10.5 and later.

For information on how to use the FSEvents API, see File System Events Programming Guide .

Security

The security technologies in Mac OS X help you safeguard sensitive data created or managed by your app, and help minimize damage caused by successful attacks from hostile code. These technologies impact how your app interacts with system resources and the file system.

App Sandbox and XPC

You secure your app against attack from malware by following the practices recommended in Secure Coding Guide . But an attacker needs only to find a single hole in your defenses, or in any of the frameworks and libraries that you link against, to gain control of your app along with all of its privileges.

Starting in Mac OS X v10.7, App Sandbox provides a last line of defense against stolen, corrupted, or deleted user data if malicious code exploits your app. App Sandbox also minimizes the damage from coding errors. Its strategy is twofold:

App Sandbox enables you to describe how your app interacts with the system. The system then grants your app the access it needs to get its job done, and no more. For your app to provide the highest level of damage containment, the best practice is to adopt the tightest sandbox possible.
App Sandbox allows the user to transparently grant your app additional access by way of Open and Save dialogs, drag and drop, and other familiar user interactions.

You describe your app’s interaction with the system by way of setting entitlements in Xcode. An entitlement is a key-value pair, defined in a property list file, that confers a specific capability or security permission to a target. For example, there are entitlement keys to indicate that your app needs access to the camera, the network, and user data such as the Address Book. For details on all the entitlements available in Mac OS X, see Entitlement Key Reference .

When you adopt App Sandbox, the system provides a special directory for use by your app—and only by your app—called a container. Your app has unfettered read/write access to the container. All Mac OS X path-finding APIs, above the POSIX layer, are relative to the container instead of to the user’s home directory. Other sandboxed apps have no access to your app’s container, as described further in “Code Signing” (page 19).

iOSNote Becauseitisnotforuserdocuments,aMacOSXcontainerdiffersfromaniOScontainer which, in iOS, is the one and only location for user documents. As the sole local location for user documents, an iOS container is usually known simply as an app’s Documents directory.

In addition, an iOS container contains the app itself. This is not so in Mac OS X.

iCloudNote Apple’siCloudtechnology,asdescribedin“iCloudStorage”(page49),usesthename “container” as well. There is no functional connection between an iCloud container and an App Sandbox container.

Your sandboxed app can access paths outside of its container in the following three ways:

At the specific direction of the user
By you configuring your app with entitlements for specific file-system locations, such as the Movies folder When a path is in any of certain directories that are world readable

The Mac OS X security technology that interacts with the user to expand your sandbox is called Powerbox. Powerbox has no API. Your app uses Powerbox transparently when, for example, you use the NSOpenPanel and NSSavePanel classes, or when the user employs drag and drop with your app.

Some app operations are more likely to be targets of malicious exploitation. Examples are the parsing of data received over a network, and the decoding of video frames. By using XPC, you can improve the effectiveness of the damage containment offered by App Sandbox by separating such potentially dangerous activities into their own address spaces.

XPC is a Mac OS X interprocess communication technology that complements App Sandbox by enabling privilege separation. Privilege separation, in turn, is a development strategy in which you divide an app into pieces according to the system resource access that each piece needs. The component pieces that you create are called XPC services . For details on adopting XPC, see Daemons and Services Programming Guide .

For a complete explanation of App Sandbox and how to use it, read App Sandbox Design Guide . Code Signing

Mac OS X employs the security technology known as code signing to allow you to certify that your app was indeed created by you. After an app is code signed, the system can detect any change to the app—whether the change is introduced accidentally or by malicious code. Various security technologies, including App Sandbox and parental controls, depend on code signing.

In most cases, you can rely on Xcode’s automatic code signing, which requires only that you specify a code signing identity in the build settings for your project. The steps to take are described in “Code Signing Your App” in Tools Workflow Guide for Mac . If you need to incorporate code signing into an automated build system, or if you link your app against third-party frameworks, refer to the procedures described in Code Signing Guide .

When you adopt App Sandbox, you must code sign your app. This is because entitlements (including the special entitlement that enables App Sandbox) are built into an app’s code signature.

Mac OS X enforces a tie between an app’s container and the app’s code signature. This important security feature ensures that no other sandboxed app can access your container. The mechanism works as follows: After the system creates a container for an app, each time an app with the same bundle ID launches, the system checks that the app’s code signature matches a code signature expected by the container. If the system detects a mismatch, it prevents the app from launching.

For a complete explanation of code signing in the context of App Sandbox, read “App Sandbox in Depth” in App Sandbox Design Guide .

The Keychain

A keychain is a secure, encrypted container for storing a user’s passwords and other secrets. It is designed to help a user manage their multiple logins, each with its own ID and password. You should always use keychain to store sensitive credentials for your app.

For more on the keychain, see “Keychain Services Concepts” in Keychain Services Programming Guide .

本文链接

Animations

2012-05-02T07:33:00Z

Animations

Both UIKit and Core Animation provide support for animations, but the level of support provided by each technology varies.

In UIKit, animations are performed using UIView objects.

Table 4-1 Animatable UIView properties

Property	Changes you can make
frame	Modify this property to change the view’s size and position relative to its superview’s coordinate system. (If the transform property does not contain the identity transform, modify the bounds or center properties instead.)
bounds	Modify this property to change the view’s size.
center	Modify this property to change the view’s position relative to its superview’s coordinate system.
transform	Modify this property to scale, rotate, or translate the view relative to its center point. Transformations using this property are always performed in 2D space. (To perform 3D transformations, you must animate the view’s layer object using Core Animation.)
alpha	Modify this property to gradually change the transparency of the view.
backgroundColor	Modify this property to change the view’s background color.
contentStretch	Modify this property to change the way the view’s contents are stretched to fill the available space.

In places where you want to perform more sophisticated animations, or animations not supported by the UIView class, you can use Core Animation and the view’s underlying layer to create the animation. Because view and layer objects are intricately linked together, changes to a view’s layer affect the view itself. Using Core Animation, you can animate the following types of changes for your view’s layer:

The size and position of the layer
The center point used when performing transformations
Transformations to the layer or its sublayers in 3D space
The addition or removal of a layer from the layer hierarchy
The layer’s Z-order relative to other sibling layers
The layer’s shadow
The layer’s border (including whether the layer’s corners are rounded)
The portion of the layer that stretches during resizing operations
The layer’s opacity
The clipping behavior for sublayers that lie outside the layer’s bounds
The current contents of the layer
The rasterization behavior of the layer

Animating View and Layer Changes Together

Applications can freely mix view-based and layer-based animation code as needed but the process for configuring your animation parameters depends on who owns the layer. Changing a view-owned layer is the same as changing the view itself, and any animations you apply to the layer’s properties respect the animation parameters of the current view-based animation block. The same is not true for layers that you create yourself. Custom layer objects ignore view-based animation block parameters and use the default Core Animation parameters instead.

If you want to customize the animation parameters for layers you create, you must use Core Animation directly. Typically, animating layers using Core Animation involves creating a CABasicAnimation object or some other concrete subclass of CAAnimation. You then add that animation to the corresponding layer. You can apply the animation from either inside or outside a view-based animation block.

Listing 4-9 shows an animation that modifies a view and a custom layer at the same time. The view in this example contains a custom CALayer object at the center of its bounds. The animation rotates the view counter clockwise while rotating the layer clockwise. Because the rotations are in opposite directions, the layer maintains its original orientation relative to the screen and does not appear to rotate significantly. However, the view beneath that layer spins 360 degrees and returns to its original orientation. This example is presented primarily to demonstrate how you can mix view and layer animations. This type of mixing should not be used in situations where precise timing is needed.

Listing 4-9 Mixing view and layer animations

[UIView animateWithDuration:1.0

delay:0.0

options: UIViewAnimationOptionCurveLinear

animations:^{

// Animate the first half of the view rotation.

CGAffineTransform xform = CGAffineTransformMakeRotation(DEGREES_TO_RADIANS(-180));

backingView.transform = xform;

// Rotate the embedded CALayer in the opposite direction.

CABasicAnimation* layerAnimation = [CABasicAnimation animationWithKeyPath:@"transform"];

layerAnimation.duration = 2.0;

layerAnimation.beginTime = 0; //CACurrentMediaTime() + 1;

layerAnimation.valueFunction = [CAValueFunction functionWithName:kCAValueFunctionRotateZ];

layerAnimation.timingFunction = [CAMediaTimingFunction

functionWithName:kCAMediaTimingFunctionLinear];

layerAnimation.fromValue = [NSNumber numberWithFloat:0.0];

layerAnimation.toValue = [NSNumber numberWithFloat:DEGREES_TO_RADIANS(360.0)];

layerAnimation.byValue = [NSNumber numberWithFloat:DEGREES_TO_RADIANS(180.0)];

[manLayer addAnimation:layerAnimation forKey:@"layerAnimation"];

}

completion:^(BOOL finished){

// Now do the second half of the view rotation.

[UIView animateWithDuration:1.0

delay: 0.0

options: UIViewAnimationOptionCurveLinear

animations:^{

CGAffineTransform xform = CGAffineTransformMakeRotation(DEGREES_TO_RADIANS(-359));

backingView.transform = xform;

}

completion:^(BOOL finished){

backingView.transform = CGAffineTransformIdentity;

}];

Note: In Listing 4-9, you could also create and apply the CABasicAnimation object outside of the view-based animation block to achieve the same results. All of the animations ultimately rely on Core Animation for their execution. Thus, if they are submitted at approximately the same time, they run together.

If precise timing between your view and layer based animations is required, it is recommended that you create all of the animations using Core Animation. You may find that some animations are easier to perform using Core Animation anyway. For example, the view-based rotation in Listing 4-9 requires a multistep sequence for rotations of more than 180 degrees, whereas the Core Animation portion uses a rotation value function that rotates from start to finish through a middle value.

Animation
Animation is a key element of today’s user interfaces. When using Core Animation animation is completely automatic. There are no animation loops or timers. Your application is not responsible for frame by frame drawing, or tracking the current state of your animation. The animation occurs automatically in a separate thread, without further interaction with your application.
This chapter provides an overview of the animation classes, and describes how to create both implicit and explicit animations.

Animation Classes and Timing
Core Animation provides an expressive set of animation classes you can use in your application:
`CABasicAnimation` provides simple interpolation between values for a layer property.
`CAKeyframeAnimation` provides support for key frame animation. You specify the key path of the layer property to be animated, an array of values that represent the value at each stage of the animation, as well as arrays of key frame times and timing functions. As the animation runs, each value is set in turn using the specified interpolation.
`CATransition` provides a transition effect that affects the entire layer's content. It fades, pushes, or reveals layer content when animating. The stock transition effects can be extended by providing your own custom Core Image filters.
`CAAnimationGroup` allows an array of animation objects to be grouped together and run concurrently.
In addition to specifying the type of animation to perform, you must also specify the duration of the animation, the pacing (how the interpolated values are distributed across the duration), if the animation is to repeat and how many times, whether it should automatically reverse when each cycle is completed, and its visual state when the animation is completed. The animation classes and the `CAMediaTiming` protocol provides all this functionality and more.
`CAAnimation` and its subclasses and the timing protocols are shared by both Core Animation and the Cocoa Animation Proxy functionality. The classes are described in detail in Animation Types and Timing Programming Guide.

Implicit Animation
Core Animation’s implicit animation model assumes that all changes to animatable layer properties should be gradual and asynchronous. Dynamically animated scenes can be achieved without ever explicitly animating layers. Changing the value of an animatable layer property causes the layer to implicitly animate the change from the old value to the new value. While an animation is in-flight, setting a new target value causes the animation transition to the new target value from its current state.
Listing 1 shows how simple it is to trigger an implicit animation that animates a layer from its current position to a new position.
Listing 1 Implicitly animating a layer’s position property
// assume that the layer is current positioned at (100.0,100.0)
theLayer.position=CGPointMake(500.0,500.0);
You can implicitly animate a single layer property at a time, or many. You can also implicitly animate several layers simultaneously. The code in Listing 2 causes four implicit animations to occur simultaneously.
Listing 2 Implicitly animating multiple properties of multiple layers
// animate theLayer's opacity to 0 while moving it
// further away in the layer
theLayer.opacity=0.0;
theLayer.zPosition=-100;

// animate anotherLayer's opacity to 1
// while moving it closer in the layer
anotherLayer.opacity=1.0;
anotherLayer.zPosition=100.0;
Implicit animations use the duration specified in the default animation for the property, unless the duration has been overridden in an implicit or explicit transaction. See “Overriding the Duration of Implied Animations” for more information.

Explicit Animation
Core Animation also supports an explicit animation model. The explicit animation model requires that you create an animation object, and set start and end values. An explicit animation won’t start until you apply the animation to a layer. The code fragment in Listing 3 creates an explicit animation that transitions a layer’s opacity from fully opaque to fully transparent, and back over a 3 second duration. The animation doesn’t begin until it is added to the layer.
Listing 3 Explicit animation
CABasicAnimation theAnimation;

theAnimation=[CABasicAnimation animationWithKeyPath:@"opacity"];
theAnimation.duration=3.0;
theAnimation.repeatCount=2;
theAnimation.autoreverses=YES;
theAnimation.fromValue=[NSNumber numberWithFloat:1.0];
theAnimation.toValue=[NSNumber numberWithFloat:0.0];
[theLayer addAnimation:theAnimation forKey:@"animateOpacity"];
Explicit animations are especially useful when creating animations that run continuously. Listing 4 shows how to create an explicit animation that applies a CoreImage bloom filter to a layer, animating its intensity. This causes the “selection layer” to pulse, drawing the user’s attention.
Listing 4 Continuous explicit animation example

// The selection layer will pulse continuously.
// This is accomplished by setting a bloom filter on the layer

// create the filter and set its default values
CIFilter filter = [CIFilter filterWithName:@"CIBloom"];
[filter setDefaults];
[filter setValue:[NSNumber numberWithFloat:5.0] forKey:@"inputRadius"];

// name the filter so we can use the keypath to animate the inputIntensity
// attribute of the filter
[filter setName:@"pulseFilter"];

// set the filter to the selection layer's filters
[selectionLayer setFilters:[NSArray arrayWithObject:filter]];

// create the animation that will handle the pulsing.
CABasicAnimation* pulseAnimation = [CABasicAnimation animation];

// the attribute we want to animate is the inputIntensity
// of the pulseFilter
pulseAnimation.keyPath = @"filters.pulseFilter.inputIntensity";

// we want it to animate from the value 0 to 1
pulseAnimation.fromValue = [NSNumber numberWithFloat: 0.0];
pulseAnimation.toValue = [NSNumber numberWithFloat: 1.5];

// over a one second duration, and run an infinite
// number of times
pulseAnimation.duration = 1.0;
pulseAnimation.repeatCount = HUGE_VALF;

// we want it to fade on, and fade off, so it needs to
// automatically autoreverse.. this causes the intensity
// input to go from 0 to 1 to 0
pulseAnimation.autoreverses = YES;

// use a timing curve of easy in, easy out..
pulseAnimation.timingFunction = [CAMediaTimingFunction functionWithName: kCAMediaTimingFunctionEaseInEaseOut];

// add the animation to the selection layer. This causes
// it to begin animating. We'll use pulseAnimation as the
// animation key name
[selectionLayer addAnimation:pulseAnimation forKey:@"pulseAnimation"];

Starting and Stopping Explicit Animations
You start an explicit animation by sending a `addAnimation:forKey:` message to the target layer, passing the animation and an identifier as parameters. Once added to the target layer the explicit animation will run until the animation completes, or it is removed from the layer. The identifier used to add an animation to a layer is also used to stop it by invoking `removeAnimationForKey:`. You can stop all animations for a layer by sending the layer a `removeAllAnimations` message.

本文链接

Managing Nib Objects in iOS

2012-04-23T05:55:00Z

Managing Nib Objects in iOS

Top-Level Objects
Objects in the nib file are created with a retain count of 1 and then autoreleased. As it rebuilds the object hierarchy, UIKit reestablishes connections between the objects using `setValue:forKey:`, which uses the available setter method or retains the object by default if no setter method is available. This means that (assuming you follow the pattern shown above) any object for which you have an outlet remains valid. If there are any top-level objects you do not store in outlets, however, you must retain either the array returned by the `loadNibNamed:owner:options:` method or the objects inside the array to prevent those objects from being released prematurely.

Memory Warnings
When a view controller receives a memory warning (`didReceiveMemoryWarning`), it should relinquish ownership of resources that are currently not needed and that can be recreated later if required. One such resource is the view controller's view itself. If it does not have a superview, the view is disposed of (in its implementation of `didReceiveMemoryWarning`, `UIViewController` invokes `[self setView:nil]`).
Because outlets to elements within the nib file are typically retained, however, even though the main view is disposed of, absent any further action the outlets are not disposed of. This is not in and of itself a problem—if and when the main view is reloaded, they will simply be replaced—but it does mean that the beneficial effect of the `didReceiveMemoryWarning` is reduced. To ensure that you properly relinquish ownership of outlets, in your custom view controller class you can implement `viewDidUnload` to invoke your accessor methods to set outlets to `nil`.
- (void)viewDidUnload {
self.anOutlet = nil;
[super viewDidUnload];
}

Managing the Lifetimes of Objects from Nib Files
Each time you ask the `NSBundle` or `NSNib` class to load a nib file, the underlying code creates a new copy of the objects in that file and returns them to you. (The nib-loading code does not recycle nib file objects from a previous load attempt.) You need to ensure that you maintain the new object graph as long as necessary, and disown it when you are finished with it. You typically need strong references to top-level objects to ensure that they are not deallocated; you don’t need strong references to objects lower down in the graph because they’re owned by their parents, and you should minimize the risk of creating strong reference cycles.
From a practical perspective, in iOS and OS X outlets should be defined as declared properties. Outlets should generally be `weak`, except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene) which should be `strong`. Outlets that you create should will therefore typically be `weak` by default, because:
Outlets that you create to, for example, subviews of a view controller’s view or a window controller’s window, are arbitrary references between objects that do not imply ownership.
The strong outlets are frequently specified by framework classes (for example, `UIViewController`’s `view` outlet, or `NSWindowController`’s `window` outlet).
@property (weak) IBOutlet MyView viewContainerSubview;
@property (strong) IBOutlet MyOtherClass topLevelObject;

Getting a Nib File’s Top-Level Objects
The easiest way to get the top-level objects of your nib file is to define outlets in the File’s Owner object along with setter methods (or better yet, properties) for accessing those objects. This approach ensures that the top-level objects are retained by your object and that you always have references to them.
Listing 1-3 shows the interface and implementation of a simplified Cocoa class that uses an outlet to retain the nib file’s only top-level object. In this case, the only top-level object in the nib file is an `NSWindow` object. Because top-level objects in Cocoa have an initial retain count of 1, an extra release message is included. This is fine because by the time the release call is made, the property has already been retained the window. You would not want to release top-level objects in this manner in an iPhone application.
Listing 1-3 Using outlets to get the top-level objects
// Class interface
@interface MyController : NSObject {
NSWindow window;
}
@property(retain) IBOutlet NSWindow window;
- (void)loadMyWindow;

@end

// Class implementation
@implementation MyController
// The synthesized property retains the window automatically.
@synthesize window;

- (void)loadMyWindow
{
[NSBundle loadNibNamed:@"myNib" owner:self];

// The window starts off with a retain count of 1
// and is then retained by the property, so add an extra release.
[window release];
}
@end
If you do not want to use outlets to store references to your nib file’s top-level objects, you must retrieve those objects manually in your code. The technique for obtaining the top-level objects differs depending on the target platform. In OS X, you must ask for the objects explicitly, whereas in iOS they are returned to you automatically.
Listing 1-4 shows the process for getting the top-level objects of a nib file in OS X. This method places a mutable array into the `nameTable` dictionary and associates it with the `NSNibTopLevelObjects` key. The nib-loading code looks for this array object and, if present, places the top-level objects in it. Because each object starts with a retain count of 1 before it is added to the array, simply releasing the array is not enough to release the objects in the array as well. As a result, this method sends a release message to each of the objects to ensure that the array is the only entity holding a reference to them.
Listing 1-4 Getting the top-level objects from a nib file at runtime
- (NSArray)loadMyNibFile
{
NSBundle aBundle = [NSBundle mainBundle];
NSMutableArray* topLevelObjs = [NSMutableArray array];
NSDictionary* nameTable = [NSDictionary dictionaryWithObjectsAndKeys:
self, NSNibOwner,
topLevelObjs, NSNibTopLevelObjects,
nil];

if (![aBundle loadNibFile:@"myNib" externalNameTable:nameTable withZone:nil])
{
NSLog(@"Warning! Could not load myNib file.\n");
return nil;
}

// Release the objects so that they are just owned by the array.
[topLevelObjs makeObjectsPerformSelector:@selector(release)];
return topLevelObjs;
}
Obtaining the top-level objects in an iPhone application is much simpler and is shown in Listing 1-2. In the UIKit framework, the `loadNibNamed:owner:options:` method of `NSBundle` automatically returns an array with the top-level objects. In addition, by the time the array is returned, the retain counts on the objects are adjusted so that you do not need to send each object an extra release message. The returned array is the only owner of the objects.

本文链接

Specifying High-Resolution Images in iOS

2012-04-20T08:46:00Z

Specifying High-Resolution Images in iOS
Any iPhone application built for iOS 4.0 and later should include high-resolution versions of its image resources. When the application is run on a device that has a high-resolution screen, high-resolution images provide extra detail and look better because they do not need to be scaled to fit the space. You provide high-resolution images for each image resource in your application bundle, including icons and launch images.
To specify a high-resolution version of an image, create a version whose width and height (measured in pixels) are twice that of the original. (You can use the extra pixels in the image to provide additional detail.) When saving the image, use the same base name but include the string `@2x` between the base filename and the filename extension. For example, if you have an image named `MyImage.png`, the name of the high-resolution version would be `MyImage@2x.png`. Put the high-resolution and original versions of your image in the same location in your application bundle.
The bundle- and image-loading routines automatically look for image files with the `@2x` string when the underlying device has a high-resolution screen. If you combine the `@2x` string with other modifiers, the `@2x` string should come before any device modifiers but after all other modifiers, such as launch orientation or URL scheme modifiers. Thus, a universal application might have the following image resource files for a single image:
`MyImage.png` - Default version of the image resource, which is also used for iPad.
`MyImage~iphone.png` - Version of the image for iPhone and iPod touch.
`MyImage@2x~iphone.png` - High-resolution version of an image for iPhone and iPod touch devices with Retina displays.
When you want to load an image, do not include the `@2x` or any device modifiers when specifying the image name in your code. For example, if your application bundle included the image files from the preceding list, you would ask for an image named `MyImage.png`. The system automatically determines which version of the image is most appropriate and loads it. Similarly, when using or drawing that image, you do not have to know whether it is the original resolution or high-resolution version. The image-drawing routines automatically adjust based on the image that was loaded. However, if you still want to know whether an image is the original or high-resolution version, you can check its scale factor. If the image is the high-resolution version, its scale factor is set to a value other than `1.0`.
For more information about how to support high-resolution devices, see “Supporting High-Resolution Screens”.

Resource Programming Guide
iOS Supports Device-Specific Resources
In iOS 4.0 and later, it is possible to mark individual resource files as usable only on a specific type of device. This capability simplifies the code you have to write for Universal applications. Rather than creating separate code paths to load one version of a resource file for iPhone and a different version of the file for iPad, you can let the bundle-loading routines choose the correct file. All you have to do is name your resource files appropriately.
To associate a resource file with a particular device, you add a custom modifier string to its filename. The inclusion of this modifier string yields filenames with the following format:
<basename><device>`.`<filename_extension>
The <basename> string represents the original name of the resource file. It also represents the name you use when accessing the file from your code. Similarly, the <filename_extension> string is the standard filename extension used to identify the type of the file. The <device> string is a case-sensitive string that can be one of the following values:
`~ipad` - The resource should be loaded on iPad devices only.
`~iphone` - The resource should be loaded on iPhone or iPod touch devices only.
You can apply device modifiers to any type of resource file. For example, suppose you have an image named `MyImage.png`. To specify different versions of the image for iPad and iPhone, you would create resource files with the names `MyImage~ipad.png` and `MyImage~iphone.png` and include them both in your bundle. To load the image, you would continue to refer to the resource as `MyImage.png` in your code and let the system choose the appropriate version, as shown here:
UIImage* anImage = [UIImage imageNamed:@"MyImage.png"];
On an iPhone or iPod touch device, the system loads the `MyImage~iphone.png` resource file, while on iPad, it loads the `MyImage~ipad.png` resource file. If a device-specific version of a resource is not found, the system falls back to looking for a resource with the original filename, which in the preceding example would be an image named `MyImage.png`.
本文链接

博客园_不及格的程序员-八神

Webkit CSS Effect Example

Device tokens

illustrate ARC with graphs

Including QuickTime Movies In A Web Page

IEEE printf specification

Core 's Framework

The Quartz Core framework (QuartzCore.framework) implements two important system technologies for graphics and imaging, Core Animation and Core Image.

QuartzThe Quartz umbrella framework includes the following subframeworks. You should not link directly with any of the subframeworks; instead link with (and import) Quartz.framework.

Quartz CoreThe Quartz Core framework (QuartzCore.framework) implements two important system technologies for graphics and imaging, Core Animation and Core Image.

QuickTime KitThe QuickTime Kit (QTKit.framework), or QTKit, is an Objective-C framework for manipulating QuickTime-based media. This framework lets you incorporate movie playback, movie editing, export to standard media formats, and other QuickTime behaviors easily into your applications.

The Mac Application Environment

Animations

Managing Nib Objects in iOS

Managing Nib Objects in iOS

Specifying High-Resolution Images in iOS

The Quartz Core framework (`QuartzCore.framework`) implements two important system technologies for graphics and imaging, Core Animation and Core Image.

Quartz
The Quartz umbrella framework includes the following subframeworks. You should not link directly with any of the subframeworks; instead link with (and import) `Quartz.framework`.

Quartz Core
The Quartz Core framework (`QuartzCore.framework`) implements two important system technologies for graphics and imaging, Core Animation and Core Image.

QuickTime Kit
The QuickTime Kit (`QTKit.framework`), or QTKit, is an Objective-C framework for manipulating QuickTime-based media. This framework lets you incorporate movie playback, movie editing, export to standard media formats, and other QuickTime behaviors easily into your applications.