Seminararbeit: iphone Entwicklung von 0 auf 100. Von Philipp Koulen

Transkript

1 Seminararbeit: iphone Entwicklung von 0 auf 100 Erstbetreuer: Zweitbetreuer: Prof. Dr. Walter Hillen Jonathan Diehl Von Philipp Koulen

2

3 Inhaltsverzeichnis Einführung...4 Ziel und Grobe Themenübersicht...4 Die Apple Entwickler Programme...4 Wodrin unterscheiden sich diese und gibt es Gemeinsamkeiten?...4 Das Member Center...5 ios / Mac / Safari Developer Center... 5 App Store Resource Center...6 Apple Developer Forum...6 Was ist das ios Provisioning Portal?... 6 Zertifikate...6 Registrierte Geräte... 6 App ID's... 7 Das Development- / Distribution Provisioning Profile...7 Xcode...7 Ein kurzer Überblick...8 AppDelegate xib Dateien...11 ViewController Supporting Files MyHelloWorld mit Interface Builder MyHelloWorld ohne Interface Builder...15 Der Organizer...16 Testen auf einem Endgerät Eine App für den App Store vorbereiten...16 Vorbereitung der Binary...17 itunes Connect Eine App einreichen Literaturnachweis... 20

4 Einführung Ziel und Grobe Themenübersicht Zielgruppe der Seminararbeit sind potenzielle iphone App Entwickler. Zuerst möchte ich allgemein einen Überblick über den Einstieg in die ios Entwicklung vermitteln. Anschließend gehe ich auf die Entwicklungsumgebung sowie den Entwicklungsprozess einer App ein. Zum Abschluss werde ich versuchen zu erklären, wie eine App in den App Store kommt. In diesem Zusammenhang werde ich folgende Themen ansprechen: die verschiedenen Apple Developer Programs das Member Center die Entwicklungsumgebung Xcode Erstellen einer eigene App itunes Connect Die Apple Entwickler Programme[1] Es gibt sechs verschiedene, sogenannte Apple Developer Programs (Entwickler Programme): MFI Program[2] Mac Developer Program[3] Safari Developer Program[4] ios Developer University Program[5] ios Enterprise Program[6] ios Developer Program[7] Wodrin unterscheiden sich diese und gibt es Gemeinsamkeiten? Durch die Teilnahme an einem (oder mehrerer) dieser Programme erhält der Entwickler Zugang zu Ressourcen wie Entwicklungsumgebung, Developer Librarys, Support oder den Apple Developer Foren. Das MFI Program, (Made for iphone Program) ist der Vollständigkeit halber aufgelistet. Teilnehmer dieses Programms sind offiziell dazu berechtigt, elektronisches Zubehör für das ipad, iphone oder den ipod touch zu entwickeln (zb. eine Dockingstation für den ipod). Weiterhin uninteressant für das Entwickeln von iphone Apps sind das Safari Developer Program, sowie das Mac Developer Program. Die Teilnahme am Safari Developer Program ist kostenlos und berechtigt Entwickler offizielle Erweiterungen für Safari zu programmieren und diese anschließend in der Safari Extensions Gallery aufzulisten. Für 99$/Jahr kann sich ein Entwickler für das Mac Developer Program registrieren lassen. Neben Zugang zu den oben genannten Developer Ressourcen kann der Entwickler eigene Mac Apps in dem Mac App Store verbreiten. 30% aller durch den Verkauf erzielter Einnahmen gehen hiervon an Apple. Interessant für die ios Entwickler sind das ios Developer University-, das ios Enterprise- sowie

5 das ios Developer Program. Die Teilnahme am ios Developer University Program ist kostenlos und bietet die Möglichkeit Apps zu entwickeln und diese auf Endgeräten zu testen. Die Verbreitung selbstprogrammierter Apps im App Store ist über dieses Programm nicht möglich. Grundsätzlich kann jeder Student an dem ios Developer University Program teilnehmen, sofern dieser von einem autorisierten Administrator dieses Programms eingeladen worden ist. Jeder Dozent einer offiziellen Hochschule kann sich als solcher registrieren lassen. Das ios Enterprise Program richtet sich speziell an Firmen die ihre eigenen Apps ausschließlich unter ihren Mitarbeitern verbreiten wollen (sogenannte In-House Apps). Teilnehmen kann jede Firma die über eine offizielle DUNS Nummer verfügt (DUNS = Data Universal Numbering System, ein neunstelliger Zahlenschlüssel der zu weltweiten Identifizierung eines Unternehmens dient). Die Kosten für die Teilnahme an diesem Programm liegen bei 299$ (ca. 230 ) pro Jahr. Mit dem Ziel vor Augen, eine eigene App über den App Store zu verbreiten ist das ios Developer Program für uns das interessanteste. Teilnehmen an diesem Programm kann jeder Entwickler, der bereit ist, die Jährlichen Kosten von 99$ (79 ) zu Bezahlen. Nach dem erfolgreichen Enrollment Process (Registrierungsvorgang), erhält der Entwickler Zugang zum Member Center. Dort finden sich alle nötigen Ressourcen und Informationen, die zur Entwicklung und Verbreitung einer App benötigt werden. Das Member Center Sobald sich der Entwickler für eines der verschiedenen Programme entschieden hat und der Registrierungsvorgang erfolgreich abgeschlossen ist, kann sich der Entwickler mit seiner Apple ID als auf im sogenannten Member Center[8] anmelden. Das Member Center bietet eine Übersicht der Verschiedenen Resourcen, auf die ein Entwickler Zugriff hat. Ich werde nur auf das Member Center entsprechend dem ios Developer Program eingehen. Das Member Center bietet Zugang zu ios / Mac / Safari Developer Center[9] ios Provisioning Portal[10] App Store Resource Center[11] itunes Connect[12] Apple Developer Forum[13] Technischer Support[14] ios / Mac / Safari Developer Center Im Developer Center finden sich alle Grundlagen zur Entwicklung von ios Apps: Ein Download Link der Entwicklungsumgebung Xcode, die ios Developer Library, verschiedene Getting Started Texte und Videos, Guides sowie Beispielcodes uvm. Hier fängt für einen ios Entwickler alles an.

