Cocoanetics » Q&A

DTCoreText: Centering an Image

Drops — Sun, 07 Apr 2013 13:09:18 +0000

Amy Worall asks:

How do I centre an image in DTCoreText? I’m working with attributed strings not HTML. Any sample code?

In this blog post will answer this.

DTCoreText consists of multiple parts: tools for converting between HTML and attributed strings, a custom layout engine doing the “frame setting” and (on iOS) several UI classes for displaying those attributed strings.

For most scenarios you would want to simply pass in some HTML data and display that, but Amy’s use case seems to forego this step. And there is nothing wrong with skipping directly to putting together an NSAttributedString. As long as you use the same attributes that the HTML parser would put in there the result should be identical.

Amy is trying to get a divider image centered amongst the text. This should be a simple exercise, but somehow it comes out as being off center. Looking at the sample code she provided didn’t yield any clues as to what could be reason for this.

My first thought when seeing this was that this has to be a bug in DTCoreText. Feelings of Panic starting to rise.

Try it in the Demo App

So my search for the cause of the off-centering began with the DTCoreText demo app. I like to make sure I have the latest version of DTCoreText (and submodules) cloned and then I try to find a place where I can test the text.

If I have HTML that does not seem to come out right, then I paste it into the CurrentTest.html which is the last menu option in the demo’s menu of snippets.

So the first test I am doing is to see if maybe centered paragraphs are broken somehow. In HTML you can switch to centered paragraph styles with the

tag or with the equivalent CSS text-align attribute. Images that are contained in the app bundle can be referenced without any path.

Lorem ipsum dolor sit amet, ...

Push the “Debug Frames” button to have DTCoreText draw additional backgrounds behind the glyph runs, the frame outline. There is also a dashed centering line.

We can see that the image is centered on the centering line. At least we know that the problem must lie elsewhere.

Inspecting the Chars view shows that the image paragraph consists of the Unicode Object Placeholder @”\ufffc” character and a newline (code 10). The Ranges view shows that the placholder character has a DTTextAttachment attribute, a run delegate attribute as well as a paragraph style with alignment 2 for centering.

The placeholder character is not being displayed itself. Instead CoreText calls the run delegate to get the dimensions from the text attachment. The run delegate asks the DTTextAttachment for Ascent, Descent and Width to be reserved so that the image has enough space to fit. Since the run delegate is a set of C-functions it has no context from being in the scope of an object. For this purpose there is a context parameter in which we pass a pointer to the text attachment.

The text attachment object and the run delegate always exist retained by the same attribute range this is possible, even under ARC.

And Now in Code

Amy provided the following gist of the code she’s been experimenting with. With what I explained above, can you spot the problem?

NSMutableParagraphStyle *centredPS = [[NSMutableParagraphStyle alloc] init];
centredPS.alignment = NSTextAlignmentCenter;
 
NSMutableAttributedString *attributedStringBuilder = [NSMutableAttributedString new];
 
DTTextAttachment *attachment = [[DTTextAttachment alloc] init];
UIImage *image = [UIImage imageNamed:@"divider"];
attachment.contents = image;
attachment.contentType = DTTextAttachmentTypeImage;
attachment.displaySize = image.size;
NSMutableDictionary *newAttributes = [NSMutableDictionary new];
[newAttributes setObject:attachment forKey:NSAttachmentAttributeName];
[newAttributes setObject:centredPS forKey:NSParagraphStyleAttributeName];
[attributedStringBuilder appendAttributedString:[[NSAttributedString alloc] 
                         initWithString:UNICODE_OBJECT_PLACEHOLDER attributes:newAttributes]];
 
[attributedStringBuilder appendString:@"\n"];
 
// then append all our normal paragraphs of text.
// This is eventually given to a DTAttributedTextView to display.

And no, I’m not referring to Amy spelling “center” incorrectly throughout.

The run delegate is missing.

If I paste this code into DemoAboutViewController, reducing the attachment display size to 100×100. This comes out quite weird.

Apparently this spaces the lines correctly from the top (done in DTCoreTextLayoutFrame), but the ascender of the image (the part going up from the base line) is only as high as the font’s ascender. This explains why in Amy’s sample image the divider looks like it is vertically in the correct position. It has a height similar to the font height.

Let’s add in the missing run delegate.

// need run delegate for sizing
CTRunDelegateRef embeddedObjectRunDelegate = createEmbeddedObjectRunDelegate((id)attachment);
[newAttributes setObject:(__bridge id)embeddedObjectRunDelegate forKey:(id)kCTRunDelegateAttributeName];
CFRelease(embeddedObjectRunDelegate);

Build&Run and we can marvel at the correct placement of my face.

Pretty, eh? (I mean the positioning)

To simplify things I have this category on NSAttributedString in DTRichTextEditor for inserting images into the editable text.

