Another quick post to announce that I’ve published the slides (and sample application) I’ve shown last week in Copenhagen; feel free to download them from the projects section!
Remember that I’ll be hosting a similar talk on September 9th in Zürich! I look forward to see you there and to discuss about iPhone development.
Just a quick post to tell you all that I’ll be speaking tomorrow evening (August 27th, 2009) in Copenhagen (Denmark) in the free JAOO Geek Night organized by the great team of Trifork. They are the organizers of world-class events such as the QCon London, QCon SF and RubyFoo London!
But even better news for the Swiss: the same event will happen in Zürich, on September 9th so feel free to come, have a snack with us, share a few drinks and talk about iPhone development.
See you there!
Notitas is available at an App Store near you! Notitas means “small notes” in Spanish, and it’s the fourth iPhone application under the akosma brand, and the first based on an original idea of my dear wife!
As the name implies, it’s a simple and easy way to create, keep and find notes in your iPhone, with some bonus: geographical awareness, so that each note remembers where it was created; the ability to publish notes in Twitter (for the moment, only if you have Twitterriffic installed in your iPhone) and send them via e-mail, too. I’m particularly happy of the Twitter integration (which prompted a whole article in this blog) so that I can use Notitas a lot as a “draft Twitter” client.
I’m already preparing version 1.1 with TwitterFon + Tweetie support, as well as a German localization thanks to Sophie from Sophiestication! Stay tuned for more goodies :)
PS: oh, and while you’re using Notitas, try shaking the board a bit and you’ll see what happens ;)
Let me introduce to you RooiFonts and DeviceDNA, the latest iPhone apps by akosma software on the App Store!
RooiFonts is an evolution of my previous Font Browser application (still open source, still in Github). RooiFonts builds upon that application bringing some more new features, like the ability to send a screenshot of a sample of text in the selected font via e-mail, or being able to compare two fonts side by side. RooiFonts is available in the App Store for USD 3.99 (CHF 4.40, EUR 2.99).
On the other hand, DeviceDNA is a free application for all of my clients, to send me their iPhone device information (including their UDID) via e-mail in a convenient way. No more explaining “open iTunes, click here, paste there…”, just install this, and you’re done.
As usual, both are available in English, French and Spanish.
As an iPhone developer, one of the simplest and easiest mechanisms you have to interact with other applications is through the use of iPhone URL Schemes. These are so important that I’ve created a wiki page where I keep track of those I come across, including code samples that help me exchange data with them.
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. Continue reading
Let’s be frank: it’s not the best time to be an iPhone developer right now. In just one year of existence, the App Store seems to have evolved from the hottest to the lamest status, without any time to breathe in the middle, but with some warning signs every so often.
Several iPhone developers have publicly stated their opposition to the Google Voice fiasco (starting with Riverturn themselves, the developers of the application), and many have simply stopped creating iPhone OS applications altogether; just to name a few, Fraser Speirs, Steven Frank and Andrew Wulf have publicly stated that they don’t want to deal with the App Store process anymore. And I’m sure that there are many more developers evaluating this very possibility out there; when you have Om Malik or Michael Arrington bashing the iPhone, it sure creates a lot of buzz and uncertainty in the market.
However, and this is my official position, even if I do not agree with the current App Store policies, I’m not quitting the iPhone OS platform anytime soon. I’ll build more applications for the iPhone in the future – heck, I’ve got 2 already approved and 3 more on the approval process pipeline, with at least 3 more in the development phase. My plan, and what this article is about, is about managing the risk represented by Apple in this business. It might be hard, but it’s not impossible, no matter what others say. Continue reading
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
A recent comment by Joe D’Andrea in a previous post reminded me about the importance of removing compiler warnings in Xcode projects. Most importantly, it reminded me of a conversation with a fellow developer a couple of weeks ago, in which he told me that he was surprised to see that my projects compiled all the time without warnings. Not a single one. Nada. And that I took the time to remove them before checking code into source control.
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.
The first iPhone application under the akosma brand has just been published on the App Store:
bluewoki
is a very simple walkie-talkie application, which uses the new GameKit framework available on the iPhone OS 3.0. It is available at the App Store! In English, Spanish and French.
The source code is really simple (around 170 lines of code) and you can get it, as usual, from Github with a BSD license.
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 :))
