//dennisbloete

Es ist soweit und ZENDOME – ein Kundenprojekt an dem ich in letzter Zeit gearbeitet habe – ist nun kostenlos im App Store erhältlich. Die Applikation wurde im Auftrag der ZENDOME GmbH entwickelt und ermöglicht die Planung von individuellen Event-Landschaften, die beispielsweise auf Messen oder für Ausstellungen verwendet werden. Der Benutzer hat die Möglichkeit, die verschiedenen geodätischen Dome zur ZENDOME.domescapes zu kombinieren und damit seine Veranstaltung vorzudenken. Ist eine Planung erstellt lässt sich schnell und unkompliziert ein Angebot anfordern.

Besonderer Wert wurde auf eine intuitive Benutzung der Anwendung gelegt. Um dies zu erreichen wurde auf die aus dem allgemeinen iPhone-Kontext bekannte Gesten und Aktionen (bspw. Pinch/Zoom, Drag and Drop, Scrolling, etc. ) zurückgegriffen und einfache Interaktionsmuster benutzt. Es gibt bereits Erweiterungspläne für kommende Versionen: So ist insbesondere eine iPad-Variante angedacht, da die größere Bildschirmfläche natürlich mehr Platz für eine komfortable und detailreiche Planung bietet. Noch etwas zum technischen Hintergrund: Das Projekt wurde mit Xcode und CocoaTouch-Standardtechnologien wie UIKit, CoreGraphics und CoreAnimation innerhalb von vier Wochen realisiert und hatte insgesamt einen Arbeitsaufwand von ca. 40 Stunden. Weitere Projektdetails und Informationen plane ich in naher Zukunft in einer kurzen Fallstudie zu veröffentlichen.

This iPhone tutorial about encapsulating authentication logic in a separate controller was planned as a chapter for an upcoming iPhone Recipes Book, but unfortunately the book got cancelled. As I had written most of it and already finished the example code I thought it might be of interest for some of you and I would like to share it before it gets dusty.

Problem

Most applications that deal with users registered on a backend (like webapps) are likely to verify
the user credentials. This recipe explains how to extract the authentication functionality that
handles the workflow of prompting the user for credentials and verifying them at the backend.

Solution

A separate (Modal View) Controller that acts as the apps AuthenticationController and gets called by other controllers. This controller encapsulates the authentication logic so that it is cleanly separated from the rest of the app. The provided code is compatible for all iPhone OS from 2.0 on.

The code for this recipe is available on GitHub and it contains an example app that features authentication with the Twitter API (HTTP Basic Auth, keepin’ it simple) along with explanatory notes in the README.

Working on iOctocat I had to integrate Gravatars. Therefore I wrote an Objective-C GravatarLoader class that I would like to share. You can use it like this:

- (void)viewDidLoad {
   [super viewDidLoad];
   gravatarLoader = [[GravatarLoader alloc] initWithTarget:self andHandle:@selector(setGravatarImage:)];
   [gravatarLoader loadEmail:@"your@email.com" withSize:50];
}

The gravatarLoader needs to be an instance variable of the class that’s using it as it loads the Gravatar asynchronously. You initialize the GravatarLoader with a target object and a selector. The selector works as request handle and gets passed an UIImage when the Gravatar is loaded. After initializing it you can load the image with the email address and the square size.

Download the GravatarLoader source.

Today a new project of mine has been released into the wild: iOctocat – a GitHub app for the iPhone and iPod Touch. It is open source and available on the App Store…

Version 0.7.0 can already be downloaded, 0.8.1 is currently reviewed by Apple. Up to now these features are supported:

• My Private News Feed
• My Activity Feed
• Profile View
• My Repositories
• Repository Details

Version 0.8.1 will also display a list of recent commits on a repository and the commit details. Things like user following and repository watching are in the backlog, some of them require the new GitHub API to implement support therefor first (like the repository watchlist).

I’m still looking for some more beta testers and people who would like to review the app. If you are interested please mail your device UUID to ioctocat@dennisbloete.de. Participation from the developer front is also welcome – feel free to fork, add missing features or report issues

Here’s a short snippet I find myself using often when I have to communicate with web services: Adding an UIActivityIndicatorView to the bar of an UINavigationController, so that users are informed of the ongoing process in the background. Unfortunately you can’t plug this together in Interface Builder, so we have to do it in code.

- (void)viewDidLoad {
   [super viewDidLoad];
   // Add an activity indicator to the navigation bar
   UIBarButtonItem *activityItem = [[UIBarButtonItem alloc] initWithCustomView:activityView];
   self.navigationItem.rightBarButtonItem = activityItem;
   [activityItem release];
}

This requires the activityView to be defined as a property of the view controller and setup in Interface Builder (hidden when stopped).

IBOutlet UIActivityIndicatorView *activityView;

When the communication with the web service start you can simply call

[activityView startAnimating];

Bei neuland beschäftigen wir uns im Rahmen eines Forschungsprojekts aktuell mit Cappuccino. Dabei handelt es sich um ein Open Source Framework zur Erstellung von Webanwendungen, die vom look and feel an Mac OS X Desktop Software angelehnt sind. Vorzeigebeispiel für solche Anwendungen ist die derzeit einzige umfangreichere Anwendung 280 Slides, die von den Cappuccino-Machern 280 North entwickelt wurde.

