ComSubVie's Creative Content » Programmieren

iPhone OS / SDK 3.0

ComSubVie — Wed, 18 Mar 2009 14:55:19 +0000

Nachdem gestern ja das neue iPhone OS vorgestellt wurde, habe ich mir dieses gleich einmal näher angeschaut (allerdings werde ich es nicht so schnell installieren, da die meisten der neuen Features für meine Applikationen jetzt nicht wirklich wesentlich von Bedeutung sind – ich hab zwar schon ein paar Ideen, aber das reicht glaub ich wenn ich das implementiere wenn alles andere schon fertig ist).

Bei der Übersicht der neuen Features wären mir die folgenden Dinge aufgefallen:

Bluetooth Kommunikation zwischen den Geräten
Zugriff auf über das Dock angeschlossene Hardware (ich hab die dazugehörige ExternalAccessory API aber noch nicht wirklich durchblickt)
CoreData (ich werd das zwar nicht so schnell verwenden, aber prinzipiell ist das ganz nett, und könnte möglicherweise das Synchen zwischen iPhone- und Desktop-Applikationen erleichtern bzw. auf einfache Weise auf beiden Seiten die gleichen Datenrepräsentation ermöglichen)
CoreLocation erlaut Turn-by-Turn Anweisungen (allerdings nicht in Google Maps, aber ich vermute dass damit TomTom & Co demnächst im AppStore verfügbar sein wird)
Push notifications (ich glaub zwar nicht das ich die so schnell brauchen werde, aber auf dieser Basis dürfte demnächst eine Meebo-Applikation erscheinen)
Notes Sync (ich verwende zwar mittlerweile Things, aber das ist trotzdem schon lange überfällig)

Eine detaillierte Liste an API Änderungen ist (für Developer) auch verfügbar – die ist wirklich recht lang. Die interessantesten sind dabei:

CoreFoundation: NSPredicate wurde hinzugefügt. Letztens habe ich mich über dessen Fehlen geärgert, weil das Filtern von UITableViews mit NSPredicate einfacher wäre als ohne. Ein entsprechendes Beispiel wird es früher oder später hier im UITableView Tutorial geben (sobald ich dieses erstellt habe).
GameKit ist meiner Meinung nach ein bisschen komisch benannt, weil das nicht nur für Spiele interessant ist:

The GKPeerPickerController class provides a standard user interface to allow a user to connect their iPhone to another user’s iPhone. The user can select between local Bluetooth connections and internet connections.
MapKit erlaubt es Google Maps in eigene Applikationen einzubauen.
UIKit hat einige interessante Erweiterungen erfahren: einige Navigationselemente lassen sich nun leicht transparent schalten.
- UITableView: reloadRowsAtIndexPaths:withRowAnimation:, reloadSectionIndexTitles, reloadSections:withRowAnimation: erlauben es bei Anpassungen an der DataSource nur die relevanten Abschnitte neu zu laden, sodass nicht mehr die ganze UITableView neu geladen werden muss.
- UITableViewCell: hier sind einige der bisher vorhandenen (und zu verwendenden) Properties inzwischen deprecated (so ist statt .text inzwischen .textLabel und .detailTextLabel zu verwenden)

Ansonsten sind mir jetzt für Developer keine wesentlichen Änderungen aufgefallen (zumindest nicht in Bereichen mit denen ich mich inzwischen beschäftigt habe).

Ich bin mir zwar nicht ganz sicher, inwieweit man das überhaupt veröffentlichen darf, da auf der Developer-Seite steht:

iPhone SDK 3.0 and iPhone OS 3.0 beta are pre-release software and are considered Apple Confidential Information. Any information Apple collects is subject to the terms of the Apple privacy policy.

Nav Bar Tutorial (Version 2)

ComSubVie — Fri, 13 Mar 2009 20:56:22 +0000

Das zweite überarbeitete Tutorial beschäftigt sich mit der NavigationBar. Dabei handelt es sich um die Navigationsleiste am oberen Bildschirmrand, mit der man beispielsweise von Detailansichten wieder zur Übersicht zurückkommt, oder beim Bearbeiten von Einträgen die beiden Buttons “Save” und “Cancel” anzeigt.

Die UINavigationBar verwendet dabei eine Art Stack auf dem UIViewController Objekte abgelegt werden. Bei der Initialisierung muss in jedem Fall ein root ViewController angegeben werden. Dies ist jene View, die am Anfang angezeigt wird.

Mit den Methoden pushViewController:animated: sowie popViewControllerAnimated: lassen sich zusätzliche UIViewController im UINavigationController einbinden, wobei die Methode pushViewController:animated: den als Parameter angegebenen UIViewController anzeigt. Zusätzlich wird automatisch ein Back-Button auf der linken Seite der NavigationBar erzeugt, welcher den Titel des vorigen ViewControllers anzeigt. Die Methode popViewControllerAnimated: entfernt den aktuellen ViewController wieder und schaltet auf die vorige Sicht zurück.

Eine View, die in einen UINavigationController eingebunden ist, besitzt die Property navigationItem, über welche sich die angezeigte UINavigationBar modifizieren lässt. So enthält die UINavigationItem Klasse die Properties backBarButtonItem, leftBarButtonItem, rightBarButtonItem sowie title. Über diese Properties lassen sich die entsprechenden Buttons bzw. der Titel der in der Navigationbar angezeigt wird modifizieren.

Genug der Theorie. Um das Ganze zu demonstrieren möchte ich eine Applikation erstellen, die drei Views enthält, zwischen denen man mit der NavigationBar umschalten kann. Die erste View soll nur einen Add und Details-Button anzeigen, über die zur zweiten View umgeschaltet werden kann. Auf der zweiten View soll es einen Zurück-Button geben, der wieder auf die erste View zurückschaltet sowie einen Edit-Button der auf die dritte View umschaltet. Die dritte View soll die beiden Buttons Cancel (zurück zur zweiten View) und Save (ebenfalls zurück zur zweiten View) enthalten.

Wie immer beginne ich mit einem neuen Projekt vom Typ iPhone OS Window-Based Application, welche ich NavBar nenne. Dementsprechend erstellt XCode eine Hauptklasse NavBarAppDelegate.m.

Zusätzlich erstelle ich die drei Klassen für die drei Views. Diese sind ebenfalls wieder vom Typ UIViewController subclass, wobei ich diese wieder First, Second und Third taufe.

Die erste View (First.m) soll den Titel First in der NavigationBar anzeigen (Zeile 9) und zusätzlich auf der rechten Seite einen Add-Button (Zeile 10). Zusätzlich wird ein Button in der View angezeigt, der den Titel Details trägt (Zeilen 12-21). Beide Buttons werden mit der Methode buttonPressed verbunden (Zeile 10 und 17). Die Methode buttonPressed initialisiert die nächste View (also Second, Zeile 25) und zeigt diese über den ViewController an (Zeile 27).

