Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Entwickler>Mobiler Entwicklerblog

Mobiler Entwicklerblog

netspy
netspy19.11.1011:43
Ich möchte hier mal meinen neuen Blog mit Beiträgen rund um die Anwendungsentwicklung – speziell mit Appcelerator Titanium – vorstellen:



Wer Titanium noch nicht kennt – damit kann man mit JavaScript native mobile Anwendungen für das iPhone, Android und BlackBerry entwickeln. Ebenfalls lassen sich plattformunabhängige Desktopanwendungen mit JavaScript, PHP und anderen Sprachen entwickeln.

In meinem Blog schreibe ich regelmäßig Beiträge zum Thema mit Neuigkeiten, Tipps und Tutorials. Wenn also Lust hat, kann gerne mal reinschauen.

Gruß
0

Kommentare

void
void19.11.1011:57
gefällt mir, weiter so!
„Developer of the Day 11. Februar 2013“
0
ExMacRabbitPro19.11.1012:05
Wie kommt denn aus JavaScript eine "native" iOS Applikation heraus? Läuft da ein Cross-Compiler? Denn wirklich nativ wäre ja C/ObjC/C++ und Cocoa.
0
Johloemoe
Johloemoe19.11.1012:09
Schöner Blog, auch wenn ich persönlich kein Freund von solchen Layern bin. Die UIKit-API ist nicht ohne Grund in Objective-C geschrieben und ich finde daher sollte man das dann auch so honorieren.. Aber sonst: Keep it up!
0
netspy
netspy19.11.1012:47
Da läuft natürlich kein Cross-Compiler mit. Allerdings bietet Titanium deutlich mehr als bspw. reine App-Wrapper wie PhoneGap. Titanium bietet ein eigenes umfangreiches API und wenn man mittels JavaScript UI-Elemente erzeugt, dann sind das eben keine HTML-Imitate wie bspw. bei Sencha Touch, sondern echte Fenster und UI-Elemente der jeweiligen Plattform. Man kann zwar auch eine WebView erzeugen und darin reine WebApps ausführen, das aber nicht der Sinn von Titanium und würde die Möglichkeiten nicht mal ansatzweise ausnutzen.

Ein großer Vorteil im Vergleich zur Entwicklung mit Objective-C ist dabei eben, dass sich Anwendungen leicht parallel für iPhone und Android entwickeln lassen. In meinen Augen keine zu unterschätzender Vorteil.

Native Entwickler können Titanium übrigens auch leicht mit eigenen Funktionen erweitern.
0
Klaus Major19.11.1013:37
Sehr schön, werde ich wohl öfter mal reinschauen!

Aber direkt im ersten Artikel ist ein kaputter Link:
Ein Klick auf "Glyphish-Iconpack" ergibt einen 404 Error


Gruß

Klaus
0
netspy
netspy19.11.1014:07
Danke für den Hinweis. Wordpress ist schon manchmal merkwürdig. Der Link hatte definitiv schon funktioniert aber bei irgendeiner Bearbeitung hat sich wohl das http aufgelöst.
0
ExMacRabbitPro19.11.1014:43
Ach ja, wirklich einfache und gute (= Performant und auf der jeweiligen Plattform nicht von nativen Apps unterscheidbar) plattformunabhängige Entwicklung - das Buzz Word Thema in der IT seit Jahren. Bisher immer viel gehört - aber nix davon gesehen.
0
Klaus Major19.11.1014:52
Aber "Livecode", vormals Revolution, kommt dem schon verdächtig nahe
0
netspy
netspy19.11.1015:26
@ExMacRabbitPro: Meine erste App mit Titanium beinhaltet unter Anderem ein Wörterbuch mit über 300.000 Stichwörtern, welche sich live durchsuchen lassen. Dabei läuft meine App gefühlt nicht langsamer als andere Wörterbücher, die (so nehme ich an) native entwickelt wurden. Es ist also durchaus möglich, vernünftige Anwendungen mit Titanium zu erstellen.

Außerdem ist es auch durchaus möglich, native langsame Anwendungen zu erzeugen. Viele Dinge bei der Anwendungsentwicklung, die für die Performance verantwortlich sind, haben nämlich erst mal nichts mit der verwendeten Programmiersprache oder dem Framework zu tun. Ein GUI baue ich über einen JavaScript-Wrapper nur unwesentlich langsamer zusammen, als native über Objective-C. Eine vermurkste Datenbank ohne gescheite Indizes wird native jedoch auch nicht schneller.

Titanium ist sicherlich nicht für alles zu verwenden und stößt in manchen Bereichen schnell an seine Grenzen. Für viele Dinge ist es jedoch super und da opfere ich gerne ein wenig Performance im Austausch gegen die Plattformunabhängigkeit und die (für mich) schnellere Entwicklung mit JavaScript.
0
ExMacRabbitPro19.11.1015:57
netspy

Das Problem was ich sehe (oder habe) ist, dass sich die GUI Elemente und die dadurch bestehende Bedien-Philosophie der einzelnen mobilen Plattformen einfach viel zu sehr unterscheiden, als dass ich mit vorstellen kann, dass für komplexere Apps (keine Spiele - die bringen meißt eh eine eigene GUI mit) sich auf diese Weise, ohne alle Plattformen auf den kleinsten gemeinsamen Nenner zu reduzieren, wirkliche plattformunabhängige Apps erstellen lassen.
Wenn man nur mal das (native) GUI Controll Set von Android und iOS gegenüberstellt, sind die unterschiede teilweise eklatant und damit auch die generelle Bedienung der Plattformen. Von Windows Mobile oder gar Blackberry möchte ich da noch nicht einmal reden.

