Vergleich zwischen Corona, Phonegap, Titan

Ich bin Webentwickler und möchte meine Webprodukte auf das iPhone übertragen. Eines der Produkte ähnelt Google Maps: Karte auf dem Telefonbildschirm anzeigen, Sie können die Karte ziehen oder ihre Größe ändern und einige Informationen anzeigen, die wir der Karte hinzufügen.

Ich weiß, dass es einige Technologien gibt, mit denen Sie HTML, CSS und Javascript verwenden können, um native iPhone-Apps zu entwickeln. Ich habe einige identifiziert:

• Ansca Mobile
• PhoneGap
• Appcelerator

Gibt es andere, ähnliche Produkte? Was sind die Unterschiede zwischen ihnen? Welches sollte ich wählen?

Ich habe mich bei stackoverflow registriert, nur um die am häufigsten gewählte Antwort oben zu kommentieren. Das Schlimme ist, dass der Stackoverflow neuen Mitgliedern nicht erlaubt, Kommentare zu posten. Also muss ich diesen Kommentar eher wie eine Antwort aussehen lassen.

Die Antwort von Rory Blyth enthält einige gültige Punkte zu den beiden mobilen Javascript-Frameworks. Seine wichtigsten Punkte sind jedoch falsch. Die Wahrheit ist, dass Titanium und PhoneGap eher ähnlich als unterschiedlich sind. Beide stellen Mobiltelefonfunktionen über eine Reihe von Javascript-APIs zur Verfügung, und die Logik der Anwendung (HTML, CSS, Javascript) wird in einem nativen WebView-Steuerelement ausgeführt.

1. PhoneGap ist nicht nur ein nativer Wrapper einer Web-App. Über die Javascript-APIs von PhoneGap hat die "Web-App" Zugriff auf die Funktionen des Mobiltelefons wie Geolocation, Beschleunigungsmesserkamera, Kontakte, Datenbank, Dateisystem usw. Grundsätzlich kann jede Funktion, die das SDK des Mobiltelefons bietet, mit dem "überbrückt" werden Javascript Welt. Andererseits hat eine normale Webanwendung, die im mobilen Webbrowser ausgeführt wird, keinen Zugriff auf die meisten dieser Funktionen (Sicherheit ist der Hauptgrund). Daher ist eine PhoneGap-App eher eine mobile App als eine Web-App. Sie können PhoneGap sicherlich verwenden, um eine Web-App zu verpacken, die überhaupt keine PhoneGap-APIs verwendet, aber dafür wurde PhoneGap nicht erstellt.

2. Titanium kompiliert Ihren HTML-, CSS- oder Javascript-Code NICHT in "native Bits". Sie werden ähnlich wie eine eingebettete Image-Datei als Ressourcen in das ausführbare Bundle gepackt. Wenn die Anwendung ausgeführt wird, werden diese Ressourcen in ein UIWebView-Steuerelement geladen und dort ausgeführt (natürlich als Javascript, nicht als native Bits). Es gibt keinen Javascript-to-Native-Code- (oder To-Objective-C-) Compiler. Dies geschieht auf die gleiche Weise auch in PhoneGap. Aus architektonischer Sicht sind diese beiden Frameworks sehr ähnlich.

Sind sie jetzt anders? Ja. Erstens scheint Titanium mehr Funktionen zu bieten als PhoneGap, da mehr Funktionen für Mobiltelefone mit Javascript verbunden werden. Am auffälligsten ist, dass PhoneGap nicht viele (wenn überhaupt) native UI-Komponenten Javascript aussetzt. Auf der anderen Seite verfügt Titanium über umfassende UI-APIs, die in Javascript aufgerufen werden können, um alle Arten nativer UI-Steuerelemente zu erstellen und zu steuern. Mithilfe dieser UI-APIs kann eine Titanium-App "nativer" aussehen als eine PhoneGap-App. Zweitens unterstützt PhoneGap mehr Handyplattformen als Titanium. PhoneGap-APIs sind allgemeiner und können auf verschiedenen Plattformen wie iPhone, Android, Blackberry, Symbian usw. verwendet werden. Titanium zielt zumindest vorerst hauptsächlich auf iPhone und Android ab. Einige seiner APIs sind plattformspezifisch (wie die iPhone UI-APIs).

Wenn Sie also Ihre App "nativer" gestalten möchten, ist Titan die bessere Wahl. Wenn Sie Ihre App einfacher auf eine andere Plattform "portieren" möchten, ist PhoneGap besser.

Aktualisiert 13.08.2010: Link zur Antwort eines Titanium-Mitarbeiters auf Mickeys Frage.

