Robert Meraner asks:

“Do you have any idea why this code works in iOS 4.3, but no longer under iOS 5? Googling it seems to turn up some ideas, but no immediate explanation.”

This is the code Robert refers to:

NSString *currentElementValue = @"01.12.2011 09:35:13 CET";
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:@"dd.MM.yyyy HH:mm:ss zzz"];
NSDate *date = [dateFormatter dateFromString:currentElementValue];

This got me confounded initially as well, but thanks to Cédric Luthi we got an official answer to this riddle: works as intended!

Trying out the above mentioned code you indeed find that date is correctly parsed on the 4.3 iPhone Simulator. If you simulate it on the 5.0 iPhone Simulator then you get a mysterious nil.

NSDateFormatter has an NSLocale property to specify how text is output or – if you use it for parsing – is to be interpreted. So my first instinct was to try different locales because of the CET time zone abbreviation.

Lo and behold, using en_GB did the trick.

NSLocale *enLocale = [[NSLocale alloc] initWithLocaleIdentifier:@"en-GB"];
dateFormatter.locale = enLocale;
[enLocale release];

I also checked which locale was used if you didn’t set the property and found that it defaulted to en-US. So apparently there was a change for this locale in iOS 5.

Cédric had exactly the same problem and raised it with Apple. He was so kind as to share his Radar as well as the detailed response he got from an Apple engineer (emphasis mine):

Engineering has determined that this issue behaves as intended based on the following information:

This is an intentional change in iOS 5. The issue is this: With the short formats as specified by z (=zzz) or v (=vvv), there can be a lot of ambiguity. For example, “ET” for Eastern Time” could apply to different time zones in many different regions. To improve formatting and parsing reliability, the short forms are only used in a locale if the “cu” (commonly used) flag is set for the locale. Otherwise, only the long forms are used (for both formatting and parsing). This is a change in open-source CLDR 2.0 / ICU 4.8, which is the basis for the ICU in iOS 5, which in turn is the basis of NSDateFormatter behavior.

For the “en” locale (= “en_US”), the cu flag is set for metazones such as Alaska, America_Central, America_Eastern, America_Mountain, America_Pacific, Atlantic, Hawaii_Aleutian, and GMT. It is not set for Europe_Central.

However, for the “en_GB” locale, the cu flag is set for Europe_Central.

So, a formatter set for short timezone style “z” or “zzz” and locale “en” or “en_US” will not parse “CEST” or “CET”, but if the locale is instead set to “en_GB” it will parse those. The “GMT” style will be parsed by all.

If the formatter is set for the long timezone style “zzzz”, and the locale is any of “en”, “en_US”, or “en_GB”, then any of the following will be parsed, because they are unambiguous:

“Pacific Daylight Time” “Central European Summer Time” “Central European Time”

The mentioned ICU change (International Components for Unicode) is quite a mouthful, so we can be thankful that Apple is on top of what these Open Source guys are deciding and their engineers are merging all these locale fixes into our favorite operating system.

In this special case we learn that it is not wise to use time zone abbreviations in server-generated XML. Better to have all dates use UTC with time zone “Z”. Alternatively you could use the UTC offset. This is never ambiguous.

If you have no say in what comes from the server then the officially recommended locale that understands CET and CEST would be en_GB. You should always use the same locale to decode a date string as was used to encode it. The necessity for this would also be present if month names are spelled out or abbreviated in the source string.

In short: Thou shalt not rely on the default locale to understand your date strings.

Joseph Collins asks:

How do you decipher a bit mask from an argument which logically OR’d multiple values together? Enum uses bit shifting.

This question came to me while looking at UIView’s header file and wondering how Apple handles the animation options bitmask.

If you have several modes of something then usually you get by with an emum. But if you can combine several flags in s single value then you have to do this by means of bit masks. Let’s explore these today.

An enum is basically just a number, an integer. But you are telling the compiler that the individual values are legal values. Internally the first value will be 0, the second will be 1 and so on. If you want the first value to be a different value you can specify this and you can even specify a different number for each value. If you don’t, then they are just numbered sequentially.

Here’s an example from UIView.h:

typedef enum {
    UIViewAnimationCurveEaseInOut,         // slow at beginning and end
    UIViewAnimationCurveEaseIn,            // slow at beginning
    UIViewAnimationCurveEaseOut,           // slow at end
    UIViewAnimationCurveLinear
} UIViewAnimationCurve;

This defines UIViewAnimationCurveEaseInOut as 0 and the other values as 1, 2 and 3 using the automatic numbering. Often a developer chooses the default value to be the first because then a property using this type is also automatically initialized with the first value, aka 0.

From the same header file we can glean another example. Still defined as an enum, but using a bit mask:

enum {
    UIViewAutoresizingNone                 = 0,
    UIViewAutoresizingFlexibleLeftMargin   = 1 << 0,
    UIViewAutoresizingFlexibleWidth        = 1 << 1,
    UIViewAutoresizingFlexibleRightMargin  = 1 << 2,
    UIViewAutoresizingFlexibleTopMargin    = 1 << 3,
    UIViewAutoresizingFlexibleHeight       = 1 << 4,
    UIViewAutoresizingFlexibleBottomMargin = 1 << 5
};
typedef NSUInteger UIViewAutoresizing;

This is actually doing what I told you above, setting individual values for the numbers of the enum. The first value is 0, the second is a 1 bit shifted to the left by 0 positions, i.e. 1. The third value is a 1 bit shifted to the left by 1 positions, i.e. 2. The fourth is a 1 bit shifted to the left by 2 positions, i.e. 4. Get it it? They could have written out the numbers like this, but a geeky engineer preferred to write the values as shifts, number << bits_to_shift.

There's another interesting fact to be seen there. Usually you would typedef an enum and call that type something of your own. Then you would use this type for defining your properties. Apple actually does not give the enum (typedef keyword omitted) a name. But actually they define a type UIViewAutoresizing to be an unsigned integer. Isn't that a bit weird because it breaks the compile-time type checking?

To understand working with bits we need to review a couple of operators in the C language.

• logical OR: a || b
• logical NOT: !a
• logical AND: a && b
• bitwise OR: a | v
• bitwise NOT: ~a
• bitwise AND:  a & b
• bitwise shift left: a << b
• bitwise shift right:  a >> b

One thing that tends to confuse people is the distinction between “logical” and “bitwise”.  You probably have used the logical operators quite a bit in if statements. Think of the bitwise cousins of essentially the same but not just for one and zero, but for all bits of a number. A logical NOT of 5 is 0, but a bitwise NOT of 5 (bin 101) is 2 (bin 010).

To put it in simpler terms, a NOT flips all ones to zeros and vice versa. The AND and OR are twice the character for logical and once for bitwise. OR means that one of the bits needs to be one for the result to also be one. AND means that both need to be one for the result to be one. Remember that.

To combine several values from a bit mask enum into one, you simply chain them together with the pipe symbol, which is the bitwise OR operator. Mathematically a bitwise OR is the same as an addition of the values, as long as they don’t overlap.

view.autoresizingMask = UIViewAutoresizingFlexibleWidth|UIViewAutoresizingFlexibleHeight;

Now if you want to use a bit mask in your own code would involve the above mentioned type definitions as well as an if to check if certain bits of this mask are set. The simplest method I know is to basically make use of the logical AND. If the result is not equal to 0 – which it is if the bit was set – then we know that this bit was set.

if (view.autoresizingMask & UIViewAutoresizingFlexibleWidth)
{
   // bit was set
}

You could also compare the result to != 0, greater than 0 or equal to the value you are checking for but personally I think that this version is the most readable. Let me repeat that bit masks only work if you have non-overlapping numbers in the enum. Each flag needs to be a distinct bit in the number, otherwise you end up with unexpected result. Adding values to it that are not single bits would set multiple flags at the same time.

And then there’s the “pro” option. If you need to have more than a single bit on or off, but actually want to have an enum in and enum, there is also a way to do that as you can see in UIViewAnimationOptions. This is really weird to mentally parse if you are seeing that for the first time.

enum {
    UIViewAnimationOptionLayoutSubviews            = 1 <<  0,
    UIViewAnimationOptionAllowUserInteraction      = 1 <<  1, // turn on user interaction while animating
    UIViewAnimationOptionBeginFromCurrentState     = 1 <<  2, // start all views from current value, not initial value
    UIViewAnimationOptionRepeat                    = 1 <<  3, // repeat animation indefinitely
    UIViewAnimationOptionAutoreverse               = 1 <<  4, // if repeat, run animation back and forth
    UIViewAnimationOptionOverrideInheritedDuration = 1 <<  5, // ignore nested duration
    UIViewAnimationOptionOverrideInheritedCurve    = 1 <<  6, // ignore nested curve
    UIViewAnimationOptionAllowAnimatedContent      = 1 <<  7, // animate contents (applies to transitions only)
    UIViewAnimationOptionShowHideTransitionViews   = 1 <<  8, // flip to/from hidden state instead of adding/removing
 
    UIViewAnimationOptionCurveEaseInOut            = 0 << 16, // default
    UIViewAnimationOptionCurveEaseIn               = 1 << 16,
    UIViewAnimationOptionCurveEaseOut              = 2 << 16,
    UIViewAnimationOptionCurveLinear               = 3 << 16,
 
    UIViewAnimationOptionTransitionNone            = 0 << 20, // default
    UIViewAnimationOptionTransitionFlipFromLeft    = 1 << 20,
    UIViewAnimationOptionTransitionFlipFromRight   = 2 << 20,
    UIViewAnimationOptionTransitionCurlUp          = 3 << 20,
    UIViewAnimationOptionTransitionCurlDown        = 4 << 20,
    UIViewAnimationOptionTransitionCrossDissolve   = 5 << 20,
    UIViewAnimationOptionTransitionFlipFromTop     = 6 << 20,
    UIViewAnimationOptionTransitionFlipFromBottom  = 7 << 20,
};
typedef NSUInteger UIViewAnimationOptions;

I’m not dyslexic, but initially I thought “WTF are they doing shifting the number 20 (bin 10100) to the left?”. So you’re forgiven if you have the same reaction.

The first block is as we discussed before. The second and third block are actually more than single bits. You need two bits to represent the values 0 through 3. And three bits for 0 through 7. So here Apple is simply using the values and shifts them into place, 16 or 20 bits respectively. The advantage here is that a single animation options bit mask offers 32 bits that can be used. Packing the transition and the curve values into this still leaves with with a single integer to pass around.

Inside the UIKit code you probably have something like this, which shifts the values back to the right edge and then masks it and then compares.

NSUInteger transition = (animationOption >> 20) & 7;
NSUInteger curve = (animationOption >> 16) & 3;

The bitwise AND serves to mask out other set bits. Though if you are bit shifting the leftmost slot to the right, then the “incoming bits” are all zeroed anyway. But it’s probably a smart idea to make this masking a habit.

When creating your own bit masks I suggest that you name them in a similar way prefixing all enum values the same. This causes them to appear together in autocompletion and groups them logically.

Did you know you can actually also specify binary and hexadecimal values directly in your code? For hex numbers you add prefix 0x for binary prefix 0b. I heard that some compilers don’t know the binary prefix, but ours (LLVM) does. So if you EVER find yourself needing that you can use it. (You probably never will.)

NSUInteger b = 0b101; // binary
NSUInteger h = 0xAA; // hex

If you only take one thing away from this article then it should be the distinction between “logical” and “bitwise”. Because then you would also know what is wrong in the original question. Can you spot it?

Image “bitmask {phantom of the opera}” by S.D. Hilderbrand

Dany asked:

I’m looking at your (nice) project NSAttributedString-Additions-for-HTML and I have some questions about your convention of writing code.
I really hope that you can reply to me, and maybe can be an idea for a future blog post (on naming conventions, and conventions in general for objective-c).

I adopted several styles I read about in the coding style guides by Google and Marcus Zarra, though I have to admit I only skimmed through these and picket a couple of things that made sense.

Though it is good practice to reflect on your style every once in a while to see if it still serves the purpose of making your code easier to maintain and read.

Because there where several questions, let me alternate them and my answers:

You sometime put @property on .m and not in .h, you do for private variables? if so why don’t use @private?

A property is basically a shortcut to get a getter and setter method created for you. Getter-only if you specify readonly. Now for instance variables that are pointers to objects you probably want to retain these. So you specify the retain tag in the property definition. Such a retaining property releases the previous value and retains the new one, the standard implementation would look something like:

@property (nonatomic, retain) NSObject *someObject;
@synthesize someObject;
 
// becomes:
 
- (void)setSomeObject:(NSObject *)aObject
{
   if (someObject != aObject) // avoid release if no change
   {
      [someObject release]; // release previous value
      someObject = [aObject retain]; // retain new value
   }
}
 
- (NSObject *)someObject
{
   return someObject;
}

So having this ivar as a property saves me quite a bit of work with the release and retain. While that is more convenient for me, I don’t necessary want to expose all these values to outside callers. Because of that I moved the property definition into a private header extension which you can recognized by the empty category name in round brackets. This way the properties are being generated, but are not visible or callable from outside.

Now with ARC that is not so much important any more because you don’t specify release or retain. So you can safely assume that this is sort of “Pre-ARC Style” and will go the way of the dodo bird.

Sometime aren’t used @property at all, in which case exactly? I know that this just mean to use the iVar without getter\setter, but in which case you prefer to do it?

A property for a scalar value (like NSInteger, CGFloat) does the same as using the ivar directly. So I never used properties for setting/getting those because it actually adds the overhead of a function call and return as opposed to accessing the value directly from within the class.