+ (NSAttributedString *)attributedStringWithImage:(UIImage *)image maxDisplaySize:(CGSize)maxDisplaySize
{
   DTTextAttachment *attachment = [[DTTextAttachment alloc] init];
   attachment.contents = (id)image;
   attachment.originalSize = image.size;
   attachment.contentType = DTTextAttachmentTypeImage;
 
   CGSize displaySize = image.size;
   if (!CGSizeEqualToSize(maxDisplaySize, CGSizeZero))
   {
      if (maxDisplaySize.width < image.size.width || 
          maxDisplaySize.height < image.size.height)
      {
         displaySize = sizeThatFitsKeepingAspectRatio(image.size,maxDisplaySize);
      }
   }
   attachment.displaySize = displaySize;
 
   DTHTMLElement *element = [[DTHTMLElement alloc] init];
   element.textAttachment = attachment;
 
   return [element attributedString];
}

This constructs the attributed string with the image exactly like DTCoreText does, via DTHTMLElement. There you can find that the run delegate is being added if the attachment property is not nil. This also adjusts the display size to fit a given maximum display size unless you pass CGSizeZero for that.

Conclusion

In DTCoreText (on iOS) besides a DTTextAttachment we need to also specify a run delegate so that Core Text is able to reserve the appropriate space for it. On Mac attributed strings can have attachments as well. There they are embedded in NSTextAttachment instances which have a file wrapper for the file as well as a cell for sizing and displaying the content.

Apple has brought over NSTextAttachment in iOS 6, but kept it private API. This is why I came up with this workaround using the killer combo of Run Delegate + DTTextAttachment. This is compatible all the way down to iOS 4.

Using Custom Fonts with DTCoreText

Drops — Wed, 20 Mar 2013 14:36:48 +0000

Friend of DTCoreText Holger was having problems getting DTCoreText to use the bold font face of his custom font.

I want to take this opportunity to explain what the root cause for Holger’s problem was and what you need to know if you’re using custom fonts with DTCoreText.

DTCoreText has access to all the fonts that are installed on the iOS device, as well as those that you bundle with your app. Fonts are always grouped by Font Family. The individual looks are called Font Faces. Typically you will have 4 variants there: regular, bold, italic and bold+italic.

Apple’s Core Text system supports TrueType (TTF) as well as OpenType (OTF) fonts.

Bundle the Font

After copying the font files into your app, you assigning them to the target so that they get copied together with the other app resources. You have to register the font file names in your app’s info.plist so that they get loaded on app launch.

The font files go into the “Fonts provided by application” section, aka UIAppFonts.

To check if the fonts get loaded correctly you can simply create them by name, for example via this temporary code in your app delegate.

CTFontRef font = CTFontCreateWithName(CFSTR("CharterITC-Regu"), 20, NULL);
NSLog(@"%@", font);

If the font can be instantiated then the NSLog will output a description where you should see the same font name as in your creation statement.

CTFont 
CTFontDescriptor {type = mutable dict, count = 1,
entries =>
 1 : {contents = "NSFontNameAttribute"} = {contents = "CharterITC-Regu"}
}

Having verified that the font is available at run time you can now proceed to use it in text.

Using the Custom Font

When somebody says “I’m using this font” then he means “I am using the faces of this font family” because he expects that DTCoreText should select the appropriate font face based on whether or not regular or bold text is required.

The selection process works by CSS styles, , , and tags modifying a HTML tag’s fontDescriptor. When the NSAttributedString is being assembled then this local fontDescriptor is called with newMatchingFont to produce a font (or get one from cache) that matches the description.

The modern way to specify a font for text in HTML is to apply a style:

The (outdated) alternative – which is also still supported – is to specify the font face directly via the tag. There the attribute name for the font family is – misleadingly – called “face”.

Debugging Font Matching

In Holger’s problem everything was set up correctly as described above, but still bold and regular text would end up using the same regular font face. Problems like this can happen if the font files come from a dubious source that didn’t take good care to set the font meta information correctly.

There’s a simple check you can perform if you run into these kinds of problems with a custom font. Create a DTCoreTextFontDescriptor from the CTFont and output the CSS style representation. Or you just set a breakpoint after the creation of the descriptor and inspect its properties.

DTCoreTextFontDescriptor *newDesc = [[DTCoreTextFontDescriptor alloc] initWithCTFont:font]; NSLog(@"%@", [newDesc cssStyleRepresentation]);

In this example the output was:

font-family:'Charter ITC';font-size:20px;font-weight:bold;

So we see that even though we passed in the CharterITC-Regu from before this face appears to have a bold trait. This should not be and is a mistake.

If both the regular font face and the bold one have the bold font trait then Core Text prefers the regular one.

Workaround / Speed Improvement

Since font matching is a painfully slow process I implemented a global font override table in DTCoreText. This override table is seeded with the contents of DTCoreTextFontOverrides.plist which contains the basic setup suitable for most preinstalled fonts on iOS.

