Soraxdesign » Tutorial

Einrichten eines iPhones als Entwicklertelefon in Xcode

rené — Sat, 22 May 2010 16:25:15 +0000

Möchte man seine Applikation nicht nur im Simulator testen sondern auf einem Endgerät, muss das iPhone erst als Developer-Device konfiguriert werden. Apple bietet dafür eine ausführliche Anleitung im iPhone Developer Portal:

Zu diesen wichtigen Schritte, habe ich hier noch einige Tipps parat.
Das iPhone, welches als Developer-Device verwendet werden soll, an den Mac anschließen und Xcode öffnen.
Für die Einrichtung des iPhones wird die UDID benötigt, wie man diese ausliest, steht hier.

Create an App ID
Dieser Name sollte eindeutig sein und so einfach wie möglich, da dieser später im Xcode Projekt eingetragen werden muss. Ideal ist Kleinschreibung und ein kurzer Projektname z.b. testapp.

Developer Ceritifcate
Im Assistenen muss ein sogenanntes “Developer Certificate” erstellt werden. Dazu wird aus der ID des Macs mit Hilfe der Schlüsselbundverwaltung (Keychain Access) eine Datei generiert, diese wird im Assistenten hochgeladen. Die Schlüsselbundverwaltung findet man schnell über Spotlight.

Im nächsten Schritt wird eine Datei namens “developer_identity.cer” generiert, dies zieht man einfach auf das Icon der geöffneten Schlüsselbundverwaltung oder klickt doppelt drauf. Es wird gefragt, ob man dieses Zertifikat hinzufügen möchte, im Dropdown sollte “Anmeldung” ausgewählt sein. Dann auf “OK” klicken.

Klickt man in der Schlüsselbundverwaltung auf “Meine Zertifkate” findet man ein Zertifikat mit dem Namen “iPhone Developer ” dort. Das “Developer Certificate” muss nur pro Entwickler angelegt werden.
Zu jeder Applikation benötigt man entweder ein “Development Provisioning Profile” oder ein “Distribution Provisioning Profile”, wobei für die Entwicklung ersteres interessant ist.

Profile
Im Assistenten wird als nächstes für die Applikation ein “Development Provisioning Profile” generiert, dafür muss diesem Profil ein Name gegeben werden. Es bietet sich an, auch weil später schwer zu unterscheiden ist, ob es sich um ein “Development Provisioning Profile” oder ein “Distribution Provisioning Profile” (dort auch noch für eine Adhoc oder AppStore Installation) handelt, den Namen des Profils nach dem Muster “ApplikationName_DeveloperProfile” bzw. “ApplikationName_DistributionProfile_Adhoc/AppStore” anzugeben. Für die Applikation “testapp” wäre dies dann “testapp_DeveloperProfile”. Im letzten Schritt lädt man das “Development Provisioning Profile” herunter und zieht es auf das Icon von Xcode.

Einrichten in Xcode
In Xcode kann man über “Window” -> “Organizer” eine Übersicht aller Geräte (iPhones) bekommen, welche am Mac angeschlossen waren und/oder als Entwicklergeräte zugelassen sind.
Dort sollte das aktuelle iPhone auftauchen, wenn dieses angeklickt wird, erscheint in der “Provisioning” – Liste das eben erstellte Profil:

Wurden alle Schritte erfolgreich abgeschlossen, kann die Applikation per “Clean all” gesäubert werden und danach per “Build & Go” auf das angeschlossene iPhone übertragen werden.
Es empfielt sich, Xcode vorher neu zu starten.

Hier ist noch einmal eine sehr ausführliche Anleitung mit vielen Bildern zu diesem Thema:
http://mobiforge.com/developing/story/deploying-iphone-apps-real-devices

Tutorial und Tips: Dokumentation von Quelltext mit Doxygen

rené — Wed, 25 Nov 2009 23:43:43 +0000

Nicht nur wenn ein Projekt größer wird, sondern prinzipiell immer sollten sowohl Quellcode als auch das Projekt an sich dokumentiert werden, damit spätere Entwickler weniger Einarbeitungszeit benötigen und nicht erst den Quellcode durcharbeiten müssen, um das Projekt zu verstehen.
Heute möchte ich auf einen Teil der Dokumentation eingehen, manchmal auch als technische Dokumentation bezeichnet (obwohl sich darüber die Geister streiten, was eine technische Dokumentation genau definiert, wie man hier [1], hier [2] oder hier [3] nachlesen kann.), dem Quellcode.