Same question for methods prototype, you sometime put it in .m, you do this for private method? and so you keep only public method on .h?

Exactly. If I have a method that I am encapsulating some functionality in that is to be called from several places inside the class code then I still want to hide that from the outside world.

I see another thing that i don’t understand, you sometime write in your .h. why that? 2 property for the same iVar one with “readonly” in .h and the other without it in .m?

@interface YourClass : NSObject
{
   NSArray *anArray;
}
@property (nonatomic, retain, readonly) NSArray *anArray;
 
and in .m
@interface YourClass ()
   @property (nonatomic, retain) NSArray *anArray;
@end

This is the private class header extension (via anonymous category) I alluded to above. The synthesize generates a method to set the array but I only want that to be accessible from inside the .m implementation. Otherwise somebody would be able to mess with where the array ivar points to with possible unexpected consequences. You want to only allow outside callers access to the minimum amount of ivars and methods possible.

Another question, you use the prefix _ only for some iVar. Why that? Is not preferable to have always or never?

UIColor *_textColor;
UIColor *backgroundColor;
and then in .m
@synthesize textColor = _textColor;
@synthesize backgroundColor;

You see me doing that if I am overwriting a property’s setter with my own code, probably because I want something else to be triggered when the property is used. For example with the textColor you might also want to call setNeedsDisplay on the view so that the text gets redrawn with the new color.

I don’t like having to invent the name of the parameter for the setter with something preceding it with an a or an, but rather want the passed parameter to have the same name as the property.

- (void)setTextColor:(UIColor *)aTextColor
- (void)setTextColor:(UIColor *)textColor // better

Now if the name of the parameter is to be textColor then I have a problem inside this code block because the ivar has the same name. So how should the compiler know whether you mean textColor, the parameter or textColor, the ivar? Using the underscore prefix is the traditional method to have the ivar have a different name, but without messing up how it looks, because the small underscore does not hurt when reading the code.

Last question (I hope): You sometime use @synthesize and sometime implement the setter\getter manually, you do that only to add some custom behavior, right? Like call a method if the variable change.

That’s exactly the reason. If you have both a synthesize and a manual implementation of the setter method then the compiler will use manual implementation. I explained above how you sometimes need to trigger something when the setter is invoked.

Conclusion

Dany’s questions made me think about the use of properties in ARC-projects. Because you don’t need retain/release any more you probably also need to implement much fewer properties, even for internal use.

With the latest version of Apple’s LLVM compiler you also get another way of hiding unnecessary info from developers. You no longer need to define all ivars that are backing properties. Also you can now put the ivar definitions into the @implementation. But this possibility blew mind mind when I first heard about it. That’s crazy!

One reason why you DON’T want to hide everything is that you might restrict access to variables and member methods which are internal to the class too much. Like you would make it impossible for sub-classes to know about and access these. Remember that the .h file is also all that the child class knows about its super class.

If I have to come up with a rule for that:

• Hide external setters it if access by other developers breaks your class.
• Don’t hide IVARs if you foresee that your class might be subclassed and these IVARs need to be accessible.

I once dabbled a bit in podcasting myself with the Dr. Touch / Cocoanetics podcast, but I decided that I am not going to continue that on my own. I still like to TALK about it, if there’s somebody out there looking for a co-host …

Whenever I walk the dog, doing chores or “grounding myself” while gardening I like to listen when experts in our industry are discussing latest developments that impact my professional live as iOS developer.

So I asked on Twitter what your favorite related shows are and from the answers I made this list. And YES I checked it twice (several people were asking).

These are your favorite podcasts related to iOS/Mac development and Apple in general.

• “Pretty much Everything from 5BY5″ - 2 Votes
  • Build and Analyze: 4 Votes – “Brilliant”, “It’s great!”, “Personal favorite”
    Listeners agree that host Marco Arment, founder of Instapaper, is a brilliant host and listening to him makes us all feel smarter.
  • The Talkshow: Host John Gruber, Apple fanboy par excellence, discusses all around Apple.
  • Hypercritical: John Siracusa of Ars Technica fame presents the critical view of Apple’s doings.
• NSBrief: “A brief podcast cast for Cocoa developers, talking about interesting developer-y stuff” – 2 Votes
• iDeveloper Live – 1 Vote
• IRQ Conflict: an interesting format: “Apple Developer. Microsoft Developer. FIGHT!” – 1 Vote
• We Have Communicators – 1 Vote
• Cocos2D Podcast: Indie Game Developer Steffen Itterheim talks about topics related to learning to use this game engine – 1 Vote

There are two more shows that I myself like with a bit of a broader scope. Strangely I was the only one mentioning these, so it seems that 5BY5 has a way larger mindshare in developers than the well established TWIT network.

Also mentioned where these podcasts, either not updated in a while or hardly relevant:

• Core Intuition: last update in June - 1 Vote
• Cocoaheads.at Podcast (German) – 1 Vote
• Hamish & Andy: an Australian Comedy Duo, no idea why it’s supposed to be of relevance to us … – 1 Vote

Over the past few months I have received questions about NSAttributedString+HTML and Rich Text Editing. Here are the Frequently Asked Questions.

I generally abbreviate NSAttributedString+HTML as NSAS+HTML. If your question or app is not in this list please let me know.

General / Cost / Licensing

What is NSAS+HTML?

Cocoa on the Mac has an initWithHTML method on NSAttributedString. NSAS+HTML consists of 3 parts:

1. A reverse-engineered and enhanced implementation of the Mac initWithHTML for use on iOS
2. UI classes to properly render the created NSAttributedString
3. Objective-C wrapper classes for CoreText to simplify it’s use

The goal of NSAS+HTML is to provide a comprehensive way to eliminate UIWebViews from your apps and reap the benefits of being able to fully control the way the rich text is rendered and how your users interact with it.

Where does it live? How do you contribute to it?

NSAS+HTML is hosted on GitHub. If you find problems then please open an issue there. If you fix a problem or add a new feature then you can send a pull request so that the modifications from your fork can be merged into the master repository.

Does NSAS+HTML contain private APIs?

No. All code was newly created by the original author Oliver Drobnik as well as several contributors. NSAS+HTML is not a web browser, but instead renders views described with HTML.

Is NSAS+HTML legal to be used in App Store Apps?

Yes. A growing number of apps is using NSAS+HTML, the examples I know about are:

• APODViewer and APODViewer HD
• Float Reader (Making Of)
• SOStacked
• Russ.No

Please let me know if your app is not in this list so that I can add it.

How is NSAS+HTML licensed?

NSAttributedString+HTML is licensed under a BSD license. This means that you can use it for free in free and commercial products as long as you mention in the app that it contains “NSAttributedString+HTML copyright by Oliver Drobnik / Cocoanetics”.

Binary apps must display such a copyright notice somewhere accessible to the user, for example in the settings or about page. Source code apps must contain the license text file that is part of the GitHub project.

Is there a way to use NSAS+HTML without attributing it?

Yes. You can purchase a non-attribution license for €75 for it that eliminates the need for the attribution while still being able to use it in your commercial and free apps.

Does NSAS+HTML support Rich Text Editing?

No. By itself NSAS+HTML only renders. A commercial component of mine, called DTRichTextEditor, builds on it and adds text input.

What is the difference between DTAttributedTextView and DTAttributedTextContentView?

DTAttributedTextView is a scrollview sub class that has a DTAttributedTextContentView as sole sub view. DTAttributedTextContentView sizes itself to automatically fit the text.

Fonts

What is the default font?

Times New Roman, 12 px. If you don’t specify any font attributes in the HTML this will be the font that is used. Headers are sized relative to that.

How do you change the default font size on DTAttributedTextView?

You can pass a dictionary with a variety of parameters to initWithHTML. One of these parameters is NSTextSizeMultiplierDocumentOption the text scale that causes all fonts to be a multiple of what their default would be. This affects all headers and body text equally.

Why does the first time attributed text is shown take 1 sec?

This is a bug in iOS that causes an extensive font matching table to be created the first time a CTFont is required. You have two possible workarounds available:

1. Pre-initialize CoreText as shown here on a background thread.
2. Put all the fonts you require in CoreTextFontOverrides.plist

If you only using one font then number 2 is the recommended method since it bypasses CoreText font matching.

What is the difference between Font, Font Face, Font Family and Font Variant?

A font family is the overall grouping of multiple fonts. Each font represents one look, like plain or bold. Font and Font Face are the same. Font is often used incorrectly synonymous with Font Family.

For example the Helvetica font family consists of these fonts/faces:

• Helvetica
• Helvetica-Bold
• Helvetica-Oblique
• Helvetica-BoldOblique

When NSAS+HTML requires a font face from a given family with a given size it will first look into the overrides plist (if present) and then use CoreText font matching.

Font Variants are different representations contained within the same font file/face. For example on iPad there is one font that contains also a small caps variant. A bold font is NOT a variant, it is a font in its own right.

Implementation

How can DTAttributedTextView be used in table view cells?

DTAttributedTextView should not be used in table view cells because it is a scrollview. You can either use DTAttributedTextContentView and use their automatically sized heights for the heightForRowAtIndexPath or use the specially created DTAttributedTextCell class for that purpose. Please refer to DemoSnippetsViewController.m to see how it is used.

Please note that if you are using a different height for each row this dramatically reduces table view scrolling performance. Instead we recommend to use a fixed height.

After implementing DTAttributedTextView URLs show up but cannot be clicked, why?

NSAS+HTML is only in charge of rendering the text, you have to take care of the interactivity because everybody might have different needs.

NSAS+HTML provides delegate methods asking for custom subviews to be put over links. You can use the DTLinkButton provided with NSAS+HTML and have this perform any action you like.

What is DTTextAttachment?

DTTextAttachment encapsulates any kind of object that the layout process should reserve space for. This could be an image or a video. The space that is reserved for displaying this is taken from the displaySize property.

How are images rendered?

NSAS+HTML has two built in methods to render images. Either you enable the shouldDrawImages property on the content view which will draw local images together with the text. Or you implement the delegate method to provide your own UIView to show the contents of the DTTextAttachment that encapsulates the image.

For local images the contents property of the attachment contains the UIImage, for remote images the contentURL provides the URL for lazy loading. NSAS+HTML provides DTLazyImageView which demonstrates how to lazily load images from remote URLs, please refer to DemoTextViewController.m to see how this is integrated.

Note that you have to trigger a re-layout once you have loaded a remote image as soon as the actually displaySize of the DTTextAttachment is known. This step is not necessary if you specify a width/height in the HTML tag because then the displaySize of the attachment is known for layouting.

Does NSAS+HTML support Floating of Images?

No. Floating allows images to be positioned on the left or right side of the document and have text flow around them. Currently layouting is done in a single pass with one layout frame. To support floating of text attachments multiple passes would be required to determine the optimal sizing of multiple rectangles to be filled with text.

Does NSAS+HTML support multiple column layout?

Yes and No. The provided UI classes only work with a single layout frame.

To get multiple column layout you have to create your own UIView that takes multiple layout frames. The steps are:

1. Create your DTCoreTextLayouter from the attributed string.
2. Create a DTCoreTextLayoutFrame for the first column specifying the rectangle
3. Create a second layout frame for the second column specifying another rectangle and the starting index that is one higher than the ending index in the first column
4. Repeat this for each column

Once you have all these layout frames your UIView subclass only needs to call renderInContext for all columns.

Does NSAS+HTML support CSS styles sheets?

Not yet, but some contributors are working on this. At present only styles that are contained in the individual tags are recognized.

Does NSAS+HTML also allow for creating HTML out of attributed strings?

Yes. There is a htmlString method in the HTML category. This needs much work still.

Does NSAS+HTML support Margin or Padding?

No. Those are attributes that require the distribute the text into multiple blocks. There is no block level support in NSAS, essentially one layout frame is one big block.

You can specify edgeInsets on all sides for  DTAttributedTextContentView which considers this inset on sizing the layout frame.

Jason Jardim asked (4 Months ago):

This is just a screen shot I found with someone posting a similar question.  I am trying to fade out he top/ bottom cells in a tableview. How do I achieve this effect?

First of all, Jason, I am sorry it took so long. I was extremely busy during the past few months but I kept your e-mail at the bottom of my inbox as something that I am really interested in to give a good answer to.

Let me make it up for you by proposing several solutions to your question as well as show one that I find the coolest.

First of all by looking at the sample screenshot we see that there is a border around the table view. This tells us that the table view does not fill the entire screen but there is obviously an imageView responsible for the ornamentals surrounding the table view.

If we go with this imageView then the next question is whether the image is below or above the table view itself. The first instinct might be “below!” but that can be treacherous and cause you more work than is actually needed to achieve this effect. You could just as well have the part for the table view “cut out” in the image, i.e. have the center portion be Alpha 0 and the top and bottom would be an alpha gradient from 100% to 0%.

A designer versed with Photoshop could easily create something like this for you. Then you put this imageView on top of your table view, size the table view to fit inside the border. Finally you will want to make sure that userInteraction is disabled on the imageView, because otherwise no touches would be reaching the table view.

While this solution is simple it does not satisfy me personally. As developer I want to achieve such an effect entirely in code because then it has the added advantage of being independent or resolution or interface orientation.

The first thing we’ll try is to mask the layer of the table view. On iOS each UIView has a CALayer that takes care of the actual drawing. And each CALayer has a mask property where you can set another layer to mask out parts of the host layer.