The override table specifies a combination of font family and bold and italic traits. When a bold face from a certain family is requested then DTCoreText can simple look up the font face name and create the CTFont from that. This is many times faster than doing a font search via Core Text.

This is why I recommend that you include this plist with your app’s resources, if only for the faster font lookup. Without it all still works, but if you have many alternating fonts then this unnecessarily slows down your app.

To get the same performance benefit for custom fonts you can simply add your custom font to the global override table. Incidentally this can also be used to work around fonts with incorrect traits. You should make these additions right after app launch, once a font has been matched it is cached and then this registration will be too late.

// these fix the bold problem [DTCoreTextFontDescriptor setOverrideFontName:@"CharterITC-Bold" forFontFamily:@"Charter ITC" bold:YES italic:NO]; [DTCoreTextFontDescriptor setOverrideFontName:@"CharterITC-BoldItal" forFontFamily:@"Charter ITC" bold:YES italic:YES]; // these are for completeness to get the faster lookup [DTCoreTextFontDescriptor setOverrideFontName:@"CharterITC-Regu" forFontFamily:@"Charter ITC" bold:NO italic:NO]; [DTCoreTextFontDescriptor setOverrideFontName:@"CharterITC-ReguItal" forFontFamily:@"Charter ITC" bold:NO italic:YES];

An alternative would be to add these 4 lines to the plist which you should be packaging with your app anyway. Though I slightly prefer the registration in code because if you use DTCoreText via CocoaPods you cannot modify the overrides plist file. But that’s your call.

Conclusion

When encountering font matching issues with external fonts you should first inspect the individual font faces if they possibly are having incorrectly specified traits. But in any case I recommend that you include the DTCoreText DemoApp’s font overrides plist with your app to speed up the matching. You can add your custom fonts in there or in code to have them included in the override process.

Today’s Hero: CHEN Xian’an

Drops — Tue, 05 Mar 2013 18:17:33 +0000

I was having a problem in DTCoreText where the multi-byte sequence making up an Emoji would not get properly encoded by DTHTMLWriter. A quick peeking into NSHTMLWriter didn’t bring relief either, Apple is not encoding these characters, but leaves them unencoded.

You can see in this screenshot that I looked at how NSHTMLWriter would encode two Emojis:

That’s not the proper way for us, we want our output to be safe with any kind of transport encoding because it might end up on a machine that does not support UTF8 as brilliantly as iOS and OS X do.

My first idea was that I might have to force the font family to be “Apple Color Emoji” which is the font that CoreText falls back to for displaying Emojis. However if you don’t have the proper encoding even setting the font family does not help.

The problem was in NSString+HTML in DTCoreText which I use in DTHTMLWriter to add HTML entities. I created an issue on GitHub to describe my plight and while I was still dabbling around with libxml2 looking for an answer there Xian’an stepped in, fixed the bug and sent a pull request. Brilliant, simply brilliant!

The solution is to use some wide unicode supporting methods found in Core Foundation, more precisely CFString.

// ... looping through the unicars if (oneChar<=255) { [tmpString appendFormat:@"%C", oneChar]; } else if (CFStringIsSurrogateHighCharacter(oneChar) && i < [self length]-1) { i++; unichar surrogateLowChar = [self characterAtIndex:i]; UTF32Char u32code = CFStringGetLongCharacterForSurrogatePair(oneChar, surrogateLowChar); [tmpString appendFormat:@"&#%lu;", (unsigned long)u32code]; } else { [tmpString appendFormat:@"&#%d;", oneChar]; }

CFStringIsSurrogateHighCharacter checks if the current unichar character is a "Surrogate High Character". If yes then CFStringGetLongCharacterForSurrogatePair retrieves the 32-bit wide character value.

It's late, I'm tired and annoyed from having to re-tag DTCoreText 1.3.2 three times, but I just had to write this up for the whole world to know ...

Thank you CHEN Xian'an, your mad bug fixing skillz my day!

Zarra on Locking

Drops — Mon, 18 Feb 2013 08:27:23 +0000

In my previous article dealing with Multi-Context Core Data I introduced a 3-context scheme that Marcus Zarra hat shown us in a back room at the 2012 NSConference.

Several people inquired about Locking, take for example Wim Fikkert:

Thanks for the great article. However, like Tom, I was wondering if the main context will not be blocked whenever you perform a save to disk with the persistent store. I am using the last design pattern, and I keep running into my app locking up. I have done some more searching and came across this article. Perhaps you can comment?

I don’t pretend to come anywhere close to being the Core Data expert that Zarra is, so I went straight to the horses mouth and asked him.

Marcus Zarra kindly responded shedding some light on the matter, emphasis mine.

There is always a lot of confusion around locking. [Editor: DOH!]

Whenever you save to the disk, no matter what context you are in, single or multiple, you are going to “lock” the NSPersistentStore while the write is taking place. That has always been true and most likely always will be true.