Unterstützung erhält man dabei durch eine Software namen Doxygen. Diese kann anhand der Projektstruktur mit Bibliotheken, Klassen und Verzeichnissen eine ansehliche Dokumentation erstellen.
Wichtig ist, dass der Quellecode im Javadoc [4] Stil kommentiert wird. Ein Beispiel:

/**
Addiert zwei Zahlen und gibt deren Summe zurück.
@param $number1 erster Summand
@param $number2 erster Summand
@return Summe der beiden Zahlen
@see subtract() subtrahiert zwei Zahlen voneinander
*/
private function calc($number1, $number2) {
return $number1 + $number2;
}

Schnell erkennt man, dass ich die Parameter eine Funktion calc mit @param beschreibe, davor kommt eine allgemeine Funktionsbeschreibung, um die Aufgabe der Funktion zu verdeutlichen. Sollte die Funktion keinen Rückgabewert haben, lässt man @return einfach weg. Der Parameter @see beschreibt einen Verweis auf eine andere Funktion, die evtl. mit dieser im Zusammenhang steht oder ähnliche Funktionalität aufweist.

Der Kopf einer Klasse sollte immer folgendes Format besitzen (die meisten IDEs wie z.B. Eclipse generieren diesen automatisch):

/**
* Ein Hello-World-Programm in Java.
* Dies ist ein Javadoc-Kommentar.
*
* @author René
* @version 1.0
*/

Nachdem ihr jetzt grundlegend wisst, wie eure Klassen “lesbar” gemacht werden, geht es daran, Doxygen [5] zu konfiguieren. Ich arbeit selbst am Mac und werde daher hier auf die Macversion eingehen, habe aber auch mit der Windowsversion gearbeitet und es gibt keinen Unterschied.
Öffnet Doxygen und startet den Wizard. Viele Sachen sollten selbsterklärend sein, hier aber einige Tips oder Fallstricke:

Step 1
Gebt hier den Pfad zum Installationsordner (!) von Doxygen an.

Project version or id
Hier müsst ihr immer manuell eine neue Version der Doku eingeben, kann ich nur empfehlen, wenn ihr an einem Projekt arbeitet, dass sich kontinuierlich (im Team) entwickelt.

Specify the directory to scan for sourcecode
Hier wird der eigentliche Projektordner mit euren Klassen, Bibliotheken usw. angegeben.

Doxygen Wizard erster Schritt

-> Nächster Schritt

Select the desired extraction mode
Ich wähle fast immer “Documented entities only”, dann erkennt ihr schnell, ob noch Klassen dokumentiert werden müssen, wenn diese nicht in der Doku auftauchen. Der Haken bei “Include cross-referenced source code in the output” gefällt mir, denn dann werden in der Doku alle Funktion aufgelistet die auf die aktuelle Funktion zugreifen.

Select programming language to optimize the results for
Hier die entsprechende Sprache wählen oder eine ähnliche. Für Objective-C habe ich z.B. mit “Java or C#” gute Erfahrungen gemacht. Einfach auch etwas ausprobieren.

Zweiter Schritt im Wizard von Doxygen

-> Nächster Schritt

Select the output format(s) to generate
Ich möchte in meinen Dokus immer links einen Frame mit Baumnavigation (“with frames and a navigation tree”) haben. Auf die Suchfunktion verzichte ich meistens, hat teilweise Probleme beim Generieren der Doku erzeugt. Ausgabe als Latex ist sehr toll, es entsteht anschließend einer verlinkte refman.tex, welche auf dem Mac z.B. mit MacTeX [6] und der eingabe “make” im Terminal in eine PDF umgewandelt werden kann.

Dritter Schritt im Wizard von Doxygen

-> Nächster Schritt