6 App Store Resource Center Das App Store Resource Center wird für den Entwickler interessant, sobald es für seine App in die Endphase geht. Was muss der Entwickler vor dem Einreichen der App an Apple beachten? Wie funktioniert der Approval Prozess? Über welche zusätzlichen Informationen muss der Entwickler Apple in Kenntnis setzen, damit die App die Tests der Apple Techniker besteht? Befolgt die App alle von Apple festgelegten Vorschriften? Das alles sind wichtige Fragen, über die sich der Entwickler vor dem Einreichen seiner App Gedanken machen muss. Antworten findet er hier. Apple Developer Forum Als Teilnehmer des ios Developer Programs erhält der Entwickler im Member Center Zugang zum Apple Developer Forum. Hier können technische Fragen direkt mit anderen Entwicklern oder sogar Apple Fachleuten diskutiert werden. Neben dem Developer Center ist das Developer Forum eine für Entwickler sehr wichtige Informationsquelle. Technischer Support Teilnehmer des ios Developer Programms dürfen Apple Technikern pro Jahr zwei Fragen stellen. Dieses können Fragen über spezielle Algorithmen, Fehlerbehebungen oder das Design sein. Zwei weitere Fragen lässt sich Apple für 79 in Rechnung stellen, 5 weitere Fragen kosten 199 [15]. Was ist das ios Provisioning Portal? Ebenfalls im Member Center zu finden ist das ios Provisioning Portal. Um eine selbstgeschriebene App auf einem iphone, ipod Touch oder ipad testen zu können müssen zuerst verschiedene Schritte durchgeführt werden. Dies erfolgt über das ios Provisioning Portal. Verwaltet werden können hier: Zertifikate[16] Registrierte Geräte zum testen[17] App ID's[18] Provisioning Profiles[19] Distribution Profiles[20] Zertifikate Zuerst wird der Entwickler aufgefordert das WWDR (Worldwide Developer Relations intermediate Certificate) herunter zu laden. Wird es vom Entwickler nicht installiert, kann dieser keine Apps auf seinem Endgerät testen. Xcode überprüft mit Hilfe dieses Zertifikates die Gültigkeit der Development- sowie die der Distribution Profiles. Das Development Profile signiert Apps für das Testen auf einem oder mehreren Endgeräten, wohingegen das Distribution Profile für die Verbreitung von Apps im App Store benötigt wird.

7 Registrierte Geräte Unter dem Reiter Devices werden alle registrierten Testgeräte aufgelistet. Über Add Device lässt sich bequem ein neues Testgerät hinzufügen. Hierzu wird lediglich ein Name und die Device ID benötigt. Der Name lässt sich frei wählen, die passende Device ID wird im Organizer angezeigt. Über jeden Entwickler Account lassen sich bis zu 100 verschiedene Geräte zum testen registrieren. App ID's Im allgemeinen dient die App ID zur Identifikation einer jeden App. Eine App ID besteht aus zwei Teilen: Dem App ID Prefix und dem App ID Suffix. Das App ID Prefix, oder auch Bundle Seed ID, ist ein einzigartiger, zehn Zeichen langer String, der bequem über Xcode erstellt und für mehrere Apps verwendet werden kann. Diese könnte folgendermaßen aussehen: MB844ANK5L Der App ID Suffix, oder auch Bundle Identifier, ist ebenfalls ein einzigartiger String, dessen Form jedoch frei wählbar ist. Von Apple wird folgendes Format vorgeschlagen: com.domainname.appname Will ich zum Beispiel eine App ID für eine App mit dem Namen MyHelloWorld für die Firma MyFirstCompany erstellen, könnte diese Folgendermaßen aussehen: MB844ANK5L.com.MyFirstCompany. MyHelloWorld Es ist möglich den Bundle Identifier durch ein * zu ersetzen, dadurch können mehrere Apps mit ein und derselben Bundle Seed ID auf verschiedenen Endgeräten installiert werden. Da einmal angelegte App ID's niemals gelöscht werden können, macht es zum Testen Sinn, die von Xcode automatisch erstellten Profile zu verwenden. Das Development- / Distribution Provisioning Profile Zum installieren einer App auf einem Endgerät muss ein sogenanntes Provisioning Profile auf diesem installiert sein. Dieses setzt sich zusammen aus einem Namen, dem Development- bzw. dem Distribution Zertifikat, der passenden App ID und es kann festgelegt werden auf welchen der registrierten Endgeräte die jeweilige App installiert werden darf. Nachdem ein Provisioning Profile erstellt worden ist, kann dieses heruntergeladen werden und per Drag & Drop in Xcode eingefügt werden werden (auf das Xcode Icon im Dock ziehen). Mithilfe des Organizers kann es anschließend auf dem passenden Endgerät(en) installiert werden.