For masking layers it does not matter which colors you use because only the alpha value of each pixel is considered for the composition. 100% alpha means that a layer pixel shows fully, 0% alpha causes a layer pixel to be transparent.

For this tutorial I created a new navigation-based app without CoreData. We also need the QuartzCore.framework for the advanced layer handling methods. A useful layer type for this purpose is CAGradientLayer which exists since iOS version 3.0.

RootViewController.h

#import <UIKit/UIKit.h>
#import <QuartzCore/QuartzCore.h>
 
@interface RootViewController : UITableViewController
{
    CAGradientLayer *maskLayer;
}
 
@end

For the sake of simplicity we create the mask in viewWillAppear because at this point the table view has already been resized to the proper size. If we would create it earlier (or if you plan to support different sizes) then you would also need code to adjust the layer bounds to fit.

- (void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
 
    if (!maskLayer)
    {
        maskLayer = [CAGradientLayer layer];
 
        CGColorRef outerColor = [UIColor colorWithWhite:1.0 alpha:0.0].CGColor;
        CGColorRef innerColor = [UIColor colorWithWhite:1.0 alpha:1.0].CGColor;
 
        maskLayer.colors = [NSArray arrayWithObjects:(id)outerColor, 
                            (id)innerColor, (id)innerColor, (id)outerColor, nil];
        maskLayer.locations = [NSArray arrayWithObjects:[NSNumber numberWithFloat:0.0], 
                            [NSNumber numberWithFloat:0.2], 
                            [NSNumber numberWithFloat:0.8], 
                            [NSNumber numberWithFloat:1.0], nil];
 
        maskLayer.bounds = CGRectMake(0, 0,
                            self.tableView.frame.size.width,
                            self.tableView.frame.size.height);
        maskLayer.anchorPoint = CGPointZero;
 
       self.view.layer.mask = maskLayer;
    }
}

We only create the layer once. Since there can be only one mask layer at a time we combine the top and the bottom gradient into one where the outer areas will be 20% of the entire height. The default anchor point is the center of the layer, so we change that to the top left.

If we stopped here then you would get the gradients, but they would move together with the contents of the table view. Luckily table views are UIScrollView child classes and thus you can also implement the UIScrollViewDelegate methods. We are using the one that fires on each movement to adjust the position of the masking layer.

- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
    [CATransaction begin];
    [CATransaction setDisableActions:YES];
    maskLayer.position = CGPointMake(0, scrollView.contentOffset.y);
    [CATransaction commit];
}

Note that we also need to disable actions because position is an animatable property on CALayer. If you set that this triggers an implicit animation which would cause the masking layer to lag behind. With actions disabled the layer position is set right away.

There’s another problem that only becomes apparent if you start scrolling and the vertical scroll bar shows: it is also affected by the mask which you probably don’t want because it looks weird.

So instead of actually use the mask for the regular layer masking we add it as a sublayer. Because now the colors are just composited on top of the table view we have to reverse them or else the inside would be whitened out and only the outside would show.

- (void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
 
    if (!maskLayer)
    {
        maskLayer = [CAGradientLayer layer];
 
        CGColorRef outerColor = [UIColor colorWithWhite:1.0 alpha:1.0].CGColor;
        CGColorRef innerColor = [UIColor colorWithWhite:1.0 alpha:0.0].CGColor;
 
        maskLayer.colors = [NSArray arrayWithObjects:(id)outerColor, 
                            (id)innerColor, (id)innerColor, (id)outerColor, nil];
        maskLayer.locations = [NSArray arrayWithObjects:[NSNumber numberWithFloat:0.0], 
                            [NSNumber numberWithFloat:0.2], 
                            [NSNumber numberWithFloat:0.8], 
                            [NSNumber numberWithFloat:1.0], nil];
 
        maskLayer.bounds = CGRectMake(0, 0,
                            self.tableView.frame.size.width,
                            self.tableView.frame.size.height);
        maskLayer.anchorPoint = CGPointZero;
 
        [self.view.layer addSublayer:maskLayer];
    }
}

This change brought us full circle to essentially adding an imageView on top of the table view to mask out the edge gradients. In this example the rootViewController’s view is a UITableView and so we have no other place to add this sublayer to. But if the table View were itself a subview of some larger view we could add the gradient layer there and not having to deal with the scrolling.

Actually it’s not entirely true that there’s no other layer besides the table view one. You can always move to the view’s superview and add it there, but this is considered bad form, a view should only fiddle with it’s own descendants.

This tutorial has shown how you can employ a CAGradientLayer to block out parts of another view. With the same technique you could for example use a CAShapeLayer to mask out an irregular portion of any view. Or you could use a plain image as contents of a plain CALayer for such an effect.

Yet another possibility – if you want the gradients to be built into the table view itself – would be to subclass UITableView and do the gradient management there. Either use one large gradient or have two UIViews that draw the gradients individually. There you would put the repositioning of the gradients into the layoutSubviews property instead of the scrollview delegate method.

Happy Masking!

On the heels of the iOS 5 announcement I started getting a multitude of e-mails asking more or less the same thing:

I have only my everyday iPhone for developing, so usually I am careful with updating. Do you think that iOS 5 is sufficiently developed and error free to install it on your main phone?

Sorry, but actually my first reaction to this question is to laugh out loud. But – once I have regained my composure – let me give you a serious answer to this question which is probably really not meant as a joke.

I can understand that everybody is excited about the many new features in iOS 5. This includes me, I’m loving the new Notification Center, I love to play with Safari’s Reader Mode and Reading List, tweet photos directly from Photo Album and poke around in the settings to see what else is new.

Curiosity got the better of me, for a simple reason: I consider it my job to test the new iOS in real life scenarios and so I generally tend to take the plunge. All BETAs go on all my main devices as soon as I can download them. BUT, and that’s a big but: my business and communications are not solely dependent on my mobile phone. If iOS 5 would have messed up any device of mine, I could still function. The same goes for my MacBook Air which runs the latest preview version of Lion. Again, that’s mostly out of curiosity and because I consider traveling fun. Serious work is done on my 27″ iMac in my office and there I never would want to take this risk.

I found already a handful of glitches that I am going to report bugs to Apple for. Besides of adding a ton of shiny new stuff, Apple has also tweaked many frameworks under the hood. We hear of apps breaking down because in some scenarios a method might not be called that should. There are many other such instances where something broke that we developers are used to relying on.

But not all problems are Apple’s fault. I know one one scenario (in my own code) where a scrollview hack is now cause for a crash. One thing that you could do before iOS 5 is now a cause for an exception, that specifically tells you NOT do do that. It’s a pity, knowing this “workaround” made me feel so smart. But seeing my app crash, makes me feel the opposite: feeling rather dumb.

If you update to iOS 5, there is no turning back. There is no way of downgrading back to iOS 4 as far as I understand. Pros tend to buy a so-called “Sacrificial iPod Touch” for the express purpose of NOT risking their main hardware.

iOS 5 is a loaded gun that not everybody with a developer license should be allowed to handle. Malcom Barclay reported receiving several iTunes reviews mentioning that the users had updated to iOS 5 with the consequence of apps crashing or no longer running. This is funny and sad at the same time.

NO, this review was NOT helpful. Generally developers appreciate if you are reporting issues to them, but you should be doing that via a support functionality or e-mail, not via 1-star reviews.

In my case I found that Evernote does no longer display note’s content, both on iPhone and iPad. I can see how this would disable some people who are using Evernote to store every piece of valuable information. In my case I will definitely survive not having it work for some time, it still works on my Macs.

You can bet that if thousands of developers install iOS 5 then Apple will be receiving tons of extra bug reports. But this is generally the idea! Apple should be able to trust us developers to treat BETA and preview versions as means to make the final product better, so that the Millions of real-life users have an even better experience when they finally upgrade in the fall.

So where does this leave you? Should you or should you not?

Nobody can answer this question for you. You SHOULD stick with stable versions if you are dependent on the devices being fully functional. If you are as foolhardy as I am AND you don’t care if your devices might become unusable for your specific use case, then you CAN try it out. But please PLEASE don’t bug other developers with the consequences of your decision. And be sure to help Apple out by submitting bug reports for all glitches you find so that the next BETA can be an improvement.

Being a member in the developer program is a license … a license to kill … your device. Your call.

As a fellow iOS Developer you might find yourself in San Francisco for WWDC or maybe on assignment. If you’re like me then you cannot survive with a modicum of connectivity. Unfortunately AT&T has visitors jump through hoops and has loads of horror stories in stock to deter people from getting what they really want.

Thanks to my sponsors at Scribd I’m here in San Francisco for the second time this year and I would like to summarize what I have learned about your options when it comes to getting affordable wireless data for the short time you’ll be in the USA.

So far I have found two viable options, the easier one being with T-Mobile, the harder but ultimately more enjoyable one going via the main iPhone carrier in the US, AT&T. 

T-Mobile

T-Mobile is making quite some business it seems as in most locations where you have an AT&T retail store you find a T-Mobile shop quite near, often just across the street. This is the case at the stores that are closest to the Market Street.

When I tried the first time, obviously, I wanted to enter the AT&T store first, but they had already closed for the day, T-Mobile has longer hours. At the mentioned location the manager has a professional Sim-Card cutter handy and is only too willing to convert a Web2Go Sim card for the iPhone 4 format. There’s one caveat: due to T-Mobile using an unusual 3G frequency you won’t get 3G data with them.

You want to get the regular prepaid deal that has access to the unlimited day passes. This is an option that you have to activate every 24 hours, but then you get unlimited EDGE for the duration for a rock bottom rate of $1.49 per day. EDGE is only like slightly more than 100kbps, but that’s still sufficient to navigate around San Francisco with the maps app, tweet a lot and have your mails pushed to you. Unlimited peace of mind.

You quickly get used to going to the special URL (that still works) and activating another 24 hours from your balance. I was told that the balance expires after a certain number of days, but when I returned outside of this period, I still found my balance intact.

The only thing that did not work was being redirected to the URL for activating another day pass. But with some friendly in-store help we got this working again, it turns out that with the direct URL I could simply reactivate the service.

AT&T

If you are a bit more on the adventurous side, then you’ll get bored with the simplicity of T-Mobile. That’s where you need to go. If you are a true iPhone fan, then you’ll also endure the lack of competence on behalf of the AT&T store staff. It actually took me three trips to three stores to get to my final (successful) result.

If you just enter a store without some mental preparation (that this blog post aims to provide) then you will hear one or more of the following stories, let me also add where the grain of truth is contained.

“We are not selling Prepaid for Smartphones”
- not true, you are. You’re just not SUPPORTING it.

“It only works with Android phones”
- there once was a Phone2Go card where this actually was true, but this does no longer apply for the current ones (with orange bubbles design)

“It does not work with iPhones”
- if you don’t modify the APN settings that might be true. But there are tools to do that which makes it only half-true, namely for n00bs.

“It sucks out all the credit if you use an unsupported phone”
- LOL, the proof for this was one guy that synched his entire mailbox from scratch and found himself out of credit after 100 MB or so.

“We’re all out of Micro-SIMs in San Francisco”
- that might be true, because the only Micro-SIMs that AT&T stores carry are the packages needed for the iPad and replacements for contract-bound iPhone 4. They are not allowed to sell you a Micro-SIM as prepaid.

You basically have two options: 1) to either jump through these hoops with keeping a straight face face while specifically stating that they don’t have to care what phone you put the card into and that you assume all risk they just should let you have a new prepaid account and sell you a regular SIM card. You will then take care of the necessary modifications yourself. 2) to not go into a corporate AT&T store but to pay a visit to the numerous independent vendors, who are only too happy to help you.

Here are the ingredients I used for getting AT&T prepaid data on my iPhone 4.

1. iPhone without Sim-Lock, mine is factory-unlocked from the UK
2. regular size SIM card for GoPhone, make sure that this is one that optionally supports a data package
3. since I don’t plan to make any phone calls I chose the 10ct/min Calling Plan
4. The minimum initial charge is $25, from these the people in the store activated the 100 MB package for $15. You can also do that later, but I found it more convenient to have this done in store already.
5. iPhone 4 users now have to convert the regular size SIM into a Micro-SIM. This can be done – if you are brave – with scissors based on a template, or with a SIM cutter.
6. The last step is best done if you have an alternate internet connection, like Hotel WiFi. I used the APN Changer online tool to create a profile to set my APN. An alternate route is to do this manually with the official Enterprise Configuration Utility.
7. That’s it. I recommend disabling cellular data until you have set everything up, just in case the story about the credits being sucked out is actually true …

If you are in the area new the Moscone center, locals call it “Market Street”, then tweet up Jeremy Johnstone who lives a block from there and would love to show off his mad SIM cutting skills with a professional tool. I have a feeling that he’ll never run out of sponsored beers for the next weeks.

And if you are in the Fisherman’s Wharf area, you can have the full service option from Fernando Cortes who runs a small phone shop (AT&T Affiliate) on 2056 Chestnut Street. It’s a bit out of the way but he’s open on weekends too, so I can definitely recommend that you go the distance if you don’t want to hear silly stories and combine the procurement of 3G data with a visit to the Wharf.

There might be one other option: some people have gotten replacement iPhone 4 SIMs claiming that theirs was broken. But I prefer to stick to the truth, it shall set you free.

One more note: Your prepaid balance expires if you don’t refill periodically. The expiration durations are 30 days for less than $25, $25 through $75 expire in 90 days and $100 refill expires in 365 days. So if you know that you’d like to come back to next year’s WWDC, then you’ll either have to start the dance from scratch or keep your account alive by adding credit to it every couple of months. I’m thinking about topping it off for $100 once before I leave and then be done with it.

