Monkey ist einfach genial. Nach erfolgreichen probieren der HTML5 und iOS Targets wollte ich mal etwas über den Tellerrand zu Android schauen.
Ein Android Target mit Monkey zu erzeugen ist ja kein Problem. Aber was wird alles benötigt um für Android zu entwickeln? Zu aller erst organisiert man sich das Android SDK für die entsprechende Plattform. In meinem Fall war es für Mac OS X (intel).
So weit so gut, was kommt als nächstes. Unter OS X muss in dem Android SDK Ordner „tools“ das Kommandozeilenprogramm „android“ gestartet werden. Es erscheint dann der „Android SDK and AVD Manager“. Nun lädtman sich im nächsten Schritt die gewünschte Android SDK Platform.
Ist das erledigt ist es ratsam unter „Virtual devices“ ein AVD anzulegen. Dieses stellt dann einen Android Simulator zur Verfügung. Die ersten Weichen sind gestellt.
Monkey & Netbeans
Das SDK ist eingerichtet, Monkey hat ein Android Target Projekt erzeugt, aber was nun? Nach ein wenig suche, wenn man die bekannten Java IDE’s abklappert, wird man bei Netbeans fündig (wenn ich ehrlich bin habe ich nur nach Netbeans gesucht).
Für die Netbeans IDE gibt es das „nbandroid“ Plugin. Dieses steht nicht selbst über das Netbeans Repository zur Verfügung. Um dieses zu installieren muss im „Plugins Fenster“ unter „Settings“ eine weitere Update Center Quelle angelegt werden. Dies wird hier sehr gut beschrieben.
Nach erfolgreicher installation kann man direkt aus Netbeans heraus Android Projekte erzeugen/starten, compilieren, usw.
Monkey hat dies aber schon erledigt und Netbeans muss nicht mehr dazu bemüht werden. Netbeans wird jetzt dazu gebraucht das Android Target zu kompilieren und entweder auf ein echtes oder auf ein simuliertes Device zu kopieren.
Und schon steckt man ganz tief in der Welt von Android und Java ;o) Bei meinen ersten Versuchen war ich bis jetzt noch nicht erfolgreich mein Monkey Projekt unter Android zum laufen zu bewegen, snif.
Exportiert man auf die iOS Plattform wird über ein Template ein Xcode 3 Projekt erzeugt. Dieses kann auch ohne weiteres mit Xcode 4 geöffnet werden.
Im Moment wird das Projekt mit dem Namen „MonkeyGame“ erzeugt. Dieser kann angeblich über eine Config Datei eingestellt werden. Da alles aber über Xcode selbst eingestellt werden kann habe ich mich auch noch nicht richtig auf die Suche gemacht ;o)
In Xcode müssen/können noch kleine Änderungen wie Default Screen, zu verwendende Icons sowie die Device Orientation eingestellt werden. Auch ob die Titlebar angezeigt werden soll oder nicht kann nachtröglich noch geöndert werden.
Tiefergreifende Änderungen können natürlich noch in Xcode vorgenommen werden. Der bessere Weg wäre natürlich weitere iOS Funktionen als Modul Monkey zur Verfügung zu stellen.
In der Monkey Demoversion ist HTML5 die einzige Zielplattform die ausgewählt werden kann. Erst in der Vollversion stehen alle andere Plattformen zur Verfügung.
HTML5 ist unter Monkey die schnellste Zielplattform auf der man seine Apps ausprobieren kann. Diese braucht keinen Simulator und muss auch nicht kompiliert werden. Schlichtweg ein möglichst modernen Browser mit guter HTML5 Unterstützung reicht hier aus.
Google Chrome liegt sehr hoch in der Gunst der Monkey Entwickler. Safari und Firefox stehen aber Chrome sicher in nichts nach.
Monk startet komischerweise einen eigenen lokalen Webserver um die HTML5 App zu starten. Erfahrungsgemäß läuft dieser aber, zumindest bei mir, nicht sehr stabil und stürzt gerne hin und wieder ab.
Dieser ist nicht unbedingt notwendig. Die erzeugte HTML Datei kann logischerweise auch direkt mit dem Browser geöffnet werden.
Update: Ein direktes öffnen ist mittlerweile nicht mehr möglich. Das HTML5 Target benötigt den lokalen Webserver.
Mehr gibt es eigentlich hier nicht zu berichten. Die erzeugten Dateien können so wie diese sind auf eine bestehende Homepage übernommen werden.
Die Verknüpfungen von Variablen und Methoden über Verbindungen im Interface Builder sind schon eine feine Sache.
Über Bindings ist es nun möglich Interface Elemente automatisch mit Werten zu befüllen ohne eine einzelne Zeile Code zu schreiben.
Im Beispiel vorher unter Actions musste das NSTextField noch mit textField’s setStringValue_(„String“) befüllt werden.
Unser Beispiel das auf den vorherigen Seiten zu finden ist wird nun erweitert. Im Fenster wird nun ein Label samt TextField hinzugefügt.
Das Textfield wird nun ausgewählt. Im Inspector aktivieren wir nun den vierten Reiter mit den Bindings. Im obersten Abschnitt „Value“ setzen wir das Höckchen bei „Bind to:“ und wählen die entsprechende Klasse. In unserem Fall heisst diese „Controller“. Bei „Model Key Path“ muss dann der Name der Variablen eingetragen werden aus dem die Werte übernommen werden sollen.
Bis jetzt haben wir alles durch Outlets, Actions und Bindings. Nur was ist zu tun wenn zum Beispiel der User den Wert eines Textfeldes öndert und wir darauf reagieren wollen?
Im Prinzip kann dies mit einer Action geschehen. Nur wird diese nicht mit (sender) definiert, sondern mit (aNotification). Siehe Methode somethingsChanged_(aNotification).
-- controller.applescript
-- asoc_03
-- Created by Christian Sonntag on 11.04.10.
-- Copyright 2010 __MyCompanyName__. All rights reserved.
script controller
property parent : class "NSObject"
property |count| : 1
--Outlet
property textField : missing value
property textFieldToChange : missing value
--Action
on doSomething_(sender)
beep
textField's setStringValue_("Hello World! (" & |count| & ")")
set my |count| to (my |count|) + 1
end doSomething_
on somethingsChanged_(aNotification)
set temp to textFieldToChange's stringValue()
set temp to temp as string
display alert "textField changed to: " & return & temp
end somethingsChanged_
end script
Wir erweitern nun wieder unser Beispiel um ein weiteres Label und ein Textfield.
Wieder ziehen wir mit gedrückter rechten Maustaste vom NSObject Controller eine Verbindung zum neuen Textfeld.
Nach dem loslassen der Maustaste wird wieder das kleine graue Fenster angezeigt. In diesem Fall wählen wir nun das Outlet „textfieldToChange“.
Nun muss für die Notification eine Verbindung zur Klasse hergestellt werden. Vom Textfeld ausgehend wird nun mit gedrückter rechten Maustaste eine Verbindung zum NSObject Controller definiert.
Wieder erscheint die Auswahl der vorhandenen Methoden und wir wählen „somethingsChanged“.
Actions sind der nächste Schritt um ASOC Programme zu schreiben. Outlets schaffen die Möglichkeit aus dem Programmcode auf UI Elemente zuzugreifen.
Actions im Gegenzug rufen Methoden auf die bei einem UI Ereignis z.B. ein Klick auf einen Button ausgelöst werden.
Diese werden wie folgt in der Klasse definiert:
-- controller.applescript
-- asoc_01
-- Created by Christian Sonntag on 11.04.10.
-- Copyright 2010 __MyCompanyName__. All rights reserved.
script controller
property parent : class "NSObject"
--Outlet
property textField : missing value
--Action
on doSomething_(sender)
end doSomething_
end script
So, ab in den Interface Builder. Aus der Library wird ein NSButton unserer Wahl ins Fenster gezogen, positioniert, angepasst und mit einem schönen Namen versehen.
Nun muss dem Button auch eine Action aus der Klasse zugewiesen werden. Mit gedrückter rechter Maustaste ziehen wir eine Verbindung von dem Controller Objekt auf den neu positionierten NSButton und lassen die rechte Maustaste los.
Auch hier erscheint wieder ein kleines schwarzes Fenster das alle vorhandenen Methoden aus der Klasse anzeigt. Hier wählen wir „doSomething“ aus.
Zum Abschluss kann alles natürlich noch mal geprüft werden. Bei ausgewähltem NSButton schauen wir nun im Inspector im vorletzten Reiter unter „Sent Actions“, und siehe da dort ist „doSomething“ zu sehen.
So jetzt hauchen wir dem ganzen noch etwas Leben ein, siehe unten. Denn nach dem kompilieren passiert nämlich gar nix. Als Beispiel lassen wir nun einen Warnton ausgeben, eine Variable wird hoch gezählen, die im Anschluss mit einem „Hello World!“ im NSTextField ausgegeben wird.
Fürs erste sind die wichtigsten Basics erklärt auf die man weiter aufbauen kann.
-- controller.applescript
-- asoc_01
-- Created by Christian Sonntag on 11.04.10.
-- Copyright 2010 __MyCompanyName__. All rights reserved.
script controller
property parent : class "NSObject"
property |count| : 1
--Outlet
property textField : missing value
--Action
on doSomething_(sender)
beep
textField's setStringValue_("Hello World! (" & |count| & ")")
set my |count| to (my |count|) + 1
end doSomething_
end script
So bis jetzt haben wir nicht besonderes getan außer ein Projekt anzulegen und eine zusätzliche Klasse einzufügen.
Jetzt gehts los, wir beschäftigen wir uns nun mit Outlets. Outlets definieren innerhalb einer Klasse eine Variable die später im Interface Builder mit einem GUI Objekt verknüpft werden kann.
Der Vorteil dabei ist dass dieses GUI Objekt einfach über den Variablennamen angesprochen werden kann. Wer noch AppleScript Studio in Erinnerung hat kennt die umständliche Referenzierung auf ein GUI Element innerhalb des Codes.
-- controller.applescript
-- asoc_01
-- Created by Christian Sonntag on 11.04.10.
-- Copyright 2010 __MyCompanyName__. All rights reserved.
script controller
property parent : class "NSObject"
--Outlet
property textField : missing value
end script
Ein Outlet muss auf missing value gesetzt werden. Aus ObjC Sicht beudetet das nil bzw. no object. Ist ein Outlet so definiert erscheint dieses im Interface Builder als ein Outlet und kann mit einem Interfaceelement verbunden werden.
So ein Outlet ist in der Klasse definiert. Wie geht es aber weiter? Zunächst muß die Datei MainMenu.xib geöffnet werden die automatisch mit dem Interface Builder geöffnet wird. Dies geschieht mit einem Doppelklick auf die Resource in XCode.
Ist der IB gestartet zieht man aus der Library ein NSObject in das MainMenu.xib Fenster.
Das NSObject ist jetzt aber noch neutral bzw. ohne Funktion. Nach einem Klick auf das neue NSObject öffnet man das Inspectorfenster und geht auf den letzten Reiter. Unter Class Identify wöhlt mann nun aus dem Dropdown Menü die neu angelegte Klasse mit dem Namen controller aus.
Das NSObject ist nun mit der controller.applescript Klasse verknüpft und kann dessen Outlets verwenden.
Als nächstes ziehen wir ein NSTextField in das Projektfenster. Nun haben wir ein Interfaceobjekt das mit dem Outlet aus der ASOC Klasse verbunden werden kann.
Zum verbinden ziehen wir bei gedrückten Rechtsklick von dem NSObject Controller eine Verbindung zu dem neu angelegten NSTextField.
Über dem NSTextField die Maustaste wieder loslassen. Interface Builder sind alle Outlets der verknüpften Klasse bekannt und zeigt diese in einem kleinen grauen Fenster an. Das gewünschte Outlet kann nun ausgewählt werden. Im Beispiel ist es das Outlet „textField“.
Outlets können natürlich auch nach der Verbindung kontrolliert werden. Dazu muss dass NSTextField ausgewählt werden. Im Inspectorfenster unter dem letzten Reiter wird bei Referencing Outlets die Verbindung angezeigt.
Das Outlet ist eingerichtet und auf das UI Objekt kann aus der ASOC Klasse heraus angesprochen werden. Hierfür stehen die entsprechenden Cocoa Methoden des Objekts zur Verfügung. Dazu sollte man sich aber ein bisschen mit der Developer Documentation auseinandersetzen.
Irgendwie wollte ich meine Begeisterung von Monkey und TYPO3 [die für T3 ist mittlerweile am abklingen ;-)] zusammen bringen und habe eine kleine Extension für TYPO3 entwickelt, mit der man das HTML5 Target von Monkey über ein Plugin in die TYPO3 Seite integrieren kann.
Einfach den Build Ordner von Monkey in den fileadmin hoch laden, das Plugin auf einer beliebigen Seite einfügen und dann in der Plugin Flexform auf diesen Ordner verweisen => fertig!
Nur leider musste ich feststellen das meine Extension einer Aufräumaktion zum Opfer gefallen war und diese nun nicht mehr im TYPO3 Repository zu finden ist. Warum auch immer? Einfach so ohne Kommentar, das hat mich ein bisschen geärgert! Und deswegen werde ich mir auch nicht mehr die Mühe machen diese ins TER hoch zu laden.
Trotzdem will ich aber den letzten Stand auf meiner Seite zur Verfügung stellen! Diese liegt nun „nur“ als zip-Datei vor, da das neue TYPO3 6 aus dem Extensionmanager „nur“ noch zip-Files und keine t3x-Files mehr exportiert..?
Beim letzten Punkt haben wir so lapidar eine neue Klasse in ein ASObjC Projekt hinzugefügt. Nur wie greift man dann auf diese zu? Um dies zu bewerkstelligen gibt es zwei verschiedene Möglichkeiten.
Instanzierung im Code
Mit der ersten Möglichkeit wird die benötigte Klasse programmatisch hinzugefügt. Hierzu wird im Header mit property test : class „test“ of current application die Klasse „includiert“. Um die Instanzierung der Klasse muss man sich dann selbst kümmern, siehe folgenden Beispielcode.
-- benötigte Klasse "includieren"
property test : class "test" of current application
script ClassTestAppDelegate
property parent : class "NSObject"
--
--
--
on classTest_(sender)
--Klasse instanzieren
set myTest to test's alloc()'s init
--auf Klassenmethode zugreifen
set strFromClass to myTest's convertString_("Wandle mich um." as string)
--Rückgabewert der Methode ausgeben
display alert strFromClass
end classTest_
--
--
--
end script
Instanzierung über Interface Builder
Eine Klasse kann aber auch ohne eine Zeile Code zu schreiben instanziert werden. In diesem Fall wird mit property test : missing value ein Outlet für den Interface Builder definiert. Innerhalb des Interface Builders zieht man nun ein NSObject Icon in das IB Dokumentenfenster. Im Identity Inspector wird der Name der Klasse eingetragen der Instanziert werden soll. Zum Schluss muss das Outlet noch mit dem NSObject verbunden werden (siehe Screenshot).
Der Beispielcode sieht wie folgt aus.
script ClassTestAppDelegate
property parent : class "NSObject"
--Instanzierung der Klasse über Interface Builder
property test : missing value
--
--
--
on classTest_(sender)
--auf Klassenmethode zugreifen
set strFromClass to test's convertString_("Wandle mich um.") as string
--Rückgabewert der Methode ausgeben
display alert strFromClass
end classTest_
--
--
--
end script
Der erste Schritt war nicht schwer. Als nächsten kleinen Schritt fügen wir eine neue Klasse hinzu.
Im linken Bereich „Groups & Files“ des Projektbaumes legen wir mit einem Rechtsklick „Add > New File…“ eine neue AppleScriptObjC Klasse an.
Im nächsten Dialog wird „AppleScript class“ ausgewählt.
Im letzten Schritt wird noch der Dateiname angegeben. Benennen wir diesen einfach mal „controller.applescript“.
-- controller.applescript
-- asoc_01
-- Created by Christian Sonntag on 11.04.10.
-- Copyright 2010 __MyCompanyName__. All rights reserved.
script controller
property parent : class "NSObject"
end script
So sieht nun eine AppleScriptObjC Klasse aus. Eigentlich unspektakulär, das einzige was aufföllt ist property parent : class „NSObject“.
Diese ASOC Klasse erbt alle Eigenschaften von NSObject. AppleScript Datentypen werden automatisch durch die ASOC-Bridge in Objective C Klassen konvertiert. Im umgekehrten Weg ist das nicht der Fall.
Werden Objective C Objekte an AppleScript zurückgegeben werden diese nicht in AS Datentypen umgewandelt. Dies hat den Vorteil dass dann weiterhin ObjC Methoden darauf angewendet werden können.
Update 26.07.2010: Unter Xcode 4 fehlt leider das ASObjC Template um eine Klasse anzulegen. Entweder man erstellt einen passende Datei von Hand, oder lädtsich ein Ersatztemnplate von www.macosxautomation.com.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.