8 Xcode[21] Vom Member Center ausgehend ist das ios Developer Center zu erreichen. Dort steht immer die aktuelle Version von Xcode sowohl für Mac OS Lion als auch für Mac OS Snow Leopard zum Download bereit (aktuell ist das die Version 4.2). Nach dem Herunterladen und erfolgreichen Installieren von Xcode kann mit einem Klick auf Create a new Xcode project(abb. 01) ein neues Projekt angelegt werden. (Abb. 01 Xcode 4.2 bei Start) Xcode liefert von Haus aus verschiedene Templates (Projektvorlagen) sowohl für ios- als auch für Mac OS X Apps. Klassischerweise fängt der Entwickler mit einem einfachen Hello World Projekt an. Hierzu wählen wir aus den ios Templates die Vorlage Single View Application, da unsere App ausschließlich über einen View mit einem Textfield verfügt. Der Entwickler wird aufgefordert einen Namen für das Projekt festzulegen, optional kann er auch einen Company Identifier sowie einen Class Prefix festlegen. Das wird allerdings erstmal ignoriert. Als Device Family wird der Eintrag Universal gewählt. Damit wird die App sowohl für iphone bzw. ipod touch als auch für ipad verfügbar sein. Use Storyboard, Use Automatic Reference Counting und Include Unit Tests wird für das MyHelloWorld Projekt ebenfalls nicht ausgewählt Ein kurzer Überblick Ausgehend von den oben gewählten Einstellungen erstellt Xcode das neue Projekt:

9 (Abb. 02 Xcode nach erstellen des Projektes) Zu sehen ist das MyHelloWorld Projekt mit den oben genannten Einstellungen. Standardmäßig ist eine AppDelegate Klasse vorhanden, ein ViewController mit den entsprechenden -.xib-dateien, die Supporting Files und die entsprechenden Frameworks sind bereits eingebunden. Üblicherweise setzt sich jede Klasse zum einen aus einem Header (.h-datei) und zum anderen aus der Implementation (.m-datei) zusammen. AppDelegate Jede ios App verfügt über eine AppDelegate Klasse. Wie der Name vermuten lässt beinhaltet diese Klasse verschiedene Methoden die bei Öffnen oder Beenden der App aufgerufen werden. Das Delegate Objekt verwaltet sozusagen den Lebenszyklus jeder App. Die AppDelegate.h sollte etwa folgendermaßen aussehen: (Abb. 03 AppDelegate.h)

10 Der #import <UIKit/UIKit.h> Befehl (Abb. 03, Z. 9) sorgt für das Einbinden des Uikit- Frameworks. ViewController;-Befehl informiert den Compiler darüber, dass in AppDelegate.m wahrscheinlich mit Objekten der Klasse ViewController gearbeitet wird. In Zeile 13 (Abb. 03) wird festgelegt, von welcher Klasse unsere AppDelegate-Klasse erbt und welche Protokolle verwendet werden sollen. In diesem fall erbt AppDelegate von UIResponder und implementiert das UIApplicationDelegate Protokoll. Ein Protokoll kann als Sammlung verschiedener Methoden beschrieben werden. Zeile 17f.(Abb. 03) zeigt die Properties. Auf -Befehl muss in der Implementation-Datei -Befehl (Abb. 04, Zeile 15f.) folgen. Letztendlich werden hierdurch für den Compiler Getter und Setter generiert. In Zeile 11 (Abb. 04) ist zu sehen, dass zusätzlich zu dem eigenen Header auch der Header der ViewController-Klasse importiert wird. Erst dadurch kennt die AppDelegate-Klasse die eigenen Methoden, sowie die der ViewController- Klasse. (Abb. 04 AppDelegate.m) Folgende Methode in AppDelegate.m wird von jeder App unmittelbar nach dem Start aufgerufen: (Abb. 05 AppDelegate.m) Hier wird zu allererst unsere window-property mit self.window = [[[UIWindow alloc] initwithframe:[[uiscreen mainscreen] bounds]] autorelease]; angelegt. Ein solches window stammt aus dem UIKit.framework, einem Framework zur Erstellung von Benutzeroberflächen. Alle Objekte diesen Frameworks tragen das Klassenprefix UI. Demzufolge ist unser window ein Objekt der Klasse UIWindow. Das self. vor window sagt lediglich, das window eine unserer Properties ist. Da window ein Objekt der Klasse UIWindow ist, welches von UIView erbt, wird dieses mit dem Methodenaufruf [[UIWindow alloc] initwithframe:] instanziiert. [UIScreen mainscreen] bounds] übergibt der Methode den entsprechenden Frame (ein Frame ist ein Rechteck mit den Daten: Ursprung.x, Ursprung.y, Breite, Höhe), in unserem Fall ist dieser Frame bildschirmfüllend. Mit dem autorelease Befehl wird festgelegt, dass der Compiler für die Speicherverwaltung von window zuständig ist. In Zeile 29 wird in einer if-abfrage entschieden, ob die Applikation auf einem iphone bzw. einem ipod touch oder einem ipad gestartet wird. Das ist für unsere universal App wichtig, da der ViewController mit der entsprechend -.xib-datei (Abb. 05, Z.30/ 32) instanziiert werden muss. Anschließend wird mit self.window.rootviewcontroller = self.viewcontroller; der frisch

