Facebook’s Imported Stories

Facebook removed the “imported stories” feature early today, which means you can’t update your flickr pictures directly from Facebook Wall anymore:

And the note (from Facebook) sounds like flickr has Facebook Connect ready? Let’s check:

No shoot! Flickr do have Facebook Connect now! Hmm, is this the only “official” way to update pictures to Facebook? Should I click the connect button? Clicked.

Holy Cow! All I want to do is updating my flickr pictures to Facebook, and look what I need to provide (to Yahoo!):

1. Give Yahoo! my basic information:
   Includes name, profile picture, gender, networks, user ID, list of friends, and any other information I’ve shared with everyone. So my flickr pictures can update correctly on Facebook.
2. Let Yahoo! access my data anytime:
   Yahoo! may access my data when I’m not using the application. Taking shower, for example.
3. Yahoo! can read my Facebook Chat:
   For what? Updating flickr pictures?
4. Give Yahoo! my profile information:
   Includes EVERYTHING, such as likes, music, TV, movies, books, quotes, about me, activities, interests, groups, events, birthday, religious and political views, education history, work history and Facebook status.
5. Let Yahoo! know my contact info:
   ONLY Current City. I thought they already have, and what’s this for? Double check? Must be.
6. I also need to sell my friends to Yahoo!:
   Like birthdays, current cities, education history, work history, events and Facebook statuses. For updating Flickr pictures, of course.

No wonder companies are willing to work with Facebook.

Back to last February, I created a WebKit plugin to convert emoji characters to iPhone emoji icons. And I started my porting to Safari Extension two days ago, now it’s available on digdog.github.com/emoji.

How it works?

The extension comes with two major parts:

1. emojiSniffer.js
2. global.html

emojiSniffer.js is the injecting script. It was designed to init() at the very last moment of the page loading, and sniff() the DOM tree by:

1. Using document.evaluate() to query document.body with XPath expression “//text()” and additional XQuery functions, so I can suck out all the textNode inside the body.
2. And scan each textNode using String.charCodeAt() to find out emoji characters.
3. Once found the emoji character, push hex-converted emoji charCode, textNode, and the index of emoji in textNode into a JSON object.
4. Send an async message safari.self.tab.dispatchMessage() with charCode to global.html, ask for the image data.

global.html is the data source, it contains a giant image data url JSON table, encoded in base64 format. When global.html received the message event from emojiSniffer.js:

1. It simply maps the JSON table with event.message as key
2. And send data url back to emojiSniffer.js asynchronously through event.target.page.dispatchMessage() method.

At the same time, emojiSniffer.js keeps scanning the DOM tree to the end (then emojiSniffer.sniff() will stop), and is also waiting for global.html to callback in emojiSniffer.delegate():

1. emojiSniffer.delegate() looks up the event name, if it’s “renderEmoji”, we start replacing the emoji characters.
2. Go through whole JSON object entries we pushed during emojiSniffer.sniff() earlier.
3. And create an img element node, set data url into src attribute.
4. Insert the img element into the text node.

And the DOM tree will update the content with emoji icons!

How to Install?

After downloaded the extension from http://digdog.github.com/emoji:

Double click the “emoji.safariextz” file on your Mac.

And click “Install” button. Done, you are good to go.

Where to Download

Download the binary from http://digdog.github.com/emoji.

Get the source code from github. It’s licensed under MIT license.

Customize FBStreamDialog content style from client:

NSString *override = @"document.getElementsByClassName('caption')[0].style.fontSize = 'medium';";

if ([self isKindOfClass:NSClassFromString(@"FBStreamDialog")]) {
    [_webView stringByEvaluatingJavaScriptFromString:override];
}

Update
Version 3.2 with new sample for iOS 4.2 is available here.

I just pushed some changes to github, and make MapKitDragAndDrop version 3.1:

Changes

1. iOS 3.2 responds to isDraggable property (but it’s not working), so use systemVersion to do the check. Thanks to Erich Wood (@erichwood) for the report.
2. No more synthesized by default, developers are allow to use either GCC or LLVM compiler with it.
3. New sample code for iOS 4.2

Story

