Jan 22

Für mich persönlich stellt JavaScript seit einiger Zeit immer wieder eine große Herausforderung dar. Insbesondere seit in Titanium Appcelerator das JSCommon Framework zum Einsatz kommen darf und soll. Meine erste iPad-App soll nun endlich fertig werden und ich stand vor der Herausforderung innerhalb einer Klasse setInterval für periodische Aufgaben benutzen zu wollen. Jede Klassen-Instanz sollte natürlich seinen eigenen Timer benutzen. Hier ist meine Lösung – runtergekocht auf eine Minimal-App bestehend aus der obligatorischen app.js und dem Module processingQueue.js:

Als Screenshots:

app.js - titanium appcelerator

Die eigentliche OOP-Klasse

 

Und hier nochmal als Quelltext zum rauskopieren :-)

Die Datei app.js instanziert zwei Objekte der Klasse processingQueue

  1. // App.js
  2. var pq = require('modules/processingQueue');
  3.  
  4. Ti.API.info("Erstelle PQ1:");
  5. PQ1 = new pq.processingQueue(200, "-Eins");
  6. Ti.API.info("Erstelle PQ2:");
  7. PQ2 = new pq.processingQueue(500, "#Zwei");

 

Das JSCommon Module processingQueue implementiert die gleichnamig Klasse, die ein Timer-Objekt initialisiert:

  1. // JavaScript Object Class processin Queue using JSCommon Modules
  2.  
  3. // Constructor:
  4. function processingQueue(timerInterval, theName) {
  5. this.myName = theName;
  6.  
  7. if(!(this.queueTimerHandle)) {
  8. var holder = this;
  9. this.queueTimerHandle = setInterval( function() {
  10. holder.applicationQueueProcessing(holder);
  11. }, timerInterval);
  12. }
  13. };
  14.  
  15. // This function is called timer based
  16. processingQueue.prototype.applicationQueueProcessing = function(me) {
  17. Ti.API.info("Processing Queue Name:" + me.myName);
  18. }
  19.  
  20. exports.processingQueue = processingQueue;

Ich hoffes es hilft jemandem…

Oct 04

Regelmäßig sieht man in den letzten Monaten einschlägige Fachzeitschriften, die Artikel über Appcelerator bringen – teilweise sogar auf der Titelseite. Dort wird dann auf wenigen Seiten beschrieben, wie einfach es doch sei mit diesem Tool Crossplattform-Entwicklung für mobile Endgeräte (vornehmlich solche mit iOS und Android) zu betreiben.

Nachdem ich nun einige Wochen mit der Appcelerator-gestützten Entwicklung einer iPad-App verbracht habe, kann ich nur sagen: Es stimmt – ist aber nur die halbe Wahrheit. Denn so lange man nur nette kleine Demo-Projekte umsetzt ist alles “Heile”. Natürlich vermisst man hier auch schon Einiges. So ist beispielsweise die Dokumentation eine einzige Katastrophe. Aber da hilft einem die rege Community gerne weiter. Und ein Workaround lässt sich auch oft genug finden.

Sehr besorgt wird man dann, wenn man sich anschaut wie lange manche Bugs schon bekannt sind und nicht gefixt werden. Im sogenannten “Forum” von Titanium werden solche Probleme von offizieller Seite zumeist auch ignoriert. Man kann zwar im Bug-Tracking-System ein Ticket eröffnen. Aber mangels einer öffentlichen Roadmap und Feedback, ist danach völlig unklar was mit diesem Bug geschieht und wann man mit einer Auslieferung des Bugfix rechnen darf.

So kann man natürlich keine kommerzielle Produkte erstellen bei denen der Kunde mit einer Deadline winkt. Folgerichtig, gibt es auch immer mehr Entwickler, die Appcelerator wieder den Rücken kehren und zurück gehen zur “echten” nativen Entwicklung mit Xcode oder Java.

Eine aktuelle und sehr interessante Diskussion zu dem Thema gibt es in Andrea Dalleras Blogbeitrag “Why you should stay away from Appcelerator’s Titanium”. Natürlich gibt es dort auch positive Stimmen, die auf die Vorteile von Appcelerator verweisen (zu recht!). Die Mehrzahl der Kommentatoren unterstützt aber sehr Kenntnisreich die Aussage von Andreas Beitrag.

Wie häufig in diesen Fällen zu beobachten, wird gerne auf alternative Programmiertechniken verwiesen, die die bekannten Memory-Probleme umgehen sollen. Sicher werde ich diese ausprobieren. Frustrierend und verwunderlich nur, dass die offiziellen Best-Practice-Beispiele, andere Vorgehensweisen propagieren.

Ich werde jetzt ein wenig nostalgisch, wenn ich an dieser Stelle noch den Vergleich zu anderen Cross-Plattform-Tools ziehe. Allen voran Flash und vor allem Director (früher von Macromedia – heute auch bei Adobe zu einem Dornröschenschlaf verdammt.) Diese Tools hatten auch immer ihre Macken und Probleme. Aber so heftig wie bei Appcelerator war es nie!
(Nach wie vor bleibt es mir ja unverständlich, warum Adobe auf Flash setzt als Basis für seine Mobile-Crossplattform-Strategie) statt auf das wesentlich bessere Director-Tool. Aber hier mag meine Wehmut die Objektivität trüben…

Quintessenz: Titanium Appcelerator ist derzeit noch instabil und kann für die produktive App-Entwicklung nur mit großer Vorsicht verwendet werden. Die Unternehmensstrategie scheint sehr von den Investoren getrieben zu sein, die es (bisher) besser fanden von neuen Features zu lesen als von stabilen Werkzeugen. Mal sehen, ob sich dies bald ändert, wenn immer mehr Entwickler Ihren Frust in Blogbeiträgen kund tun…

Why you should stay away from Appcelerator’s Titanium