11 angelegte viewcontroller dem window übergeben (Abb. 05, Z.34). Zu guter letzt wird das ganze noch mit [self.window makekeyandvisible]; (Abb. 05, Z.35) für den Benutzer sichtbar gemacht. -.xib Dateien Eine -.xib-datei kann als ein Archiv von serialisierten Objekten beschrieben werden. Vor Start einer App werden alle -xib-dateien Datei geladen, und der Inhalt dann zum Beispiel mit [[MyViewController alloc] initwithnibname:] von UIViewControllern (hier self.viewcontroller) geladen. Der Vorteil von der Verwendung von -xib-dateien ist der, dass der Entwickler noch vor dem eigentlich Programmieren sehen kann, wie die App später aussieht. Das vereinfacht den Einstieg in das Programmieren einer App. -.xib-dateien sorgen zusätzlich für einen deutlich übersichtlicheren Programmcode. Für die Entwicklung einer App mit einem statischen, sich nicht weiter verändernden View kann die Verwendung der -.xib-dateien sehr nützlich sein. Vergleicht man die in Abb.02 zu sehenden ViewController_iPhone.xib- und ViewController_iPad.xib-Dateien ist deutlich zu sehen, dass (abgesehen von dem Namen), der einzige Unterschied zwischen den beiden Dateien in der Größe des beinhaltenden View ist. Sowohl in der iphone, als auch in der ipad -.xib-datei ist ein View-Objekt das einzige vorhandene Objekt. ViewController DIe ViewController-Klasse besteht, ebenso wie die AppDelegate-Klasse, aus einer Header- und einer Implementation-Datei. In ViewController.h wird mit #import <UIKit/UIKit.h> das UIKit- Framework importiert. Es wird die vererbende Klasse angegeben und es könnten Protokolle eingebunden werden (Abb. 06). Bisher sind keine Protokolle eingebunden. (Abb. 06 ViewController.h) Ein UIViewControllers ist für die Verwaltung der Inhalte eines View zuständig und was mit diesen passiert wenn sich zum Beispiel das Gerät dreht. Standardmäßig sind in der ViewController.m-Datei unteranderem folgende Methoden vorhanden: - (void)viewdidload{} - (void)viewdidunload{} - (void)viewwillappear:(bool)animated{} - (void)viewdidappear:(bool)animated{} - (void)viewwilldisappear:(bool)animated{} - (void)viewdiddisappear:(bool)animated{} Nachdem in AppDelegate.m die Methode self.viewcontroller = [[[ViewController alloc] initwithnibname:@"viewcontroller_iphone" bundle:nil] autorelease]; aufgerufen wurde werden in ViewController.m die obenstehenden Methoden in exakt der gezeigten Reihenfolge abgearbeitet. Für individuelle Gestaltung des View können die viewdidload-, viewwillappear- oder viewdidappear-methoden entsprechend überschrieben werden. In der shouldautorotatetointerfaceorientation-methode könnte zum Beispiel mit return NO;

