iPad Friday: July 30, 2010

See Also
Last week's iPad Friday

Hello and happy Friday.  Today's iPad wallpapers continue our study in Light and Shadow.  Enjoy!

(click an image for the full-size wallpaper)

iPhone Friday: July 30, 2010

See Also
Last week's iPhone Friday

Hello and happy Friday.  Today's iPhone wallpapers continue our study in Light and Shadow.  Enjoy!

(click an image for the full-size wallpaper)

New app prototyping tool from Rex Xu: Apps-On

We have created a series of tools (sketch and grid paper) for designers and developers to easily layout and design iPhone and iPad apps but when I look at the work that Rex Xu just completed for his product Apps-on Post-it Notes, all I can say is, "Now why didn't we do that."

This smart little idea is basically an iPhone screen (with printed bezel) at actual size printed on Post-it Notes.  The screen itself has a 20pt dot grid making it easy to layout out your next set of comps/ideas.  And for those people who love and live by Post-it Notes, this is a great tool to add to your development toolkit.

Each Apps-on pad has 50 sheets for your designs.  Prices start at $20.00 (USD) for 5 pads for the "Starter" pack.  There is also a Pro pack with 10 pads for $30.00 (USD) and Master pack with 20 pads for only $59.00 (USD) all available online at Apps-on.com.

Good job Rex and good luck!

original link

Apple announces new 12-Core Mac Pro

Apple announced its latest update to the Mac Pro line of computers coming August.  The new Mac Pro supports up to 12 cores.  Twelve!

So now you can have a 12-core system at up to 2.93GHz and the Intel Xeon processors support Hyper-Threading, which allows two threads to run simultaneously on each core. So, for example, a 12-core Mac Pro presents 24 virtual cores that are recognized by Mac OS X.

Not only will it have incredible processing power but it allows up to 32BG RAM and up to 8TB storage (or four 512GB Solid-State drives).  I think I'm in love... again.

original link

Apple announces new 27-inch LED Cinema Display

Apple announced the coming release of a new super-sized 27-inch LED Cinema Display.

After seeing a friends 27-inch iMac, watching movies and television on it as well as working on it, I have to say that i've become a screen size-queen.  It's beautiful.  So, now I can have the 27-inch experience with my 17-inch MacBook Pro.  Thank you Apple.

original link

Apple releases new Magic Trackpad for Mac computers

Apple released a new device targeted for the Mac desktop computers: Magic Trackpad.  For all of us who have the current model of MacBook and MacBook Pro notebook computers know the new trackpad is the mouse of the mobile world, but its better (and worse) than a mouse for various reasons.  So all of you (envious) Mac Pro and iMac users who like the trackpad on the notebooks can now rest easy knowing there is an option for you to get one too.

The Magic Trackpad works just like the Multi-Touch trackpad of the notebook computers allowing you to scroll, swipe, pinch, and rotate content with your fingers.  It has both the physical and tap to click functionality of the notebook computer and uses the same set of configurable Trackpad options found in System Preferences allowing you to use gestures like Four Finger Swipe Up/Down for Exposé and Left/Right for Application Switching as well as many other features.

The Magic Trackpad uses Bluetooth and allows for a secure connection up to 33 feet away—without cables.  The profile of the Magic Trackpad is the same as the Apple Wireless Keyboard and sits flush along next to it.  The Magic Trackpad is priced at $69.00 (USD) and is available now.

original link

Objective-C Tuesdays: wide character strings

See Also
Strings in Objective-C

Last week we looked at Unicode escape sequences in C string and NSString literal. Today we'll take a quick overview of wide character strings and talk about where they fit into the iOS development.

When the C language was developed in the early 1970's, little thought was given to representing non-English languages. By default, most C compilers assumed that both code files and application output used 7-bit ASCII encoding and that each logical character in a string fit into a single 8-bit byte or char value. By the time C was first standardized by ANSI in 1989 (and by ISO in 1990), the need to handle many more characters than ASCII was obvious, but the Unicode standard was still nascent. So the ANSI C committee included a wide character type and wide character string functions in the C89 standard, but didn't tie wide character support to any specific character encoding scheme.