What is not true is that the main context gets locked. That is a over-simplification of what happens. If, during a save, you attempt to fetch more data from disk then you will be blocked. That is the effect people are seeing and screaming about.

Aha, so locking only affects a persistent store (aka the sqlite file). This is the 3-level approach I was referring to:

Here we see that we only have writing access to the PSC (Persistent Store Coordinator) in the background writer context. In my Open Source DTDownloadCache I am doing the actual save to disk on a delayed timer that checks if there are changes and if there are any saves them.

So what about all those other copies of the data that is already in memory?

However, if you are working with data that is already in memory then you won’t be blocked.

Also, depending on what you are fetching and how your fetch is configured, you can do a fetch that doesn’t block because the data is already in disk. That is harder to accomplish though so I relegate it to a side point. I should note that the default for a NSFetchRequest is to hit disk no matter what (this is the staleness interval)

The core problem is the locking of the NSPersistentStore. Since that cannot be avoided it needs to be lessened. To do that you spread it out into smaller hits so that the main (or other) contexts have a chance to get in and retrieve data frequently enough that the user does not get the sensation of “locking”. Small/frequent saves during imports is a common solution.

Now reading access is something that might cause a pause when NSFetchedResultsController cannot find current data in the Main MOC. Then it has to inquire its parent context for the data which has to get it from disk.

And of course Zarra also has an alternative but he doubts the viability of that even himself:

Another solution that is a bit hairy is to have *two* NSPersistentStoreCoordinator instances, one for writing one for reading. However that gets very complex very fast and I never recommend it. With a double PSC design you must tell the primary context when things change because it has no automatic notification. I mention it for completeness of the answer as opposed to a suggestion. I have yet to see that solution end well

Let’s recap:

writing to disk = locking the store, always

accessing data already in memory does not lock inside the staleness interval, otherwise is has to go up the chain an eventually get fresh data from disk

importing data = small/frequent saves (decoupled as shown above)

My personal conclusion is that you’ll have to experiment with how frequent you call a save on the Managed Object Context that is connected to your persistent store. There might be scenarios where you can get away with saving all the time and other where you should wait for an opportune moment in UI interaction when the user wouldn’t notice a slight pause on the main thread.

Thank you Marcus Zarra for your generously dispensed insight!

How to send image to remote server

Drops — Fri, 11 Jan 2013 07:14:24 +0000

Somebody asked on StackOverflow:

how to send image to Remote server from the below code last string is placed with image

NSString *reqString=[NSString stringWithFormat:@"http://projeceads.info/spir/productinfo/productadd/%@/%@/%@/%@/%@/%@/%@/%@",ownerId,productNameTxt.text,QuantityTxt.text,sizeTxt.text,ageTxt.text,priceTxt.text,descriptionView.text,imgstr]; NSURL *reqUrl=[NSURL URLWithString:reqString]; NSURLConnection *connection=[[NSURLConnection alloc]initWithRequest:[NSURLRequest requestWithURL:reqUrl] delegate:self];
[connection start]; }

Now there are several things wrong with this question. This is the very first question this person asked on StackOverflow and he didn’t even set a proper user name yet. The code is not formatted as such, the English is bad and to most casual onlookers it is unclear what this question is about.

Still I felt an urge to give a good answer because often it is non-sensical questions like this that challenge our ability to parse the intent of the asking person and our knowledge of the subject matter. It is also such a situation where you can give an answer that exactly matches the question as well as a second answer that is a better way of achieving the intent.

There are two ways how you can upload data to a web server: GET or POST

With GET you have to put all information that you want the web server to have into the URL. With POST you additionally can put information into the POST body.

From your question I deduct that he seems to try to upload the image via a GET request and thus needs to “append the image to the URL”.

An image as such is binary data, either uncompressed as RGBA values, usually 1 byte each times width times height. Since this is too much data for most uses, people like to compress images. UIImagePNGRepresentation allows you to create the data in PNG or JPEG format.

But even this compressed format is might not transferable via HTTP if your webserver is unable to process binary data. Historically you have not been able to use all values a byte can hold (0-255) in HTTP which itself is a pure text format. Originally HTTP was only using 7-bit ASCII characters (0-127) which are safe to be transmitted. Because of this any binary data you want to send somewhere has to be encoded into a representation that only uses safe characters. The most prevalent such encoding scheme is “base64″.

One drawback of base64 encoding is that it increases the amount of data you need to send by about a third. Also most modern web servers can actually receive binary post data which is why in the following article I did not need to encode the image. I wrote up here how to upload an image via POST to TwitPic. You need to put together the correct headers and compose a POST body as shown here: http://www.cocoanetics.com/2010/02/uploading-uiimages-to-twitpic/

This is the way I would recommend you upload your image as well, if your web server supports it. This is not the answer you are looking for, but it is the approach you SHOULD take.