12 das Mitdrehen des Views deaktiviert werden. - (BOOL)shouldAutorotateToInterfaceOrientation: (UIInterfaceOrientation)interfaceOrientation { // Return YES for supported orientations if ([[UIDevice currentdevice] userinterfaceidiom] == UIUserInterfaceIdiomPhone) { return (interfaceorientation!= UIInterfaceOrientationPortraitUpsideDown); } else { return YES; } } In Unserem Fall wird die DeviceOrientation abhängig von den Endgeräten festgelegt. Hier wird mit dem return YES; -Befehl alle vier möglichen Orientierungen für das ipad unterstützt. Für das iphone oder den ipod touch werden die Orientierungen UIDeviceOrientationPortrait, UIDeviceOrientationLandscapeLeft und UIDeviceOrientationLandscapeRight unterstützt. Supporting Files Neben den verschiedenen Klassen und -.xib-dateien ist in Abb. 02 noch der Ordner Supporting Files zu sehen. In diesem Ordner zu sehen seien sollten die MyHelloWorld-Info.plist-, die InfoPlist.strings-, die main.m- und die MyHelloWorld-Prefix.pch-Datei. Die MyHelloWorld-Info.plist-, Datei ist nichts anderes als eine.xml-datei die verschiedene Informationen über die App beinhaltet. Welchen Namen hat die App? Wie heisst das App Icon? Welche Orientierungen werden unterstützt? Das alles steht in der MyHelloWorld-Info.plist-Datei jeder App. Die InfoPlist.strings -Datei ist nichts anderes als eine andere Form der MyHelloWorld-Info.plist- Datei. Kopiert der Entwickler beispielsweise CFBundleDisplayName = "Brot"; in die Datei, hätte die App beim nächsten Start den schönen Namen Brot. Die main.m jeder Applikation wird direkt nach dem starten jeder App (durch antippen des App- Icons) ausgeführt. main() wiederum ruft UIApplicationMain() auf, die wiederum die App Initialisiert und die application:didfinishlaunchingwithoptions: -Methode aufruft. Weiterhin findet sich die MyHelloWorld-Prefix.pch-Datei im Supporting Files Ordner. Diese -Prefix.pch-Datei ist ein sogenannter Projektspezifischer Precompiled Header. In dieser Datei können beispielsweise für die gesamte App wichtige Frameworks importiert werden oder Warnungen für etwa ältere Geräte deren Software zu alt ist. Zu guter Letzt soll dem Supporting Files Ordner eine Localizable-Datei hinzugefügt werden. Per Rechtsklick auf den Ordner New File auswählen und unter IOS oder Mac OS X den Reiter Resource auswählen. Eine Localizable-Datei ist eine Strings File, sie erhält den sinnigen Namen Localizable.strings. Der leeren Datei fügt der Entwickler folgenden Eintrag hinzu: "PLACEHOLDER" = "Hallo Welt";. Die Funktionalität von solchen Localizable.Strings-Dateien ist einfach: Ein Wert (hier: "Hallo Welt") wird einem Schlüssel (hier: "PLACEHOLDER") zugeowiesen. Eine Localizable.Strings-Datei zu verwenden ist selbstverständlich keine Pflicht, bringt jedoch gerade bei größeren Projekten viele Vorteile mit sich. Statische Texte (Überschriften, wiederkehrende Placeholder, Warnungen, Hinweise...) die als Wert einem Schlüssel in der Localizable.Strings-Datei eingetragen sind, können aus jeder Klasse der App erreicht werden. Will der Entwickler zu einen späteren Zeitpunkt beispielsweise den Hinweis-Text verändern, kann er

13 dies in dieser zentralen Datei tun. MyHelloWorld mit Interface Builder[22] Es gibt viele verschiedene Wege in einer App eine bestimmte Funktionalität zu erreichen. Grade für Einsteiger eignet sich der Interface Builder (IB) sehr gut, da relativ schnell eine optisch ansprechende aussehende GUI (Graphical User Interface, Benutzeroberfläche) zusammengeklickt werden kann. Der IB ist ein in Xcode integriertes Tool zur Gestaltung von GUIs. Mit einem Klick auf eine der beiden -.xib-dateien sollte ein leerer View zu sehen sein. Per Klick auf diesen sollten im Utilities Inspector (Abb. 06, rechte Seite) direkt die zugehörigen Informationen über den Inhalt der -.xib- Datei angezeigt werden. (Abb Interface Builder) Ist der Utility Inspector ausgeblendet, kann er über View Utilities Show Utilities eingeblendet werden. Damit die App später etwas mehr kann, als ausschließlich einen Text anzuzeigen, wählt der Entwickler ein UITextField aus der sogenannten Object Library (Abb. 07) aus und zieht dieses per Drag & Drop in den View. (Abb. 07 Object Library) (Abb. 08 Attributes Inspector auswählen) Nach Klick auf das UITextField im View zeigt der Attributes Insprector (Abb. 08) verschiedene Attribute des angeklickten Objektes. Für das MyHelloWorld-Projekt ist hier für das UITextField nur der Wert Appears while editing für das Clear Button-Attribut interessant. Jetzt muss das UITextField noch mit der ViewController-Klasse verbunden werden. Hierzu muss dem ViewController.h ein passendes Attribut, sowie das UITextFieldDelegate-Protokoll hinzugefügt ViewController : UIViewController <UITextFieldDelegate>{

14 IBOutlet UITextField *mytextfield; } Das UITextFieldDelegate-Protokoll wird benötigt, damit nach Texteingabe die Virtuelle Tastatur bei berühren des Return -Buttons automatisch verschwindet. Weiterhin werden getter und setter für mytextfield benötigt. Das wird praktischerweise (nonatomic, retain)iboutlet UITextField *mytextfield; Der IBOutlet-Schlüssel wird nur verwendet, wenn Objekte über den IB angelegt werden.wichtig: in ViewController.m noch den mytextfield; Zusätzlich muss ViewController.m um die textfieldshouldreturn: Delegate-Methode erweitert werden. Diese sorgt für das Verschwinden der virtuellen Tastatur nach berühren des Return-Buttons. - (BOOL)textFieldShouldReturn:(UITextField *)textfield { [textfield resignfirstresponder]; return YES; } Als Platzhalter soll mytextfield den Text Hallo Welt anzeigen. Jetzt wird die Funktionalität der Localizable.strings-Datei klar. Die App sucht in der Localizable.strings-Datei nach dem passenden Wert für den Schlüssel "PLACEHOLDER", und übergibt diesen mytextfield als Platzhalter. mytextfield.placeholder = Hallo Welt); Zurück im Interface Builder müssen jetzt die entsprechenden Verbindungen gesetzt werden. (Abb. 09 Verbindung herstellen) (Abb. 10 Delegate setzen) Der Entwickler muss hierzu Rechtsklick auf File's Owner klicken, und mit gedrückter Rechtstaste den Courser zu dem Text Field-Objekt ziehen. Ein kleines Fenster (Abb. 09) wird erscheinen. Dort muss der Entwickler auf mytextfield klicken. Hiermit wurde die Verbindung von dem UITextField- Objekt in der -.xib-datei zu dem mytextfield-objekt in ViewController-Klasse hergestellt. Als letzten Schritt muss das Passende Delegate-Objekt für das UITextfield gesetzt werden. Mit Rechtsklick auf das Text Field-Objekt und gedrückter rechter Maustaste muss der Entwickler den Courser zu File's Owner bewegen. Es erscheint erneut ein kleines Fenster (Abb. 10). Hier wählt der Entwickler delegate aus. Das gleiche muss nun für die zweite -.xib-datei durchgeführt werden. Mit Produkt Run kann der Entwickler das Projekt auf einem iphone- oder einem ipad Simulator testen.