First.m:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#import "First.h"
#import "Second.h"

@implementation First

- (void)loadView {
[super loadView];

self.navigationItem.title = @"First";
self.navigationItem.rightBarButtonItem = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemAdd target:self action:@selector(buttonPressed:)];

UIView *tempView = [[UIView alloc] initWithFrame:CGRectMake(0.0, 0.0, 320.0, 480.0)];

UIButton *button = [UIButton buttonWithType:UIButtonTypeRoundedRect];
button.frame = CGRectMake(10.0, 10.0, 300.0, 50.0);
[button setTitle:@"Details" forState:UIControlStateNormal];
[button addTarget:self action:@selector(buttonPressed:) forControlEvents:UIControlEventTouchUpInside];
[tempView addSubview:button];

[self setView:tempView];
[tempView release];
}

- (void)buttonPressed:(id)sender {
Second *second = [[[Second alloc] initWithNibName:nil bundle:nil] autorelease];

[self.navigationController pushViewController:second animated:YES];
}

@end

Die zweite View enthält durch das laden automatisch einen Back-Button auf der rechten Seite der NavigationBar. Zusätzlich muss ein Edit-Button auf der rechten Seite hinzugefügt werden (Zeile 10) und der Titel auf Second gesetzt werden (Zeile 9). Wenn der Back-Button gedrückt wird, schaltet der NavigationController automatisch auf die vorige View zurück. Bei Benutzung des Edit-Buttons (Zeile 8 ) muss äquivalent zur vorigen View eine neue Instanz der nächsten View erzeugt und auf diese umgeschaltet werden (Zeilen 14-16).

Second.m:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#import "Second.h"
#import "Third.h"

@implementation Second

- (void)loadView {
[super loadView];

self.navigationItem.title = @"Second";
self.navigationItem.rightBarButtonItem = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemEdit target:self action:@selector(buttonPressed:)];
}

- (void)buttonPressed:(id)sender {
Third *third = [[[Third alloc] initWithNibName:nil bundle:nil] autorelease];

[self.navigationController pushViewController:third animated:YES];
}

@end

Die letzte View besitzt den Titel Third (Zeile 8 ) sowie zwei Buttons in der Navigationbar (Cancel, Zeile 9 sowie Save, Zeile 10). Beide Buttons lösen einen Rücksprung zur vorigen View aus (Zeile 14):

Third.m:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#import "Third.h"

@implementation Third

- (void)loadView {
[super loadView];

self.navigationItem.title = @"Third";
self.navigationItem.leftBarButtonItem = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemCancel target:self action:@selector(buttonPressed:)];
self.navigationItem.rightBarButtonItem = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemSave target:self action:@selector(buttonPressed:)];
}

- (void)buttonPressed:(id)sender {
[self.navigationController popViewControllerAnimated:YES];
}

@end

Im Hauptprogramm (NavBarAppDelegate) muss nun eine Instanz der ersten View (der Root View) erstellt werden (Zeile 11) und ein UINavigationController mit dieser initialisiert werden (Zeile 12). Anschließend wird der Navigation Controller als View der Applikation aktiviert (Zeile 14).

NavBarAppDelegate.m:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#import "NavBarAppDelegate.h"
#import "First.h"

@implementation NavBarAppDelegate

@synthesize window;

UINavigationController *navController;

- (void)applicationDidFinishLaunching:(UIApplication *)application {
First *firstView = [[First alloc] initWithNibName:nil bundle:nil];
navController = [[UINavigationController alloc] initWithRootViewController:firstView];

[window addSubview:[navController view]];

[window makeKeyAndVisible];
}

- (void)dealloc {
[window release];
[navController release];

[super dealloc];
}

@end

Auch hier erspare ich es mir das ganze Projekt als Source hochzuladen, da auch dieses noch recht trivial ist. Die nächsten geplanten Tutorials sind: Kombination UITabBar mit UINavigationBar, UITableView sowie Delegation. Sowie eventuell etwas über Cocoa-Memorymanagement. Mal schauen…

Tab Bar Tutorial (Version 2)

ComSubVie — Wed, 11 Mar 2009 22:26:52 +0000

Nachdem ich ja bereits geschrieben habe, dass ich inzwischen vom Interface Builder abgekommen bin (zumindest Großteils; um eine View zu entwerfen und die Daten dann im Code zu übernehmen ist der IB durchaus ganz brauchbar) beginne ich mal mit der ersten Anleitung ohne den IB.

Wie bereits zuvor beginne ich mit einer TabBar Applikation. Dabei soll einfach eine Applikation entstehen, die 2 verschiedene Views enthält, zwischen denen man mit Hilfe einer TabBar umschalten kann. Das grundsätzliche Vorgehen bei der Projekterstellung bleibt dabei gleich, d.h. zuerst wird ein neues Projekt vom Typ iPhone OS Window-Based Application erstellt. Da ich die Applikation TabBar genannt habe, erzeugt XCode eine Hauptklasse TabBarAppDelegate.m.

Zusätzlich dazu erstelle ich zwei weitere Klassen, für jede View eine eigene Klasse, die vom Typ UIViewController subclass sind, und die ich sinnvollerweise First.m sowie Second.m nenne. In jeder dieser beiden Views erstelle ich in der Methode loadView ein Label, welches den Text “First View” bzw. “Second View” anzeigen soll. Diese beiden Klassen sind eigentlich selbsterklärend und sehen wie folgt aus (die Header-Dateien First.h und Second.h habe ich dabei nicht modifiziert):

First.m:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#import "First.h"

@implementation First

- (void)loadView {
[super loadView];

UILabel *label = [[UILabel alloc] initWithFrame:CGRectMake(0.0, 0.0, 320.0, 480.0)];
label.textAlignment = UITextAlignmentCenter;
label.text = @"First View";

[self setView:label];

[label release];
}

@end

Second.m:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#import "Second.h"

@implementation Second

- (void)loadView {
[super loadView];

UILabel *label = [[UILabel alloc] initWithFrame:CGRectMake(0.0, 0.0, 320.0, 480.0)];
label.textAlignment = UITextAlignmentCenter;
label.text = @"Second View";

[self setView:label];

[label release];
}

@end

Im Hauptprogramm, d.h. in der TabBarAppDelegate erstelle ich von jedem der beiden ViewController First und Second eine neue Instanz (Zeile 13 und 14). Ein ViewController besitzt die Property tabBarItem, bei der man den Titel angeben kann (.title), der auf dem zugehörigen Tab dargestellt werden soll, sowie auch ein dazugehöriges Icon (.image). Die beiden Tabs werden hier ebenfalls mit “First” und “Second” tituliert (Zeile 16 und 17). Anschließend wird ein neuer UITabBarController erstellt (Zeile 19) sowie mitgeteilt welche Views (bzw. Tabs) er darstellen soll (Zeile 20). Letztendlich wird dem aktuellen Window der Applikation der UITabBarController als Subview gesetzt (Zeile 22).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