wchar_t
C89 introduced a new integer type, wchar_t. This is similar to a char, but typically "wider". On many systems, including Windows, a wchar_t is 16 bits. This is typical of systems that implemented their Unicode support using earlier versions of the Unicode standard, which originally defined fewer than 65,535 characters. Unicode was later expanded to support historical and special purpose character sets, so on some systems, including Mac OS X and iOS, the wchar_t type is 32 bits in size. This is often poorly documented, but you can use a simple test like this to find out:

// how big is wchar_t?
NSLog(@"wchar_t is %u bits wide", 8 * sizeof(wchar_t));

On a Mac or iPhone, this will print "wchar_t is 32 bits wide". Additionally, wchar_t is a typedef for another integer type in C. In C++, wchar_t is a built-in integer type. In practice, this means you need to #include <wchar.h> in C when using wide characters.

signed or unsigned?
The char integer type is almost always a signed integer with a range from -128 to 127. You can use the CHAR_MIN and CHAR_MAX constants defined in <limits.h> to find out the range for a particular compiler:

NSLog(@"CHAR_MIN = %0.f", (double)CHAR_MIN);
NSLog(@"CHAR_MAX = %0.f", (double)CHAR_MIN);

The wchar_t type can be signed or unsigned. The WCHAR_MIN and WCHAR_MAX constants hold the range of a wchar_t and are defined in both <wchar.h> and <stdint.h>.

NSLog(@"WCHAR_MIN = %0.f", (double)WCHAR_MIN);
NSLog(@"WCHAR_MAX = %0.f", (double)WCHAR_MIN);

On Windows, wchar_t is an unsigned 16-bit integer. On Mac and iPhone, wchar_t is a signed 32-bit integer, so the code above will print out "WCHAR_MAX = 2147483647" and "WCHAR_MIN = -2147483648". For the most part you don't need to worry about whether wchar_t is signed or unsigned; it only becomes important if you need to do comparisons and operations that mix wchar_t with other integer types (a rarity).

wide character literals
We looked at C string literals in previous entries. Wide character string literals are very similar, but are prefixed with 'L':

// example of a wide character string literal
wchar_t const *s = L"foobarf!";

Like C string literals, wide strings separated by only whitespace are considered one logical string:

// wide strings written in segments
wchar_t const *s1 = L"foo" "bar";
wchar_t const *s2 = L"Hello, " L"world!";

wide character functions
Most string functions in the standard C library are defined in the <string.h> header. A very similar set of functions for wide character strings are defined in <wchar.h>. The functions follow a similar naming convention. Where string functions are prefixed with str, the wide character equivalents are prefixed with wcs (for wide character string). So the strlen() function calculates the length of a string and the corresponding wcslen() function calculates the length of a wide character string.

not used much
In practice, you won't use wide character strings very often in Objective-C since the NSString class does just about everything wide character strings are meant to do, but you may occasionally run across them in other C libraries.

Next time, we'll begin looking at common string operations using C strings and NSStrings, starting with string concatenation.

iPad Friday: July 23, 2010

See Also
Last week's iPad Friday

Hello and happy Friday.  Todays' iPad wallpapers continue the study of light and shadows.  Enjoy.

(click an image for the full-size wallpaper)

iPhone Friday: July 23, 2010

See Also
Last week's iPhone Friday

Hello and happy Friday.  Todays' iPhone wallpapers continue the study of light and shadows.  Enjoy.

(click an image for the full-size wallpaper)

Why doesn't my UIImageView respond to taps?

If you're trying to make a UIImageView respond to a tap or other gesture and it's being stubborn and just ignoring you, make sure you've set userInteractionEnabled to YES. You can do this programmatically after the UIImageView is created or loaded or in the Attributes Inspector pane in Interface Builder if the UIImageView is defined in a NIB file. Naturally, userInteractionEnabled defaults to NO.