Aktualisiert am 04.12.2010: Ich habe beschlossen, diesen Beitrag jährlich zu überprüfen, um seine Informationen auf dem neuesten Stand zu halten. Viele Dinge haben sich in einem Jahr geändert, wodurch einige der Informationen im ersten Beitrag veraltet waren.

Die größte Veränderung kam von Titan. Anfang dieses Jahres veröffentlichte Appcelerator Titanium 1.0, das vom architektonischen Standpunkt aus drastisch von seinen Vorgängerversionen abwich. In 1.0 wird das UIWebView-Steuerelement nicht mehr verwendet. Stattdessen rufen Sie Titanium-APIs für alle UI-Funktionen auf. Diese Änderung bedeutet ein paar Dinge:

1. Ihre App-Benutzeroberfläche wird vollständig nativ. Ihre App enthält keine Web-Benutzeroberfläche mehr, da die nativen Titanium-APIs die Kontrolle über alle Ihre Benutzeroberflächenanforderungen übernehmen. Titan verdient viel Anerkennung, indem es Pionierarbeit an der Grenze der "Cross-Platform Native UI" leistet. Es bietet Programmierern, die das Erscheinungsbild der nativen Benutzeroberfläche bevorzugen, aber die offizielle Programmiersprache nicht mögen, eine Alternative.

2. Sie können HTML oder CSS in Ihrer App nicht verwenden, da die Webansicht nicht mehr vorhanden ist. (Hinweis: Sie können weiterhin eine Webansicht in Titanium erstellen. Es gibt jedoch nur wenige Titanium-Funktionen, die Sie in der Webansicht nutzen können.) Titanium Fragen und Antworten: Was ist mit HTML und CSS passiert?

3. Sie können keine gängigen JS-Bibliotheken wie JQuery verwenden, die die Existenz eines DOM-Objekts voraussetzen. Sie verwenden weiterhin JavaScript als Codierungssprache. Dies ist jedoch so ziemlich die einzige Webtechnologie, die Sie verwenden können, wenn Sie als Webprogrammierer zu Titanium 1.0 kommen.

Titan-Video: Was ist neu in Titan 1.0.

Kompiliert Titanium 1.0 Ihr JavaScript in "native Bits"? Nein. Appcelerator hat dieses Problem mit diesem Entwickler-Blog endlich gelöst: Titanium Guides Project: JS Environment.Wir Programmierer sind echte Menschen als die in der Marketingabteilung, nicht wahr? :-)

Fahren Sie mit PhoneGap fort. Es gibt nicht viele neue Dinge über PhoneGap zu sagen. Ich bin der Meinung, dass die Entwicklung von PhoneGap nicht sehr aktiv war, bis IBM später in diesem Jahr an Bord kam. Einige Leute argumentierten sogar, dass IBM mehr Code zu PhoneGap beiträgt als Nitobi. Ob wahr oder nicht, es ist gut zu wissen, dass PhoneGap aktiv entwickelt wird.

PhoneGap basiert weiterhin auf Webtechnologien wie HTML, CSS und JavaScript. Es sieht nicht so aus, als ob PhoneGap einen Plan hat, native UI-Funktionen wie Titanium mit JavaScript zu verbinden. Während die Web-Benutzeroberfläche in Bezug auf Leistung und natives Erscheinungsbild immer noch hinter der nativen Benutzeroberfläche zurückbleibt, wird diese Lücke schnell geschlossen. Es gibt zwei Trends bei Webtechnologien, die der mobilen Web-Benutzeroberfläche in Bezug auf die Leistung eine hervorragende Funktion verleihen:

1. JavaScript-Engine, die von einem Interpreter zu einer virtuellen Maschine wechselt. JavaScript ist JIT, das zur schnelleren Ausführung in nativen Code kompiliert wurde. Safari JS Engine: SquirrelFish Extreme

2. Das Rendern von Webseiten geht von der Abhängigkeit von der CPU zur Verwendung der GPU-Beschleunigung über. Grafikintensive Aufgaben wie Seitenübergang und 3D-Animation werden mithilfe der Hardwarebeschleunigung viel flüssiger. GPU Accelerated Compositing in Chrome

Solche Verbesserungen, die von Desktop-Browsern stammen, werden schnell an mobile Browser geliefert. Seit iOS 3.2 und Android 2.0 ist die Steuerung der mobilen Webansicht wesentlich leistungsfähiger und HTML5-freundlicher geworden. Die Zukunft des mobilen Webs ist so vielversprechend, dass es ein großes Kind in die Stadt gezogen hat: JQuery hat kürzlich sein mobiles Web-Framework angekündigt. Mit JQuery Mobile, das UI-Gadgets bereitstellt, und PhoneGap, das Telefonfunktionen bereitstellt, bilden beide zusammen meiner Meinung nach eine perfekte mobile Webplattform.