#import "TabBarAppDelegate.h"

#import "First.h"
#import "Second.h"

@implementation TabBarAppDelegate

@synthesize window;

UITabBarController *tabBarController;

- (void)applicationDidFinishLaunching:(UIApplication *)application {
First *firstViewController = [[First alloc] initWithNibName:nil bundle:nil];
Second *secondViewController = [[Second alloc] initWithNibName:nil bundle:nil];

firstViewController.tabBarItem.title = @"First";
secondViewController.tabBarItem.title = @"Second";

tabBarController = [[UITabBarController alloc] init];
tabBarController.viewControllers = [NSArray arrayWithObjects:firstViewController, secondViewController, nil];

[window addSubview:[tabBarController view]];

[firstViewController release];
[secondViewController release];

[window makeKeyAndVisible];
}

- (void)dealloc {
[tabBarController release];

[window release];
[super dealloc];
}

@end

Und das war schon die ganze Hexerei. Irgendwie weitaus einfacher und schneller als mit dem Interface Builder, und außerdem weiß man so in etwa was dabei passiert. Da das ganze so trivial ist halte ich es nicht für notwendig ein Archiv des Projektes zum Download zur Verfügung zu stellen, ich kann es bei Bedarf aber durchaus gerne weitergeben.

Slow Blogging Days

ComSubVie — Thu, 05 Mar 2009 08:40:58 +0000

Ich hab gerade auf Rebel Science News gelesen:

I am intensely involved in a programming project and I am finding it hard to change my focus to other matters. As a result, my blogging activities will be less frequent. Please bear with me.

Das kann ich nur unterschreiben. Aber mein Programm macht durchaus Fortschritte. Außerdem sollte ich jetzt demnächst neue iPhone-HowTo’s (ohne Interface Builder) posten, aber im Moment bin ich eher mim programmieren beschäftigt (und Diplomarbeit sollt ich wohl auch irgendwann mal machen).

iPhone Development: Current Status

ComSubVie — Sun, 01 Mar 2009 22:18:14 +0000

Nachdem ich ja letztens 2 kurze Tutorials geschrieben habe, bin ich dann irgendwann draufgekommen, das das ganze dann doch nicht so einfach ist. Da ich ja nach wie vor damit beschäftigt bin, meine FlightLog-Applikation zu schreiben, musste ich feststellen, dass das mit dem Interface Builder irgendwie nicht immer so hinhaut wie man es erwarten sollte. Daher verwende ich diesen nur noch in seltenen Fällen.

Demzufolge wird es demnächst auch ein neues HowTo geben, wie man Tab Bar + Navigation Bar + TableView + SQLite verwendet, um was-auch-immer zu machen. Allerdings wird dies wohl noch ein Zeiterl dauern… (und irgendwie sollte ich nebenbei auch noch schauen, das meine Diplomarbeit fertig wird).

Hier dennoch 2 Screenshots vom aktuellen Status meiner Applikation (die Daten kommen bereits aus einer SQLite Datenbank):

iPhone Development: Nav Bar Mini HowTo

ComSubVie — Sat, 28 Feb 2009 12:49:27 +0000

Nachdem sich das letzte Mini HowTo it dem “Root”-Navigationselement, der Tab Bar beschäftigt hat, will ich hier die Verwendung der Navigation Bar zeigen. Wenn keine Tab Bar verwendet wird, dann kann die Navigation Bar das “höchste” Navigationselement der Anwendung sein, ansonsten muss es in ein View der Tab Bar eingebaut werden.

Beispiele für die Navigation Bar finden sich in vielen Applikationen, so wird dies zum Beispiel bei den Kontakten verwendet, um einen neuen Kontakt anzulegen, oder um von einem Kontakt wieder auf die Kontaktliste zurückzukommen.

Wie bereits zuvor erwähnt verwende ich für sämtliche Applikationen die Window-Based Application als Vorlage. Äquivalent zur Anwendung der Tab Bar wird die Datei MainWindow.xib im Interface Builder geöffnet und ein Navigation Controller in das Fenster gezogen. Das Resultat sollte dann wie folgt aussehen:

Anschließend wird dieser Controller im AppDelegate in XCode wieder als IBOutlet hinzugefügt:

TutorialNavigationBarAppDelegate.h:

1
2
3
4
5
6
7
8
9
10
11

#import