Im letzten Schritt kann man sich entscheiden, ob Diagramme der Klassenstrukturen erzeugt werden sollen. Lohnt sich prinzipiell nur, wenn es viele Klassenabhängigkeiten im Projekt gibt. Daher Punkt 2 oder, falls dem nicht so ist, Punkt 1 wählen.
Nachdem der Wizard durchgestanden ist, kann gerne im Reiter “Run” auf den Button “Run Doxygen” gedrückt werden. Vergesst nicht, eure Profildatei zu speichern!
Geht nichts schief, bekommt ihr, wenn ihr den Button “Show HTML Output” mit eurer Maus malträtiert, eine HTML-Seite eurer Doku im Browser präsentiert. Das sieht dann so aus:

Ausgabe der HTML Doku

Kommen wir nun zu einigen Experteneinstellungen, die ihr im zweiten Reiter findet. Dort sind einige Einstellungen versteckt, die teilweise sehr wichtig sind.

-> Project

OUTPUT_LANGUAGE
Sprachumstellung auf Deutsch, so dass einige Standardbegriffe in der Doku auf Deutsch erscheinen (“File List” -> “Auflistung der Dateien”). Es sind aber noch nicht alle Begriffe übersetzt.

STRIP_FROM_PATH
Wollt ihr in eurer Doku nicht immer my/project/with/long/path/to/the/classes/Hello.java zu stehen habe, dann gebt dort den Pfad ein, der abgeschnitten werden soll. (in diesem Falle “my/project/with/long/path/to/the/classes”).

SEPARATE_MEMBER_PAGES
Seid ihr ein eifriger Kommentator und schreibt auch was zu euren Klassenvariablen, könnt ihr eure Romane auf einzelnen Seiten ausgeben lassen.

-> Build

EXTRACT_ALL
Soll wirklich alles und nicht nur dokumentierte Klassen bearbeitet werden, setzt ihr hier einfach einen Haken. Dann werden aber wirklich alle (!) Dateien, Variablen und Methoden in die Doku aufgenommen. Das kann auch noch verfeinert werden, indem ihr EXTRACT_PRIVATE explizit auswählt, so dass auch private Klassenvariablen ausgelesen werden.

-> Input

INPUT_ENCODING
Hier tragt ihr am besten “ISO-8859-1″ ein, wenn eure Dateien nicht im UTF-8 Format abgespeichert sind, sonst bekommt ihr in eurer Doku nur Zeichensalat.

EXCLUDE
Sehr wichtige Einstellunge. Oftmals liegen in einem Projekt Testdateien oder -klassen, die man ungern in der Doku haben möchte. Klar kann man anwählen, dass man nur dokumentierte Dateien aufnehmen möchte, aber die Holzhammermethode ist das explizite ausschliessen bestimmter Dateien.

-> HTML

HTML_HEADER, HTML_FOOTER, HTML_STYLESHEET
Über HTML_HEADER kann eine eigene HTML-Datei für den Kopf festgelegt werden, das gleiche gilt für den Footer. HTML_STYLESHEET bietet die Möglichkeit, die Standard-CSS von Doxygen zu verändern bzw. zu überschreiben. Vergesst nicht, eure verlinkten Dateien aus externen HTML-Dateien bzw. die CSS in den Zielordner eurer Doku zu kopieren.

TREEVIEW_WIDTH
Hier könnt ihr die Breite des linken Frames mit der Baumstruktur festlegen. Oftmals sind 250px einfach zu schmal und bei heutigen Auflösungen auch unnötig klein.

So sähe dann übrigens die PDF Datei aus, wenn ihr sie durch MacTeX jagt:
Dokumentation

Was heisst “technische Dokumentation” für euch? Womit dokumentiert ihr eure Projekte und habt ihr Tips für Doxygen oder was man anders machen könnte? Womit bildet ihr eure Datenbankmodelle ab und was habt ihr für Erfahrungen damit? Über einen Kommentar würde ich mich freuen!

Quellen

[1] Die Technische Dokumentation im Wandel: http://www.transline.de/transline-tecNews/technische-dokumentation-im-wandel-anforderungen-redaktionssysteme-docuglobe
[2] Was ist Technische Dokumentation?: http://www.comet.de/technische_redaktion/technische_dokumentation.php
[3] Checkliste zur Qualitätssicherung Technischer Dokumentation: http://www.indoition.com/de/qualitaet-software-dokumentation.htm
[4] Javadoc - was ist das und wie nutze ich es?: http://de.wikipedia.org/wiki/Javadoc
[5]
Source code documentation generator tool: http://www.stack.nl/~dimitri/doxygen/
[6] The MacTeX-2009 Distribution: http://www.tug.org/mactex/2009/

