To use it, just clone the repository, copy the config.yaml.sample file as config.yaml and edit its values inside. Run the script and voilà! A new blog post entry with your del.icio.us bookmarks.

The script can also be helpful to those wondering how to use the XML-RPC interface of WordPress from a Ruby script, or how to use the Net::HTTP library to consume a REST API.

[source:ruby] def get_delicious_bookmarks # Connect to delicious and get updates http = Net::HTTP.new(DELICIOUS_SERVER, DELICIOUS_PORT) http.use_ssl = true req = Net::HTTP::Get.new(DELICIOUS_DATES_PATH) req.add_field(“User-Agent”, DELICIOUS_USER_AGENT) req.basic_auth username, password response = http.request(req) results = response.body [/source]

[source:ruby] def post_to_wordpress(title, text) entry = { :title => title, :description => text } # Connect to WordPress using the XML-RPC interface blog = XMLRPC::Client.new(server, path, port) blog.call(“metaWeblog.newPost”, blogid, username, password, entry, true) [/source]

Enjoy! As usual, the code is released with a BSD license.

• Microsoft: Windows, Internet Explorer, Microsoft Office, and C#.
• Sun: Solaris, HotJava (sic), StarOffice, and Java.
• Apple: Mac OS X, Safari, iWork, and Objective-C.
• Google: Chrome OS, Chrome, Google Docs, and… Go.

Precisely, Go was the last piece that Google had to create in order to fit into the framework above. And it did, with a bright team including Ken Thompson (of Unix and C fame) and Rob Pike (of Plan 9 and UTF-8 fame). With names like that, and with Google’s own funding and infrastructure, it is normal that the media went into a hype frenzy yesterday.

I think, however, that Google’s engineers got tired of what the current and upcoming versions of their “official” programming languages (Java 7, C++0x and Python 3.0) had to offer, and simply came up with a programming language that fits better their needs and expectations. As one of the slides of the TechTalk says, with current languages “You can be productive or safe, not both.”

Features like built-in support for concurrency or garbage collection hide the real true feature behind the language: faster build times with static typing support. This is important for Google from a software economy point of view: they want more productivity from their developers, or, in other words, more bang for their buck, all together with verifiable quality and speed of execution. Go seems to be designed to deliver in these areas. However, Rob Pike is careful to say that the language is experimental, so time will tell if their efforts were worth it.

In any case, it is worth noting that there was a previous programming language called Go! (whose author even wrote a book about it), and after an InformationWeek article revealed this, a petition has started in the Go bug tracking, asking Google to change the name of the language, all in the name of Google’s own “Don’t be evil” motto.

However, not all editors document the URL schemes they support in their apps, and this blocks reuse and collaboration. I recently came into such a problem, trying to use TwitterFon from my own apps, to post messages to Twitter. The TwitterFon site only specifies the following iPhone URL scheme:

twitterfon:///post?this%20is%20a%20test

The problem is, this URL scheme does not perform an URL-decoding on the message parameter, which means that a phrase like “this is a test” will appear in TwitterFon URL-encoded, that is, as “this%20is%20a%20test”. Clearly not acceptable.

However, thanks to Ashley Mills, I learnt that the USA Today iPhone app is able to use TwitterFon to share articles via Twitter, and does this properly, without URL-encoded characters. How do they do that? Obviously, they are using an URL scheme exported by TwitterFon, but not documented anywhere (*). I finally discovered that the URL scheme sought is the following (“message” instead of “post”!):

twitterfon:///message?some%20text%20here

This is how I found out: I impersonated TwitterFon in my own iPhone with an ad-hoc app created in Xcode, that shows me the URL used by USA Today to launch TwitterFon. These are the steps required:

1. Open iTunes and look for the application whose URL schemes you’re interested in (in my case, TwitterFon Pro); right click on it and select “Show in Finder”;
2. Duplicate the .ipa file in the Finder and change its extension to .zip – yes, .ipa applications are simply compressed .zip files;
3. Uncompress the .zip file and open the folder; inside, navigate to the “Payload” folder, and right-click on the .app file inside; select “Show Package Contents”;
4. Browse inside the package and open the Info.plist file; inside, you’ll find two keys that are interesting for us: CFBundleURLTypes (“URL types”) and CFBundleIdentifier (“Bundle identifier”). Select them and copy them to your clipboard;
5. Create a new Xcode application, using the “iPhone OS / View-based application” template;
6. Open the Info.plist file corresponding to the default target and remove the existing CFBundleIdentifier (“Bundle identifier”) key; paste the two items you’ve copied in the previous step – this means we’re creating an application that will “impersonate” itself as the “real” one;
7. Modify the new Xcode project’s app delegate adding the following method: [source:c] - (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url { viewController.viewer.text = [url absoluteString]; return YES; } [/source]
8. Add a UITextView to your viewController (you can do this easily in Interface Builder, editing the .xib file), and expose it through a public property (called “viewer” above) so that the app delegate can access it;
9. Prepare your Xcode project for ad-hoc deployment: add a “distribution” configuration, an entitlements.plist file, etc;
10. Plug your iPhone, select “Distribution / iPhone OS Device”, and “Run” your application; the application will build and Xcode will install it into your device. ATTENTION: this application will overwrite the original one! This is because it has the same bundle identifier. Be sure to backup your data before doing this, as it will be lost completely;
11. Now run the application calling the one you impersonate (in this case, the USA Today one) and force it to call the “impersonated” application (in this case, by “sharing” an article via Twitter). This will trigger the launch of the impersonated application, the call to application:handleOpenURL:, which itself will display the calling URL on the iPhone screen.

You can download a zip file with the Xcode project created above if you want. Be careful if you run it on your own device!

Voilà! Finally, delete your own impersonated app, go to the App Store, re-install the application you’ve impersonated (normally it’s a free download, even for non-free apps), and you are done. The same mechanism could be used to find out similar, hidden URL mechanisms in other apps.

(*) Actually this URL scheme is only shortly mentioned in the changelog of the application…

Of course, Xcode provides “Groups” to organize your source code, but the idea is to be able to quickly identify the different kind of files that make up your Xcode project, either for Mac or for the iPhone, without having to open the Xcode project file. This means having both a folder structure, and an internal source code file structure. All of this will help you maintain your project in the future, which means cheaper costs, and less time spent looking for bugs.

All of this is also particularly useful when browsing projects via Google Code, Github or any other kind of file view of source code repositories. If your code is organized in a nice folder structure, it is easier to explore than if all the files sit in the same folder.

In this post I will enumerate some best practices that I use in all of my projects. So let’s say that you start a new Xcode project. Here’s the Xcode window that is presented to you (seen in “Condensed” mode, which is the one I prefer):

This is the project layout as seen in the Finder:

As you can see (and as you might have experienced), in the default layout used by Xcode, all new source code files will be thrown into the “Classes” folder, while all the new Resources will be just stored in the project root. In the long term, this layout can be really painful to deal with. So let’s just start rearranging things a bit:

Organize source files in folders and mirror them in Xcode

When I start a new Xcode project, I usually do the following:

1. I remove the “Classes” group (just deleting references, not moving the items to the trash, as shown in the image below)
2. Then I add the following subfolders to the “Classes” folder:
   • AppDelegate
   • Controllers
   • Models
   • Helpers
3. Finally, drag the enhanced “Classes” folder from the Finder to the Xcode project window, asking to “recursively create groups for every subfolder”:

Create separate folders for different Resource elements

The next step is to actually create a resource folder in Finder, and add a subfolder for every kind of resource that my project will use: sounds, images, SQLite databases, NIBs, etc. Then I do the following:

1. Remove the Resource group from the Xcode project (just deleting references)
2. Then I drag the newly created “Resources” folder from the Finder to the Xcode project window, asking to “recursively create groups for every subfolder”, like we did for the “Classes” folder.

Doing this has an interesting side effect: when you localize your application in other languages, each folder will contain a subfolder with the localized resources inside (for example, an “en.lproj” for English, “es.lproj” for Spanish, and so on).

Organize your code consistently

Each @implementation *.m file should always present methods in this order:

1. init and dealloc
2. public methods
3. public @dynamic properties
4. delegate methods (for each supported protocol)
5. private methods

Use #pragma statements to separate the regions shown above

Each logic group of methods should be separated from each other using the following lines (just type “#p” and hit the TAB key in Xcode!): [source:c:firstline(79)] // … return cell; }

pragma mark -

pragma mark UIAlertViewDelegate methods

• (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex { // … [/source] The advantage of this approach is that later, you can use those #pragma marks to generate an automatic layout in the symbols pop-up of Xcode:

You can get this pop-up window clicking on this sector of your Xcode window:

Only leave public methods in the header files

This means putting private methods definitions in a (Private) category on top of the *.m file. This will remove all compiler warnings (about “this class might not respond to this selector”) and will cleanly separate what’s public from what’s not: [source:c:firstline(9)]

import “UntitledViewController.h”

@interface UntitledViewController (Private) - (id)returnPrivateObject; - (void)changeInternalState:(NSString *)param; @end

@implementation UntitledViewController

• (id)init { [/source]

Use consistent coding conventions

You can use my own, if you wish.

Treat warnings as errors

I’ve said a lot about that in a previous post, but here’s a quick reminder:

Create “Distribution” configurations for the new project

Duplicate the “Release” configuration and create two new ones: “Distribution Ad Hoc” and “Distribution App Store”. Each one will have to be configured with their corresponding provisioning profiles.

Add an “Entiitlements.plist” file to the project

Remember to uncheck (disable, turn off) the “get-task-allow” value (I still don’t understand why every Xcode project does not create this file automatically). Then add the “Entitlements.plist” value to the corresponding key in the “distribution” configurations created in the previous step.

Use source control

As soon as your project source tree is ready, commit it to your repository, whichever this is.

Conclusion

This is how the final project might look like:

Of course, you might as well enforce the above best practices using your own default project templates; depending on your requirements, this might be a useful thing to do. You must store those new Xcode templates in the following locations:

• iPhone: /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Project Templates
• Mac: /Developer/Library/Xcode/Project Templates

Hope this helps! As usual, feel free to add your comments, best practices, rants and other reactions in the comments section below.

He actually didn’t know you could remove all compiler warnings; he thought Objective-C was the land of compiler warnings. This situation, I think, is far from exceptional, and due mostly to cultural and technical reasons.

It is my opinion, that removing compiler warnings is basic project hygiene, like writing unit tests, or using the Clang Static Analyzer. I will explain in this post some techniques I use to remove warnings in my Objective-C code.

First of all, why does the Objective-C compiler (or compilers in general) output “warnings”? Many developers are puzzled the first time they encounter them, since even if the compiler complained, the application usually runs anyway without (perceptible) problems.

Warnings are used to signal specific issues in the source code which could potentially lead to crashes or misbehavior under some circumstances, but which should not (pay attention to the verb “should”) block the normal compilation and (hopefully) execution of your code (otherwise, it would be a compiler error).

It’s the way used by your compiler to say:

Hey, I’m not sure, but there’s something fishy in here.

Not removing warnings, as I said above, is a problem that originates both in the programming background of the developer, and specific technical issues.

Culturally speaking, many other programming environments either do not have compilers at all (at least not “visible” ones, like Ruby or PHP) or simply do not spit warnings for anything else than deprecated methods (like C# or Java); this situation has made many developers new to the iPhone platform to blatantly ignore them.

Technically, given the fact that Objective-C is the “other” object-oriented superset of C, and that it behaves as a coin with both a static and a dynamic side, compiler warnings convey a great amount of precious information that must never be ignored.

In this sense, Objective-C has a lot in common with C++. Ignoring warnings in C++ is strongly discouraged, and Scott Meyers explains this in chapter 9 of his book “Effective C++”, stating that (third edition, page 263):

Take compiler warnings seriously, and strive to compile warning-free at the maximum warning level supported by your compilers

In the case of Objective-C, this can be done by setting GCC_TREAT_WARNINGS_AS_ERRORS (-Werror) to true in your build settings.

Steve McConnell takes this advice to another level of importance in his classic book “Code Complete” (second edition, page 557):

Set your compiler’s warning level to the highest, pickiest level possible, and fix the errors it reports. It’s sloppy to ignore compiler errors. It’s even sloppier to turn off the warnings so that you can’t even see them. Children sometimes think that if they close their eyes and can’t see you, they’ve made you go away (…). Assume that the people who wrote the compiler know a great deal more about your language than you do. If they’re warning you about something, it usually means you have an opportunity to learn something new about your language.

To give a concrete example of the importance of warnings, many of us have had to migrate applications developed for iPhone OS 2.x to the 3.0 operating system, mostly because failure to run on the new version of the OS was ground for removal from the App Store. That moment of truth, the rebuild of the Xcode project, unveiled a plethora of compiler warnings, most due to deprecated methods, like the tableView:accessoryTypeForRowWithIndexPath: method of the UITableViewDelegate protocol, or the initWithFrame:reuseIdentifier: method of the UITableViewCell class (which, incidentally, are properly marked as such in the documentation, too).

Compiler warnings in Objective-C have a multitude of reasons:

• Using deprecated symbols;
• Calling method names not declared in included headers;
• Calling methods belonging to implicit protocols;
• Using some ambiguous commands which might be intentional but are syntactically valid anyway;
• Forgetting to return a result in methods not returning “void”;
• Forgetting to #import the header file of a class declared as a forward “@class”;
• Downcasting values and pointers implicitly.

Many solutions exist for these problems, and I do not claim to know them all; I’ll just describe some of them, and hopefully some of the readers of this post will add others in the comments below.

1) Make implicit protocols explicit

This is a really simple one, and it’s also good for documentation and code clarity reasons. Get all the references of delegate methods you use in the code, and group the methods into their own header file. Import the header file whenever you need, and make classes explicitly implement them:

[source:c] //… @interface NewClass : NSObject { //… [/source]

Of course, take advantage of Objective-C’s @required and @optional keywords in your protocol declarations; they are used by the compiler to verify (or not) the existence of delegate methods in your class implementation. This way, you’ll surely remove some warnings.

2) Do not use “id” as the data type for delegate fields Using id as datatype for delegate fields

I personally use the following declaration for delegate fields:

[source:c] //… NSObject *delegate; //… [/source]

instead of simply

[source:c] //… id delegate; //… [/source]

This is because I always check on delegates before calling their methods. Call me paranoid, but this is what a good delegate call looks to me:

[source:c] if([delegate respondsToSelector:@selector(someObj:doesThis:)]) { [delegate someObj:self doesThis:@"123"]; } [/source]

Using NSObject instead of id in the delegate declaration avoid yet another warning. Update, 2009-07-17: This is because using id raises a warning that “respondsToSelector:” is not defined in SomeProtocol. The solution for this is making SomeProtocol inherit from the NSObject protocol (I always forget this double life of the NSObject symbol):

[source:c] @protocol SomeProtocol //… @end [/source]

This way, you can use id<SomeProtocol> variables without problem.

3) Create categories for private methods

Objective-C uses the @private, @public and @protected identifiers only for instance fields, but otherwise methods can only be marked as instance (“-”) or static (“+”), but all methods specified in the header file are public by default.

If you need to specify private methods, do that in your implementation file, creating what’s called a “category” of your own class, which basically “extends” the class with new methods:

[source:c]

import “NewClass.h”

@implementation NewClass (Private) // your methods here @end

@implementation NewClass // … @end [/source]

This way you can define private methods, not exposing them in the public interface file. And you remove some more warnings.

4) Turn implicit type conversions and casts into explicit ones:

This one is inspired by McConnell’s Code Complete (second edition, page 293):

[source:c] int i; float y, x; y = x + (float)i [/source]

Even if the compiler could work out the “y = x + i” expression without problem, the code above will remove yet another warning, and will make your code more obvious and easier to read, since it clearly states your intentions.

5.1) Support earlier OS versions via runtime checks

If you have to write iPhone applications compatible with both the 3.0 and 2.x versions, this sample from Apple https://developer.apple.com/iphone/library/samplecode/MailComposer/listing7.html provides instructions on how to do it.

“MailComposer runs on earlier and later releases of the iPhone OS and uses new APIs introduced in iPhone SDK 3.0. See below for steps that describe how to target earlier 0S versions while building with newly released APIs.”

It is worth noting that this sample application compiles without a single warning!

5.2) Support earlier OS versions via #defines