Update June 4th, a week later: Now my first 100 MB were used up, so I refilled my account via credit card for $100 (to get the 365 days non-expiration) and from these I used $25 for 500 MB MB. That should be more than enough to get me over WWDC and the navigating/twittering for my second week in San Francisco.

Devin Snipes asks:

I’ve advanced in my iOS development and have officially started work on a client project. My client has requested tons of changes since I told them the application was complete. Should I keep doing these changes or just stop. I under-charged them, made several thousand changes and also felt like I over-worked myself. How would you deal with this?

My second question is related to the somewhat ‘legal’ matters of iOS development. Do you have a standard iOS development contract that you request your clients to abide by? If so, could you send me a copy or could I look over it to get some idea as to what I should do.

Both are really good questions. (“Good question” usually means that they don’t have a simple answer)But let me attempt to go back in my own experience and give you a couple of pointers as to how I dealt with exactly the same situation and what I learned from it.

As a rule of thumb people who contract you for making an app are cheap. Cheap as in Uncle Scrooge. And they know that whoever commits to a number first, loses. That’s why they ask you for a quote knowing dead well that as a beginning programmer you are absolutely incapable of judging the true amount of work that you will put into the app. Being the kind of lottery that is the app store, these couple of hundred dollars are sort of the price for their ticket. Low cost, potentially big rewards. Buy another name this is called “business sense”. Keep costs low to have a big margin.

So they say “it’s a really simple idea, it just needs this, this and this. How soon can you have done it, for what price?” And that’s a trick question that tricks beginning developers into thinking about facts. You think “ok, these are 3 fairly simple items, maybe I can do these in x hours”, you multiply this by a rate that you feel you should be worth and that’s what you quote. Only to find that when you present the first version to the client you get a “And what about feature x? I thought it is obvious that this has to be in there as well! Without that the app is worthless”. And this goes several times back and forth until you have spend three times as much on the job as you quoted initially.

Then there’s work that you did not quote, but still need to do, because the client has no Apple account, you need to build, hand-hold the client through the submission process and the app starts getting downloads you get the crash reports. The app might be successful like in the case of my first contracting client who made $10,000 in the first month, with an app that I charged him $400 for. Or the app might crash and burn and you hear “I would have paid you more, but unfortunately the app is not selling”.

The theme of all this being: you have lots of work, but don’t get paid for it. On a tangent you might be wisening up and refuse to work any more, only to find an e-mail from your client requesting that you hand over the source code so that another developer will continue on the app.

I know this from having fallen prey to several such sharks myself. So how can you avoid being tricked like that? Developing iOS apps should be rewarding, not draining you.

Your second question goes in the right direction, but let me tell you outright that I don’t have a standard iOS development contract. You might find some on the Internet, but I fear that you suspect that if you had a written contract that this would be the magic bullet that would make it all alright for you. But it doesn’t. No contract is worth the paper it is printed on, if you don’t know what it is supposed to do. A contract is nothing but a summary of items that two parties are agreeing upon. So make up your own! You are fully capable of writing on a piece of paper “Devin Snipes and Client X are agreeing that …” and fill in what you feel is worth agreeing on.

Let me give you a list of items that I would put in there personally:

Design

I tell people: ” I am not a designer, I am a programmer”. I expect UI/UX design to be provided in form of Mockups and written functional specification. That means I want a document that describes what the app can do and essentially how you navigate between it’s functions. My strength is writing efficient code fast, it would be a waste of the client’s money if he also paid me for photoshopping some Google Images into app icons.

If you are dealing with companies then most of the time they have their own designers, you can offer to do a (chargeable) workshop with them to give them some pointers as to how to approach the UX/UI and technical stuff like what resolution images you want and that the double-resolution images should be named a certain way.

If the client cannot provide that, then I have friends and partners who can help him distill out such a spec, for a price. In either case you should only start touching code once you feel that all questions are answered and all functions are set. Unless the client wants a prototype, which is a project of its own.

Tell your client “Apple says a good app is 60% design”. This means that they can save 60% of the total app costs of they do all the design legwork before talking to you. You know, a typical designer charges around $500 for an app icon. Not because it’s the first piece of artwork that’s seen from an app. The reason for this high cost is that even a pro would work 1-2 days on it. Knowing this, how do you now feel that you promised that you would do this “quick app” in a week for the same amount that somebody else pays a designer for just the icon?

Price

If you have the strength then you should not commit to a quote. Ideally you will charge for each and every hour you spend on this project and – trust me – you have NO IDEA how many hours this will actually be. But if they insist and threaten to take the business else where (and you need the money) then you can put together a quote, but itemize it. Referring to the earlier mentioned design document you should make a list, item 1 …. x hours, item 2 …. y hours, etc.

Don’t forget to allot time for: project setup, communication, app store submission, version 1 bug fixing, testing and whatever work you have to do besides of coding. And when you have estimated all the hours, take everything times two. You will arrive at a final quote that is orders of magnitude higher than what you would have quoted shooting from the hip.

And then when the client complains that he thinks you are calculating too many hours for “such a simple app”, you tell him: for an all in quote you have to factor in unforeseen eventualities, that’s why he probably will be way better of just paying your billable hours every 2 weeks or monthly. An hour-based arrangement should always feel to the client as being the better deal, because he knows that for all-in projects you are probably faster than you estimate.

Honestly I have the most respect for iOS developers who have an hour-based ongoing arrangement with their clients. And I kind of feel sad for the poor solo developers who let themselves be suckered into too-cheap all-in deals.

There is another philosophy, but this applies more for small contracting outfits: agile project management, called SCRUM. There the amount of effort for certain features is not estimated in hours, but relative to each other as a number of points. One item (called a “User Story”) could have 5 points and if something else is the same amount of work, it will have the same number of points. With scrum the customer will never see hours, but you will have a certain mutliplier (that only you know) to convert these so called “Story Points” into currency.

Scope

On several occasions you should stress that the agreed upon project scope is only what is written down in the functional spec design document. There are absolutely NO “obvious features” and there is no “I thought we also said we would do x”. If it’s not in the spec then it’s not covered. The client CAN have it, but it increases the project cost.

It is usually sufficient to just make a quote addendum similar to the first itemized quote: new item A …. x hours. And then ask the client to agree to the project extension in an e-mail. Everything that makes the project bigger you want to have documented somewhere. You could add it to the functional specification document or simply collect it in your mail box. But you might need to go back eventually and present to your client – refusing to pay more – the items that he sent you his approval for.

I told you earlier: a contract is everything that two people agree upon verbally or in written words. So those e-mails are essentially mini-contracts themselves. But don’t make the mistake of only discussing this on the phone, because people will generally choose to only remember talking that suits their agenda. On a study that was done, they found that people lie the most on the telephone because there is no record of it.

As a beginner you might be falling in love with all the nifty little things you could add to an app to make it “better”. The client didn’t ask for it, but hey, why not do a UIView animation from a to b. It looks SO MUCH MORE professional with that … STOP THAT right now! If you have cool ideas, don’t just put them in the app, but instead suggest them to the client. Most likely he will value your initiative but you will then actually have his approval for the extra stuff.

It is your job to follow the spec as closely as you can with the least amount of extra work. I like to structure my code to be reusing components wherever I can. So if you think that something you develop for one client might be useful later on, then design for reusablilty. This means for example, writing a delegate protocol instead of having all parameters of a class in fixed instance variables. This is not much extra work, but might save you some in the future. But bear in mind that you are not getting paid for too much creative programming. You should not expect your client to be happy about paying for your future benefits.

You want to write the least amount of code that covers the requirements. And if time permits make it loosely coupled and written in a way that you can come back to this code in half a year and still know how the pieces fit together.

Scheduling

Be clear about the amount of time you can put into a client’s project. Often a client would expect you to finish the project in the same amount that a full-time developer would take. But especially when you’re still going to school or university you might not have more than a couple of hours every day to work on this.  Even full time I am not estimated with more than 6 useful coding hours per day. Maybe I’m getting old (37 years) but writing good code is hard work on my brain.

Your client probably approached you, Devin, not because of your speed, but because he knows that he will get his app made for cheap. So right after nailing you on a low price he will try to get you committed on a release date. Rule Number 1 in IT: It’s finished, when it’s done.

Just be honest with the guy. You’ll do your best to do some magic, but miracles take a little longer. If he needs it by a certain date then you need to get more resources. If you estimate 40 hours for an app, then 2 guys might be able to do it in about half the time, possibly slightly more because of the additional overhead. You have to judge when to sub-contract parts of the app to another developer. Don’t feel bad if you have to do, your thoughts should not be revolving around how much money you will lose because it now goes to the second developer. If you were smart in your negotiations then you have enough room to keep 10-20% of the payment and still pass on a decent amount per hour to your samaritan.

Ownership

Generally if there is no other agreement made then the (self-employed) developer retains ownership of the source code. It’s just like any other written piece of art. He who wrote it owns the authorship rights. The client only implicitly gets the right to commercial use of the final product he commissioned. Without a contract that modifies this default situation you own the source and don’t have to give it to anybody. BTW this is not true for employees, there everything they invent belongs to their employer per default.

This is important to know for two reasons: 1) if a client is smart and has you sign a contract containing the “hand-me-over-the-source-clause” then you will need to be aware of this as this means you potentially lose any future business with him. Thus you have to charge more up front. 2) if there is a conflict of interest or he does not pay you have a great hostage.

I usually keep all project source code in a repository on my server so that I have at least two copies, one on my local machine (plus Timemachine backup), one on my server on the internet. For very select clients I give them a read-only access to the repository, but only if I am certain that we have an ongoing business relationship. There is the rare case when I am handing over the source, but that’s usually when I feel that there’s no hope of every making another Dime from this guy.

But even handing over the code does not mean you cannot reuse parts of what you made. When you code you learn how to achieve certain things better and faster and this knowledge you cannot selectively forget. Who is to keep you from building a new class from scratch that does exactly work the same as the other class the source of which you just handed over? (Well, in the US your client theoretically has the option of patenting what you made, but let’s not worry about this for now)

Conflict Resolution

There are two ways how people get paid for projects: either by sending invoices periodically for the hours they worked, or by sending two or three invoices for installments of the total project cost. You could agree on a third up front on signing, a third when the first prototype is done and a third the day you submit to the app store. Any such payment can also be seen as the client being ok with what happened so far.

If you had any form of contract or agreement then the payment schedule would have been a part of it. But then you would also have an agreement on the other items mentioned above. So what do you do – as a beginner – if the client tells you that he won’t pay anything more than he original was quoted. I had this very situation about a year ago, have a look at the recommendations of how to deal with contracting clients who don’t want to pay.

Now about your case: I definitely recommend you compile a list of the original specs and then a second list with all the items that were added later. The original specs are what payment was agreed on. The additional specs still need such an agreement. In one case the original project quote was for 400 Euros and by making this addendum list I was able to show to the client that he approved over 100% more hours of work. Multiplied with my rate at that time, that increased the project payment to 1500 Euros. There were some items where I couldn’t find any e-mail with him responding OK, so these I essentially did for free.

If your client is unfazed by the second list, then you should be clear about being willing to walk away from the project. Either you agree to agree on a mode that you both can live with. Or you agree to disagree. The client is free to find himself another developer (whom you should secretly warn about him and send him to this article). Your stance should communicate that you are definitely willing to drop everything related to his app if no agreement can be reached.

As a beginner your feeling might be “oh my god this is my only customer and if he doesn’t like me I might never again find another”. But don’t you worry, there is much more iOS work to be done than there are developers. Usually demonstrating this “willingness to walk away” does NOT result in terminating the project. Rather the client will start to take you seriously and stop seeing you as a cheap coding monkey but as a human being who stands up for himself. And probably willing to negotiate agreeable terms as he still wants this app to be finished and put on the app store.

And you know, an unhappy programmer might be forgetting a crashing bug in the app, but not be around to quickly fix it. So it’s also in the client’s best interest to keep you happy.

Bugs, New Features

Software is never really “done”. After submission to the App Store your client might contact you because of some crash reports or customer feedback. Typically the app should have been tested thoroughly and bugs should not happen, right? But they do, if only for obscure scenarios where you used a 4.x feature and the app is running on a 3.x iPhone. Stuff that’s obvious to you in hindsight.

Now is the second time to agree on an hourly rate for quick fixes and one or the other enhancement. Again, if the user insists on quotes then give him a high quote for a “maintenance contract”, payable monthly. You are a professional and you are not dragging your feet when fixing your bugs. Hey, it’s a matter of pride. If the client wants to again nail you on a fixed quote, then that means you have not learned your lesson and he still does not take you seriously.

You want to have a situation of trust: he should trust you to work as fast and efficient as you possibly can providing quality that matches the agreed specifications. You should be able to trust that he will pay and treat you as a professional developer.

Conclusion

You might have grown to be a great iOS developer, but now you need to also train your business sense. These guidelines and insights should give you a nudge in the right direction. Your situation happens to every fledgling contractor. In the worst case you should change clients. In the best case you can talk with your client and find common ground based in reciprocal trust and respect.

Granted, beggars can’t be choosers. You might be saying “I was young, I needed the money”. But does that mean you have to do the equivalent of slave labor? Yes, you can have low rates at the beginning, but you still should adhere to some common sense guidelines as they are contained in this article. As you get better, you would not change your approach, but raise your hourly rates.

