Yes, it’s possible. Even if Objective-C is one of my preferred programming languages, in any case I think it’s worth mentioning that, 2 years after the official iPhone SDK has been announced, the iPhone development landscape has really grown up, and many, many different options are available today. This article provides a very high-level enumeration of some options I’ve found on the web, but I’m sure there are even more alternatives around.
Here it goes: Continue reading
Here’s a quick review of the most important iPhone and Mac OS X developer conferences I’ve found on the web (in no particular order). Definitely, there’s no shortage of conferences when you need information about the latest Cocoa, Mac OS X and iPhone technologies; check this out!
Also noteworthy, but not so much about software development I think, is the Mobile Enterprise Conference in Amsterdam (Netherlands) on November 3rd, which has a couple of tracks about the iPhone in enterprise.
Feel free to add links to other similar events elsewhere in the world!
Update, 2009-10-02: Here’s the link to Jonathan ‘Wolf’ Rentzsch’s C4 Independent Developers Conference.
Update, 2009-10-03: The Øredev 2009 Developer Conference in Malmö (Sweden) next November has iPhone / Mobile tracks too. And so will the Scandinavian Developer Conference 2010 in Göteborg (also in Sweden).
I love playing with iPhone URL schemes. And if you ask me, just like for Mail.app and Safari, I think there should be a “default” Twitter client URL scheme in the iPhone, with an interface in the Settings application allowing you to set the application that you prefer to tweet. Alas, this is not the case, and each application must manually allow users to select their preferred client, from a list of known ones.
Having documented iPhone URL schemes for TwitterFon, Twitterrific, Tweetie and Twittelator, I’ve created a project, available in Github, called TwitThis, which helps users choose their preferred Twitter client, and makes it easy to remember the user choice, and to launch the associated application with a single command:
This application has the following features:
If you have to support several different Twitter clients, feel free to use these classes in your own project! The project, as usual, is available in Github with a liberal BSD license. Enjoy! I’d love to hear your comments below.
Xcode does not impose any structure to your source code tree. This is both cool and useful to quickly throw a couple of lines for a prototype, but in my experience, this approach does not scale. More often than not, without any hygiene, your project can become a mess. Just using Xcode defaults, after a while your resources will sit beside your .xcodeproj file, all the project classes will be thrown together in the Classes folder, and if you have a relatively large project, this approach makes finding individual files painful.
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. Continue reading
Now that the NDA on the iPhone OS 3.0 SDK has been lifted (which happened much faster than what I thought it would take!) here’s my first contribution to the world of iPhone OS 3.0 open source code: sample code about how to use OpenGL ES 2.0 on the iPhone 3GS, something I announced in Twitter last week.
As you might know by now, one of the biggest enhancements (and yet, one of the most obscure) of the newly released iPhone 3GS is the new GPU chipset, which allows developers to create applications using Open GL ES 2.0 (together with Open GL 1.1, which was already available in the first two iterations of the iPhone). This is a major advance, invisible to the end user, which, coupled with the unprecedented performance boost of the iPhone 3GS, opens up the possibility to developers to create applications with new textures and effects, yet unforeseen on this platform.
Given that Xcode does not (yet) bring an Xcode template to play with, and that the OpenGL ES 2.0 Programming Guide book, by Aaftab Munshi, Dan Ginsburg and Dave Shreiner does not (obviously) bring iPhone examples, I have created a project in Github where I will be publishing the code samples in the book, as I progress in the lecture, ordered by chapter, ready to compile and play with.
Enjoy! I’m happy not having to use the word “[REDACTED]“ any more now (there’s the other OS, the bigger cat, but, oh well…)
Update, 2009-06-24: I just found this blog post by the folks of Black Pixel (Daniel Pasco‘s company) with benchmarks about OpenGL ES on the iPhone 3GS… and the first line says it all:
Holy crap, this thing is fast
Update, 2009-06-24: Jeff LaMarche just announced that the authors of the book have published iPhone – compatible code in the book website! That effectively renders this project useless :))
Last year I blogged about the upcoming SDK 2.0 for the iPhone 3G, and boy did it change my life. For those who haven’t followed closely everything that happened in this blog lately, there’s been this (that’s me in the WWDC keynote main room at the Moscone center) and then that (yours truly talking at the first ever European iPhone conference). All of this has been the result of going to San Francisco last June. That particular trip changed everything; I never thought that a simple plane ticket could generate this much.
The iPhone has literally changed my professional life. But it was only the beginning. Last Tuesday, Apple announced the iPhone SDK 3.0, and I’ll expose here some thoughts about what’s coming next. Continue reading
(Somehow this project seems to me so simple, that I’m sure someone has done this before. Anyway). This is my feeble attempt to bring an answer to the eternal dichotomy between those arguing about the relative benefits of creating user interfaces via Interface Builder or via pure Objective-C code: let me introduce nib2objc.
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!
Finishing my series of copied flattered UIs, like that Facebook thingy or that Twitterriffic gadget, here’s Apple’s own iPhone keyboard, in a really sloppy implementation that has been blatantly and horribly copied, with awful sounds that pop when you tap the numbers and such. The Fring iPhone application uses a similar keyboard, but with a different color set.
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.
Memory management in the iPhone is a hot topic. And since tonight I’m talking about it on tonight’s monthly meetup of the French-speaking Swiss iPhone Developers group, I might as well share some tips here from my own experience.
I won’t go dive through the basics; I think that Scott Stevenson did a great job in his “Learn Objective-C” tutorial at CocoaDevCentral, from where the image below comes. I’m just going to highlight some iPhone-specific issues here and there, and provide some hints on how to solve them.
I’ve uploaded (yet another) update to the Objective-C REST client I’ve blogged about previously. This time I’ve scanned the code with the excellent LLVM/Clang Static Analyzer and fixed a couple of memory leaks here and there. I strongly recommend to scan your own projects with this tool, it’s extremely simple to use:
scan-build -k -V xcodebuildon the root of the Xcode project folder;