Ich sollte auch Sencha Touch als ein weiteres mobiles Web-UI-Gadget-Framework erwähnen . Sencha Touch Version 1.0 wurde kürzlich unter einem dualen Lizenzmodell veröffentlicht, das GPLv3 enthält. Sencha Touch funktioniert genauso gut mit PhoneGap wie JQuery Mobile.

Wenn Sie ein GWT- Programmierer sind (wie ich), sollten Sie sich GWT Mobile ansehen , ein Open-Source-Projekt zum Erstellen mobiler Webanwendungen mit GWT. Es enthält einen PhoneGap GWT-Wrapper, der die Verwendung von PhoneGap in GWT ermöglicht.

Nach dem, was ich gesammelt habe, gibt es hier einige Unterschiede zwischen den beiden:

• PhoneGap generiert grundsätzlich native Wrapper für noch vorhandene Web-Apps . Es spuckt ein WhateverYourPlatformIs-Projekt aus, Sie erstellen es und stellen es bereit. Wenn wir über das iPhone sprechen (wo ich meine Zeit verbringe), scheint es nicht viel anders zu sein als das Erstellen eines Web-App-Starters (eine Verknüpfung, die ein eigenes Springboard-Symbol erhält, sodass Sie es wie ( wie ) starten können. eine native App). Die "App" selbst ist immer noch html / js / etc. Und läuft in einem gehosteten Browser-Steuerelement. Darüber hinaus bietet PhoneGap eine Brücke zwischen JavaScript und nativen Geräte-APIs. Sie schreiben also JavaScript für PhoneGap-APIs, und PhoneGap führt dann den entsprechenden entsprechenden nativen Aufruf durch. In dieser Hinsicht unterscheidet es sich von der Bereitstellung einer einfachen alten Web-App.

• Die Titanquelle wird in native Bits kompiliert. Das heißt, Ihr HTML / js / etc. werden nicht einfach an ein Projekt angehängt und dann in einem Webbrowser-Steuerelement gehostet - sie werden in native Apps umgewandelt. Dies bedeutet beispielsweise, dass die Benutzeroberfläche Ihrer App aus nativen UI-Komponenten besteht. Es gibt Möglichkeiten, ein natives Erscheinungsbild zu erhalten, ohne eine native App zu haben, aber ... nun ... was für ein Albtraum, der sich normalerweise herausstellt.

Die beiden sind insofern ähnlich, als Sie alle Ihre Inhalte mit typischen Webtechnologien (html / js / css / bla bla bla) schreiben und über benutzerdefinierte JavaScript-APIs Zugriff auf native Funktionen erhalten.

Aber auch hier beginnen PhoneGap-Apps (PhonGapps? Ich weiß nicht ... ist das ein dummer Name? Es ist einfacher zu sagen - ich weiß so viel) ihr Leben als Web-Apps und beenden ihr Leben als Web-Apps. Auf dem iPhone ist Ihr HTML / JS / etc. wird nur in einem UIWebView-Steuerelement ausgeführt, und die PhoneGap-JavaScript-APIs, die Ihre js-Aufrufe an native APIs weiterleiten.

Titan-Apps werden zu nativen Apps - sie werden nur mithilfe von Web-Dev-Technologie entwickelt.

Was bedeutet das eigentlich bedeuten ?

1. Eine Titanium-App sieht aus wie eine "echte" App, da es sich letztendlich um eine "echte" App handelt.

2. Eine PhoneGap-App sieht aus wie eine Web-App, die in einem Browser-Steuerelement gehostet wird, da es sich letztendlich um eine Web-App handelt, die in einem Browser-Steuerelement gehostet wird.

Welches ist das Richtige für Sie?

• Wenn Sie native Apps mit Webentwicklungsfähigkeiten schreiben möchten, ist Titanium die beste Wahl.

• Wenn Sie eine App mit Webentwicklungsfähigkeiten schreiben möchten, die Sie realistisch auf mehreren Plattformen (iPhone, Android, Blackberry und allen anderen Plattformen) bereitstellen können, und wenn Sie Zugriff auf eine Teilmenge nativer Plattformfunktionen (GPS, GPS, Beschleunigungsmesser usw.) über eine einheitliche JavaScript-API ist PhoneGap wahrscheinlich das, was Sie wollen.