Most people have no idea how much work it is that has to go into a respectable app. They are not stupid, or maliciously ignorant. It will be your job to dissuade a couple of people from making “a quick app” and be picky about your contracts to take on the projects that are intellectually challenging and where you can work with nice and smart people at eye-level.

Jamar Parris asks:

I’ve really been contemplating whether to focus my efforts on one versus the other as I’m still new to both technologies. What impact do you think will HTML5, CSS3, WebGL, etc have on Objective-C iOS developers?

The question web versus native is one that makes waves every once in a while when there is support for a new formerly native technology in browsers or when Apple rejects an app. Let me expand my answer a bit, as there were a couple of recent experiences that serve well to underline my opinion on this question.

When I went full steam ahead with being a full-time iOS developer I made the conscious decision to only focus on a single platform. The main reason for doing so is that I feel that only when focussing like this you have a chance to become great at it. As a general rule of thumb you need to spend about 10,000 hours on any subject matter to be world class. Be it art or science, you need to put in the hours to grow the skills you need to excel at the topic you have chosen.

Of course you can be a Jack of all Trades, but those typically never make much money. There are two career paths that are possible in IT: you can either strive to become an expert at programming, some large corporations call these “programmer/analyst”. Or you can develop into a management role. It is only on rare occasions that you will find great managers that are also great and active developers. Pure development (i.e. coding) is only a part of what does into making an app. Lots of it is overhead that good management tries to keep from hindering the developers.

Having said that you can look into becoming a manager/leader even without committing to a single platform. As a manager your platform is people and the OS of these – if you will – are their needs, wishes and social interactions between them.

Now, that’s more like a comment on the “focussing my efforts” part of your question. Yes, I think you should definitely focus. But first the question is Management versus Expert path.

Now for the expert path, there is only one answer that I can give you and that is from my own autobiography. I am putting all my eggs in the “native” basket. Off the top of my head, here are my primary reasons:

• I love Cocoa and Objective-C for their elegance and power
• There are orders of magnitude more web developers on Earth than iOS developers, so it is rather more likely that I can be at the top in iOS than in web tech.
• Experts generally earn more than Generalists and iOS Experts are currently the most sought after bunch.
• I have yet to see a business model on the web that would work for solo-developers like myself. I can make and sell apps at virtually no cost. For monetization on the web you only have SOAS (Software as a Service) and Ads, both of which are only feasable if you build a business around them, not for doing an app here or there.
• I love Apple and by working within their eco system I cast my vote for their awesomeness
• I hate JavaScript, frown at Java and .NET and actively dislike Microsoft.

Granted, those are mostly emotional reasons, but I think all reasons you can have are such. It boils down to my core belief that I think that native development is more fun and has better rewards than web tech.

Let me also properly answer the second part, which is not really asking about my opinion what is better. Sorry for going overboard here. The second question is actually about what I think the impact will be. And there I can give you a less emotional answer, again from my perspective.

With more and more apps pushing onto the stage that is the app store Apple has set forth some guidelines for app reviewers that we can also consider when making design decisions, long before touching any code on any platform. The clear message is: we want no more fart apps and an app should be way more than a web page to be approved. Apps that would look the same if you did them in HTML/CSS face a high likelihood of being rejected these days.

The example I can quote is this: iCatalog. This is a white label app I own and that my partner ICS in the USA is selling as a catalog on iPad solution to their clients. With some smart technology we take the PDFs and make them interactive. Now there are some customers who are able to provide full lists of products in XML, for these we can do a nice solution where you can select size and color options and get price information. For other clients we only have product names and URLs. There we would display a webview with the product page in it. With the problem that these would obviously only work if you are connected to the internet.

One of these web-catalogs recently got rejected by Apple, citing:

We’ve completed the review of your app, but cannot post this version to the App Store because it did not comply with the App Store Review Guidelines, as detailed below:

• 12.3: Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected

For me as a developer it is hard to get such a rejection. Fortunately we were able to argue the plethora of additional native features that iCatalog boasts in our favor. Also we just had completed a new offline feature that went into the app to sweeten the deal for Apple. So it went through and got approved on the second go.

What does this tell us? For one thing, Apple is tightening the noose around apps that are bordering on being repackaged web apps. So if you start making an app, make sure that you use native device features (like, sensors, CoreAnimation, location, camera, etc) that make clear the value proposition of your work.

If something works just as well as a web app, then by all means have it as web app! Most of the time these would be free services that just have a viewing component for which you need Internet anyway. In some rare examples like Readability the problem there was a disagreement over sharing 30% of subscription revenues with Apple that prompted them to go the web-based route.

New HTML technologies make inroads into former native app territories. Like you can get position data now in mobile browsers. So the number of reasons for doing native apps might be seen decreasing over time. Apple’s Nitro JavaScript engine is only present in mobile Safari for the very same reason: they don’t want developers to do fancy JS tricks in UIWebViews like so many are doing it these days to get rich text editing or HTML rendering. Apple established a developer program of its own right on the developer center, on par with the iOS and Mac ones. This also hints at what they are trying to achieve.

Apple wants native apps to make use of all what their devices are offering. Apple wants web apps to work and platform-independent as possible. And you know, WebKit is Open Source and the de facto standard for rendering web pages.

On the other side, while technologies like WebGL are nice in theory, native platforms will always stay ahead in performance due to the native interfaces available to talk more or less directly with the GPU and hardware. We have seen several apps recently that are showing off some really cool ideas of what you can do with this power, like the one that tracks your face to adjust a 3D rendering.

If you are interested in local mobile computing power and the interesting things that you can do with shaky or no internet connection then native is the way to go. If you can outsource the computing power to the cloud and internet connection is satisfactorily then you can also be web-based. But frankly the first option gets me way more excited. Even though there is a promise of an always available internet connection, the reality proves that internet has varying degrees of connectivity. While you might be ok in big cities, everybody knows a great deal of places that continue to have spotty or no service at all.

While many internet-based startups blissfully ignore this fact when building their service, this is a reality where web apps don’t have a good answer for. Native apps can detect what level of connectivity exists and dynamically modify their behavior. Like being able to fully play a game on an airplane and upload your achievements later when you are back online. Web apps try to solve the connection problem in two ways: by keeping session state on the server and identifying your session by cookie or URL. Or by the new HTML offline features. This might be a solution for some light-weight scenarios, but I don’t lots of iPhone users installing HTML web apps on their springboards. It just feels weird to me.

But I may be surprised if somebody comes up with some new and innovative use for all the new web technologies. But so far I have not seen a single web app that I would prefer over a native app on my Mac or iPhone. I have the distinct feeling that too much brainpower is used on web platforms to work around inherent limitations. The same brainpower is put to better use on an established native platform which gives you GPU-accelerated UI paradigms, multi-touch handling and other hardware features neatly packaged in APIs that – for the most part – are a pleasure to work with.

There one other trap in treating this as a either/or question. The mobile market as a wholes is growing exponentially. So it does not mean that moving from the native to the web or vice versa takes something away from either platform. For each such decision there are dozens of competitors only to willing to step into the supposed hole you left. So on the grand scale it does not matter what you as a single person decide to go into. If you don’t become the next shooting star iOS developer, then somebody else will.

To summarize I would say, you should go for the platform or role that inspires you the most. For me it is Apple, native and cool uses of the hardware.

Daniel Wood asked:

Considering making a Blockees universal. What are people’s thoughts on universal apps? Good for users, but splits sales between devices.

My first gut response was, that IMHO users love universal apps, whereas marketeers and financiers hate them. HD or “for iPad” versions can generally be sold for a higher price.

Daniel then voiced his fear that if you have an universal app you might “dilute” your download rank on iTunes. Again I responded from my feeling that I don’t think that this is right. Daniel challenged me to prove it. And so I will.

I went to Applyzer and copy/pasted the top 100 free US apps from category “top overall” from iPhone and iPad into a graphic. Applyzer has the top 1000 for for the following categories:

• Paid (iPhone/iPod)
• Free (iPhone/iPod)
• Grossing (iPhone/iPod)
• Paid (iPad)
• Free (iPad)
• Grossing (iPad)
• Paid (Mac)
• Free (Mac)
• Grossing (Mac)

Then I went through the list and marked all apps that are showing as universal in iTunes. Then I searched where the same app would be in both ranks. Finally I made a quick survey if I could spot apps that had a separate iPhone and iPad version.

Note that this was done from hand and I might have missed a couple of connections. But even then I think the picture is rather obvious.

There were 27 universal apps in the free overall US top 100 and 33 in the iPad chart. Of these I could find 16 universal apps that where ranking similarily high in both charts. 11 universal iPhone apps did not show in the top 100 iPad chart. 14 universal iPad apps did not show in the top 100 iPhone/iPod chart. Possibly they were only slightly outside the top 100, I did not check.

The percentage of successful universal apps is an order of magnitude higher than dedicated versions. Amongst the top 100 (again only quickly looking visually) I could only find 4 apps that both had separate versions.

I invite your scrutiny of this casual analysis of mine, however I think that this graphic can only lead to this answer to Daniel’s question:

Make your free app universal, if you are NOT Rovio. I think this analysis debunks the myth that making a free app universal is bad for it’s ranking.

Peter Reinhardt asks:

The app AppSwitch displays the console entries from NSLog logging in the iphone app. I tried to figure out how they do it but couldnt find an API. Do you have an idea?

Intriguing question! My first gut reaction was that the guys from AppSwitch must have some magic sauce as I didn’t know of a way to access the console log on device like the Xcode organizer is able to. My first response was that probably they are doing some stderr bending as is possible with c++. But then I bought the app to see their trick with my own eyes.

In this blog post I’ll show you how that’s done.

Indeed, when I first launched the app there were several console messages from other apps, so they must have found a method to access these.

I briefly looked at the contents of the log file directories, but /private/var/logs is not readable on device. Plain file reading is out of the question.

The answer to the riddle is ASL, the Apple System Log facility. This is a low-level C API which is present on OSX as well as iOS and as such it has a man page. It turns out you can query the log for messages related to specific apps or just log the entire thing.

A bit of experimentation and dipping into long past C-programming enabled me to come up with this code which takes all current log messages and converts them into a dictionary.

aslmsg q, m;
int i;
const char *key, *val;
 
q = asl_new(ASL_TYPE_QUERY);
 
aslresponse r = asl_search(NULL, q);
while (NULL != (m = aslresponse_next(r)))
{
	NSMutableDictionary *tmpDict = [NSMutableDictionary dictionary];
 
	for (i = 0; (NULL != (key = asl_key(m, i))); i++)
	{
		NSString *keyString = [NSString stringWithUTF8String:(char *)key];
 
		val = asl_get(m, key);
 
		NSString *string = [NSString stringWithUTF8String:val];
		[tmpDict setObject:string forKey:keyString];
	}
 
	NSLog(@"%@", tmpDict);
}
aslresponse_free(r);

The necessary header asl.h can be included without having to add any extra framework. There are some interesting parts to be gleaned from the header. Did you – for example – know that there are more than 3 logging levels?

• Level 0 – “Emergency”
• Level 1 – “Alert”
• Level 2 – “Critical”
• Level 3 – “Error”
• Level 4 – “Warning”
• Level 5 – “Notice”
• Level 6 – “Info”
• Level 7 – “Debug”

Since we are actually performing a search there are some nifty options to reduce the number of messages we are getting back. If I only want the messages of the app “Logger”, then I just add the following line after the asl_new:

asl_set_query(q, ASL_KEY_SENDER, "Logger", ASL_QUERY_OP_EQUAL);

To visualize, this is how an NSLog will look like

You can see that there is a unix timestamp, Sender “Logger” is the name of my app and NSLog logs with level 4.

Conclusion

If you know how getting log messages is quite easy for somebody with a bit of C under his belt. For everybody else somebody should write an Objective-C wrapper.

With the above knowledge several interesting usage scenarios suddenly become possible. For example one might want to add a mechanism to your apps to have users in need of support mail you the app logs. Or an framework like the Hockey ad-hoc distribution system might be able to provide access to log files similar to the crash reports you now get on iTunes Connect.

In this article I only covered reading logs. However ASL also offers methods to LOG messages. So I can imagine somebody creating a replacement for NSLog with the ability of customizing your log messages. For example to set lower log levels for debug messages or to even add your own custom keys.

Since AppSwitch is an approved app on the app store we can assume for the time being that using ASL to read the system log is deemed legal.

Communicating with web services you have to decide on a way to transport the date back and forth. Recently – with the help of the popular Twitter-API – JSON seems to have come ahead in the race. Other contenders are property lists and XML. Property Lists (PLISTs) are available in XML-Text and a binary (“old”) format and are widely supported in the Apple APIs which makes them a joy to work with.

JSON files on the other hand are easy to be generated server-side as they are basically just concatenated text, much less verbose than pure XML. The binary alternative might also be a contender when it comes to performance in transmission and parsing, provided some component is installed on the server to generate them.

In this blog article we are trying to answer the question once and for all what you should use in your own apps.

Martin Brugger from Austrian iOS development company BytePoets spent a lot of time researching the hard facts for us, so that we have a solid base for our analysis. In part this work is based on what Sam Soffes previously published on the performance of a variety of JSON benchmarks. He created a new GitHub project for his benchmarks which are using all the latest version of all JSON toolkits from where you can check out the code for yourself.