Now to actually answer your question “how do I create a URL that includes a representation of an image” (because my server admin is too stupid to build me a script that would also accept a POST)…

The steps are:

Create a compressed representation with UIImage…Representation

Base64-encode the output from 1

URL-encode the output from 2

append to URL string

send GET request

For base64-encoding I use a method created by famous Matt Gallagher. URL-encoding is necessary because even less characters are legal to use in well-formed URLs than are in 7-bit HTTP. For URL-encoding I use this NSString category.

Summary

Even though it is possible you should not send images via GET URLs. Send them like normal people as POST requests and put the image data into the POST body in either binary or base64-encoded format.

The steps are:

Create a compressed representation with UIImage…Representation

Base64-encode the output from 1 (optional, if your web server doesn’t support binary or you want to be safe)

construct content headers

append POST body

send POST request

PS: Of course you can also use one of the many networking frameworks out there for constructing POST requests. But I can guarantee that you will not find a single one that will allow your to append a textual-doubly-encoded image representation to the GET URL.

Assorted Observations

Drops — Fri, 12 Oct 2012 11:57:54 +0000

While I am developing my first own Mac app I’ve been adding to this blog post whenever something was weird to me. Or simply different.

You can definitely see in many instances how some modus operandi on iOS has its roots on Mac, but Apple had to change things a bit around to accomodate the different UI paradigms on the mobile platform.

CG versus NS

You will find that AppKit uses structs for everything that are prefixed with NS, even though the contents are identical. In many cases you can assign a CGRect to an NSRect though that would disturb purists.

There are a plethora of macros to move between these worlds. So you better use these so that if somebody reads your code does not get the impression you don’t know what you are doing.

Upside Down

NSViews have the origin of their coordinate system in the lower left corner of the view. On UIKit we are used to origin being in the upper left corner. Fortunately there’s a simple trick to flip the coordinate system.

In your NSView subclass add this:

- (BOOL)isFlipped { return YES; }

Henceforth all added sub views will be positioned just like on iOS. Since the default implementation of this method returns NO you can only make this modification to your own sub-classes.

Basic Drawing

Like on iOS you have two way of drawing stuff. You can act on the higher level Objective-C API of AppKit/UIKit or you can go down to the Quartz level. Internally all drawing gets mapped to Quartz anyway, so if you already have such lower-level code you can easily transfer it, though you might have to be careful about the coordinate system flipping.

To draw a simple rectangle at the corner of the NSView you can do that in AppKit:

- (void)drawRect:(NSRect)dirtyRect { [[NSColor redColor] set]; [NSBezierPath strokeRect:self.bounds]; }

Or in Quartz:

- (void)drawRect:(NSRect)dirtyRect { CGContextRef context = [[NSGraphicsContext currentContext] graphicsPort]; CGContextSetRGBStrokeColor(context, 1.0, 0, 0, 1.0); CGContextStrokeRect(context, self.bounds); }

The main difference is that you have to obtain the CGContext reference from the current NSGraphicsContext as opposed to UIGraphicsGetCurrentContext. Without isFlipped:YES both AppKit and Quartz have the lower left origin. On iOS Quartz draws from the lower left corner, UIKit from the upper left corner. You might remember having to the coordinate system for Quartz drawing on iOS by means of a transform.

Drop a Shadow

To drop a shadow behind an NSImage you can use the NSShadow class. Similar to NSColors you can also simply “set” the shadow instance on the graphics context.

- (void)drawRect:(NSRect)dirtyRect { NSShadow *shadow = [[NSShadow alloc] init]; [shadow setShadowColor: [NSColor colorWithDeviceWhite: 0.0f alpha: 1.0f]]; [shadow setShadowBlurRadius: 5.0f]; [_shadow setShadowOffset: NSMakeSize(0, -1)]; [shadow set]; [_pageImage drawInRect:[self _rectForPage] fromRect:NSZeroRect operation:NSCompositeCopy fraction:1.0]; }

This creates a shadow and the subsequent drawing operations will show it. Be careful however, because on Mac graphics contexts sometimes get reused.

Clean Up After Yourself

NSPageController creates a snapshot of the view that is going out and the one that is appearing. One thing that was not obvious to me was that it reuses the graphics context used to draw its content view.

The page view would be drawn once and as soon as you started to move your finger it would create another snapshot reusing the graphics context we previously set the shadow on. You see that the gray area in the dashed red box is blurry and so is the page corner where I am drawing a red line for debug purposes.

I was puzzled at first because on iOS you don’t ever see a graphics being reused like this. The solution – of course – is to save the graphics state before making changes to it and restore that state when you’re done drawing.

- (void)drawRect:(NSRect)dirtyRect { NSGraphicsContext* context = [NSGraphicsContext currentContext]; [context saveGraphicsState]; [[self shadow] set]; [_pageImage drawInRect:[self _rectForPage] fromRect:NSZeroRect operation:NSCompositeCopy fraction:1.0]; [context restoreGraphicsState]; }