15 MyHelloWorld ohne Interface Builder Manche Entwickler sind dem Interface Builder gegenüber eher abgeneigt, weshalb ich jetzt exakt das gleiche Projekt ohne Verwendung des IB erklären werde. Ausgehend von Abb.02 fügen wir ViewController.h das UITextFieldDelegate-Protokoll und das mytextfield-attribut ViewController : UIViewController <UITextFieldDelegate>{ UITextField *mytextfield; } können hier weggelassen werden. In ViewController.m wird wieder die textfieldshouldreturn:-methode hinzugefügt, damit nach Texteingabe die virtuelle Tastatur wieder verschwindet: - (BOOL)textFieldShouldReturn:(UITextField *)textfield { [textfield resignfirstresponder]; return YES; } In der viewdidload-methode muss jetzt das mytextfield-objekt angelegt und passend definiert werden. Hierzu wird zuerst mytextfield initiiert: mytextfield = [[UITextField alloc] initwithframe:cgrectmake(20, 20, self.view.frame.size.width-40, 30)]; Der Ursprung des Textfeldes soll bei x = 20 und y = 20 liegen, die Breite jedoch soll unabhängig von Gerät und Orientierung 20 Pixel vom Rand links und rechts entfernt sein. Diesen Wert erhält der Entwickler mit self.view.frame.size.width-40. Als nächsten Schritt muss das Delegate-Objekt für mytextfield auf ViewController gesetzt werden: mytextfield.delegate = self; Damit mytextfield genauso aussieht, wie das erste MyHelloWorld-Projekt muss der borderstyle und die Hintergrundfarbe, sowie der Platzhalter korrekt gesetzt werden: mytextfield.borderstyle = UITextBorderStyleRoundedRect; mytextfield.backgroundcolor = [UIColor whitecolor]; mytextfield.placeholder = localization"); Es fehlt noch der Clear-Button, und die Funktionalität des Mitdrehens: mytextfield.clearbuttonmode = UITextFieldViewModeWhileEditing; mytextfield.autoresizingmask = UIViewAutoresizingFlexibleWidth; Der Clear-Button soll nur während des Texteditierens angezeigt werden, und das Textfeld soll sich an die Bildschirmbreite anpassen. Zum Abschluss muss mytextfield noch an den ViewController.view übergeben werden: [self.view addsubview:mytextfield]; Damit sich mytextfield auch tatsächlich an die Bildschirmbreite jedes Gerätes anpasst muss der shouldautorotatetointerfaceorientation:-methode noch folgende Zeile Code hinzugefügt werden: [self.view autoresizessubviews]; Damit sollte die MyHelloWorld App sowohl iphone-, als auch ipad-kompatibel sein, und auf jedem der Geräte die Interface Rotation unterstützen.