Objective-C Tuesdays: Unicode string literals

See Also
Strings in Objective-C

Last week we started looking into C string and NSString literals. Today we'll continue this topic by looking at embedding Unicode characters in literals using Unicode escape sequences.

Unicode escape sequences were added to the C language in the TC2 amendment to C99, and to the Objective-C language (for NSString literals) with Mac OS X 10.5. The C99 standard actually refers to these escape sequences as universal character names since C doesn't require that the compiler use a particular character set or encoding scheme, but iOS and most modern systems use the Unicode character set so we'll continue to call them "Unicode escapes".

There are two flavors of Unicode escapes. The first begins with a backslash (\) followed by a lower case 'u' and four hexadecimal digits, allowing the encoding of Unicode characters from 0 to 65535. This Unicode range encodes the basic multilingual plane, which includes most characters in common use today. The second Unicode escape type begins with a backslash (\) followed by an upper case 'U' and eight hexadecimal digits, which can encode every possible Unicode character, including historical languages and special character sets such as musical notation.

// Examples of Unicode escapes

char const *gamma1 = "\u0393";    // capital Greek letter gamma (Γ)
NSString *gamma2 = @"\U00000393"; // also Γ

Unlike hexadecimal escape sequences, Unicode escapes are required to have four or eight digits after the 'u' or 'U' respectively. If you have too few digits, the compiler generates a "incomplete universal character name" error.

If you're familiar with character encoding issues, you're probably wondering how Unicode characters get encoded in plain old C strings. Since the char data type can only hold a character value from zero to 255, what does the compiler do when it encounters a capital gamma (Γ) with a Unicode character value of 915 (or 393 in hex)? The C99 standard leaves this up to the compiler. In the version of GCC that ships with Xcode and the iOS SDK, the answer is UTF-8 encoding.

This is one potential gotcha when using Unicode escape sequences. Even though the string literal in our example specifies a single logical character, capital gamma (Γ)

char const *gamma1 = "\u0393";

the compiler has no way to encode that logical character in a single char. We would expect that

NSLog(@"%u", strlen(gamma1));

would print 1 for the length of the string, but it actually prints 2.

If you read the first post in the strings series, you might remember this table showing the memory layout of the word "Geek" in Greek letters (Γεεκ) in the UTF-8 encoding:

Address	64	65	66	67	68	69	70	71	72
Value	206	147	206	181	206	181	206	186	0
Character	'Γ'		'ε'		'ε'		'κ'		'\0'

In UTF-8, letters in the Greek alphabet take up two bytes (or chars) each. (And other characters may use three or four bytes.) The standard C strlen() function actually counts chars (or bytes) in the string rather than logical characters, which made perfect sense in 1970 when computers used ASCII or another single byte character set like Latin-1.

NSString literals suffer from a similar problem. Internally, NSString uses 16 bit words to encode each character. This made sense when NSString was created, since early versions of the Unicode standard only encoded up to 65,535 characters, so a 16 bit word value could hold any Unicode character (at the time).

Unfortunately the Unicode consortium discovered there was a strong desire to encode historical scripts and special character sets like music and math notation along with modern languages, and 16 bits wasn't large enough to accommodate all the symbols. The Unicode character set was expanded to 32 bits and the UTF-16 encoding was created. In the UTF-16 encoding, characters in the hexadecimal ranges DC00-DFFF (the low surrogates) and D800-DB7F (the high surrogates) are used in pairs to encode Unicode characters with values greater than 65,535. This is analogous to how UTF-8 uses multiple bytes to encode a single logical character.

So the musical G clef symbol (𝄞) which has Unicode value 1D11E in hex (119,070 in decimal), is encoded as two "characters" in an NSString.