These experiments specifically excluded raw XML parsing because the NSXMLParser that comes with iOS is using the sequential SAX method and thus the results cannot be easily compared to JSON and PLIST which take in text and output NSDictionary or NSArray objects. Most of the data types in JSON and all of the ones in PLISTs map to typed Objective-C objects, in contrast to XML where you don’t have such a built in schema. Thus pure XML might be more flexible, but at the same time you have to jump through hoops to get strong typing. It’s a non-starter in today’s race.

So the contestors in our race where:

• YAJL
• JSONKit
• TouchJSON
• JSON Framework
• Apple’s JSON Framework (private)
• Property List (XML)
• Property List (Binary)

One interesting thing that Soffes had uncovered was that Apple indeed has their own highly performant private API for parsing JSON. Sam reconstructed the necessary headers and so it’s another interesting contender to see here, even though we are not allowed to use the JSON.framework in our app store apps. Pity, it’s quite fast.

The amazing race

To get even more relevant data Brugger benchmarked the serialization and deserialization of an array and a dictionary of 1000 entries each) and the standard Twitter JSON. Since the latter cannot be mappted into property lists, this test was excluded for PLISTs.

Here are the writing results, shorter bars are better.

As you can see there is a wide variety between the various toolkits. Arrays, Dictionaries and Twitter’s JSON take varying amounts of time to process. We immediately see the winner: JSONKit, which was just recently updated to version 1.4. Second place goes to property lists, where – curiously – there is almost no difference between the binary and XML formats. Then there is the JSON Framework on the third spot, winning over the private Apple API ever so slightly.

I get the feeling that the low level optimization work that’s been put into JSONKit as well as being carried out by smart Apple engineers is responsible for this result.

Let’s have a look at the reading performance. This is probably the more important one of both benchmarks since most of the data on your mobile device will be received and consumed. Here the verdict is a little more complex than just stating places. Just as with the writing benchmarks arrays are generally quicker to process. This part is again clearly won by JSONKit, closely followed by binary PLIST. Third place is split between YaJL and Apple JSON.

If the consumed data is a big dictionary the clear winner is the binary property list, followed by JSONKit and Apple JSON. YAJL and XML PLIST share the forth place.

When it comes to “real life” scenarios – like parsing the Twitter JSON – property lists cannot compete unfortunately, so here’s another clear win for JSONKit. This is by a wide margin as the second YAJL and the third Apple JSON are orders of magnitude slower.

Does size matter?

Now another question we set out to answer revolves around the time it takes for JSON or PLIST data to be transferred to the client. This is a function of the size, the smaller it is even without compression, the faster it has travelled over the pipe.

My hunch was that binary PLISTs would be way smaller then everything else, but I was proven wrong as you can see from the following chart:

The NSArray is a third larger expressed as XML PLIST than as JSON, the NSDictionary is even twice as large. The binary PLIST is about the same, so much less of a dramatic difference than I had expected.

Conclusion

In terms of transfer speed any plain-text format like XML or XML Plist loses against the compactness of JSON or binary PLISTs. But as stated earlier the difference between BPLIST and JSON can be disregarded because there almost is none.

In all tests JSONKit was the clear winner or came pretty close to it. It really depends on the specifics of your own project whether you would best use this or Apple’s binary PLIST format. If you are coding multi-platform then it would probably be smarter to go for JSON because the binary PLIST format is not widely used on any other platforms than iOS or OSX. In contrast if you can afford the luxury of only targeting Apple platforms then binary PLIST is just as good a choice, provided you can install the components necessary on your server to be able to output it there.

For all other intents and purposes you can think of JSONKit and binary property lists as identical in transfer and processing speeds. Thanks to the amazing tuning that went into both.

Elias Sanchez asks:

Hello Oliver. Quick? Do you have any tips in making a toolbar appear/disappear? Trying to mimic what the NYT app does when looking at an article. Is it using Core Animation perhaps? Can’t find anything out there. Any ideas? ThxU

Looking at the NYT App you can see that they do quite a bit of manipulation of the bars of which there are 3: Tab Bar, Navigation Bar and sometimes a Tool Bar.

For beginning iOS Developers it might seem daunting to combine all of these for the effect that the NYT App achieves. In this article I give you an analysis of what they did so that you have their techniques at your disposal, too.

Let’s start out by investigating how the basic navigation views are laid out.

At its root the app has a tab bar (Latest, Popular, Saved, Search, More). Each of the tabs has its own view controller stack. To get the navigation bar and table navigation these tab view controllers have to be navigation controllers with table view controllers as first element on their stack.

You can imagine this like several stacks next to each other where each stack belongs to one tab in the tab bar controller. Because of this, if you navigate around on one tab, the contents of the other tabs are not affected.

So the front page of the article list is a tableview controller (with a header view “Most E-Mailed”) in a navigation controller in a tab bar controller. You see the hierarchy in front of your mental eye?

Now if you tap on an article several things happen at the same time:

• The tab bar at the bottom slides to the left, together with the article list
• The navigation bar becomes translucent
• A toobar slides in from the bottom

The same happens in reverse if you go back. You can hide and unhide both the navigation bar and the toolbar by tapping on the screen while the article always fills the entire view. As a geeky detail there is an ad banner riding on the top of the toolbar and moving with it.

First the Bars

For this tutorial you would prepare a tab bar application from the project template. Then you would remove the FirstViewController and replace it with a UINavigationController which gets a UITableViewController as first child. You can download the project here: NYTBars. Have a look at the MainWindow.xib to see this layout.

The following code will perform the hiding and sliding on the individual article view controller:

- (void)viewDidLoad {
    [super viewDidLoad];
 
	UIBarButtonItem *item = [[[UIBarButtonItem alloc]
			initWithBarButtonSystemItem:UIBarButtonSystemItemAdd
			target:self
			action:@selector(add:)] autorelease];
	[self setToolbarItems:[NSArray arrayWithObject:item]];
}
 
- (void)viewWillAppear:(BOOL)animated
{
	[super viewWillAppear:animated];
 
	[self.navigationController setToolbarHidden:NO animated:YES];
	self.navigationController.toolbar.barStyle = UIBarStyleBlackTranslucent;
	self.navigationController.navigationBar.barStyle = UIBarStyleBlackTranslucent;
}
 
- (void)viewWillDisappear:(BOOL)animated
{
	[super viewWillDisappear:animated];
 
	[self.navigationController setToolbarHidden:YES animated:YES];
	self.navigationController.toolbar.barStyle = UIBarStyleBlack;
	self.navigationController.navigationBar.barStyle = UIBarStyleBlack;
}

In viewDidLoad we are setting up the items for the toolbar. The toolbar itself is owned by the view controller’s navigation controller i.e. the UINavigationController that this view controller is currently on. But the items you specify via the view controller’s setToolbarItems. These are local to the view controller and every view controller can set it’s own toolbar items. If I’m not mistaken then this methodology was introduced with iOS 3.0. Before that you had to manage the toolbar yourself.

If we look closely at the transition from article list to individual article we see that the animations occur during the slide. This is why we put the showing and hiding in the WILL delegate methods. If we wanted the animations to happen after the slide in then we would instead use the DID methods. viewWillAppear is triggered as soon as the view controller is pushed on the navigation controller and before the animation is over.

So you see how we change the bar style between translucent and opaque and how we show/hide the toolbar with animated:YES. We don’t tell the article view controller that it wantsFullScreenLayout, because this would cause the view to be under the status bar as well, but the same principle would work for hiding this as well.

One thing though: the tab bar sticks around still, so – before pushing the article view controller – we need to tell it that it will also hide the tab bar. The property in question is called hidesBottomBarWhenPushed, admittedly not really intuitive. The “bottom bar” should rather be called “tab bar” in my opinion. I put it in the initWithNibName, but any place before the pushing is fine:

self.hidesBottomBarWhenPushed = YES;

Previously I had this setting right be fore pushViewController but I prefer to put these things into the objects themselves where possible.

Tap to Hide

To get the interactivity i.e. ability to hide the bars we use a tap gesture recognizer which we attach to the view in viewDidLoad and wire up some more hiding/showing.

- (void)viewDidLoad {
	// other inits omitted
 
	UITapGestureRecognizer *gesture = [[UITapGestureRecognizer alloc] 
			initWithTarget:self action:@selector(tapped:)];
	[self.view addGestureRecognizer:gesture];
	[gesture release];
}
 
- (void)tapped:(UITapGestureRecognizer *)gesture
{
	BOOL barsHidden = self.navigationController.navigationBar.hidden;
 
	[self.navigationController setToolbarHidden:!barsHidden animated:YES];
	[self.navigationController setNavigationBarHidden:!barsHidden animated:YES];
}

This makes for the nice effect to switch between full-screen reading and access to tools or the back button.

Bonus Section: Ad Riding on Toolbar

The toolbar is just a UIToolbar which descends from UIView. For performance reasons the default setting is to not clip subviews. Therefore we might be tempted to add our ad banner like this to the toolbar:

UIView *simulatedAd = [[[UIView alloc] initWithFrame:CGRectMake(0, -30, 320, 30)] autorelease];
simulatedAd.backgroundColor = [UIColor blueColor];
[self.navigationController.toolbar addSubview:simulatedAd];

This works, but only while the toolbar is visible. iOS hides the toolbar and by extension all of its subviews when it goes off screen. It does not check whether a non-clipped child view would still be visible. This causes the ad view to disappear as well. Not the affect we were shooting for.

Instead we need to position the add as subview of the article view controller and move it in synchronized fashion whenever the toolbar moves.

How about some fancy pants KVO (Key Value Observing)? Nope, won’t work. No KVO event triggers on key “frame” and the bounds of the toolbar don’t change even though KVO triggers on “bounds” every time the bar moves. And since there is no notification to my knowledge that would inform us about the bar moving this leaves us with only one option: move it ourselves and time it to be in sync with the bar.

Since we know exactly when the bar is coming or going we can simply animated the frame of the ad banner for the same distance and duration. Apple provides the UINavigationControllerHideShowBarDuration constant which gives us the exact timing.

- (void)viewDidLoad
{
	// ...
 
	// the +15 is a mystery to me
	simulatedAd = [[[UIView alloc] initWithFrame:CGRectMake(0, 
			self.view.bounds.size.height+15, 320, 30)] autorelease];
	simulatedAd.backgroundColor = [UIColor blueColor];
	simulatedAd.autoresizingMask = UIViewAutoresizingFlexibleTopMargin;
	[self.view addSubview:simulatedAd];
}
 
- (void)positionAdUp:(BOOL)up animated:(BOOL)animated
{
	CGRect frame = CGRectMake(0, self.view.bounds.size.height-30, 320, 30);
 
	if (up)
	{
		frame.origin.y -= self.navigationController.toolbar.bounds.size.height;
	}
 
	if (animated)
	{
		[UIView beginAnimations:nil context:nil];
		[UIView setAnimationDuration:UINavigationControllerHideShowBarDuration];
	}
 
	simulatedAd.frame = frame;
 
	if (animated)
	{
		[UIView commitAnimations];
	}
}
 
- (void)viewWillAppear:(BOOL)animated
{
	// ...
	[self positionAdUp:YES animated:YES];
}
 
- (void)viewDidAppear:(BOOL)animated
{
	// ...
	[self positionAdUp:YES animated:YES];
}
 
- (void)viewWillDisappear:(BOOL)animated
{
	// ...
	[self positionAdUp:NO animated:YES];
}
 
- (void)tapped:(UITapGestureRecognizer *)gesture
{
	// ...
	[self positionAdUp:barsHidden animated:YES];
}

Like this we can animate the ad around or by calling the positionAdUp method with animated:NO it would pop there. If you didn’t want the ad to already show on slide in, then you could pop it in in viewDidAppear or after the ad is loaded from server.

With this the ad is always perfectly synchronized with the bar. I discovered the +15 in the init through trial and error with slowmo though I cannot explain how this is calculated. For all other other frame moving I’m subtracting the ad banner height from the view height and it fits. If you can come up with a good explanation, let me know in the comments.

Conclusion

If you know how that mimicking the NYT App’s UI is a breeze. Personally I would not put so much UI changes into the user’s face. Especially the hiding of the tab bar in tandem with sliding in a toolbar looks awkward to me. You could just as well wait with the toolbar until the navigation animation is over and then slide it in. Less lines crossing over each other.

As usual, if you read this article to it’s and and learned something from it, then I would like to encourage you to use the Flattr button below to show your appreciation or the social bookmarking feature to share this article with your developer colleagues.

I’m interested in getting your questions because answering them helps me structure the material in my head. And there’s a saying that “what you teach you learn”, because of that.

Devin Snipes, an aspiring young iOS Developer asks:

Hello Dr. Touch,

My name is Devin Snipes, I’m 15 years old and I’m an iPhone Developer. I’ve been following your work for a little less than a year, and I’ve grown to love it. Your work is amazing, and I hope to someday be as good as you are in programming for the iOS platform. I currently have a few iPhone applications on the AppStore, but nothing compared to yours.

I’d like to ask you a few questions that will hopefully give me more insight on your developmental skills and how I can improve on my skill.

Well, “You catch more flies with honey than vinegar”. If somebody asks so nicely I’ll usually try to respond with something useful.

1. How did you become so great at programming for the iPhone?

I’m doing it full time only since last December. And before that I was looking at code on most days for a couple of hours. Do you know the rule of 10,000? It says that if you want to be world-class in any field you have to invest 10,000 hours in total. Before I got into developing for the iPhone I was collecting programming time for many years. So I probably reached 10,000 a while ago. But that’s not strictly Cocoa time. At 10 hours a day it takes you around 3 years to reach 10,000. So I’m probably around 5,000 hours doing iPhone stuff.