That fixes the problem nicely.

So we can concluded that it is probably generally good citizenship to clean up changes to the graphics context.

Layer or No Layer?

The red dashed boxes you see in the screenshots are subviews of the large page view. With half an ear I had heard that since quite recently OS X can also back NSViews with CoreAnimation layers. This always has been the only way on iOS.

You can activate this layer-backing mode by setting the wantsLayer property to YES. I figured that layers must be better, so I turned it on for the subviews.

Now I was seeing another strange effect together with the NSPageController. The snapshot for the pages would only include the boxes that where present on screen when you started the swiping motion on the trackpad.

When I disabled the layer-backing suddenly the snapshots would also properly include the sub-views. If you know why this is and maybe can explain the advantages of using layer-backing then please speak up!

Difference in Animation

One explanation for many differences is the simple fact that all views on iOS only ever WHERE layer-backed. Whereas you only are beginning to get this as an option on OS X since 10.7. You can see many places where stock-controls show weird artifacts when used in a layer-hierarchy. Any layer that you make layer-backed view (via setWantsLayer:YES) will automatically pass on the setting to all of its subviews.

Now if you are using some ancient UI controls down the layer-hierarchy, like for example NSTextField there are situations where you see that it is unable to properly draw itself.

Animations on iOS are usually done by simply setting a property value. This triggers an implicit animation with a duration of like 25 ms. If you are resizing an UIImageView like this then CoreAnimation will take care of the animation frames between start and finish. All the while you already see the final value on the property.

On Mac Animations existed since long before there where CALayers, CA as in Core Animation. There a frame change is actually done by calling the animator of a view and setting the property there. This will then take care of setting a different frame for each animation step and the view redrawing itself.