// NSString sometimes has a misleading "length"
NSString *gClef = @"\U0001d11e"; // musical G clef symbol (𝄞)
NSLog(@"%u", [gClef length]);

The log statement prints out 2 instead of 1.

In memory, the NSString data looks like this:

Address	64	65	66	67	68	69
Value	0xD834		0xDD1E		0
Character	'𝄞'				'\0'

Like the strlen() function for C strings, the -length method actually returns the number of words in the NSString, which is usually but not always the number of logical characters in the NSString object.

Next time, we'll continue our dive into Unicode string madness by looking at wide character strings.

A few things iOS developers ought to know about the ARM architecture

A good blog post by Pierre Lebeaupin that examines the difference between ARMv7, ARM11, Cortex A8 and A4 and looks at some low level characteristics of the ARM processors that power the iPhone and iPad.

original link

iPad Friday: July 16, 2010

See Also
Last week's iPad Friday

Hello and happy Friday.  Today's iPad wallpapers are a study in light and shadow, global illumination and ambient occlusion.  Enjoy!

(click an image for the full-size wallpaper)

iPhone Friday: July 16, 2010

See Also
Last week's iPhone Friday

Hello and happy Friday.  Today's iPhone wallpapers are a study in light and shadow, global illumination and ambient occlusion.  Enjoy!

(click an image for the full-size wallpaper)

Objective-C Tuesdays: string literals

See Also
Strings in Objective-C

Last time we started our new topic, strings, by looking at memory organization and character encodings of C strings. Today we'll look at C string and NSString literals.

Most programs do string processing, or at least print out a status message or two. It's convenient to define some strings directly in the program's code. Since strings are really just lists of numbers, you could certainly define your strings "by the numbers" using the raw character codes:

// what does this print out?
char message[7] = { 105, 80, 104, 111, 110, 101, 0 };
printf(message);