That makes me an intermediary iOS Developer with good analytics and good abstraction skills. Not yet a real expert, but (working on) getting there. There are people who are more “expert” than myself, the stars of Cocoa, if you will. Check out how their bylines describe the place that iOS development has taken in their life.

• Matt Legend Gammell (“Instinctive Code”)
• Marcus Zarra (“Cocoa is my Girlfriend”)
• Matt Gallagher (“Cocoa with Love”)
• Aaron Hillegass (“Big Nerd Ranch”)

My trick is to vary the time I can log towards this goal. I’m not only programming, I’m also watching training videos, doing coaching, teaching development courses, troubleshooting in other people’s apps, making encapsulated software components that I’m selling, I have some apps of my own and lots of contract work. The latter in itself is only partially coding because you also have to train your brain in how to put people’s ideas and specifications into code.

If you program hours and hours on end then you also begin to come up with ways how to use your time more effectively. Like for example putting together a set of tools and utility classes that you are using all the time to quickly achieve standard tasks. Take it one level higher and then you are writing software components that can be plugged into your own apps or even other people’s apps. Writing reusable code not only makes your life easier, it also forces you to think through and abstract interfaces such that your components are loosely coupled. That’s the essence of MVC (Model-View-Controller), the heart of Cocoa.

And some other activities that are only peripheral like blogging and podcasting. But I find that as long as you center it on a single topic then all your activities cross-pollinate. That’s why I gave up on Windows support or programming for any other platform than iOS. And I find that by writing about programming it forces me to chew through boring documentation and try out the techniques I’m covering. This META level of Cocoa Coding teaches me just as well as my readers.

Obviously it helps if you can do it full-time, that’s why I detailed this multi-prong strategy in my previous blog article Business as Unusual.

2. Who made the shirt you were wearing in your iPhone 4 unboxing video?

It was given to me last Christmas by my brother-in-law who has a friend who has the tools to make T-Shirts. Do you think I should start a line of Dr. Touch merchandising items?

3. This might be going a little over-board, but do you mind taking a look at a few of my current iPhone & iPad applications and tell me how I could improve them? I’d really appreciate it if you took the time to look over them and give me your diagnosis on how they can be improved or fixed up.

I’m only judging what I see on the app store and those are just my first gut responses. If you have a minute to look at these apps too then please add your feedback in the comments.

uChat for iPhone (FREE) / uChat for iPad ($0.99)

• make this into a hybrid app, drop the price to free and instead add iAds.
• don’t have any screens that cover the entire display and only have 4 buttons
• it looks to me that the chat screen only use half of the available area
• Ramp up the design, now there is next to none, using the gray scroll view background makes the app look dead

Am I Ugly (FREE)

• there is no design, so the hard answer: Yes, you (the app) are ugly
• apart from this it’s ok for a “Hello App Store” app, but to be something that you would want people to enjoy you’d have to make it way more useful.

iTweet! (FREE)

• there are half-baked attempts at design, but I don’t think you should mix gray round UI elements with standard blue nav bars
• navigation controllers should always have a title for the nav bars to prevent user confusion
• with iOS4 the need for the core functionality (tweet and listen to music simultaneously) is in doubt

Summary

By the number of apps alone you are way ahead of me. It took me half a year part time work to get to 4 and I was 34 at that time. You have that number (and the attached experience) at half my age. So I won’t be surprised if you overtake me sooner or later.

You seem to be making good progress since I see you using not just clicked-together standard UI stuff, but you’re also using GameKit, interfacing Twitter API, TwitPi and other advanced techniques. This tells me that you have grown sufficient abstractive reasoning that you can take an API or framework and use it from your code.

Apple says that 60% of the work that flows into an app should be design and your apps are lacking in this regard. So either you should work on your app design skills by trying to paper-prototype apps similar to famous examples like Tapbots. Or you should hire a friend who has “an eye for such things” to help you lay out the UX (User Experience) and UI (User Interface).

Apart from this I can only recommend a daily work out regime. Collect Cocoa hours, 10k or more. Maybe that’s an idea for an app…

Jayesh asks:

Thanks for your article on UIImage from UIView.

Need one more favor; I am in situation where I want to draw line or area (e.g. rectangle) on UI Image (e.g. Blue print) and save it again.

Basically I will show image and put circle / rectangle on image showing area in blue print and save it.

How should I do that? Can you please suggest approach, sample codes etc?

So the task is to take a UIImage, make it writable in some way and then make a new image out of that for later use. Off the top of my head, I can immediately think of two ways to do that: with UIKit and with CoreGraphics. CoreGraphics has a slight advantage, being lower level, of being thread-safe. But for a simple graphical addition to an existing image I see nothing wrong with UIKit. As usual you should only do very quick operations with UIKit because it requires to be run on the main thread which is the only thread updating the user interface.

So, first, let’s create a method that adds a circle to a passed UIImage.

- (UIImage *)imageByDrawingCircleOnImage:(UIImage *)image
{
	// begin a graphics context of sufficient size
	UIGraphicsBeginImageContext(image.size);
 
	// draw original image into the context
	[image drawAtPoint:CGPointZero];
 
	// get the context for CoreGraphics
	CGContextRef ctx = UIGraphicsGetCurrentContext();
 
	// set stroking color and draw circle
	[[UIColor redColor] setStroke];
 
	// make circle rect 5 px from border
	CGRect circleRect = CGRectMake(0, 0,
				image.size.width,
				image.size.height);
	circleRect = CGRectInset(circleRect, 5, 5);
 
	// draw circle
	CGContextStrokeEllipseInRect(ctx, circleRect);
 
	// make image out of bitmap context
	UIImage *retImage = UIGraphicsGetImageFromCurrentImageContext();
 
	// free the context
	UIGraphicsEndImageContext();
 
	return retImage;
}

This code is only using UIKit methods, except for the lonely CGContextStrokeEllipseInRect. This is the reason why we need to retrieve a handle for the current context. UIKit has it’s own reference so that all UI* methods work without specifically setting a context. Should you ever need to force a specific context that you had created elsewhere, then you can use UIGraphicsPushContext to put this other context “topmost” and UIGraphicsPopContext to clean up.

To use the above mentioned function all you need is this:

// load image from bundle
UIImage *image = [UIImage imageNamed:@"user-1.png"];
 
// call circle drawing
UIImage *imageWithCircle = [self imageByDrawingCircleOnImage:image];
 
// save it to documents
NSString *documentsPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,
							NSUserDomainMask, YES) lastObject];
NSString *filePath = [documentsPath stringByAppendingPathComponent:@"output.png"];
NSData *imageData = UIImagePNGRepresentation(imageWithCircle);
[imageData writeToFile:filePath atomically:YES];
 
NSLog(@"Saved new image to %@", filePath);

So, that’s the UIKit variant. Sometimes though you need to draw on a background thread and thus have to be sure to use thread-safe methods.

The iOS 4 release notes mention that drawing images and fonts is thread-safe as of SDK 4.0.

Drawing to a graphics context in UIKit is now thread-safe. Specifically:

• The routines used to access and manipulate the graphics context can now correctly handle contexts residing on different threads.
• String and image drawing is now thread-safe.

Using color and font objects in multiple threads is now safe to do.

So the above sample should be fine for most purposes. Calling it on a background thread would work on 4.0 and above, but cause weird error messages on earlier SDK versions. One example might be if you needed to draw contents of a CATiledLayer, which is occuring on a special background thread.

So how would this example look in CoreGraphics and without UIKit functions?

First we would require a method to create a bitmap context of sufficient size. I took an example I found somewhere and modified it to my needs. I actually discovered that you don’t have to allocate the storage for the bitmap context yourself, it works fine as of 3.2, even though the documentation states that you should not do that before 4.0. Well, it works, I’ll stick with it.

CGContextRef newBitmapContextSuitableForSize(CGSize size)
{
	int pixelsWide = size.width;
	int pixelsHigh = size.height;
    CGContextRef    context = NULL;
    CGColorSpaceRef colorSpace;
   // void *          bitmapData;
    int             bitmapByteCount;
    int             bitmapBytesPerRow;
 
    bitmapBytesPerRow   = (pixelsWide * 4); //4
    bitmapByteCount     = (bitmapBytesPerRow * pixelsHigh);
 
   /* bitmapData = malloc( bitmapByteCount );
 
	memset(bitmapData, 0, bitmapByteCount);  // set memory to black, alpha 0
 
    if (bitmapData == NULL)
    {
        return NULL;
    }
*/
	colorSpace = CGColorSpaceCreateDeviceRGB();
 
	context = CGBitmapContextCreate ( NULL, // instead of bitmapData
					pixelsWide,
					pixelsHigh,
					8,      // bits per component
					bitmapBytesPerRow,
					colorSpace,
					kCGImageAlphaPremultipliedFirst);
	CGColorSpaceRelease( colorSpace );
 
    if (context== NULL)
    {
       // free (bitmapData);
        return NULL;
    }
 
    return context;
}

Note that if you would put the malloc back in then you also need to free the memory pointer after you’re done. Previously I did not know that so all this memory leaked. This approach of passing NULL instead of a pointer apparently works on 3.2 and above, officially from 4.0.

- (UIImage *)imageByDrawingCircleOnImageCG:(UIImage *)image
{
	// begin a graphics context of sufficient size
	CGContextRef ctx = newBitmapContextSuitableForSize(image.size);
 
	// need to flip the transform matrix
	// CoreGraphics has (0,0) in lower left
	CGContextScaleCTM(ctx, 1, -1);
	CGContextTranslateCTM(ctx, 0, -image.size.height);
 
	// draw original image into the context
	CGRect imageRect = CGRectMake(0, 0, image.size.width, image.size.height);
	CGContextDrawImage(ctx, imageRect, image.CGImage);
 
	// set stroking color and draw circle
	CGContextSetRGBStrokeColor(ctx, 1, 0, 0, 1);
 
	// make circle rect 5 px from border
	CGRect circleRect = CGRectMake(0, 0,
			image.size.width,
			image.size.height);
	circleRect = CGRectInset(circleRect, 5, 5);
 
	// draw circle
	CGContextStrokeEllipseInRect(ctx, circleRect);
 
	// make image out of bitmap context
	CGImageRef cgImage = CGBitmapContextCreateImage(ctx);
	UIImage *retImage = [UIImage imageWithCGImage:cgImage];
	CGImageRelease(cgImage);
 
	// free the context
	CGContextRelease(ctx);
 
	return retImage;
}

Besides of having to use this helper function to create a suitable bitmap context you should also note that we have to go via creating a CGImage first. From this we can then create a UIImage. Also you might have spotted that we need to turn the transformation matrix upside down because otherwise all our graphics would be that. CoreGraphics generally assumes the origin of drawing in the lower left hand corner.

I’ve shown you both methods of drawing on images, now you can take your pick which one you prefer.

A not-to-be-named friend asked me:

I would like your opinion the GM build. Should I (not sure how) remove it and then load the new iOS 4.0? I know it wouldn’t have the game center, but I don’t use that anyway. I am afraid if I don’t remove, the software will expire (happened on beta 4 and then I couldn’t use the phone (or back up first) until I could load the latest.

If you’re one of those developers that managed to install the iOS 4.0 Gold Master right after Uncle Steve announced it, then you might wonder if you should update to the really final release that came out just now.

Wait! That’s a trick question…!

A version is called Gold Master if it is the final code that would be put on a master CD to be mass-produced by the factory. Since we are getting iOS updates via the Internet there is no longer any physical media involved. A different name, less anachronistic, would have been RTM (“Release to Manufacturing”). Or not, there is no manufacturing involved in unleashing Apple software upon the world.

So let’s see if that really WAS true and we got the really REALLY finaly 4.0 version after the Stevenote. To check on which version is the latest I used a trick I learned from TUAW to get a list of the ipsw restore files bearing version 4.0. They employed the OSX built-in text-to-speech engine to have the Mac tell you as soon as the 4.0 version became available on Apple’s servers. A cool trick! But we need only the first line of their script:

curl -s -L http://phobos.apple.com/version | grep -i Restore | grep -i iPhone | grep -i 4.0

This part gets an XML file from Apple’s servers and cuts out the lines that include iPhone, Restore and 4.0. You get several lines that all share the same build number: 8A293.

Now let’s cross check that against our own phone, that we have already be-goldened.

Down there at Version it also says 8A293. Heureka! Apple told the truth when they told us that we developers will get the final shipping version of iOS 4.0.

Check for yourself if you have this build number. If yes, then you might see if you can fool somebody else and ask them if they already upgraded to the really final 4.0.

zeke817 asks:

Hey guys just wondering how to put a timer in the appdelegate. I need a timer to keep playing on through multiple views instead of just playing on 1 view. Any help apperciated

Using timers is pretty simple. There are plenty examples around and it’s not difficult to understand. Having said that, I am responding to this question for three reasons:

1. my posts on my blog have been pretty scarce recently due to lots of programming for customer projects
2. I think I should at least document how I am using timers so that I can refer people to this post when the question arises again and again.
3. Explaining a simple thing to somebody else is the best way to train clarity in teaching.

Generally speaking timers are not instantiated but scheduled. The difference is that the SDK/OS takes care of their memory management and we only have to worry about whether or not we want them to fire. So we don’t need to ever release a timer, instead we invalidate it.

Now your choice is to have a timer fire just once or repeatedly. If you want it ongoing then it’s wise to have an instance variable defined in the header for saving the address of the NSTimer instance in so that we can command it to invalidate itself once we no longer want it to go on. It it’s just a one-off thing, then we don’t need an IVAR.

That means adding this to the header’s interface description between the curly brackets, a variable named “timer” which points (asterisk) to an NSTimer instance.

NSTimer *myTimer;

Somewhere in our code we want to start the timer. There are two methods of creating a timer, via invocation or target/selector. The second one is easier to understand so it’s the one I’ve been using. With it you specify the method that you want to be called back on every time the timer fires.

myTimer = [NSTimer scheduledTimerWithTimeInterval:5.0 target:self
                               selector:@selector(timerFired:) userInfo:nil repeats:YES];

That creates a timer, that will fire after 5 seconds and then repeatedly every 5 seconds. When it fires it will call timerFired: in the same instance you scheduled it, due to using self. You could also be passing some user data, but we don’t need that for now, so we pass nil.

Of course we need to provide the timerFired: method as well:

- (void) timerFired:(NSTimer *)timer
{
	NSLog(@"Tick");
}

If you have an ongoing timer the least you should do is to invalidate it in the class dealloc. If you are invalidating it without destroying the instance you should also set your instance variable to nil because invalidating an already invalidated timer causes an exception. But [nil invalidate] is always ignored by objective-C.

- (void)dealloc
{
    [myTimer invalidate], myTimer = nil;
    // other releases
    [super dealloc];
}

Having a pointer to the timer allows you to do a couple of useful things with the instance methods that NSTimer provides. You can fire it manually, you can ask it if it isValid or you can invalidate it. Because internally NSTimer works with dates (more precisely: with a time duration in seconds since a reference date) for when it fires and not durations you can also get fireDate or setFireDate.

Now about userInfo, you can put anything in there that you like to have present as data in the timerFired method. If you’re just scheduling timer events for self, then this is mostly useless as you can access all instance variables anyway. But if you have some calculated data from right before the scheduling that’s not in an IVAR then you can pass it. Or if you are scheduling the receiver of the timerEvent to be a different object then it has much more usefulness.

Timers are a great invention, especially for achieving repeated calling of a given method. Though when you find yourself creating timers with repeats:NO then you might be better of using performSelector:withObject:afterDelay:, I think this is cleaner especially since another developer usually expects timers to be continuous.

It’s been more than half a year since I published the first installment of this Quiz aimed at Cocoa Cracks. Back then people seemed to like the challenges I presented. So I collected a few more nuggets. If you ever stumbled on an crash or strange result that you did not expect, then mail it to me.

These questions will show if you are really the Cocoa Crack you like to believe to be. To see the answer highlight the answer text with your mouse. No peeking! Respond in the comments how many you got correct.

Quiz: Warm Up. Your UI designer gave you a PNG with the instruction “just tile this in the background” of a UIView. Do you have to subclass UIView, overriding the drawRect of the view and performing drawImage for all tiles? Or is there a simpler method?

Answer: You create a UIImage by loading the PNG and then create a “color” from it with [UIColor colorWithPatternImage:image]. Then you apply this as the background color of the view.

- (void) setTextColor:(UIColor *)newTextColor
{
	if (newTextColor != textColor)
	{
		[textColor release];
 
		if (newTextColor)
		{
			self.textColor = [newTextColor retain];
		}
		else // default
		{
			self.textColor = [[UIColor whiteColor] retain];
		}
		bubbleView.highlightedTextColor = textColor;
	}
}

Answer: You have an endless recursion. self.textColor is a simplified way to write [self setTextColor:]. So this method keeps calling itself until the stack is full and your app gets terminated. The leak is calling retain on an assignment to a retaining property. But if you fix the crashing bug by removing both self then there is no leak.

CGContextRef currentContext = UIGraphicsGetCurrentContext();
 
// Draw a black line at the top and a white line 1 pixel below
 
CGContextSetLineWidth(currentContext, 1);
 
CGContextSetRGBStrokeColor(currentContext, 0.0, 0.0, 0.0, 1.0); // Black
CGContextMoveToPoint(currentContext, 0, 0); // top left
CGContextAddLineToPoint(currentContext, rect.size.width, 0); // to top right
CGContextStrokePath(currentContext);
 
CGContextSetRGBStrokeColor(currentContext, 1.0, 1.0, 1.0, 1.0); // White
CGContextMoveToPoint(currentContext, 0, 1); // left
CGContextAddLineToPoint(currentContext, rect.size.width, 1);
CGContextStrokePath(currentContext);

Answer: Core Graphics does not work on pixels directly, that’s why you use floating point numbers for coordinates. It works on coordinates and the resulting bitmap is always rendered. Half of the line width is always applied half a unit to each side of the line. To remedy this you need to move the coordinates of the lines by half a unit up or down.

(Thanks to Michael Kaye for sending this in)

Answer: You can have any UIView have rounded corners by setting the cornerRadius property of it’s CALayer. The layer of a UIView is actually what’s responsible for drawing the contents of the view. You need: to import <QuartzCore/QuartzCore.h>

Answer: In the webViewDidFinishLoad: delegate method you retrieve the title via javascript and set it like that. self.title = [webView stringByEvaluatingJavaScriptFromString: @"document.title"];

Quiz: You have written code to load some UIImages in the background (performSelectorOnBackgroundThread or NSInvocationOperation). The loading code calls the method below to resize the loaded image. This has “always working before”, but suddenly you keep getting a EXC_BAD_ACESS on the line marked. You have double checked all retains and even set NSZombieEnabled to YES because usually you get this message if you are using an overreleased object. But that did not fix the problem. What’s the reason for the crash and how would you fix it?

+ (UIImage*)imageWithImage:(UIImage*)image
			  scaledToSize:(CGSize)newSize;
{
	UIGraphicsBeginImageContext( newSize );
	[image drawInRect:CGRectMake(0,0,newSize.width,newSize.height)];   // <- crash
	UIImage* newImage = UIGraphicsGetImageFromCurrentImageContext();
	UIGraphicsEndImageContext();
 
	return newImage;
}

Answer: UIKit is not thread-safe. Therefore all drawing via UIKit needs to happen on the main thread. The UIGraphicsBeginImageContext works to create the context, but the memory for it is owned to the main thread and trying to access it with drawInRect from another thread is causing this exception. To fix it you need to rewrite this method to create your own bitmap context on the non-main thread so that you then own the memory for it. After creating the bitmap context you draw the image to it with CGContextDrawImage and then create a new CGImage with CGBitmapContextCreateImage. From the CGImage you create a UIImage to return from the method.

Quiz: Off the top of your head: how many methods do you know of having a piece of code contained in one method being performed in the background? Which?

Answer: Correct Answers are: performSelectorOnBackgroundThread and creating an NSInvocationOperation from the selector as those work on an existing method. Creating an NSOperation sub-class or manual threading with NSThread are also valid answers, but those require that you move the code into a new class or need to be well versed with threading voodoo.

So how many answers did you know? Be honest! If you also have a Cocoa riddle like these to contribute please mail them directly to me (oliver@drobnik.com) and I will publish them in this format.

gdscei asks:

“Hello, how can i make an image view work as a button? I want it to be assigned to the ‘reload’ action of WebView.
Can someone give me instructions how to do this?”

Often people start out constructing their UI visually, starting with this line of reasoning “I want to show an image. Ah, UIImageView”. So they create the visual appearance of their UI either by clicking it together in Interface Builder or – if slightly more advanced in their coding skills – creating those image views in code.

So if we create a new view-based project in XCode, we could modify the viewDidLoad of the main view controller like this to show the image:

- (void)viewDidLoad {
    [super viewDidLoad];
 
	UIImageView *imageView = [[UIImageView alloc] initWithFrame:
		CGRectMake(100.0, 100.0, 57.0, 57.0)];
	imageView.image = [UIImage imageNamed:@"Icon.png"];
	[self.view addSubview:imageView];
	[imageView release];
}

The next logical step in reasoning right after displaying the icon is now to get touch handling somehow. And that’s where you will get stuck because UIImageView is a dead end when it comes to reacting to the user’s finger.

Sure, if you consider yourself extra smart and that you won’t be stumped by such an inconvenient “cul de sac” then you will proceed to subclass UIImageView and adding touch handling via the touchesBegan, touchesMoved, touchesCancelled and touchesEnded method. And don’t go telling me that you would never make such a mistake. I know, I did and I’ve seen smarter programmers than the both of us proceed to painstakingly code their own touch handling for UIImageViews.

This post is NOT about doing that. I cannot prevent you from scratching your left ear with your right index finger, but I CAN show a smarter way to get your own interactive custom buttons.

I already gave away half of the solution: CUSTOM BUTTONS. Apple made it confusing to beginners by having the default style for a button being a rounded rectangle with text inside. That’s why there is such a strong trend to using UIImageViews because beginners cannot imagine that their beautifully crafted button images would fit into this rounded container. But in fact the rounded rectangle style is only one of several possibilities.

UIButtonType can have these values:

• UIButtonTypeCustom,
• UIButtonTypeRoundedRect
• UIButtonTypeDetailDisclosure
• UIButtonTypeInfoLight
• UIButtonTypeInfoDark
• UIButtonTypeContactAdd

The very first on UIButtonTypeCustom will be our choice for making our own custom button. For all the other button types Apple provides the drawing, for the custom one you have to bring your own, preferably in the form of UIImages for the various states.

Let’s have a brief look at the inheritance of UIImageView versus UIButton. This kinship was not obvious to me, I only discovered it by accident when I also was in the situation that I wanted to touch-enable some subviews.

UIImageView inherits from UIView : UIResponder : NSObject
UIButton inherits from UIControl : UIView : UIResponder : NSObject

So we can see that up to UIView both have the same set of methods and behaviors. An image view is just a UIView where an image from a property is being drawn in the view’s area, probably inside the drawRect. A button gains an additional level of inheritance: UIControl. If you read up on UIControl in the documentation it tells you that UIControl adds mechanisms to “convey user intent to the application”. It adds the target-action methodology to UIView where you can add targets and methods as actions that get executed when certain things happen. Like for example a touch is lifted inside a button or the value of a slider has changed.

But UIImageView and UIButton are views! Both have the genes of UIView inside of them and cannot deny their pedigree.

Knowing the above mentioned facts, why would you want to painstakingly code your own touch handling routines if you get them for free when choosing UIButton to display your icon image instead?

We can replace the above mentioned code with this:

- (void)viewDidLoad {
    [super viewDidLoad];
 
    UIButton *imageButton = [UIButton buttonWithType:UIButtonTypeCustom];
    imageButton.frame = CGRectMake(100.0, 100.0, 57.0, 57.0);
    [imageButton setImage:[UIImage imageNamed:@"Icon.png"] forState:UIControlStateNormal];
    [self.view addSubview:imageButton];
}

Note that for buttons you generally don’t do alloc-initWithFrame, but use the factory method buttonWithType. Since this gives us an autoreleased button we don’t need to manually release it after addSubview.

If you do that you get exactly the same result, with a minor difference. If you tap the icon it darkens automatically to show the touch. That’s because UIButton expects to display something different when the button is touched. You can set a specific image for the highlighted state, if you don’t then UIButton takes the normal state image and darkens it automatically.

To disable this behavior change the property or set an image for the highlighted state:

imageButton.adjustsImageWhenHighlighted = NO;
// or
[imageButton setImage:[UIImage imageNamed:@"Icon_highlighted.png"]
	forState:UIControlStateHighlighted];

Possible control states are:

enum {
   UIControlStateNormal               = 0,
   UIControlStateHighlighted          = 1 << 0,
   UIControlStateDisabled             = 1 << 1,
   UIControlStateSelected             = 1 << 2,
   UIControlStateApplication          = 0x00FF0000,
   UIControlStateReserved             = 0xFF000000
};

Therefore control state is more than a single value, it actually can also be a combination of several bits. The normal state is 0, the highlighted state is 1, disabled 2 and selected 4. You can specify any combination thereof by using the bitwise or operator |. For example to set an image for selected OR highlighted you use UIControlStateSelected|UIControlStateHighlighted. This possibility is not clear if you look at the inspector for a button in Interface Builder. That’s why I prefer to do my buttons in code.

To clarify the states: A button at rest is “normal”. As long as you put your finger down on it, it’s “highlighted”. If you lift again, it returns to “normal”. If you set it’s enabled property to NO, then it’s “disabled”. If you set it’s selected property to YES, then it’s “selected”.

Cocoa Cracks NOTE that UIControlStateApplication actually shows us a range (16 bits) that we can use ourselves to define extra special states for our own controls. And UIControlStateReserved is a range (16 bits) that is reserved for Apple-internal use.

Ok, so much for states and looks. Adding targets and actions for the various possible interactions with a button is easy again:

[imageButton addTarget:self action:@selector(buttonPushed:)
	  forControlEvents:UIControlEventTouchUpInside];

We also have to implement the “action” which is just a method. The target is the class instance where you implement the method, the action is a selector, i.e. the “fingerprint” of the method.

- (void) buttonPushed:(id)sender
{
	NSLog(@"It works!");
}

Note that a pointer to your button instance will be passed via the sender parameter. This can sometimes be useful, for example if you want to use a single method to respond to multiple buttons. In this case you would use the tag of the passed sender to discern which button the call was coming from.

This method of making images respond to touches works with very little extra tying. I’m using it in DTCalendarView for the individual days as well as for a full screen tap recognition in DTSplashExtender. Best of all: it saves you lot of extra code or even having to subclass UIImageView.