Sie fragen sich vielleicht: Warum sollte ich eine PhoneGapp schreiben (ich habe beschlossen, den Namen zu verwenden) und nicht eine Web-App, die im Web gehostet wird? Kann ich auf diese Weise nicht immer noch auf einige native Gerätefunktionen zugreifen, aber auch den Komfort einer echten Webbereitstellung nutzen, anstatt den Benutzer zu zwingen, meine "native" App herunterzuladen und zu installieren?

Die Antwort lautet: Weil Sie Ihre PhoneGapp an den App Store senden und dafür eine Gebühr erheben können. Sie erhalten auch das Startsymbol, wodurch es für den Benutzer schwieriger wird, Ihre App zu vergessen (ich vergesse viel eher ein Lesezeichen als ein App-Symbol).

Sie könnten sicherlich eine Gebühr für den Zugriff auf Ihre im Internet gehostete Web-App erheben, aber wie viele Personen werden den Prozess wirklich durchlaufen, um dies zu tun? Im App Store wähle ich eine App aus, tippe auf die Schaltfläche "Kaufen", gebe ein Passwort ein und fertig. Es wird installiert. Sekunden später benutze ich es. Wenn ich die einmalige mobile Web-Transaktionsschnittstelle eines anderen Benutzers verwenden müsste, was wahrscheinlich bedeutet, dass ich meinen Namen, meine Adresse, Telefonnummer, CC-Nummer und andere Dinge, die ich nicht abhören möchte, abtippen müsste, würde ich das mit ziemlicher Sicherheit nicht tun. ' Ich mache es nicht durch. Außerdem vertraue ich Apple - ich bin zuversichtlich, dass Steve Jobs meine Informationen nicht protokollieren und dann meinem CC eine Reihe von ungezogenen Zeitschriftenabonnements für Kicks in Rechnung stellen wird.

Abgesehen von der Tatsache, dass es sich um Webentwickler handelt, sind PhoneGap und Titanium sehr unterschiedlich - bis zu dem Punkt, dass sie nur oberflächlich vergleichbar sind.

Ich hasse Web-Apps im Übrigen, und wenn Sie iTunes App Store-Rezensionen lesen, können Benutzer sie ziemlich gut erkennen. Ich werde keine Namen nennen, aber ich habe ein paar "Apps" auf meinem Telefon, die wie Müll aussehen und ausgeführt werden, und das liegt daran, dass es sich um Web-Apps handelt, die in UIWebView-Instanzen gehostet werden. Wenn ich eine Web-App verwenden wollte, würde ich Safari öffnen und zu einer navigieren. Ich habe ein iPhone gekauft, weil ich Dinge möchte, die iPhone-y sind. Ich habe kein Problem damit, beispielsweise eine schicke Google-Web-App in Safari zu verwenden, aber ich würde mich betrogen fühlen, wenn Google nur ein Lesezeichen auf Springboard schleicht, indem es eine Web-App als native App präsentiert.

Muss jetzt gehen. Meine Freundin hat den Ausdruck, dass Sie diesen Computer für drei Sekunden nicht mehr benutzen könnten.

Ich nehme an einem Kurs in Android / iPhone-Entwicklung teil und wir haben 8 Wochen mit Titanium verbracht (nicht Vollzeit) (Version war Titanium 1.4.2 und die Zeit war ungefähr im November 2010). Hier ist meine Erfahrung.

iPhone Android Dual-Ziel

Obwohl die API-Handbücher behaupten, dass die Funktionalität sowohl für Android als auch für iPhone verfügbar ist, ist dies nicht der Fall. Viele der Dinge funktionieren einfach nicht auf einer der Plattformen. Einige Dinge funktionieren anders.

Viele Leute in der Klasse haben iPhone-Anwendungen erstellt, und sie können sie nicht ohne größere Änderungen an Android arbeiten lassen. Ich entwickelte eine einfache Kinder-App namens Animap (siehe Android Market / Appstore in Schweden) und begann unter Windows zu entwickeln. Sobald das Android-Ziel funktioniert hat, habe ich das Projekt unter OS X geöffnet. Es werden keine Build-Inhalte für das iPhone angezeigt, nur für Android. Sie müssen ein Dual-Target-Projekt unter OS X starten. (Ok, ich habe die relevanten Dateien in ein neues Projekt kopiert.) Nächstes Problem - Die Animationen funktionieren nicht auf dem iPhone (sie funktionieren auf Android). Die Bildlaufereignisse funktionieren auf dem iPhone nicht gleich. (dh unter Android wird das Unberührungsereignis angezeigt, wenn der Benutzer aufhört zu scrollen und seinen Finger vom Bildschirm löst. Dies ist auf dem iPhone nicht der Fall.)