Geek points if you recognized that message is a null terminated string. Super ultra mega geek points if you can read what it says (hint: it's ASCII).

So obviously writing the raw character codes isn't that convenient for the programmer. Since the compiler has to translate your code into machine instructions anyway, it's a no-brainer to make it translate strings into the correctly encoded bytes. A string literal is a representation of a string in your program that the compiler translates into the corresponding character codes and stores in the program's data section. There are two kinds of string literals in Objective-C: plain old C string literals and NSString literals. They look like this:

// C string literal
char const *s1 = "Hello, world!";

// NSString literal
NSString *s2 = @"Hello, world!";

The double quote characters (") mark the beginning and the end of the string literal. NSString literals are prefixed with @ to distinguish them from C string literals. It's important not to mix the two up; they're not directly compatible.

Line Breaks
String literals are not allowed to span multiple lines. Actually, that's not exactly true, so I'll illustrate what I mean; this string is not a legal string literal:

// not a legal string literal
char const *s1 = "Hello, world!
How are you?";

Line breaks are not allowed inside the double quotes in a string literal. To include a line break, you use the new line (\n) escape sequence. We'll talk more about escape sequences below, but using the new line escape sequence, the string literal becomes:

// string literal containing a new line
char const *s1 = "Hello, world!\nHow are you?";

Notice that the new line escape sequence takes the place of an actual line break in the code. When the compiler sees "\n" in a string literal, it replaces it with ASCII character code 10, the line feed (or new line) character.

But sometimes you don't want to add line breaks to your string literal, but simply to break a long string literal across several lines to make your code more readable. One way is to use a backslash (\) before the line break to tell the compiler to ignore the line break; this is often used to format long preprocessor macros. These two string literals are identical:

char const *error1 = "Unable to complete request: please wait a few minutes and try again.";

char const *error2 = "Unable to complete request: \
please wait a few minutes and try again.";

This works for NSString literals also, but note that any leading space in the continuation line will be interpreted as part of the string. Also note that the backslash (\) must be directly before the line break in the code; if you have any space or tab characters between the backslash and the line break, the compiler will complain.

A better way to do this is by simply breaking the string literal into two or more string literals that are separated only by whitespace. The following two string literals are identical:

char const *error1 = "Unable to complete request: please wait a few minutes and try again.";

char const *error2 = "Unable to complete request: "
                     "please wait a few minutes and try again.";

This also works for NSString literals; only the first part of an NSString literal is prefixed with @:

NSString *error1 = @"Unable to complete request: please wait a few minutes and try again.";

NSString *error2 = @"Unable to complete request: "
                    "please wait a few minutes and try again.";

Only spaces, tabs and line breaks are allowed between sections of a string literal. If the string is supposed to have a line break at the end of each section, you need to add new line escapes:

char const *error_page = 
  "<html>\n"
  "  <head><title>404 Not Found</title></head>\n"
  "  <body>\n"
  "    <h1>404 Not Found</h1>\n"
  "  </body>\n"
  "</html>\n"; 

Escape Sequences
There are other escape sequences like the new line (\n) escape sequence. The most commonly used ones are:

escape sequence	name	ASCII value
\n	new line or line feed	10
\r	carriage return	13
\t	tab	9
\"	double quote	34
\\	backslash	92

Each of these escape sequences requires two characters in the string literal, but becomes only one character in the string when the program is compiled.

Octal Escape Sequences
If you wish to specify an arbitrary byte value in a string literal, you can use an octal escape sequence. Octal escape sequences begin with a backslash (\) like normal escapes, but the backslash is followed by an octal (base 8) number instead of a letter or punctuation mark.

// octal escape sequence examples
char const *bell = "\7";  // ASCII code 7 (bell)
char const *bs = "\10";   // ASCII code 8 (backspace)
char const *del = "\177"; // ASCII code 127 (delete)

The octal numbers in escape sequences are limited to three digits; you can pad short octal numbers with leading zeros:

char const *bell = "\007";

which is handy to format a long sequence of octal escapes. Also note that octal numbers must be between 0 and 255. Octal escapes greater than 255 (377 octal) will be interpreted in a surprising way:

// max octal value is 377 (255 decimal)
char const *two55 = "\377";
NSLog(@"length = %u", strlen(two55));
NSLog(@"first char = %u", (unsigned char)two55[0]);
// prints: 
//   length = 1
//   first char = 255

// octal value of 378 (256 decimal) isn't a valid escape
char const *two56 = "\378";
NSLog(@"length = %u", strlen(two56));
NSLog(@"first char = %u", (unsigned char)two56[0]);
NSLog(@"second char = %u", (unsigned char)two56[1]);
// prints:
//   length = 2
//   first char = 31 (octal 37)
//   second char = 56 (ASCII code for '8')

Because the compiler will try to read up to three octal digits, an octal escape with fewer than three digits can sometimes have an unexpected interpretation. For example, embedding a form feed character (ASCII code 12, octal 14) at the start of this string produces the expected string:

char const *heading = "\14Preface";

NSLog(@"first char = %u", (unsigned char)title[0]);
NSLog(@"second char = %u", (unsigned char)title[1]);
// prints:
//   first char = 12 (form feed, octal value 14)
//   second char = 80 (ASCII code for 'P')

But if the character directly after '\14' is a valid octal digit, the compiler produces something unintended:

char const *heading = "\141. Introduction";

NSLog(@"first char = %u", (unsigned char)title[0]);
NSLog(@"second char = %u", (unsigned char)title[1]);
// prints:
//   first char = 97 (octal value 141)
//   second char = 46 (ASCII code for '.')

The heading number '1' is a valid octal digit, so the compiler assumes it's part of the octal escape. There are several ways to prevent this. You can use an escape sequence to specify the ambiguous character, break the string into parts, or simply pad the octal number with leading zeros.

// dealing with ambiguous octal escapes

// replace possible octal characters with escapes
char const *heading1 = "\14\61. Introduction"; // '\61' is octal escape for '1'

// pad octal escape to three digits
char const *heading2 = "\0141. Introduction"; // unambiguous

// break string into parts
char const *heading3 = "\14" "1. Introduction"; // easier to read

Hexadecimal Escape Sequences
Hexadecimal numbers can also be used in escape sequences to specify an arbitrary byte value. Hexadecimal escape sequences begin with a backslash (\) followed by 'x' and one or more hexadecimal (base 16) numbers. Note that the 'x' must be lower case. Like octal escapes, you can pad hexadecimal escapes with leading zeros.

// hexadecimal escape sequence examples
char const *tab = "\x09";    // ASCII code 9 (horizontal tab)
char const *newline = "\xA"; // ASCII code 10 (new line/line feed)
char const *del = "\x7f";    // ASCII code 127 (delete)

The upper hexadecimal digits (represented by A through F) can be upper or lower case.

Like octal escapes, hexadecimal escapes have a gotcha: the compiler will interpret every valid hex digit after the "\x" as part of the hexadecimal escape. For example, embedding a form feed character (ASCII code 12) at the start of this string works as expected:

char const *title = "\xcThe C Language";

NSLog(@"first char = %u", (unsigned char)title[0]);
NSLog(@"second char = %u", (unsigned char)title[1]);
// prints:
//   first char = 12 (form feed, hex value c)
//   second char = 84 (ASCII code for 'T')

Since 'T' isn't a valid hex digit, the compiler figures out that the first character is '\xc'. The following string doesn't work as expected:

char const *title = "\xcC Language Primer";

NSLog(@"first char = %u", (unsigned char)title[0]);
NSLog(@"second char = %u", (unsigned char)title[1]);
// prints:
//   first char = 204 (hex value cc)
//   second char = 32 (ASCII code for space)

Since 'C' is a valid hex digit, the compiler sees the first character as '\xcC' (cc in hex, 204 in decimal) and the second character as the space after the 'C'. To prevent this, you can replace any ambiguous character with an escape sequence, or better yet simply break the string into parts.

// dealing with ambiguous hexadecimal escapes

// replace possible hex characters with escapes
char const *title1 = "\xc\103 Language Primer"; // '\103' is octal escape for 'C'

// break string into parts
char const *title2 = "\xc" "C Language Primer"; // much easier to read

As in octal escapes, the hexadecimal number in a hexadecimal escape is limited to the range of 0 through 255. If you specify a hexadecimal escape sequence larger than 255, the compiler will emit a "hex escape sequence out of range" warning.

Next time we will continue our look at string literals by examining Unicode escape sequences.

iPad Friday: July 9, 2010

See Also
Last week's iPad Friday

Hello and happy iPad Friday!  I hope you enjoy today's iPad wallpapers.
Cheers!

(click an image for the full-size wallpaper)

iPhone Friday: July 9, 2010

See Also
Last week's iPhone Friday

Hello and happy iPhone Friday!  I hope you enjoy today's iPhone wallpapers.  Cheers!

(click an image for the full-size wallpaper)

Day One Apple iAd Earnings Five Times Android's

The an iPhone developer has posted their initial earnings from hosting Apple's new iAds in their application. According to FastCompany, iAds have gotten an impressive response:

iAd's "click-through" rate is something like five times higher, and its effective cost-per-thousand-impressions (ECPM) is around 300 times greater than offered by Android's system.

It will be interesting if other developers report similar revenue rates and if iAds continue to deliver after the novelty has worn off.

Read Day One Apple iAd Earnings Five Times Android's

original link

Will New Radiation Labels Affect Mobile Phone Sales?

Kevin has just had an article published in Xconomy:

A new law is about to go into effect in San Francisco requiring sellers of mobile phones to post the “Specific Absorption Rate” (SAR) levels of the devices. How will conveying this information to consumers affect sales of mobile phones and devices—and which manufactures will feel the burden of this new stigma?

Check it out!

original link