In version 3.0, when -initWithAnnotation:resuseIdentifier: called, I create annotationView based on the availability of MKAnnotationView’s isDraggable property. If MKAnnotationView can handle isDraggable, I will return the built-in MKPinAnnotationView; if not, I create DDAnnotationView instead, and let it handle the drag/drop functionality.

But here comes one problem: though document said isDraggable only available in iOS 4 and later, iOS 3.2 does has this property (but not enabled). As result, my

self.hasBuiltInDraggingSupport = [[MKAnnotationView class] instancesRespondToSelector:NSSelectorFromString(@"isDraggable")];

will return YES on iOS 3.2, and create the non-draggble MKPinAnnotationView back.

So one of the quickest solution is to check system version number instead of using -instancesRespondToSelect: to decide if we need to use DDAnnotationView:

self.hasBuiltInDraggingSupport = [[UIDevice currentDevice] systemVersion] compare:@"4.0" options:NSNumericSearch] != NSOrderedAscending;

That’s one of the changes in version 3.1.

Thoughts

As for synthesized by default, I previously enabled Objective-C 2.0 Non-fragile ABI for using the “synthesized by default” feature in MapKitDragAndDrop 3.0, turns out it a pain in the butt for many developers, even Apple removed these options in latest Xcode 4 preview.

And my thoughts on ivar changed: If you really want to get rid of ivar in Objective-C, use NSManagedObject. That’s more likely to be an ideal solution to you, even though you get other messy problems. Keep using ivar is not a bad idea after all, that’s how I told myself.

So, after considering, I changed my mind, no more synthesized by default in this version, and you are allowed to use either GCC or LLVM Compiler with it now.

License

Source code is licensed under MIT license. You can download it from github.

References

• MapKitDragAndDrop 3
• MapKitDragAndDrop 2.0
• MapKit annotation drag and drop with callout info update
• “-Xclang -fobjc-nonfragile-abi2” is single flag with one argument
• To nil, or not to nil, that is the question

I had updated my open source projects on github, they are all released under the rule below:

• Script projects are in the Public Domain
  Scripts are helpers to me, they are designed to improve my development workflows, or some prove of concepts during the design stage. I’m not going to make any restrictions on them, and hope they can improve your works too!

  1. xcode-git-cfbundleversion
  2. html5video
  3. UntilGizmodoPubliclyApologizesToGrayPowell
     　

• Component projects are released under MIT License
  Component projects can be either script based or Objective-C based, they are created to be used in my softwares. And since I spend times on those babies, I’d like to protect them, so I released them under MIT License. To compare with other free software licenses like GPL, LGPL and BSD, the MIT License gives you more rights and less restrictions, so that you can use, modify, and merge them in your softwares freely.

  1. DDActionHeaderView
  2. DDShareViewController
  3. DDAlertPrompt
  4. DDBadgeViewCell
  5. DDSocialDialog
  6. MapKitDragAndDrop
  7. NSDate-RelativeDate
  8. emoji
  9. iphone.gs
     　

• Application projects are released under New BSD License
  Unless there are some specific reasons, I’m not a big fan of releasing application projects as open source. But still, you will see them often in the upcoming future, at least for another one Objective-C based iOS application. Since they’re all ready-to-use softwares, I’d like to protect them with New BSD License (or you want to call it obnoxious BSD advertising clause, that’s totally okay to me).

  1. GrupaReveal
  2. FrostyPlace 　

Thanks for reading, please enjoy.

Recently, I released 3 different iOS UI Components on github.

They are

• DDActionHeaderView
• DDShareViewController
• DDAlertPrompt

And I haven’t had a chance to talk about them all, but let me show you the first one, which is also my favorite: DDActionHeaderView.

Story of DDActionHeaderView

Back to December 2009, that’s almost one year ago, I was struggling to create my first serious iPhone utility app, lots of proof of concept design and user interface experiments ongoing back then. And one of my ideas was to create a new UI component that:

1. Combine the core concept of UIToolbar and UINavigationBar.
2. Keep the simplicity and accessibility at the same time.
3. And users can use it fast.