Da dies an keiner Stelle erwähnt wird, müssen Sie grundsätzlich zuerst auf einer Plattform und dann auf der anderen Plattform eine Versuchsprogrammierung durchführen. Mit Versuch und Irrtum meine ich, dass es ungefähr zwei Tage dauern wird, bis eine so einfache App wie Animap auf der anderen Plattform funktioniert. Sie müssen auch haben, wenn (Android) dann ... oder wenn (iPhone) ... überall in Ihrem Code ...

Herunterladen und einrichten

Sie müssen den Anweisungen auf den Brief folgen. Versuchen Sie nicht, Java 64 Bit zu verwenden. Die Demo-Anwendung KitchenSink 1.4.0 wird nicht kompiliert. (1.3 funktioniert in Ordnung!) Sie müssen Dateien direkt auf dem Laufwerk C ablegen, da lange Pfadnamen dazu führen, dass das externe Programm nicht alle Befehlszeilenparameter empfängt, wenn sie zu lang werden. (Für kleine Programme jedoch in Ordnung) 1/3 der Fälle stoppt die Toolchain einfach und Sie müssen erneut auf "Starten" klicken. Dann wird es wahrscheinlich funktionieren ... sehr unzuverlässig. Der Simulator wird beim Start nicht gefunden und dann müssen Sie einfach adb.exe mit Strg + Alt + Entf beenden und erneut versuchen.

Netzwerkverbindung

In einem WLAN-Netzwerk verlieren Sie manchmal die Live-Verbindung und Titanium stürzt auf Ihnen ab (die Kompilierungs- / Bereitstellungsschnittstelle). Wenn Sie keine funktionierende Internetverbindung haben, wird diese nicht gestartet, da Sie nicht bei ihren Servern angemeldet werden können.

API

CSS, HTML und jQuery sind im Vergleich dazu ein Kinderspiel. Titan ähnelt jeder anderen alten GUI-API, und Sie müssen einige Eigenschaften für jede einzelne Schaltfläche / jedes einzelne Feld / usw. Festlegen. Ein Feld falsch zu machen ist einfach zu einfach, sich an alle Eigenschaften zu erinnern, die eingestellt werden müssen? Haben Sie es an der richtigen Stelle mit Großbuchstaben geschrieben? (da dies nicht vom Compiler abgefangen wird, sondern als Laufzeitfehler angesehen wird, wenn Sie das Glück haben, diesen Teil zu testen)

In Titanium brechen die Dinge einfach zusammen, wenn Sie eine weitere Ansicht über einem Steuerelement hinzufügen oder auf eine andere Stelle in der GUI klicken.

Dokumentation

Einige API-Seiten tragen das Android-Symbol, geben jedoch nur dann eine Null zurück, wenn Sie versuchen, das Steuerelement zu erstellen. Sie sind trotz der Symbole nicht einfach auf der Android-Plattform verfügbar. Manchmal wird erwähnt, dass Android eine bestimmte Methode nicht unterstützt, aber dann fehlt die gesamte API.

Spüle

Die Demo-Anwendung. Habe ich erwähnt, dass es nicht kompiliert werden kann, wenn Sie es in Ihren Eclipse-Projektordner legen, weil der Pfad zu lang wird? Muss auf Ihrem Laufwerk C im Stammordner abgelegt werden. Ich benutze derzeit einen Symbolik-Link (mklink / J ...)

Undokumentierte Methoden

Sie müssen Dinge wahrscheinlich als label.setText ('Hello World') verwenden, um ein Label zuverlässig zu ändern, aber dies ist überhaupt nicht dokumentiert.

Debuggen

Titanium.API.info ('Ausdrucke sind die einzige Möglichkeit zum Debuggen');

Bearbeitung

Die APIs sind in keinem guten Format verfügbar, sodass Sie in Eclipse keine normale Code-Vervollständigung mit Hilfe usw. erhalten können. Aptana bitte helfen!

Hardware

Es scheint, dass der Compiler / die Tools nicht multithreaded sind, daher ist ein schneller Computer mit einer schnellen Festplatte ein Muss, da Sie viel Versuch und Irrtum machen müssen. Habe ich die schlechte Dokumentation erwähnt? Sie müssen dort alles ausprobieren, da Sie ihm nicht vertrauen können!

Einige positive Dinge

• Open Source

• Aus früheren Projekten habe ich mir versprochen, nie wieder Closed Source zu verwenden, da man Dinge nicht einfach reparieren kann, indem man Stunden und Arbeitskräfte darauf wirft. Wichtig, wenn Sie zu spät im Projekt sind und eine harte Frist einhalten müssen. Dies ist Open Source und ich konnte sehen, warum die Werkzeugkette reißt, und es auch tatsächlich beheben.