Cappuccino ist wie SproutCore Teil (und möglicherweise Wegbereiter) eines aktuellen Trends, Webanwendungen stärker an das Aussehen und Verhalten von Desktop-Software anzugleichen. Im Gegensatz zu SproutCore setzt Cappuccino jedoch nicht auf altbekannte Mittel: Anwendungen werden mit Objective-J entwickelt — eine neue Sprache, die das übliche Gespann aus HTML, CSS und JavaScript ersetzt.

Objective-J

Wie der Name schon andeutet: Objective-J orientiert sich sehr stark an Objective-C, genau genommen ist es eine Portierung der Objective-C-Syntax zu JavaScript. Ziel dabei ist es auch, die in Cocoa zur Vefügung stehenden Klassen zu portieren und sie als Cappuccino-Klassen abzubilden (bspw. NSObject -> CPObject, NSView -> CPView). Die Cappuccino-API wird somit also nach dem Vorbild der Cocoa-API entwickelt, es ist jedoch vieles noch nicht portiert (aktueller Versionsstand von Cappuccino ist 0.6).

Aus den Erfahrungen der letzten Tage würde ich sagen, dass man relativ schnell einen Einstieg findet, wenn man sich kopfüber in das Einsteigertutorial stürzt – wer keine Objective-C-Kenntnisse mitbringt sollte sich zunächst die kurze Einführung in Objective-J angucken. Das Entwickeln eigener Anwendungen setzt eine umfangreiche Auseinandersetzung mit der Cappuccino API oder besser noch Cocoa-Vorkenntnisse voraus, da es bislang erst relativ wenig Dokumentation und Beispiele gibt. Vor allem Best Practice-Hinweise zur Umsetzungen fehlen noch und wären in Zukunft hilfreich. In den nächsten Tagen werde ich versuchen, immer mal wieder stückweise einzelne Erfahrungen, die wir im Forschungsprojekt machen zu posten und näher darauf einzugehen.

Bis dahin viel Spaß beim Experimentieren! Erfahrungsaustausch – gerne auch zu SproutCore – wäre super!

Weiterführendes

• Objective-J Referenz
• Objective-J Plugin für XCode
• nib2cib: Ein Tool, um Interface Builder Dateien in von Cappuccino darstellbare CIBs umzuwandeln (aktuell aber noch sehr früher Entwicklungsstand)
• Tutorial zum Übertragen von Daten aus einer Rails-Anwendung an Cappuccino

Wer etwas mehr zu den Hintergründen erfahren möchte, der kann sich die folgenden beiden Interview-Podcasts von Ajaxian anhören: Der eine zu Cappuccino und Objective-J, der andere zu SproutCore. Die Podcasts sind beide ca. 15 Minuten lang und gehen auch etwas auf die unterschiedlichen Ansätze der beiden Frameworks ein.

Wer bislang noch keine Erfahrung mit Cocoa/Objective-C mitbringt kann sich auch etwas im Mac Dev Center umsehen. Dort findet man einige nützliche Ressourcen zur Entwicklung mit Objective-C, beispielsweise The Objective-C 2.0 Programming Language oder den Cocoa Fundamentals Guide.

Die Stanford Universität bietet dieses Semester zum ersten Mal einen iPhone-Dev-Kurs an und stellt die Folien im Netz zur Verfügung. Das ist zwar nicht genau unser Thema, aber insbesondere die ersten Lectures behandeln Objective-C und sind gut um schnell einen Überblick zu bekommen:

• Objective-C und wichtige Klassen
• Eigene Objekte und Klassen
• View Fundamentals: Was sind Frames, Bounds, Rects, Points, etc.?

Die letzte Zeit über habe ich mich mehr oder weniger intensiv bemüht, einen Einstieg in die Objective-C und Cocoa Welt zu finden. Die ersten Kapitel des Hillegass Buch waren schnell durchgearbeitet und ich würde sagen, dass sich das Buch gut für Einsteiger eignet, da es neben der theoretischen Einführung auch immer wieder kleine Hands-On Beispiele gibt. Etwas ungewohnt ist das alles schon, wenn man aus der Ruby-Ecke kommt, aber durch meinen kurzen Abstecher Richtung Smalltalk ist Objective-C dann doch gar nicht so fremd und schwer zu lernen wie anfangs gedacht.

Etwas leichter fällt das Lernen allerdings, wenn man bereits Bekanntes relativ einfach übertragen kann. So verhält es sich in diesem Fall mit MacRuby. MacRuby erschien kürzlich in der Version 0.3 und ist im Gegensatz zu RubyCocoa eine OS X-native Implementierung der Brücke zwischen Ruby und Cocoa. Vor ein paar Tagen fand ich im Mac Dev Center einen sehr guten Einführungsartikel zur Entwicklung von Cocoa Anwendungen mit MacRuby, den ich jedem der sich mal etwas mit Cocoa befassen will empfehle. MacRuby ist schnell installiert und den Artikel durchzugehen dauert vielleicht 45 Minuten. Das gibt einem zumindest einen schnellen Einblick und mit Sicherheit die Erkenntnis, dass der Interface Builder eine sehr geniales Tool ist

Trotz mangelnder Zeit wegen Umzug ist das Hillegass Buch jetzt doch wieder auf meinem Schreibtisch gelandet, weil ich mir fest vorgenommen habe, die nächsten Tage doch noch etwas mehr mit Cocoa zu experimentieren – nichtzuletzt weil grade der Interface Builder eben sehr viel Spaß macht. Das erinnert mich ein wenig an damalige Zeiten der Anwendungsentwicklung mit Flash und ActionScript…