@interface TutorialNavigationBarAppDelegate : NSObject {
UIWindow *window;
UINavigationController *navController; // LINE ADDED
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet UINavigationController *navController; // LINE ADDED

@end

TutorialNavigationBarAppDelegate.m:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

#import "TutorialNavigationBarAppDelegate.h"

@implementation TutorialNavigationBarAppDelegate

@synthesize window;
@synthesize navController; // LINE ADDED

- (void)applicationDidFinishLaunching:(UIApplication *)application {
[window addSubview:[navController view]]; // LINE ADDED

// Override point for customization after application launch
[window makeKeyAndVisible];
}

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

@end

Im Anschluss werden die Outlets im Interface Builder verbunden, d.h. der Navigation Controller wird rechts angeklickt und der Kreis des “New Referencing Outlet” auf das Tutorial Navigation Bar App Delegate gezogen. Das Resultat sollte dann wie folgt aussehen:

Die Applikation sollte jetzt bereits laufen und eine leere View mit einer Navigation Bar anzeigen:

Um die Navigation Bar vernünftig verwenden zu können, wird einerseits ein Eingabe-Element benötigt, mit dem auf eine andere View umgeschaltet werden kann, andererseits auch noch diese View, auf die umgeschaltet werden soll.

Im XCode erstelle ich daher eine neue Datei vom Typ “User Interfaces” “View XIB”, die ich View2.xib taufe.

Diese Datei wird nun mit dem Interface Builder geöffnet. Damit diese hier auch der richtigen Größe entspricht, kann man über “View Attributes” als Top Bar eine Navigation Bar simulieren.

Diese View bekommt ein Label, welches ich “displayText” taufe, damit man zumindest irgendetwas erkennen kann.

Weiters muss für diese View auch wieder ein View Controller erstellt werden. Dazu erstellt man im XCode eine neue Datei vom Typ “UIViewController subclass”, die ich View2ViewController taufe.

In diesen beiden Dateien erstelle ich ein IBOutlet für das Label, damit man den Text auch modifizieren kann. Die beiden Dateien sehen danach wie folgt aus:

View2ViewController.h:

1
2
3
4
5
6
7
8
9

#import

@interface View2ViewController : UIViewController {
UILabel *displayText; // LINE ADDED
}

@property (nonatomic, retain) IBOutlet UILabel *displayText; // LINE ADDED

@end

View2ViewController.m:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#import "View2ViewController.h"

@implementation View2ViewController

@synthesize displayText; // LINE ADDED

/*
// Implement viewDidLoad to do additional setup after loading the view, typically from a nib.
- (void)viewDidLoad {
[super viewDidLoad];
}
*/

- (void)didReceiveMemoryWarning {
[super didReceiveMemoryWarning]; // Releases the view if it doesn't have a superview
// Release anything that's not essential, such as cached data
}

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

@end

View Controller und View müssen im Interface Builder wieder miteinander verbunden werden. Als Class für den “File’s Owner” verwendet man den eben erstellten View2ViewController:

Und das “New Referencing Outlet” des displayText Labels mit dem displayText Attribut des “File’s Owner”. Das Resultat sollte dann wie folgt aussehen:

Außerdem muss noch das View Attribut des “File’s Owner” mit der View verbunden werden. Dazu wird der “File’s Owner” rechts angeklickt, und der Kreis neben “view” auf die View gezogen. Das Ergebnis sollte so aussehen:

Die Umschaltung auf diese View muss nun irgendwie ausgelöst werden, daher füge ich in der MainWindow.xib einen Button hinzu (im Normalfall wird dies vermutlich eher aus einer TableView geschehen), den ich detailsButton taufe. Das sieht im Interface Builder dann wie folgt aus:

Wie man an diesem Bild erkennen kann, wird die View durch den Button ersetzt. Wenn man eine eigene View einsetzen will (was ich durchaus als sinnvoll erachte), so sollte man dem View Controller hier eine eigene XIB Datei angeben (allerdings bin ich mir nicht ganz sicher ob das funktioniert, weil es beim Tab Bar Controller ja nicht geklappt hat).

Anschließend füge ich die Outlets und die Action im AppDelegate ein (eine eigene View hätte hier den Vorteil, das die App Delegate nicht so überfüllt ist). Zustätzlich muss auch die neue View hier eingetragen werden. Die neuen App Delegate Dateien sehen dann so aus:

TutorialNavBarAppDelegate.h:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#import

#import "View2ViewController.h"

@interface TutorialNavigationBarAppDelegate : NSObject {
UIWindow *window;
UINavigationController *navController;

UIButton *detailsButton; // LINE ADDED

View2ViewController *view2Controller; // LINE ADDED
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet UINavigationController *navController;

@property (nonatomic, retain) IBOutlet UIButton *detailsButton; // LINE ADDED

@property (nonatomic, retain) View2ViewController *view2Controller; // LINE ADDED

- (IBAction) buttonPressed:(id)sender; // LINE ADDED

@end

TutorialNavBarAppDelegate.m:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

#import "TutorialNavigationBarAppDelegate.h"

@implementation TutorialNavigationBarAppDelegate

@synthesize window;
@synthesize navController;
@synthesize detailsButton; // LINE ADDED

@synthesize view2Controller; // LINE ADDED

- (IBAction) buttonPressed:(id)sender { // BLOCK ADDED
if ( view2Controller == nil ) {
view2Controller = [[View2ViewController alloc] initWithNibName:@"View2" bundle:nil];
[view2Controller displayText].text = @"Details";
}

[navController pushViewController:view2Controller animated:YES];
}

- (void)applicationDidFinishLaunching:(UIApplication *)application {
[window addSubview:[navController view]];

// Override point for customization after application launch
[window makeKeyAndVisible];
}

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

@end

Die buttonPressed Methode erzeugt eine neue View auf Basis des View2ViewControllers mit der View2 XIB als Resource, wobei der Text des Labels mit “Details” beschriftet wird. Anschließend wird der Navigation Controller aufgefordert, die View entsprechend umzuschalten.

Im Anschluss werden die ganzen Dinge wieder im Interface Builder verbunden, d.h. das “New Referencing Outlet” des detailsButton mit dem Tutorial Nav Bar App Delegate displayButton Attribut und das Touch Down Event des detailsButton mit der buttonPressed Methode des Tutorial Nav Bar App Delegates. Das Resultat ist hier dargestellt:

Das fertige Resultat sollte nun so aussehen:

Falls man einen Add Button einsetzen will, muss man dies in der viewDidLoad Methode des entsprechenden ViewControllers hinzufügen (bei diesem Beispiel funktioniert dies daher nur im View2ViewController, da die Startseite keine eigene View besitzt). Der folgende Code erledigt dies:

1
2
3
4
5
6
7
8
9

- (IBAction) addButtonPressed:(id)sender {
// TODO Add Implementation
}

- (void)viewDidLoad {
self.navigationItem.rightBarButtonItem = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemAdd target:self action:@selector(addButtonPressed:)];

[super viewDidLoad];
}

Hier ist nun wieder der komplette Code des Beispiels: TutorialNavBar (ZIP-Archiv)

iPhone Development: Tab Bar Mini HowTo

ComSubVie — Fri, 27 Feb 2009 22:25:44 +0000

Das Interface des iPhones ist in mehrere verschiedene Komponenten unterteilt. Die Tab Bar ist dabei jene Komponenten, die am unteren Rand des Displays angezeigt wird, und zwischen verschiedenen Darstellungen umschaltet.

Beim Telefon ist dies beispielswiese Favoriten, Anrufliste, Kontakte, Ziffernblock und Voicemail; bei der Uhr Weltuhr, Wecker, Stoppuhr sowie Timer.

Eine Tab Bar ist das “höchste” Navigationselement am iPhone. D.h. wenn eine Tab Bar verwendet werden soll, so sind alle anderen Ansichten dieser untergeordnet. Daher muss bei einer Applikation mit Tab Bar basierter Navigation diese Tab Bar als erstes Element implementiert werden.

Für sämtliche Applikationen am iPhone verwende ich die Window-Based Application als Vorlage. Diese generiert nur eine AppDelegate Klasse für die Anwendung sowie eine MainWindow.xib Datei, die das Interface definiert:

Um eine Tab Bar zu verwenden, wird zuerst die Datei MainWindow.xib im Interface Builder geöffnet und ein Tab Bar Controller in das Fenster gezogen. Das Resultat sieht wie folgt aus:

Anschließend wird im XCode der Controller als IBOutlet hinzugefügt, d.h. die Datei TutorialTabBarAppDelegate.h wie folgt geändert:

1
2
3
4
5
6
7
8
9
10
11

#import

@interface TutorialTabBarAppDelegate : NSObject {
UIWindow *window;
UITabBarController *tabBarController; // LINE ADDED
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet UITabBarController *tabBarController; // LINE ADDED

@end

Anschließend wird der Tab Bar Controller als View der Anwendung initialisiert, d.h. die Datei TutorialTabBarAppDelegate.m wie folgt modifiziert:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

#import "TutorialTabBarAppDelegate.h"

@implementation TutorialTabBarAppDelegate

@synthesize window;
@synthesize tabBarController; // LINE ADDED

- (void)applicationDidFinishLaunching:(UIApplication *)application {
[window addSubview:[tabBarController view]]; // LINE ADDED

// Override point for customization after application launch
[window makeKeyAndVisible];
}

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

@end

Anschließend geht es wieder zurück zum Interface Builder. Hier wird der Tab Bar Controller rechts angeklickt. Daraufhin erscheint ein Popup-Fenster, in dem man den Kreis neben “New Referencing Outlet” auf das Tutorial Tab Bar App Delegate Objekt dragt, wo dann wieder ein Popup mit dem Inhalt “tabBarController” erscheint. Dieser tabBarController entspricht der IBOutlet-Variablen, die wir zuvor gerade angelegt haben. Das Resultat sollte wie folgt aussehen:

Die Applikation sollte jetzt bereits laufen und eine funktionierende Tab Bar darstellen:

Damit die ganze Anwendung überhaupt erst Sinn ergibt müssen für die einzelnen Tabs noch entsprechende Inhalte generiert werden. Dazu wird für jedes Tab eine eigene View angelegt.

Dazu wird im XCode eine neue Datei vom Typ UIViewController subclass angelegt, die den Namen “Tab1ViewController” erhält:

Die dadurch erstellten Dateien lasse ich vorerst unangetastet. Weiterhin wird eine Interface Builder Datei für diesen Controller erstellt, d.h. eine neue Datei vom Typ “View XIB” mit dem Namen “Tab1View” zum Projekt hinzugefügt:

Die Datei Tab1View.xib muss nun mit dem Interface Builder geöffnet werden. Für den “File’s Owner” wird im Identity Inspector als Class das NSObject durch Tab1ViewController ersetzt:

Anschließend muss das “New Referencing Outlet” der View mit dem Attribut view des “File’s Owner” verbunden werden. Dazu dient wieder ein Rechtsklick auf View und ein anschließendes Draggen des Krieses auf “File’s Owner”.

Um die View in der Tutorial-Applikation auch identifizieren zu können, wird ein entsprechendes Label in die View gezogen. Das Resultat sieht im Interface Builder dann so aus:

Das View muss nun noch entsprechend in der Tab Bar eingebunden werden. Die Idee dies direkt im Interface Builder zu machen ist zwar naheliegend und funktioniert auch prinzipiell – zumindest solange bis man dann versucht das Programm auszuführen, dann endet es mit einer Exception. Also muss man doch wieder zum Code greifen. Daher muss die App Delegate wir folgt angepasst werden:

TutorialTabBarAppDelegate.h:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#import

#import "Tab1ViewController.h" // LINE ADDED

@interface TutorialTabBarAppDelegate : NSObject {
UIWindow *window;
UITabBarController *tabBarController;

Tab1ViewController *tab1ViewController; // LINE ADDED
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet UITabBarController *tabBarController;

@property (nonatomic, retain) Tab1ViewController *tab1ViewController;// LINE ADDED

@end

TutorialTabBarAppDelegate.m:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#import "TutorialTabBarAppDelegate.h"

@implementation TutorialTabBarAppDelegate

@synthesize window;
@synthesize tabBarController;

@synthesize tab1ViewController; // LINE ADDED

- (void)applicationDidFinishLaunching:(UIApplication *)application {
tab1ViewController = // LINES ADDED
[[Tab1ViewController alloc] initWithNibName:@"Tab1View" bundle:nil];

[[[[tabBarController viewControllers] objectAtIndex:0] view] addSubview:[tab1ViewController view]];

[window addSubview:[tabBarController view]];

// Override point for customization after application launch
[window makeKeyAndVisible];
}

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

@end

Äquivalent wird ein Tab2ViewController sowie eine Tab2View angelegt sowie im AppDelegate eingebaut. Das fertige Programm sieht dann wie folgt aus:

Der fertige Sourcecode des Programms ist hier als Download verfügbar: TutorialTabBar (ZIP-Archiv)

Viel Erfolg beim Programmieren!

Siftables

ComSubVie — Sun, 15 Feb 2009 19:30:41 +0000

Siftables sind eine Entwicklung des MIT Media Lab. Im Prinzip handelt es sich dabei um Mini-Computer mit eingebautem Bildschirm, die Beschleunigungssensoren beinhalten und erkennen wenn sie sich nahe kommen. Man kann daher auf jedem der Bausteine irgendwelche Informationen darstellen, und durch physikalische Nähe der Bausteine diese miteinander interagieren lassen. Ein entsprechendes Beispiel dafür ist die Generierung der Fibonacci-Sequenz:

Ebenso genial finde ich den Music Sequencer:

Das ganze Projekt wurde (sehr gut) in einer TED Präsentation vorgeführt:

Ich bin mir zwar noch nicht wirklich sicher, ob es für das ganze sinnvolle Anwendungen gibt, aber ich finde es trotzdem ziemlich cool. Ich will sowas haben – auch wenn ich nicht weiß was ich damit machen soll…

Nähere Informationen finden sich im Taco Lab Blog und auf der Homepage.

Programming is hard

ComSubVie — Thu, 12 Feb 2009 19:55:03 +0000

Bei meinen mehr-oder-weniger täglichen Blog-Exkursionen bin ich heute über Jon Skeed: Coding Blog gestolpert (igitt, ASP). Für .net Programmierer sicher sehr lesenswert, für alle anderen nicht so der Bringer. Aber den Artikel Programming is hard fand ich ganz nett:

If your code deals with arbitrary human text, it’s probably broken. (Have you taken the Turkey test recently?)

If your code deals with floating point numbers, it’s probably broken.

If your code deals with concurrency (whether that means database transactions, threading, whatever), it’s probably broken.

If your code deals with dates, times and time zones, it’s probably broken. (Time zones in particular are hideous.)

If your code has a user interface with anything other than a fixed size and a fixed set of labels (no i18n), it’s probably broken.

Teensy AVR & Mac AVR-GCC

ComSubVie — Fri, 30 Jan 2009 09:52:42 +0000

Ich habe gerade ein recht günstiges AVR Starterkit gefunden, das Teensy USB Development Board ($19), welches einen AVR AT90USB162 beinhaltet (ok, ein ATxmega irgendwas wäre mir lieber, aber immerhin), einige I/O Pins beinhaltet und direkt über USB programmiert werden kann (unter allen gängigen Betriebssystemen, inclusive OS X).

Zusätzlich habe ich das AVR MacPack entdeckt, welches im Prinzip nur der AVR GCC für OS X ist. Das ist zumindest für jene Leute interessant, die AVRs programmieren wollen, aber die benötigte Software nicht unbedingt über DarwinPorts installieren wollen. Das MacPack scheint auch regelmäßig aktualisiert zu werden.

Java ist komisch

ComSubVie — Thu, 29 Jan 2009 22:59:58 +0000

Nachdem wir heute am TGM eine kleine Diskussion hatten, wobei der Christoph behauptet hat, dass man in Java zu einem char kein int addieren kann, und ich das einfach nicht glauben konnte, musste ich das gleich mal probieren. Und er hatte fast recht. Beim ersten Versuch gelang es mir nicht, den Fehler zu erzeugen, aber ich habe es dann doch geschafft:

Wenn man (also typischer Java-Programmierer, also nicht schreibfaul) programmiert ist das eigentlich einfach zu erreichen. Der folgende Code liefert beim Kompilieren eine entsprechende Fehlermeldung (possible loss of precision - was ja durchaus nicht falsch ist, wobei das eigentlich nur eine Warnung sein sollte, und kein Fehler, aber da ist Java ja sowieso ein bisschen komisch):

1
2
3
4
5
6
7
8
9
10

public class Test {
public static void main( String args [] ) {
char zeichen = 'a';
int x = 5;

zeichen = zeichen + x;

System.out.println( zeichen );
}
}

Wobei die vom C-Programmierer favorisierte kurze Schreibweise (die auch mein erster Versuch war) problemlos funktioniert und beim Ausführen auch das erwartete Ergebnis zurückliefert:

1
2
3
4
5
6
7
8
9
10

public class Test {
public static void main( String args [] ) {
char zeichen = 'a';
int x = 5;

zeichen += x;

System.out.println( zeichen );
}
}

Eine alternative funktionierende Lösung wäre ein entsprechendes Casten:

1
2
3
4
5
6
7
8
9
10

public class Test {
public static void main( String args [] ) {
char zeichen = 'a';
int x = 5;

zeichen = (char)(zeichen + x);

System.out.println( zeichen );
}
}

Abschließend kann man sagen, dass sich Java da zwar schon ein bisschen seltsam verhält (es bringt zum Beispiel auch nichts nur das x auf char zu casten, man muss das Ergebnis der Addition casten. Aber zumindest funktioniert eine Addition sehr wohl, wobei die Nichtfunktionalität ja eh niemand so wirklich glauben wollte…

Musiker & Programmierer

ComSubVie — Wed, 21 Jan 2009 21:05:52 +0000

Nachdem ich ja doch den einen oder anderen Musiker kenne, der auch programmiert (Hallo Christoph!), und ich meine tägliche Portion Coding Horror lese, ist mir natürlich der Artikel The One Thing Programmers and Musicians Have In Common aufgefallen. Ist jetzt nicht unbedingt ein weltbewegender Artikel, ist auch nicht sonderlich lang – wenn man mal von den Kommentaren absieht, aber für die musikinteressierten Programmierer durchaus einen Blick wert…

A Byte of Vim

ComSubVie — Tue, 20 Jan 2009 19:41:56 +0000

Ich bin gerade auf ein (online) Buch über den Vi(m) gestoßen: A Byte of Vim. Die Kurzbeschreibung des Buches lautet wie folgt:

“A Byte of Vim” is a book which aims to help you to learn how to use the Vim editor (version 7), even if all you know is how to use the computer keyboard.

The first part of this book is meant for new users who want to understand what Vim is and learn how to use it.

The second part of this book is for people who already know how to use Vim and want to learn about features that make Vim so powerful, such as windows and tabs, personal information management, making it a programmer’s editor, how to extend Vim with your own plugins, and more.

Ich bin selber noch nicht zum Lesen gekommen, aber ich denke das es sich in jedem Fall auszahlt. Für Leute die Papier bevorzugen lässt sich das Buch auch in gebundener Form bestellen.

Patente: trim()

ComSubVie — Sat, 17 Jan 2009 10:30:03 +0000

Die spinnen die Amis. Es gibt wieder mal ein neues Patent:

Method of automatically removing leading and trailing space characters from data being entered into a database system

Das ist wohl die klassische trim() Funktion. Patent-Inhaber ist IBM, United States Patent Number 7,475,086. Wobei IBM ja zumindest irgendwann gemeint hat sie würden Software-Patente nicht einklagen (immerhin). Die Kurzbeschreibung:

A computer Implemented method of automatically removing space characters from data being entered into a database system are provided. When a user creates a table in a database system into which data having leading and/or trailing character spaces may be entered, the user may specifically instruct the database system to remove any character spaces before entering the data into the table. Consequently, when a piece of data is being entered into the table, the database system will determine whether the piece of data includes leading and/or trailing character spaces. If so, the database system will automatically remove the character spaces from the piece of data before it is entered into the table. Hence, the use of TRIM functions when retrieving data from the database system will be obviated.

Interessantes Interface: Zero Chance

ComSubVie — Fri, 16 Jan 2009 16:25:34 +0000

Über touchArcade bin ich auf Zero Chance (iTMS-Link) gestoßen (es gibt schon auch viele österreichische iPhone-Entwickler), wobei mir vor allem folgender Absatz ins Auge gestochen hat:

Zero Chance is both a top-down and a 3D third-person game – the orientation of the iPhone or iPod touch determines the perspective.

Das Demo-Video in YouTube demonstriert dies durchaus ansehlich. Ich bin mir zwar noch nicht ganz sicher, wie das eigentlich implementiert wurde, aber ich finde diese Perspektiven-Änderung aufgrund der iPhone-Lage durchaus interessant:

Things I Learned the Hard Way

ComSubVie — Fri, 16 Jan 2009 15:07:58 +0000

Ich weiß nicht mehr genau wie ich eigentlich auf dieses Blog gestoßen bin, aber es enthält ein paar interessante Artikel. Insbesondere die Reihe Things I Learned the Hard Way finde ich nicht unspannend.

Programmierer

Ein Artikel dieser Reihe – Programmers are Tiny Gods – beschäftigt sich mit Programmierern, und wie man mit diesen umgehen sollte.

In Genesis, God creates things in a certain order. Why plants before animals? I dunno. It just seemed right to Him. (Don’t worry, it’s just a metaphor.)

Programmers are the same way. In any programming language, there will be many ways to solve a problem. The right way to do it is a personal decision, made by the programmer, just like in Genesis.

Programmers are the Gods of their tiny worlds. They create something out of nothing. In their command-line universe, they say when it’s sunny and when it rains. And the tiny universe complies.

Ich muss zugeben, dass ich den letzten Satz hier beim ersten Mal anders gelesen habe: And the tiny universe COMPILES. Außerdem will ich da zwei ganz wichtige Verhaltensgrundregeln wiederholen:

So if you’re working with a programmer, you have to treat him or her like a God. You have to pray. You cannot issue edicts. You have to come on bended knee.

if you give a programmer a problem with parameters, they’ll apply every bit of genius they have to solve it in the best possible way. If you tell them how to do it, you’ll suffer the wrath of an angry God.

Designer

Ein anderer Artikel dieser Reihe – What’s Your Suggestion? – beschäftigt sich mit Designern, und warum diese als Teammitglieder umständlich sein können:

If you spent any time in an art-related education, you’ve experienced critique sessions. For the uninitiated, a critique is when you put your hard work on a wall in front of your teacher and peers, and they all rip the living shit out of it.

Critique sessions are rarely about suggesting solutions. In fact, to suggest alternatives would be insulting. It’d be like someone telling Picasso to make all those brush strokes blend in more. Sure, it happens, but it’s not the point. A lot of the criticism in these sessions boils down to “this isn’t working for me. Push harder.”

That’s why most designers make awful team members. It’s why, when the biz dev guy says “this is how our startup is going to make money,” our first inclination is to tear down the idea. We’re in critique mode and that’s just what you do.

Das ist eine interessante Feststellung, die ich zumindest nicht widerlegen kann. Als Lösung schlägt er vor, dass Designer ihre Einstellung ändern müssen:

Fortunately the solution is simple: just force yourself to come up with an alternate solution.

It’s also become a great mental exercise. When I’m tempted to write that piss-all-over-it email, I think to myself, “so what’s the solution I want to see?” If I can’t come up with one, I won’t send the email. Better to be quiet and see how things progress than to be the negative blocker guy.

Das ist sicher nicht nur für Designer eine gute Idee, nur im Unterricht vielleicht nicht immer die ideale Lösung.

Java 5 & enums

ComSubVie — Fri, 16 Jan 2009 13:02:35 +0000

Christoph hat mir letztens einen Link geschickt: No, silly! It’s an enum! Ich habe mich dabei beim Lesen königlich amüsiert, das könnte durchaus die reale Entstehungsgeschichte der Java-Enums sein. Kurz zusammengefasst:

JLD#3: So an enum is… a non-instantiable, memberless, final class with subclasses, members and instances?
JLD#2: Yes!
JLD#1: Precisely!
JLD#3: But that’s just a plain old class!
JLD#1: No, silly! It’s an enum!

Java ist zum Teil schon sehr bescheuert…

Programmier-Tipps

ComSubVie — Mon, 12 Jan 2009 17:50:20 +0000

Ich bin auf einen Artikel von Wil Shipley gestoßen: Free Programming Tips are Worth Every Penny. Für diejenigen denen der Name nichts sagt: Wil Shipley ist der Autor einer sehr genialen Software (für Mac): Delicious Library – eine Software mit der ich bisher durchwegs zufrieden bin, und bei der der Preis für die Features mehr als gerechtfertigt ist (insbesondere da es über Apple on Campus einen Studentenrabatt gibt).

Wie auch immer, in dem oben erwähnten Artikel gibt er einige Tipps, wie man Software-Engineering betreiben sollte. In den meisten Fällen kann ich ihm bedenkenlos zustimmen. Jeder der irgendwie mit Programmieren zu tun hat sollte den Artikel lesen, er ist auch zum Teil recht unterhaltsam geschrieben. Dennoch will ich einige Teile davon hier herausnehmen und kommentieren…

* The Way of the Code Samurai *

Now, I don’t actually know much about real samurai, but the basic thing I’ve heard is they stand and stare at each other for hours, and then suddenly BAM strike once and the other guy is down.

That’s how you should code.

Ich finde das ist ein durchaus gelungener Vergleich. Es bedarf zwar ein bisschen einer Erklärung was er damit genau meint, aber ich muss zugeben, dass mich diese Formulierung durchaus amüsiert hat. Gemeint hat er damit:

Think first. Think some more. Think about the whole problem. Think about a little part of the problem you’re going to start with. Think about the whole thing again, in relation to your idea on the starting point.

Jetzt sollte der obige Vergleich klar sein. Viele mögen in diesem Fall durchaus anderer Meinung sein – insbesondere die ganze Agile Development Methodologie sieht ja vor das man einfach zum Programmieren anfangen sollte, und wenn etwas nicht passt kann man es ja ändern, weil Code-Änderungen billig sind. Das mag durchaus sein, aber es ist schon sehr sinnvoll sich zuerst genau zu überlegen was man denn eigentlich Programmieren will, sich einen Algorithmus zu überlegen und vor allem zu verstehen was man erreichen will und wie sich das mit dem Rest des Codes verträgt.

Nicht unwesentlich ist auch – wie auch in dem Artikel aufgeführt wird – dass man verschiedene Features zuerst in einem kleinen Test-Rahmen implementieren sollte, und erst dann in das eigentliche Projekt übernehmen soll – oder besser gleich nochmal neu schreiben.

Write all your code “clean”, the first time you write it. Make classes for everything. Use enumerated types. Don’t take shortcuts. Don’t have any part of the code where you say, “Oh, yah, I just glossed over that for now.” You are NOT going to go back and fix it. Seriously, how often do you say to yourself, “I think I’ll dive into this messy code today and try to make it nice and pretty without adding any functionality?”

Ich habe schon viel Zeit damit verbracht Code “zu reinigen” – zwar auch nur wenn ich neue Funktionalität hinzufügen will, aber oft ist es dabei dazu gekommen, dass ich zuerst grundlegende Funktionalitäten neu implementiert habe. Am Ende erreicht man dann zwar viel saubereren – und mitunter auch fehlerfreieren – Code, aber man denkt sich auch oft warum das nicht gleich so geschrieben wurde. In den meisten Fällen war es wenigstens nicht mein eigener Code, aber es gab durchaus auch Momente wo ich den eigenen Code gereinigt habe – oder in manchen Extremfällen gleich ganz neu geschrieben habe.

Don’t gloss over anything. Write every line to be bulletproof. Write every method as if every other method was out to get your code and try to make it crash, and your job was to make sure it wasn’t going to happen in YOUR code. Assume the user is going to hit keys randomly. Assume the network is going to get disconnected. Assume the hardware will fail.

Dazu kann ich eigentlich gar nichts mehr sagen. Amen.

Less source code is better. This is almost always true. The exceptions to this are so rare that every time you think you’ve found one you should REALLY doubt yourself.

Diese Aussage ist definitiv richtig. Durch Test-Driven-Development lassen sich zahlreiche Fällen davon ausschließen (weil man ja nur noch den Code schreibt den man wirklich braucht, und nicht auch noch jenen den man vielleicht mal brauchen könnte), aber grundsätzlich ist ein kurzer Code nie falsch.

Soviel zum Artikel. Aber auch die Kommentare dabei sind mitunter einer Erwähnung würdig:

Thinking first, then doing, is #1. I find it applies to more and more in life. If one gets too finicky, one will surely end up a very sad, lonely Mr. Spock type-of-person, but in many ways this fascist dogma is very good, and extremely healthy – if you want to remain sanely in business for long.

Ich lese gerade “Blink” von Malcolm Gladwell (wenn ich fertig bin wird es sicher auch wieder einen entsprechenden Artikel geben). In Kombination mit der obigen Aussage kam mir dabei der Gedanke, das man mit ausreichend Erfahrung nicht unbedingt immer wirklich viel nachdenken muss, bevor man mit dem Programmieren beginnt. Bei vielen Problemstellungen wird es einfach “BAM” machen, und man weiß genau was man wie tun muss. Wenn man dann noch darüber nachdenkt ist eher zu befürchten, dass es zu einer weniger idealen Lösung kommt.

Der Vergleich gilt durchaus auch beim Design von Software. Wenn man sich ein Design ansieht, und dabei der erste Eindruck “seltsam” (oder etwas äquivalentes) ist – und man bereits ein bisschen Erfahrung hat – dann ist durchaus anzunehmen, dass irgendetwas mit dem Design nicht stimmt.

If Microsoft designed bridges I’d stay the fuck home.

Dieser Kommentar kommt aus der Diskussion, ob Software Engineering wirklich Engineering ist oder nicht. Weil im “herkömmlichen Engineering” muss man wirklich von Anfang an alles bedenken und durchkonstruieren (wie beispielsweise bei einer Brücke), bevor man mit dem Bau beginnt, und dann kann man nichts mehr ändern, und bei der Software kann man auch bedenkenlos anfangen und immer wenn es notwendig ist entsprechende Änderungen durchführen. Dazu habe ich auch einen interessanten Artikel gefunden (Software-Engineering beim NASA Space-Shuttle Projekt – dort ist es wirklich Engineering), den ich bei Gelegenheit kommentieren möchte…

iPhone Development unter PowerPC

ComSubVie — Fri, 26 Sep 2008 10:55:21 +0000

Es ist zwar mühsam das iPhone SDK auf einem PowerPC zu installieren, aber es geht. Dazu muss man das SDK herunterladen und die Daten aus dem Disk-Image herauskopieren. Sodann muss man in der Datei iPhone SDK.mpkg/iPhone SDK.dist ein paar Einträge ändern (zu der Datei kommt man über iPhone SDK.mpgk => Paketinhalt zeigen):

Die 3 Funktionen isIntel(), agreedToSLA() sowie SDKPresent() müssen so umgeschrieben werden, dass diese in jedem Fall true zurückgeben. Ist dies geschehen, so lässt sich das SDK mit der Datei iPhone SDK.mpkg installieren.

Nach der Installation funktioniert das SDK zwar prinzipiell, jedoch muss man noch den Simulator dazu bringen, den PowerPC als unterstützte Plattform zu akzeptieren. Dazu muss die Datei /Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/Specifications/iPhone Simulator Architectures.xcspec um die RealArchitectures ppc (=g3), ppc7400 (=g4), ppc970 (=g5) und/oder ppc64 (=g5 64bit) erweitert werden. Zusätzlich müssen für diese Architekturen noch die entsprechenden Konfigurationsblöcke geschrieben oder aus der Datei /Developer/Platforms/MacOSX.platform/Developer/Library/Xcode/Specifications/MacOSX Architectures.xcspec übernommen werden. Dieser Vorgang wurde auch von Tom Bradford in seinem Blog beschrieben: iPhone SDK Beta 2 PPC Fix.

Ist dies erledigt, so kann man entsprechende Applikationen entwickeln und am Simulator testen. Sollen die Applikationen jedoch wirklich auf das iPhone übertragen werden, so müssen zuerst einmal entsprechend Münzen bei Apple eingeworfen werden (d.h. man muss sich für 99$ als iPhone Developer registrieren lassen). Danach kann man über den Apple-Developer-Account entsprechende Zertifikate für sich und seine Applikationen erstellen.

Wenn man den Anweisungen aus dem Developer-Portal folgt, so kann man mit den entsprechenden Zertifikaten theoretisch die Applikation erstellen und auf das iPhone übertragen. Allerdings schlägt aus irgendwelchen unerfindlichen Gründen dir Signaturprozess fehl. Dieses “Feature” lässt sich jedoch durch einen seltsamen Umweg lösen: das erzeugte Object File (ein Thin Binary) muss in ein Universal Binary umgewandelt werden. Das Universal Binary kann dann signiert werden, und anschließend wieder in ein Thin Binary rückgewandelt werden. Ich weiß weder wieso das funktioniert noch wie man auf sowas kommt, aber es ist in den Apple Diskussionsforen beschrieben worden: iPhone SDK CodeSign Error. Wenn man mit Projektverzeichnissen arbeitet, die Leerzeichen enthalten, so muss das oben erwähnte Script wie im gleichen Thread erklärt erweitert werden.

Anschließend sollte der Entwicklung, Übertragung und Veröffentlichung von iPhone Programmen nichts mehr im Wege stehen. Mir ist es jedenfalls auf diese Art gelungen eine kleine Anwendung auf mein iPhone zu übertragen.

EJB Again

ComSubVie — Wed, 21 May 2008 11:30:33 +0000

Ich habe wieder einmal feststellen müssen, das man wahrhaftig viel Zeit mit Enterprise JavaBeans verscheißen kann. Ich hab mir nur eine kleine TestBean gebaut (inzwischen ist es schon ein bisschen mehr), die einen Kunden persistieren soll, bzw. aktualisieren falls dieser schon existiert. Der erste Versuch war wie folgt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public Long addCustomer( String userName, String password, String firstName, String lastName, String emailAddress )
{
Customer customer = new Customer( userName, password, firstName, lastName, emailAddress );

try {
entityManager.persist( customer );
} catch ( EntityExistsException eee ) {
String sQuery = "select c from " + Customer.class.getSimpleName() + " c where c.userName = :userName";
Query cQuery = entityManager.createQuery( sQuery );
cQuery.setParameter( "userName", userName );
customer = (Customer) cQuery.getSingleResult();
}
return customer.getId();
}

Damit bekam ich aber dauernd eine Invalid Transaction Exception (ich hab mir nicht gemerkt wie die blöde Exception genau geheißen hat), wenn der Kunde bereits persistent ist.

Das Problem ist, dass eine EntityExistsException die aktuelle Transaction zum rollbacken markiert, und diese daher nicht mehr gültig ist. Wenn man das Ganze umdreht funktioniert’s auf wundersame Weise auf einmal:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public Long addCustomer( String userName, String password, String firstName, String lastName, String emailAddress )
{
Customer customer;

try {
String sQuery = "select c from " + Customer.class.getSimpleName() + " c where c.userName = :userName";
Query cQuery = entityManager.createQuery( sQuery );
cQuery.setParameter( "userName", userName );
customer = (Customer) cQuery.getSingleResult();

/* update fields*/
entityManager.merge( customer );
} catch( NoResultException nre ) {
customer = new Customer( userName, password, firstName, lastName, emailAddress );
entityManager.persist( customer );
}
return customer.getId();
}