• Bugdatabase

• Es ist auch offen. Sie können einfach sehen, dass Sie nicht alleine sind und eine Problemumgehung durchführen, anstatt weitere 4 Stunden für Versuch und Irrtum aufzuwenden.

• Gemeinschaft

• Scheint in ihren Foren aktiv zu sein.

Bugs

• Titan 1.4 ist nicht threadsicher . Das heißt, wenn Sie Threads verwenden (verwenden Sie die Eigenschaft url: in einem createWindow-Aufruf) und programmieren, wie die Threads funktionieren, und Ereignisse mit Daten hin und her senden, stoßen Sie auf viele sehr, sehr seltsame Dinge - verlorene Handler, verloren Fenster, zu viele Ereignisse, zu wenige Ereignisse usw. usw. Dies hängt alles vom Zeitpunkt ab. Wenn Sie die Codezeilen in eine andere Reihenfolge bringen, kann dies zum Absturz oder zur Heilung Ihrer Anwendung führen. Das Hinzufügen eines Fensters in einer anderen Datei.js unterbricht die Ausführung Ihrer app.js ... Dadurch werden auch interne Datenstrukturen in Titanium zerstört, da sie manchmal interne Datenstrukturen parallel aktualisieren und einen gerade geänderten Wert mit etwas anderem überschreiben können.

Viele der Probleme, die ich mit Titan hatte, sind auf meinen Hintergrund auf Echtzeitsystemen wie OSE zurückzuführen, die Hunderte von Threads, Ereignissen und Nachrichtenübermittlung unterstützen. Dies sollte in Titanium 1.4 funktionieren, aber es funktioniert einfach nicht zuverlässig.

• Javascript (was für mich neu ist) stirbt stillschweigend bei Laufzeitfehlern. Dies bedeutet auch, dass kleine und häufige Fehler wie das falsche Schreiben eines Variablennamens oder das Einlesen eines Nullzeigers nicht abstürzen, wenn dies der Fall sein sollte, sodass Sie ihn debuggen können. Stattdessen funktionieren Teile Ihres Programms einfach nicht mehr, z. B. ein Eventhandler, weil Sie ein Zeichen falsch platziert / falsch eingegeben haben.

• Dann haben wir einfachere Fehler in Titanium, wie einige Parameter, die in den Funktionen nicht funktionieren (was zumindest auf der Android-Plattform ziemlich häufig ist).

• Geschwindigkeit des Test- und Fehler-Debug-Zyklus Nachdem ich Titnium Developer auf mehreren Computern ausgeführt hatte, stellte ich fest, dass der Engpass die Festplatte ist. Ein SSD-Laufwerk auf einem Laptop beschleunigt den Erstellungszyklus etwa drei- bis fünfmal schneller als auf einem Laufwerk mit 4200 U / min. Auf einem Desktop ist der Build mit zwei Laufwerken in RAID 1 (Striping-Modus) etwa 25 Prozent schneller als auf einem einzelnen Laufwerk mit einer etwas schnelleren CPU und übertrifft auch den Laptop mit SSD-Laufwerk.

Zusammenfassung

• Aus den Kommentaren in diesem Thread geht hervor, dass es einen Kampf um die Anzahl der Plattformen gibt, für die ein solches Tool Apps liefern kann. Die Anzahl der APIs scheint das Hauptverkaufsargument zu sein.

Dies scheint sehr gut durch, wenn Sie es verwenden. Wenn Sie sich den offenen Bugtracker ansehen, sehen Sie, dass die Anzahl der Fehler immer schneller zunimmt als die Anzahl der behobenen Fehler. Dies ist normalerweise ein Zeichen dafür, dass die Entwickler immer mehr Funktionen hinzufügen, anstatt sich darauf zu konzentrieren, die Anzahl der Fehler zu verringern.

Als Berater, der versucht, für einen Kunden relativ einfache Apps für mehrere Plattformen bereitzustellen, bin ich mir nicht sicher, ob dies tatsächlich schneller ist als die native App-Entwicklung auf zwei Plattformen. Dies liegt an der Tatsache, dass Sie mit Titan schnell sind, wenn Sie auf dem neuesten Stand sind, aber dann plötzlich nach unten schauen und sich in einem Loch befinden, das so tief ist, dass Sie nicht wissen, wie viele Stunden für eine Problemumgehung aufgewendet werden müssen. Sie können eine bestimmte Funktionalität für eine bestimmte Frist / Zeit / Kosten einfach NICHT versprechen.