16 Der Organizer[23] Nach dem Programmieren der ersten App stellt sich für den Entwickler die Frage wie er diese auf einem iphone, ipod touch oder einem ipad installieren und testen kann. Erstmals wird für den Entwickler der Organizer interessant. Dieser kann mit einem Klick auf Window Organizer eingeblendet werden. Ist im Organizer der Reiter Devices ausgewählt, zeigt eine Liste aller mit dem Mac verbundenen, für Entwicklung geeigneten Apple Geräte. An oberster Stelle sollte der eigene Mac auftauchen, gefolgt von den verbundenen Geräten. Sollte der Entwickler eines zur Hand, dieses allerdings noch nicht mit dem Mac verbunden haben sollte er dies jetzt tun. Sobald es in der Liste auftaucht, kann er es mit einem Klick auf Add to Portal dem Provisioning Portal hinzufügen. Sobald das Gerät erfolgreich zu dem Provisioning Portal hinzugefügt wurde navigiert der Benutzer zurück zu Xcode. Testen auf einem Endgerät (Abb. 11 Build scheme) In Abb. 11ist zu sehen, wo der Entwickler das sogenannte Build scheme auf das entsprechende, verbundene Gerät setzen kann. Nach dem Klick auf Run sollte die App auf dem Gerät starten. Für das Entwickeln von mobilen Applikationen ist das testen auf Endgeräten sehr wichtig, da diese sich teilweise anders verhalten als der Simulator. So kann es vorkommen, dass Apps auf einem Endgerät laufen, auf dem Simulator allerdings abstürzen. Das gleiche ist natürlich auch umgekehrt möglich. Eine App für den App Store vorbereiten[24] Im Member Center ist ein Link auf das App Store Resource Center. Wählt der Entwickler dort unter ios den Link Prepare for App Submission aus, erfährt er alles, was vor dem Abschicken einer App an Apple zu beachten ist. Grob zusammengefasst sind folgende Informationen bereit zu halten: App Name Ist der Name aussagekräftig? Ist er eventuell schon vorhanden? App Beschreibung Was müssen potenzielle Kunden über die App wissen? Was weckt die Neugierde? Erst- und Zweitkategorie Jede App wird im App Store einer Erst- und einer Zweitkategorie untergeordnet. Copyright Wer hat ein Copyright auf die App? App Rating Das App Rating ist nicht etwa die Bewertung der App im App Store, sondern ein von Apple ermittelter Wert, der eine Aussage über eventuelle gewaltverherrlichende Inhalte macht. Folgende Werte kann ein App Rating haben: 4+ App enthält keinerlei anstößigen Inhalt 9+ App enthält teilweise mild ausgeprägte Gewaltverherrlichende Inhalte und sollte nicht für Kinder unter neun Jahren verfügbar sein. 12+ Apps dieser Wertung können zusätzlich noch simuliertes Glücksspiel enthalten, und sollten für Kinder unter zwölf Jahren nicht verfügbar sein 17+ Apps dieser Wertung können neben stark aggressiven Sprachinhalten und stark ausgeprägter

17 Gewalt noch Alkohol-, Drogen- oder Sexverherrlichende Inhalte haben und sollten für Kinder und Jugendlich unter 17Jahren nicht verfügbar sein Keywords Mit welchen Suchbegriffen kann die App über die Suchfunktion im App Store gefunden werden? SKU Nummer Die SKU Nummer ist einer Einzigartige Nummer zu Identifizierung der App. Sie ist nur für den Entwickler interessant und kann frei gewählt werden. App URL Gibt es zu der App eine Webseite? Falls ja, sollte diese mitgeliefert werden. Screenshots Eine App sollte ein bis fünf Screenshots mit liefern. Diese sollten nach Möglichkeit Besonderheiten der App zeigen. Für viele Benutzer wecken erst die Screenshots die Kaufmotivation. Für iphone oder ipod touch Apps sollten ein bis fünf Screenshots mit einer der folgenden Auflösungen vorhanden sein:960x640, 960x600, 640x900, 640x920, 480x320, 480x300, 320x480 oder 320x460. Für ipad Apps sollten ebenfalls ein bis fünf Screenshots der Auflösungen 1024x768, 1024x748, 768x1024 oder 768x1004. Die DPI muss mindestens 72 sein und sollte im RGB Farbspektrum liegen. Gültige Formate sind.jpeg,.jpg,.tif,.tiff oder.png. Support URL Eine Support URL sollte wenn vorhanden angegeben werden. Support Addresse Eine Support Adresse ist Pflicht. Gerade für Bezahl-Apps ist es für den Kunden wichtig, dass er sich bei Problemen an einen Support wenden kann. Preis, Verfügbarkeits Datum, Märkte Was soll die App kosten? Ab wann soll sie verfügbar sein? Wo soll sie verfügbar sein? Großes App Icon 512 x 512 Das Große App Icon wird benötigt, da der App Store auch über jeden Webbrowser zu erreichen ist. Auch hier soll das Logo unverpixelt dargestellt werden können. Vorbereitung der Binary Für das Abschicken der App an Apple muss diese zunächst archiviert werden. Hierzu müssen zunächst einige Schritte innerhalb von Xcode vorgenommen werden. Der Entwickler navigiert, wie in Abb.02 zu sehen, auf die Projektübersicht, und dort unter TARGETS klickt er das MyHelloWorld Projekt an. Hier wird der Reiter Summary ausgewählt. Jetzt kann der passende Bundle Identifier für ein Distribution Profile eingetragen werden. Die Versions- und Build Nr. kann mit dem Wert 1.0 unverändert bleiben. Für Devices bleibt der Wert ebenfalls auf Universal. Das Deployment Target ist standardmäßig auf 5.0 gesetzt. Damit wäre Die App für alle Geräte mit niedrigerer ios Version nicht zugänglich. Aus diesem Grund sollte der Entwickler immer versuchen ein Möglichst niedriges Deploment Target zu wählen. Da viele Funktionen allerdings erst mit ios 4.x kamen, wird für die meisten neueren Apps das Deployment Target bei 4.x liegen. So auch für unsere App. Weiterhin interessant ist das App Icon. Das soll laut Apple Vorgabe die Größe 57x57 Pixel haben. Da die neuere Generation der iphones mit dem Retina Display eine deutlich höhere Auflösung schafft, sollte jede App auch ein Retina Display Icon der Größe 114x114 mitliefern. Die Namensgebung für das Icon sieht wie folgt aus: App Icon für nicht Retina Display: iconname.png (57x57) App Icon für Retina Display: IconName@2x.png (114x114) App Icon für ipads: iconname.png (72x72) Es geht weiter in dem Reiter Info.