Tutorial: Mehrsprachige Anwendungen in Flex 3

rené — Thu, 22 Oct 2009 20:21:41 +0000

Wer schon einmal vor der Aufgabe stand, eine Flex Projekt mehrsprachig zu gestalten, dem bieten sich beim ersten Überlegen mehrere Lösungen an:

ein Array für jede Sprache
XML Datei
eine Datenbank, mit einer Serversprache und Stream über AMF
…bestimmt noch viele weitere Lösungen

Jedoch hat sich Adobe Gedanken gemacht und eine recht elegante Lösung für Flex 3 vorgesehen: Runtime Localization mit Ressourcen. Dabei gibt es viele Vorteile:

mehrere Ressourcen (=Sprachen) können in ein Projekt kompiliert werden
Ressourcen werden extern in .properties Dateien gespeichert (Trennung vom Code)
direktes Umschalten zwischen verschiedenen Sprachen (alle Referenzen werden sofort aktualisiert)
auch Sounds, Bilder können “mehrsprachig” verknüpft werden
zur Laufzeit können neue Ressourcen aus XML Dateien, Datenbankanfragen erzeugt werden

Nun aber zum Tutorial. Erzeugt euch ein Flex 3 Projekt und editiert eure *.mxml Datei wie folgt:

"1.0" encoding="utf-8"?>
xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
text="@Resource(bundle='myResources', key='SLOGAN')" fontSize="20" x="10" y="40"/>
x="10" y="10">>
x="10" y="78" width="211" height="193"/>
>

Dabei kann man deutlich erkennen, dass hier eine Ressource mit dem Namen “myResources” und dort der Key “SLOGAN” aufgerufen wird. Schaltet ihr in die Designansicht, seht ihr, dass das der Inhalt des Attributs text jetzt etwas unschön quer über die Applikation ragt.
Anschließend erzeugt ihr euch in eurem src Ordner einen Ordner locale, darin zwei Ordner de_DE und en_US. In diesen weiterhin jeweils eine Datei namens myResources.properties (hier ist die oben erwähnte .properties Datei, außerdem der Link vom text Attribut mit “myResources”). Danach sollte eure Ordnerstuktur so ähnlich aussehen:

Anschließend müsst ihr unbedingt die Kodierung der Dateien auf UTF-8 setzen. Dazu Rechtsklick auf die myResources.properties -> Eigenschaften. Hier stellt ihr das Text File Encoding auf UTF-8:

Damit der Compiler auch die Ressourcen findet, muss der Pfad zu diesem in dem Compileroptionen angegeben werden. Dazu öffnet ihr die Eigenschaften des Projektes, geht auf Flex Compiler und ergänzt/ersetzt dort um folgendes:

-locale=en_US -source-path=../locale/{locale}

Damit wird dem Flex Compiler mitgeteilt, dass die Standardsprache englisch ist sowie weitere Sprachen im Ordner “locale” zu finden sind. Die “..” sind entscheidend, da der Flex Compiler einen relativen src-Pfad nimmt und nicht den absoluten wie man ihn im Projektbaum sieht. Scheint noch ein Relikt aus der Betaphase zu sein.

Jetzt sind alle Vorbereitungen getroffen, wenn ihr das Projekt ausführt sollte der Platzhalter SLOGAN durch euren Text aus der Datei en_US/myResources.properties ersetzt werden. Jedoch sprach ich noch vom direkten Umschalten zwischen mehreren Sprachen. Dazu verknüpfen wir die vorhandenen Ressources mit einer Combobox.
Kurz etwas zum Hintergrund des Flex Compilers: Für jede Sprachresource muss für es einen Resource im Frameworkordner des Flex Frameworks (SDK) geben. D.h. für en_US gibt es bereits nach der Installation ein fertiges Sprachpaket unter frameworks/locale/en_US/framework_rb.swc. Wenn wir aber in den Compileroptionen -locale=de_DE angeben, erwartet der Compiler, eben dieses Sprachpaket unter frameworks/locale/de_DE/framework_rb.swc zu finden. Das ist aber von Hause aus nicht so. Deswegen müssen wir manuell die Resourcen für unsere Sprachen erzeugen. Diese geschieht recht simpel, indem man die vorhandene (englische) Resource dupliziert.