Über mich selbst: Ich benutze Python seit zwei Jahren mit wxPython. (Diese GUI ist inkonsistent, bricht aber nie so ab. Vielleicht habe ich das von Javascript und Titanium verwendete Threading-Modell nicht verstanden, aber ich bin laut ihren offenen Diskussionsforen nicht allein. GUI-Objekte verwenden plötzlich den falschen Kontext / nicht aktualisieren .. ???) vorher habe ich einen Hintergrund in C- und ASM-Programmierung für mobile Geräte.

[Bearbeiten - Teil mit Fehlern hinzugefügt und nicht threadsicher] [Bearbeiten - jetzt seit einem Monat +, hauptsächlich auf dem PC, aber auch unter OS X. Duales Ziel für iPhone und Android hinzugefügt. Geschwindigkeit des Test- und Fehler-Debug-Zyklus hinzugefügt.]

Das Corona SDK (Ansca Mobile) verwendet Lua als Codierungssprache. Weitere Informationen zu Lua finden Sie auf lua.org.

Während wir planen, weitere Webintegrations- und native UI-Elemente hinzuzufügen, wird unser Fokus eher auf grafikintensiven Anwendungen wie der Spieleentwicklung als auf webbasierten Technologien liegen. Mit anderen Worten, wir stellen uns nicht vor, dass Leute Corona-Apps vollständig in Javascript / HTML / CSS schreiben.

Ich arbeite jetzt seit über einer Woche mit Titan und habe das Gefühl, ein gutes Gefühl für seine Schwäche zu haben.

1) Wenn Sie hoffen, dass Sie denselben Code auf mehreren Plattformen verwenden, viel Glück! Sie werden so etwas wie backgroundGradient sehen und erstaunt sein, bis Sie herausfinden, dass die Android-Version es nicht unterstützt. Müssen Sie dann wieder ein Verlaufsbild verwenden, können Sie es auch für beide Versionen verwenden, um den Code zu vereinfachen, oder?

2) Viele seltsame Verhaltensweisen, auf dem Titanium Android SDK müssen Sie verstehen, was ein "schweres" Fenster ist, nur um die Zurück-Taste zum Laufen zu bringen oder um Ereignisse besser zu orientieren. So ist die Android-Plattform nicht wirklich, sondern nur so, wie Titanium versucht, ihre API zum Laufen zu bringen.

3) Wenn Sie in die Dunkelheit geworfen werden, stürzen die Dinge ab und Sie müssen anfangen, Code zu kommentieren. Wenn Sie ihn finden, verwenden Sie ihn niemals. Es gibt bestimmte offensichtliche Fehler, wie Orientierung und Prozente auf Android, die seit über sechs Monaten ein Problem sind.

4) Bugs .... es gibt viele Bugs und sie werden gemeldet, monatelang herumgesessen, in ein paar Tagen behoben. Ich bin überrascht, dass sie sogar planen, ein Black Berry Mobile SDK herauszubringen, wenn es so viele andere Probleme mit Android gibt.

5) Titanium Iphone versus Titanium Android Javascript Engines sind völlig unterschiedlich. In der Android-Version können Sie Remote-Javascript-Dateien herunterladen, Bibliotheken wie Mootools, JQuery usw. einschließen und verwenden. Ich war im Himmel, als ich das herausfand, weil ich meine Android-App nicht weiter kompilieren musste. Der Installationsprozess für Android Apk dauert so lange! Iphone nichts davon ist möglich, auch die iPhone-Version hat eine viel schnellere Javascript-Engine.

Wenn Sie sich von vielen nativen UI-Teilen fernhalten, verwenden Sie stattdessen setInterval, um Orientierungsänderungen zu erkennen, sich an Verlaufsbilder zu halten, die Schaltfläche "Zurück" zu vergessen, eigene Animationen zu erstellen, Fensterüberschriften, Symbolleisten und das Dashboard zu vergessen. Sie können wirklich eine API erstellen, die auf beiden funktioniert und nicht viel Umschreiben erfordert. Aber an diesem Punkt ist es genauso träge wie eine Webapp.

Lohnt es sich also? Nach all dem Schmerz ist es jede Minute wert. Sie können die Logik abstrahieren und einfach eine andere Benutzeroberfläche für jede erstellen, anstatt überall. Mit Titan können Sie flüssige Anwendungen durchführen, die sich schnell anfühlen. Sie verlieren die leistungsstarken Layoutfähigkeiten jeder Plattform, aber wenn Sie einfach denken, können die Dinge in einer einzigen Sprache erledigt werden.