Daher gibt es eigentlich nur drei Konsequenzen:
1. Entweder man kann mit so einem System keine der Plattformen wirklich gebührend ausreizen und erschreckt die User.
2. Oder das Runtimesystem bringt eine eigene GUI Philosophie mit, die vom Look&Feel versucht den jeweiligen Host nachzumachen.
3. Oder der eigene Code strotzt irgend wann von "if (iPhone) .... else if (Andoid) else if (WinMobile) else if (.....)" Konstrukten um den Unterschieden gerecht zu werden.

Wie hoch in der Komplexität würdest Du denn deine Wörterbuch App einschätzen? Bitte verstehe mich nicht falsch, ich möchte nichts herunter machen und würdige deine Entwicklung - aber die frage ist doch, kann ich mit so einer Plattform so etwas wie Pages oder die iTunes App des iPad ohne Mühe erstellen - und das WIRKLICH Plattformunabhängig? Das mag am Anfang vielleicht nur unrelevant sein, aber wenn man die mobile Entwicklung professionell betreibt und sich weiter Entwickelt werden auch die Apps und die Ziele die man sich steckt immer größer (ist jedenfalls meine Erfahrung) und dabei würde ich nie auf etwas setzen bei dem ich Gefahr laufe gegen die Wand zu rennen.

Ich bezweifele einfach, dass so eine Multi-Plattform Lib einem einen wirklichen Nutzen bringt. Denn wenn man - wie gesagt - einmal von simplen Apps ab geht - dann kommt so eine Lib in massive Schwierigkeiten. Denn sie muss (müsste) - wie gesagt - dem Entwickler eine Schicht zur Verfügung stellen, welche die Plattform Eigenheiten ausgleicht. Und das kann nicht funktionieren. Wenn man sich mur einmal anschaut, was in iOS mittlerweile alles unter der Haube steckt - das ist schon gewaltig. Alleine die Core APIs wie z.b. Core Graphics, Core Animation, Core Location, Core Data oder z.B. das Game Center. Wie soll das auf alle Plattformen herunter gebrochen werden? Geht nicht - ist viel zu iOS spezifisch. Und genau so sieht es auch umgekehrt aus, wenn man von den anderen Plattformen kommt. Die Konsequenz ist, auf diese Dinge zu verzichten oder doch wieder "if (iPhone) .... else if (Andoid) else if (WinMobile) else if (.....)". Und dann ist der "Multiplattform-Benefit" gerade den Bach herunter gegangen.

Klar kommen solche Demos ala "Wir entwickeln in 3:16 h ein kleines plattform-unabhängiges Game" auf jeder Entwicklermesse gut an und erzeigen einen *wow* Effekt. Aber was war es dann auch schon.
0
netspy
netspy19.11.1016:28
Wie schon gesagt, ist Titanium nicht für jedes Projekt die erste Wahl. Mit Plattformunabhängigkeit meine ich jetzt auch nicht unbedingt, dass man eine App einmal entwickelt und per Knopfdruck für verschiedenen Plattformen zur Verfügung stellt. Das geht zwar, jedoch muss man dann – wie du schon schreibst – viele Kompromisse eingehen und kann keine Plattform ausreizen. Macht man sich jedoch schon vor der Entwicklung Gedanken, kann man mit Titanium viel Programmlogik auslagern und auf unterschiedlichen Plattformen ohne weitere Anpassungen wieder verwenden. Man muss dann „nur“ noch den GUI-Teil separat entwickeln. Entwickelt man native für iOS und Android, lässt sich schon die Programmlogik kaum austauschen, da ja meist Objective-C und Java genutzt werden.

Da Titanium native UI-Elemente erzeugt, nimmt es einem in manchen UI-Belangen die Arbeit aber auch ab und eine TabGroup erscheint eben beim iPhone unten und bei Android oben. Will man dagegen beim iPhone bspw. einen Picker nutzen, muss man sich für Android was anderes einfallen lassen.

Meine Wörterbuch-App ist nicht so sonderlich komplex aber ich sehe auch für zukünftige Erweiterungen grundsätzlich erst mal nichts, was sich nicht mit Titanium umsetzen ließe. Dazu kommt, dass sich Titanium ja native erweitern lässt und zur Not eine fehlende Funktionalität auf diese Weise ergänzt werden kann. Bspw. wird noch kein In-App Purchase unterstützt, was sich bei Bedarf jedoch ergänzen ließe.

Noch zu deiner Frage: Pages wäre definitiv keine App, bei der ich Titanium empfehlen würde. Hier würde die Performance im Vordergrund stehen und die sprechen bei so einer Anwendung klar gegen Titanium und Co. Eine iTunes App wäre dagegen IMO schon realisierbar.

Ich verstehe deine Bedenken sehr gut und die sind auch keineswegs unbegründet. Titanium ist jedoch nach meiner bisherigen Erfahrung auf jeden Fall einen Blick wert und bietet deutlich mehr als die üblichen App-Wrapper der Marke PhoneGap.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.