Für Windows geht dieses mit

bincopylocale.exe en_US de_DE

sowie unter Mac mit dem Befehl

bin/copylocale.sh en_US de_DE

Nun aber zur Umschaltung zwischen verschiedenen Sprachen. Folgendermaßen sieht der Code jetzt aus:

"1.0" encoding="utf-8"?>
xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
>
[ResourceBundle("myResources")]
>

[Bindable]
private var locales:Array = [ "en_US" , "de_DE" ];

private function localeComboBox_initializeHandler(event:Event):void
{
localeComboBox.selectedIndex = locales.indexOf(resourceManager.localeChain[0]);
}

private function localeComboBox_changeHandler(event:Event):void
{
// Set the localeChain to either the one-element Array
// [ "en_US" ] or the one-element Array [ "de_DE" ].
resourceManager.localeChain = [localeComboBox.selectedItem];

}

]]>

text="{resourceManager.getString('myResources', 'SLOGAN')}" fontSize="20" x="10" y="40"/>
x="10" y="10" id="localeComboBox" dataProvider="{locales}"
initialize="localeComboBox_initializeHandler(event)"
change="localeComboBox_changeHandler(event)"/>
x="10" y="78" width="211" height="193" source="{resourceManager.getString('myResources', 'IMGSRC')}"/>
>

Die wichtigste Veränderung stellt die Ersetzung aller “@Resource(bundle….” durch “{resourceManager.getString(…” dar. Damit greift ihr direkt auf den resourceManager zu, welchem ihr über die Combobox verschiedene Sprachresourcen zuweisen könnt. Dabei ist localeChain der entscheidene Begriff.
Im Download und der Demo findet ihr auch ein Beispiel für “mehrsprachige” Bilder.

Demo
Download Beispiel

Tutorial: ExternalInterface – Zusammenspiel von SWF und JavaScript

rené — Mon, 24 Aug 2009 20:37:05 +0000

Manchmal ist es nötig, SWF Dateien mit dem aktuellen Container (meistens eine umschliessende HTML Seite) korrespondieren zu lassen. Ob nun Inhalte in Formularen geändert, Seitenwechsel oder auch das Zusammenspiel mit anderen SWF Dateien geschehen soll, kann dies über JavaScript gelöst werden. Eine Schnittstelle bietet dabei die ExternalInterace Klasse von ActionScript 3.

Früher war diese Funktion unter dem Namen fscommand() bekannt und hat diese ersetzt.

Um von JavaScript auf eine Methode in ActionScript zuzugreifen, muss diese dem Flash Player bekannt gemacht werden. Dieser erfolgt mit der Methode addCallback():

ExternalInterface.addCallback("setTextFromJS", setText);

Dabei wird die (JavaScript)Methode “setTextFromJS” dem Flash Player und somit dem ExternalInterface bekannt gemacht. Die zweite Variable legt die Funktion fest, die in ActionScript aufgerufen werden soll.
Nun kann mit der aktuelle SWF Container in der HTML Seite über dessen Namen angesprochen werde und die Methode aufgerufen werden. Parameterübergabe funktioniert wie gehabt in JavaScript:

Natürlich ist dies auch umgekehrt möglich. Über die Funktion

ExternalInterface.call('setTextFromAS', s);

kann aus ActionScript heraus eine JavaScript Funktion aufgerufen werden mit Parameterübergabe. Soweit ich weiß, kommt immer ein String an. Der Parameter s kann dabei ein Wert sein, der von ActionScript an JavaScript gesendet werden soll.

Hier habe ich ein Beispiel online gestellt. Der übergebene Text aus dem Textfeld wird an die SWF gesendet und anschließend wieder an JavaScript und in ein zweites Textfeld geschrieben.

Beispiel
Download des Beispielcodes