Warum nicht eine Web-App? Auf Einstiegs-Android-Handys ist es schrecklich langsam, eine Webansicht zu generieren, und verbraucht viel Speicher, den Sie für komplexere Logik verwenden könnten.

Hier ist eine neuere und eingehendere Analyse von Appcelerator und PhoneGap: http://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap

Und hier ist noch detaillierter, wie sie sich programmatisch unterscheiden: http://savagelook.com/blog/portfolio/phonegap-is-web-based-appcelerator-is-pure-javascript

Das native Mapkit wird in Titanium unterstützt

HTML5-Widgets so zu gestalten, dass sie wie iPhone-Widgets aussehen, ist eine Sache, aber eine gleich gute Leistung zu erzielen, ist eine ganz andere Sache. Die Leistung von HTML5-Animationen (auch einfache Ansichtsübergänge), das Scrollen langer Listen und die Reaktion auf Gesten fühlen sich klebrig und ruckartig an. Ein iPhone-Benutzer wird den Unterschied bemerken.

Es gibt auch einige Unterschiede in der Art der Gesten, die von verschiedenen Geräten unterstützt werden, was ebenfalls zu plattformspezifischem Code und Usability-Problemen führt.

Ich werde vorerst bei nativen Apps bleiben, denke ich.

Rhomobile Rhodes ( http://rhomobile.com/products/rhodes ) ist dem Ansatz von PhoneGap sehr ähnlich, ist jedoch das einzige Framework mit:

1. ein Model View Controller-Muster (wie die meisten Web-Frameworks bieten)
2. ein Object Relational Manager
3. Unterstützung für alle gängigen Smartphones (einschließlich Windows Phone 7)
4. Ein gehosteter Entwicklungsdienst (nicht nur ein gehosteter Build): http://rhohub.com
5. Ein vollständiger Debugger und SDK-freier Emulator in der RhoStudio IDE
6. Unterstützung für synchronisierte Offline-Daten

Für alle, die sich für Titan interessieren, muss ich sagen, dass sie keine sehr gute Dokumentation haben. Einige Klassen, Eigenschaften und Methoden fehlen. Aber in ihrer Beispiel-App KitchenSink ist viel "dokumentiert", so dass es nicht so schlimm ist.

Mein Verständnis von PhoneGap ist, dass sie Javascript-APIs für einen Großteil der iPhone-APIs bereitstellen.

Titan scheint für einen Webentwickler einfacher zu sein. Es ist eine einfache XML-Datei, um eine grundlegende TabView-Anwendung zu erstellen, und dann wird alles im Inhaltsbereich von HTML / JS gesteuert. Ich weiß auch, dass Titanium Javascript-Zugriff auf einige der Frameworks bietet (insbesondere Zugriff auf Standortinformationen, die Telefon-ID usw.).

UPDATE: Titanium hat die Maps-API in Version 0.8 ihres Frameworks hinzugefügt.

Sie sollten Ziel c lernen und native Apps programmieren. Verlassen Sie sich nicht auf diese Dinge, von denen Sie glauben, dass sie das Leben leichter machen. Apple hat sichergestellt, dass der einfachste Weg die Verwendung der nativen Tools und der Sprache ist. Für Ihre 100 Zeilen Javascript kann ich das gleiche in 3 Codezeilen oder überhaupt keinen Code tun, je nach Element. Sehen Sie sich einige Tutorials an - wenn Sie Javascript verstehen, ist Ziel c nicht schwer. Problemumgehungen sind miserabel und Apple kann jederzeit den Stecker ziehen.

Von den von Ihnen erwähnten Lösungen scheint Ihnen keine direkten Zugriff auf das in OS 3.0 eingeführte MapKit-Framework zu ermöglichen.

Da die HTML-Widgets von Google Maps bei weitem nicht so gut sind wie MapKit (ein Beispiel finden Sie in Google Latitude), sollten Sie am besten eine native Cocoa Touch-Anwendung entwickeln oder eine Lösung auswählen, die Sie erweitern können, um die MapKit-Integration hinzuzufügen. PhoneGap ist auf diese Weise erweiterbar (es ist Open Source, also standardmäßig), und einige der anderen Lösungen könnten es auch sein.

Bearbeiten: Titan unterstützt jetzt MapKit

Ich habe Corona ausprobiert. Es war gut, bis ich herausfand, dass es kein Streaming von MP3-Audio unterstützt. Also habe ich genau dort angehalten. Ich denke, wenn ich wirklich ein iPhone App Entwickler sein will, sollte ich lernen, obj c. Ich wollte nur eine App erstellen, die eine Liste von Radiosendern enthält, und wenn Sie darauf klicken, wird sie abgespielt.