Use #ifdef IPHONE_OS_3.0 and IPHONE_OS_2.2.1 if you can (or must) provide different binaries for each supported platform. This might be the case for in-house applications, but again, it might help removing some warnings too.

6) Use @class in the @interface, #import on the @implementation

Whenever you use a class on a header file, to avoid cross-references, use the @class keyword to reference it, but do not forget to #import its header file in the implementation!

[source:c] @class AnotherClass

@interface SomeClass : NSObject { @private AnotherClass *field; //… } [/source]

and then

[source:c]

import “AnotherClass.h”

@implementation SomeClass

• (id)init { if (self = [super init]) { field = [[AnotherClass alloc] init]; } return self; }

@end [/source]

The problem is, if you do not #import the file, you get a warning…

The advantage of this technique is not obvious in small projects, but it is strongly recommended anyway; it prevents header files from cross-referencing each other, and it reduces build times in projects anyway. It is the Objective-C analog to the technique of using “class” statements in C++ header files, instead of #include.

For more information: Matt Gallagher also wrote about this issue, and I strongly recommend his article too! Read also this article from Apple about the issue of compiler warnings which covers all the options available on GCC in great detail.

Finally, all of this boils down to the fact that iPhone programming is not as easy as web development, and that iPhone applications, for many reasons, require patience and attention. Removing warnings from your code is just one of many steps to have great iPhone applications, running smoothly without problems.

Update, 2009-07-17: Regarding the “id vs. NSObject” issue, I’ve used NSObject because you get a warning when calling respondsToSelector: on a variable of type id. Now, after reading all the comments I’ve gone back to Xcode and found out that you can define SomeProtocol as implementing the NSObject protocol itself, and this solves the problem. Thanks everyone for the heads-up!

Unbeknown to most of us, the ibtool utility bundled with Interface Builder and Xcode allows us to inspect the contents of NIB files (or XIBs, for that matter) and get from them nice property lists XML streams, which I transform in NSDictionary instances, which I loop over and over util I get something that looks like this:

[source:c] UIView *view6 = [[UIView alloc] initWithFrame:CGRectMake(0.0, 0.0, 320.0, 460.0)]; view6.frame = CGRectMake(0.0, 0.0, 320.0, 460.0); view6.alpha = 1.000; view6.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight; view6.backgroundColor = [UIColor colorWithWhite:0.750 alpha:1.000]; view6.clearsContextBeforeDrawing = NO; // …

UIButton *view9 = [UIButton buttonWithType:UIButtonTypeRoundedRect]; view9.frame = CGRectMake(167.0, 65.0, 72.0, 37.0); view9.adjustsImageWhenDisabled = YES; view9.adjustsImageWhenHighlighted = YES; view9.alpha = 1.000; view9.autoresizingMask = UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleBottomMargin; view9.clearsContextBeforeDrawing = NO; view9.clipsToBounds = NO; view9.contentHorizontalAlignment = UIControlContentHorizontalAlignmentCenter; // … [view9 setTitleShadowColor:[UIColor colorWithWhite:0.000 alpha:1.000] forState:UIControlStateSelected];

// … [view6 addSubview:view9]; // … [/source]

Using this tool, I can now use IB for design, and then generate the code for those designs, in case I prefer to use a code-only approach (usually for UITableViewCells, as I explained before). For the moment it only works with UIKit classes, but I don’t think it might be a problem to extend it to AppKit classes as well.

I hope this project is useful to all of you! As usual, open source, public domain and on Github.

Update, 2009-04-09: This project has been featured in an article in Ars Technica by Erica Sadun!

This code, apart from showing the keyboard and playing those sounds, it doesn’t do anything else, even if a simple “tel:” URL call might suffice to turn it into a real dialer. As usual the code is on Github; feel free to play with it, extend it, and do what you want.

My solution (there might be many others!) consists in the following key elements:

• Avoid loading images right after the RSS feed is parsed; instead, use the -tableView:willDisplayCell:forRowAtIndexPath: delegate method in the controller to trigger the loading of the image for cells that become visible; this ensures that only the cells that are visible will receive the order to load images from the network;
• Use a “model” class for each element of the table, and make the custom UITableViewCell subclass a delegate of this model object; then, the model object is responsible of loading its own image, and will tell the UITableViewCell when done;
• Use the ASIHTTPRequest framework, with a shared download queue in the application delegate, so that all of the requests are properly queued, and network resources are properly used;
• Show feedback to the user with scrolling wheels whenever and wherever appropriate;
• Use the Reachability class from Apple’s own sample code to see if we’re really connected to Flickr, and otherwise show an error to the user.

I have created a sample project, as usual in Github, where I gather RSS data from Flickr’s public feed, and then I download synchronously the preview images of the feed. I even included a very simple Core Animation effect which reminds me of how the iTunes iPhone application allows us to hear previews of the songs we want to buy (the image flips and shows another view “behind”).

Feel free to contribute, fork, enjoy, read, use in your own projects, as you want. As I said, there might be many other (and most probably better) approaches to do this, so feel free to leave your comments below, as usual.

I use Twitterriffic a lot, both on the iPhone and on my Mac, and particularly in the iPhone version, I’ve always liked the little editor for tweets. It grows and shrinks as you type, it appears and disappears following the keyboard, and it provides a standard toolbar with many useful buttons (Actually, I wish the Mac version would have a similar text entry box, which would grow bigger as I type; it’s probably the only complaint I have about it!)

Well, here’s my own attempt at doing something similar, and after 1 hour of work, the result is published, ready for you to enjoy at Github. As usual, no strings attached, pure public domain stuff, so use it and play with it as you wish.

So feel free to check out the projects I’ve moved there, and of course, to fork them and enjoy the code as you see fit.