- (void)layoutSubviewsAnimated:(BOOL)animated { if (animated) { // temporarily set the document view frame to the entire contianer, to avoid flicker at bottom section [[self documentView] setFrame:self.bounds]; [NSAnimationContext beginGrouping]; [[NSAnimationContext currentContext] setDuration:kDMPaletteContainerAnimationDuration]; [[NSAnimationContext currentContext] setCompletionHandler:^{ }]; } NSSortDescriptor *sortDescriptor = [NSSortDescriptor sortDescriptorWithKey:@"index" ascending:YES]; contentSectionViews = [contentSectionViews sortedArrayUsingDescriptors:[NSArray arrayWithObject:sortDescriptor]]; [contentSectionViews enumerateObjectsUsingBlock:^(DMPaletteSectionView* paletteSection, NSUInteger idx, BOOL *stop) { if (animated) { [[paletteSection animator] setFrame:[self frameForSectionAtIndex:idx]]; } else { paletteSection.frame = [self frameForSectionAtIndex:idx]; } }]; if (animated) { [NSAnimationContext endGrouping]; } }

It makes me smile to see the possibility of adding a completion handler to the animation group set up here. A sign of new tech infusing the tried and true approach.

If you appreciate this difference in how animations occur in iOS versus traditional OS X then you begin to understand why Apple could never have pulled off the responsiveness of iOS with animators. Only Core Animation and layer animations allow for doing all sorts of tricks on the GPU to scale the contents of layers/views.

First Responder, WTF?

On iOS you might have made a view first responder a few times before, usually you would do that with a UITextView to have the keyboard show. Also there we resigned to the fact there there is no public method to get the current first responder, but we are content with that since becomeFirstResponder automatically resigns the current first responder from its status before the new view becomes the new one.

On Mac it is sufficient for the user to click on any view and it will be made first responder, provided that it responds with acceptsFirstResponder YES. If not then the click will travel up the responder chain and the next view responding with YES will be it. Since you can have multiple windows visible on Mac at the same time, each window has its own first responder which you can inquire from the window.

Setting a first responder in code is also slightly different than on iOS. There the NSWindow instance provides a method to set the first responder. According to the docs this sends resignFirstResponder to the current one and then – if that was successful – asks the new one to becomeFirstResonder.

[[self mainDocumentWindowController].window makeFirstResponder:pageView];

What I don’t yet understand is why in my experiments a becomeFirstResponder often did work, but not always. For example an NSPageController seems to not relinquish first responder status this way. In my app I had to use the makeFirstResponder instead. The only answer I got on Twitter in this regard was along the lines of “NSPageController is a bitch”.

Editing Command Validation

If a UIView can deal with the usual editing commands, like copy:, paste. et al then you can implement a canPerformAction:withSender: which depending on the selector passed in the action parameter can inform the system what actions are available. This is used by the system to only show menu items in UIMenuController that somebody can take care of.

On Mac the story is a bit more complicated. You’ll not find a canPerformAction method there. Instead you implement validateUserInterfaceItem which passes a generic object that tells you the action selector and an element tag.

- (BOOL)validateUserInterfaceItem:(id < NSValidatedUserInterfaceItem >)anItem { SEL action = [anItem action]; NSUInteger selectedZoneCount = [[self selectedHotZoneViews] count]; if (action == @selector(selectAll:)) { if ([_hotZoneViews count]>selectedZoneCount) { return YES; } } return NO; }

You see, same mechanism, but on Mac this allows for many different kinds of NSValidatedUserInterfaceItems, be they menu items or something else. Apple probably decided on the different name to make it less confusing on the unsuspecting developer.

Conclusion

You can see the parallels in iOS and Mac everywhere you look. There are many classes that are identical on both OSes, but wherever there are different user interface paradigms you usually have an NS and UI class duality going on.

iOS is full of optimizations where you can Apple see cleaning up cruft that has gathered in AppKit classes and only putting the leanest and meanest parts into iOS. Thankfully with the success of this high octane approach the Mac platform apparently benefits from many “back to the Mac” tweaks under the hood.

CoreLocation Background Update Messaging

Drops — Fri, 29 Jun 2012 10:29:25 +0000

Two years ago I put together revolutionary chart that detailed the flow of delegate messages when sending an app into background. This was even featured by Erica Sadun of TUAW because it for the first time visualized the whole process in a easy to understand way.

Based on this chart Carl Brown from PDAgent made an addendum to deal with the special case of background region updates and sent it to me. To my shame I have to admit that it was sitting at the bottom of my inbox for 4 months now and it is only now that in my effort to reach Inbox Zero I am dealing with this and putting it up here for your viewing pleasure.

This is the original flow as it was current with iOS 4 and I think it is also mostly true for iOS 5.

And here is Carl’s CoreLocation addendum. I had originally planned to merge this flow chart with the original one, but it was not immediately obvious to me how I could achieve that in a visually pleasing way.

Though maybe it would be smarter to keep them separate because they deal with different subsystems.

Carl reported these findings from his experiments:

The weird thing about the Core Location Delegate events is that you get application:didFinishLaunchingWithOptions: but it isn’t followed by applicationDidBecomeActive: or applicationWillEnterForeground: or applicationDidEnterBackground: – which is something I didn’t expect.

The other odd thing is that if you double-tap the home button and use the task manager to Kill-9 the App, the next Core Location notification will launch the App again, but the App will not re-appear in the recently used Apps list (as revealed by double-tapping the home button), so the user can’t kill the app again (at least not without launching it by hand first). So it becomes an effectively unkillable App (which makes your memory leaks way worse).

So the most important info here seems to be that an app activated from a background location update neither becomes active nor enters any fore- or background. Which makes sense because we don’t want the app to pop to the front just because we have moved. It should be the user’s decision whether he would want to reopen the app. The OS will then make sure to take either the already running (or restarted) instance from the background or launch the app if it got terminated.

Out of curiosity I still would love to merge both flow charts into one “ultimate” one. If you’re good with OmniGraffle then you can take a shot if you like to try, email me and I’ll send you the graffle files.

Beware of NSString Optimizations

Drops — Thu, 29 Mar 2012 17:03:27 +0000

There are some scenarios where NSString acts as a class cluster internally to optimize handling of certain strings. One such case bit me today, and so I want to tell you about it.

Class clusters work such that you think you are always dealing with just instances of NSString, but in reality the runtime goes and chooses different subclasses for certain tasks. You might have already seen some effects of this behavior when debugging and the debugger actually showing you something other than NSString as the type of a variable.

Consider the following innocent splitting of tokens:

NSString *text =@"One,,two,three,"; NSArray *components = [text componentsSeparatedByString:@","]; for (NSString *oneString in components) { NSLog(@"'%@' = %@ %p", oneString, [oneString class], oneString); }

What are the class types you expect to see for the individual components? NSString? Wrong.

'One' = __NSCFString 0x688e270 '' = __NSCFConstantString 0x1459cd8 'two' = __NSCFString 0x688e290 'three' = __NSCFString 0x6881890 '' = __NSCFConstantString 0x1459cd8

The NSCFStrings are actually toll-free bridging strings that can act as CFString in Core Foundation Land as well as NSString in Objective-C land. But note the NSCFConstantString!

This is the kind of optimization that I fell prey to. Look at the memory address! The two empty strings are even one and the same object as you can see by glancing at the output memory address. Who would expect that?

Not only is it a different class that you thought it would be, Objective-C also optimizes certain strings by folding them into certain other subclasses.

Now for the example where this triggered a face-palm…

It’s a Trap!

In DTCoreText I added a convenience method that creates a HTML string from an attributed string. For this I am looping through the paragraphs and add P tags for each.

NSArray *paragraphs = [plainString componentsSeparatedByString:@"\n"]; for (NSString *oneParagraph in paragraphs) { NSRange paragraphRange = NSMakeRange(location, [oneParagraph length]); // skip empty paragraph at end if (oneParagraph == [paragraphs lastObject] && !paragraphRange.length) { continue; } ... }

Since the attributed string might have a \n at the end we don’t want to create an empty P. So I thought that it would be smart to compare the oneParagraph with the lastObject of the paragraphs array and if this was empty then skip it.

BUT, I showed you above that an empty element is actually turned into a certain NSCFConstantString. This would mean that in this example every empty component would be equal to the empty last one and thus be skipped. Not what we wanted.

Because of this optimization the lastObject method becomes useless to determine if oneParagraph is indeed the last one. We have change the slick fast enumeration to a classical for loop with a counter variable.

for (int i=0; i<[paragraphs count]; i++) { NSString *oneParagraph = [paragraphs objectAtIndex:i]; NSRange paragraphRange = NSMakeRange(location, [oneParagraph length]); // skip empty paragraph at the end if (i==[paragraphs count]-1) { if (!paragraphRange.length) { continue; } } ... }

It’s a bit clunkier, but now it is safe from this optimization. An alternative to this approach would be to still use fast enumeration, but increment a counter variable. But unfortunately there is no built-in method of knowing if one loop is the last one of the enumeration. So we still have to compare our counter with the array count.

New or Improved?

I wonder why this doesn’t confuse more people who are unaware of this optimization. Or is that something that was introduced in the later iOS SDKs? Well if you run the first code block on iOS 4.3 simulator you get a slightly different result.

You still get both empty strings pointing to the same instance, but now the constant string is a “normal” NSCFString. So Apple apparently introduced the NSCFConstantString in iOS 5 to be able to optimized certain uses cases. Having a subclass allows them to override certain expensive operations like for example hardcoding the hash value.

But apparently this folding of constant strings into single instances was around even before iOS 4 and so we have to be aware of this possibly wreaking havoc with our slick loop logic.

ObjectiveSee Interview

Drops — Tue, 14 Feb 2012 12:08:32 +0000

ObjectiveSee is a web site dedicated to interviewing iOS developers. They use the format of a Q&A and they have several intriguing people’s up already: Justin Williams, Nathan Spindel, Keith Blount, Whitney Young, … oh and ME!

iOS 5 Breaking NSDateFormatter?

Drops — Fri, 23 Dec 2011 16:06:46 +0000

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.

Bit Masks

Drops — Wed, 21 Dec 2011 12:52:57 +0000

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

Coding Style

Drops — Mon, 05 Dec 2011 10:55:45 +0000

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.

Podcasts for iOS Developers

Drops — Wed, 07 Sep 2011 08:59:08 +0000

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 …

Update: I resurrected the Cocoanetics Podcast! Subscribe to it on iTunes or add the RSS feed to your favorite podcasting app or listen to the shows right on this website.

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.

This Week in Tech: Host Leo Laporte is a seasoned radio pro that manages to gather around tech journalists discussing the broader IT eco system we care about.

MacBreak Weekly: The broadest opinion fest possible when it comes to Apple products.

The third major network is Wizzard Media, providing several interesting feeds:

Mac OS Ken: Host Ken Ray hosts this daily news show focussing on Mac and Apple news.

Today in iOS: A very well made news podcast on the “latest happenings in the iPhone OS world”

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

If you feel that this list is incomplete please drop your suggestions in the comment box.

NSAttributedString+HTML Q&A

Drops — Wed, 31 Aug 2011 08:02:18 +0000

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:

A reverse-engineered and enhanced implementation of the Mac initWithHTML for use on iOS

UI classes to properly render the created NSAttributedString

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:

Pre-initialize CoreText as shown here on a background thread.

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:

Create your DTCoreTextLayouter from the attributed string.

Create a DTCoreTextLayoutFrame for the first column specifying the rectangle

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

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.

Adding Fading Gradients to UITableView

Drops — Fri, 26 Aug 2011 08:22:37 +0000

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 #import @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!

Is it safe to install iOS 5 on your everyday iPhone?

Drops — Mon, 13 Jun 2011 18:14:41 +0000

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.

Prepaid 3G Data for Visitors to the USA – Truth and Fiction

Drops — Mon, 30 May 2011 04:42:02 +0000

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.

iPhone without Sim-Lock, mine is factory-unlocked from the UK

regular size SIM card for GoPhone, make sure that this is one that optionally supports a data package

since I don’t plan to make any phone calls I chose the 10ct/min Calling Plan

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.

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.

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.

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.

Tons of Changes

Drops — Fri, 27 May 2011 08:05:18 +0000

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.

What Impact will new Web-Technologies have on iOS Developers?

Drops — Wed, 25 May 2011 10:23:03 +0000

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.

To Universal or Not

Drops — Wed, 18 May 2011 13:06:31 +0000

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.