18 Hier sollten bei Custom ios Target Properties noch (falls bisher nicht geschehen) für den den Icon files -Schlüssel die entsprechenden App Icon Namen eingetragen werden (Abb. 12) (Abb. 12 Alle App Icons) Manchmal schmeißt Xcode bei dem Versuch die Binary abzuschicken die Exception, dass keine gültige Build Architecture gefunden wurde. Das kann mit dem angegebenen Deployment Target zusammenhängen, da sich die Build Architecture von den älteren zu den neueren Geräten geändert hat. Um dem vorzubeugen Sollten für den Schlüssel Required Device Capabilities die Werte armv6 und armv7 eingetragen werden (Abb. 13). (Abb. 13 Build Architecture in der -Info.plist) Jetzt wird automatisch die gültige Build Architecture Wert gewählt. In dem Reiter Build Settings sollte unter Architectures für den Schlüssel Valid Architectures jetzt der Wert armv6 armv7 zu sehen sein. Wichtig unter Code Signing ist jetzt, die Code Signing Identity auf iphone Distribution zu setzen. Sind in der -Info.plist der Wert für den Bundle Identifier gesetzt, sollte sich das Gültige Distribution Profile auswählen lassen, und für Release oder iphone Distribution gesetzt werden (Abb. 14). (Abb Codesigning) Das sollte erst einmal zur Vorbereitung der Binary reichen. itunes Connect Itunes Connect ist Apples Webportal zur Verwaltung von alldem, was mit den selbstgeschrieben Apps zu tun hat: Teammitglieder des Entwickler Accounts können hier verwaltet werden. Verkaufszahlen und Finanzberichte können eingesehen und exportiert werden. Bei Appspeziefischen Fragen kann direkt Verbindung mit Apple aufgenommen werden. Bereits im App Store vorhandene Apps können verwaltet werden, und selbstverständlich können neue Apps hochgeladen werden. Eine App einreichen Über Manage your Apps wird der Entwickler zu einer Übersicht aller seiner vorhandenen Apps weitergeleitet. Per Klick auf Add New App hat der Entwickler die Möglichkeit eine neue App hinzuzufügen. App Information Hier wird der Entwickler aufgefordert den App Name, die SKU Nummer sowie die korrekte Bundle ID der App einzugeben. Die Bundle ID wird per Drop Down Menü aus einer Liste gültiger Profile des Provisioning Portals ausgewählt und muss mit der in Xcode eingestellten Bundle ID

19 übereinstimmen. YourAppName Das nächste Fenster trägt als Überschrift den soeben eingegeben App Namen. Hier wird festgelegt, ab wann die App verfügbar sein soll und für welchen Preis. Weiterhin können hier die Weltweiten App Stores ausgewählt werden. Dabei ist zu beachten, dass Bezahl-Apps automatisch nur in den App Stores verfügbar sein werden, für die der Aktuelle ios Paid Applications Vertrag gilt. Metadata Hier sollen alle wichtigen Informationen über die App angegeben werden. Dazu gehören: Die Versionsnummer der App. Die App Beschreibung. Erst- und Zweitkategorie. Key-Wörter. Copyright. Kontakt Adresse. Support URL. App URL (Optional). Privacy Policy URL (Optional). Review Notes. Unter Review Notes sollten für Apple Techniker alle Informationen aufgeführt sein, die zum testen wichtig sind. Dazu gehören beispielsweise Benutzername und Passwort für Apps, die einen speziellen Account benötigen. Als nächstes wird das App Rating ermittelt. Das erfolgt anhand elf Fragen über Gewalt-, Drogen-, oder Sexverherrlichende Inhalte der App, die per Radio Buttons mit None, Infrequent/Mild oder Frequent/Intense beantwortet werden. Zum Schluss müssen noch die die nötigen Bilder hochgeladen werden. Dazu gehören ein Großes App Icon der Größe 512x512 Pixel, ein bis fünf IPhone oder ipod touch Screenshot sowie eventuelle ipad Screenshots. Mit dem Klick auf Save werden die eingegeben und Hochgeladenen Daten gespeichert. Die App befindet sich jetzt in dem Waiting for Binary -Status. Zurück in Xcode trennt der Entwickler alle Geräte von dem Mac, und stellt das Build scheme auf ios Device. Klickt der Entwickler jetzt Product Archive erstellt Xcode die gewünschte Binary. Falls keine Übereinstimmung des angegebenen Bundle Identifiers mit einem gültigen Distribution Profile gefunden wird, schmeißt Xcode eine einen Code Sign error: Code Sign error: The identity 'iphone Distribution' doesn't match any identity in any profile In diesem fall sollte der Bundle Identifier bzw. das entsprechende Distribution Profile überprüft werden. Ist das nicht der Fall, kann öffnet sich automatisch der Organizer mit ausgewähltem Reiter Archives. Mit einem Klick auf Submit wird der Entwickler in wenigen Schritten durch den Submit Process geleitet.

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