Rapid, is a very important notion for designing utilities on small iOS devices like iPhone or iPod touch. Those little gadgets should launch fast, do things fast, and go away fast.

For example, you don’t want your users to waste time looking at strange icons on the toolbar and trying to figure out (or just by guessing actually) what those icons do. And meanwhile, there’s no much space for you to add description next to the icons.

Icons on toolbar seems to be a simple interface with clear functionality, but things could be worse when you have four or five different looking icons on the toolbar, and the situation gets even worse when each icons are bringing up their own UIActionSheet.

It becomes some kinds of crazy knock'em down games in carnival booths, and you’re not going to win prizes from your users for that.

And DDActionHeaderView is the solution…

One Icon to Rule Them All

The gray circle on the right is called Action Picker, it contains action items. Users can tap to expand that action picker and look for actions that can be executed.

Once users tap the action item icon, the action picker shrinks back to normal, and action executed. So now:

1. You saved lots of spaces for you app on screen.
2. You got users focus on what they want when they want.
3. Action Picker designed to look like an extra layer hidden under the skin.
4. A well chosen default icon (first one) for Action Picker to display, can provide more detail information for underlying action items.

Eat Your Own Dog Food

DDActionHeaderView’s variants (e.g. dataSource protocol version) were first used in my iPhone app QR+Emoji, and the version you saw on github is a simplified version that is used in my newly released app: FrostyPlace.

Requirement

• iOS 4.0 SDK or later, demo project is using iOS 4.2GM SDK.
• QuartzCore framework.

DDActionHeaderView uses Blocks, Quartz 2D, CALayer, CAGradientLayer, CAAnimation and UIGestureRecognizer.

Screenshots

License

DDActionHeaderView and other two projects are released under MIT License.
Source code and demo are available on github.

Let’s take a look at the Objective-C Programming Language, chapter of Declared Properties, section of dealloc:

Note: Typically in a dealloc method you should release object instance variables directly (rather than invoking a set accessor and passing nil as the parameter), as illustrated in this example:

- (void)dealloc {  
    [property release];
    [super dealloc];
}

If you are using the modern runtime and synthesizing the instance variable, however, you cannot access the instance variable directly, so you must invoke the accessor method:

- (void)dealloc {
    [self setProperty:nil];
    [super dealloc];
}

So the question is, should we nil the ivar in -dealloc?

My answer is yes, and the reason is ivar is going to be veiled, and nil ivar in -dealloc is future proofing your code, forearm for the next big change of Objective-C.

If you look back closely, Apple is trying very hard to obscure the instance variable concept (especially the direct accessing of ivar):

1. They first introduced declared properties,
2. then the dot syntax,
3. and the recent synthesizing ivar (Objective-C non-fragile ABI 2.0).

They all point to a clear and simple picture:

“ivar is the gateway to the memory management hell, we should get rid of it.”

Instead of accessing the ivar directly, using declared property would be a better way to avoid kinds of troubles that related to the object ownership and disposal. No matter what kind of messages: assign, retain, copy or release, all send out through a unified interface, the declared property.

I think that’s why we saw this showing up in -dealloc:

[self setProperty:nil];

I could be wrong, you know

But since @jeff_lamarche and @danielpunkass are talking about it, I would love to let you know my thought on this.

Update

My wild guess is now a failed guess, according to Michael Jurewitz from Apple:

@digdog Actually, not being able to access the underlying ivar on synthesized properties is just a bug that is fixed in recent compilers.

And keep in mind, using accessor in -dealloc should be really carefully considered (even to avoid), not because accessors can be overridden (thanks @hatfinch), but also mutators/accessors are KVO compliant. By invoking any of them, the suitable KVO notifications are sent, unexpected result might happen if your codes are complex enough, especially when you doing that in deconstructor…

So I would nil ivar in this way:

- (void)dealloc {  
    [property release], property = nil;
}

Note: for the comma operator, please read.

References

1. iPhone Development: Dealloc
2. iPhone Development: More on Dealloc
3. Red Sweater Blog - Don’t Coddle Your Code
4. Uli’s Web Site: Defensive Coding in Objective-C
5. The Great Dealloc Debate at Under the Bridge