Hidden Files

Die komfortabelste Lösung, versteckte Dateien in Finder ein- und auszublenden ist, sich jeweils eine einfache Automator-Aktion zu schreiben. Hierzu einfach das Programm Automator starten, als Vorlage “Dienst” auswählen und eine neue Aktion “Shell-Skript ausführen…” wie folgt anlegen (click to enlarge):

Nun einfach “Speichern unter…”, einen sprechenden Namen vergeben unter dem die Aktion dann als Dienst auftauchen soll (z.B. “Show Hidden Files”) und fertig. Nach dem gleichen Verfahren eine zweite Aktion “Hide Hidden Files” erstellen, wobei die erste Zeile des Skripts dann entsprechend wie folgt lautet:

defaults write com.apple.finder AppleShowAllFiles FALSE

Gespeichert sind diese Automator-Aktionen unter ~/Library/Services (nur für den Fall, dass man sie irgendwann mal wieder entfernen möchte). Aufrufen lassen sich diese Dienste jetzt über das Finder-Menü:

Damit aber nicht genug: richtig komfortabel wird es erst, wenn wir diesen Diensten noch Tastaturkürzel zuweisen. Hierzu einfach wie oben zu sehen auf “Dienste-Einstellungen…” gehen und dort jeweils rechts neben dem gewünschten Dienst einmal doppelklicken (sodass das Eingabefeld erscheint) und dann die gewünschte Tastenkombination drücken – schon wieder fertig.

Wem das Erstellen dieser Automationen noch zu aufwändig ist, der kann auch einfach die nachfolgende ZIP-Datei herunter laden, entpacken und die beiden enthaltenen Dateien einfach nach ~/Library/Services kopieren

hidden-files-services.zip

Stay tuned…

Das dritte Hamburg Web Performance Meetup fand am 25. April in den Räumlichkeiten von Telefónica in der City Nord statt. Den fast vierzig Teilnehmern, die sich trotz eines zeitgleich laufenden, hochkarätigen Champions-League-Spiels nicht vor den Fernseher gesetzt hatten, wurden zwei interessante Vorträge geboten.

Den Anfang machten Jan Vogel (DI UNTERNEHMER) und Uwe Beßle (Iteratec) mit dem Thema “Optimierung der gefühlten Performance – Web Performance Management für Fortgeschrittene”. Die beiden präsentierten ihre Erfahrungen, die sie im Umfeld einer der weltweit größten eCommerce-Sites gemacht haben. Vorgestellt wurden u.a. eigene Metriken für Performance und Kundenzufriedenheit.

Im Rahmen des Projekts wurden End-User-Tests mit etwa 1.500 Probanden sowie automatisierte Tests mit dem Tool WebPagetest (WPT) durchgeführt. Mit Best-Practise-Beispielen zu WPT und einem regen und ausführlichen Frage-und-Antwort-Teil endete dieser Vortrag.

Der zweite Teil des Abends bestritten Oliver Ochs und meine Wenigkeit mit unserer Präsentation “Building Performance, ein Frontend-Build-Prozess”.

Wir haben einen auf Maven basierenden Build-Prozess vorgestellt, mit dem die Frontent-Komponente des DSL-Portals von Telefónica O₂ erstellt wird. In mehreren Schritten sorgt dieser Build-Prozess automatisiert dafür, dass HTML, CSS, JavaScript und Bildelemente hinsichtlich der Web Performance optimiert werden. Dabei kommen unter anderem Werkzeuge wie OptiPng, Web Ressource Optimizer, JSLint, CSSLint und der Google Closure Optimizer zum Einsatz, die als Maven-Plugins ohne großen Aufwand in den Prozess integriert werden.

Der Abend endete mit einer Verlosung von Fachbüchern des Sponsors unseres Web Performance Meetups in Hamburg, dem O’Reilly Verlag.

Unser Vortrag zum Frontend-Build-Prozess ist bei SlideShare verfügbar:

• Building Performance – ein Frontend-Build-Prozess für Java mit Maven

Geplant sind wieder zwei Talks:

Jan Vogel (DI UNTERNEHMER) und Uwe Beßle (Iteratec) – Optimierung der “gefühlten” Performance – Web Performance Management für Fortgeschrittene

Anhand konkreter Erfahrungen im Umfeld einer der größten eCommerce Sites wird vorgestellt, wie es gelingt, das subjektive Kundenempfinden zum Maßstab für das kontinuierliche Web-Performance-Management der komplexen Anwendungslandschaft einer großen eCommerce-Site zu machen. Dabei wird die Entwicklung und Definition von Ladezeit-Indikatoren und deren Messung mit dem Open Source-Tool WebPagetest beleuchtet. Es wird vorgestellt, wie die Auswirkung von Ladezeiten auf die Kundenzufriedenheit mittels einer Remote-Studie abgeleitet werden kann. Abgerundet wird der Vortrag mit einer Darstellung von Best-Practise-Beispielen bei der Arbeit mit WPT und WPT-Monitor.

Jan Weinschenker und Oliver Ochs (Holisticon AG) – Building Performance, ein Frontend-Build-Prozess

In diesem Vortrag geht es um eine konkrete Website. Im ersten Teil des Vortrags stellen wir die wichtigsten Optimierungsmaßnahmen vor, die außerhalb eines Builds durchgeführt wurden. Für eine dauerhafte, nachhaltige Performance-Optimierung müssen die Maßnahmen automatisiert bzw. in den Build-Prozess integriert werden. Im zweiten Teil des Vortrags zeigen wir einen beispielhaften Build-Prozess für Java-Webanwendungen, der Teile der Optimierungsmaßnahmen durchführt. Andere Teile müssen durch eine geeignete Architektur sichergestellt werden, wofür wir ebenfalls Ideen liefern.

Das Event ist leider sowohl bei Meetup.com als auch in der XING-Gruppe bereits ausgebucht.

Diese Geräte sind heutzutage vollgepackt mit vielfältigen technischen Gimmicks: GPS-Modul, Beschleunigungssensor, Kontaktverwaltung, Kamera uws. gehören bei iPhone, Android & Co. zum Standard. Eine für mobile Geräte optimierte Webseite hat oft nur eingeschränkten Zugriff auf diese Funktionen.

Für den vollen Zugriff benötigt man eine App, die direkt auf dem mobilen Gerät installiert wird. Als Entwickler muss man sich dann vor seinen Rechner setzen und die App für das iPhone oder für Android entwickeln. Die entsprechenden Entwicklungswerkzeuge sind für sich genommen sehr komfortabel. Nur ist man zunächst einmal an eine der SmartPhone-Welten gebunden.

Das ist natürlich sehr unbefriedigend, wenn man einen großen Anwenderkreis ansprechen will.

Doch wie kommt man zu einer brauchbaren App, die auf vielen mobilen Geräten läuft, ohne sich allzu tief in die speziellen Niederungen der Android- oder iOS-Entwicklung hinab begeben zu müssen?

Hybride Apps

Die Antwort auf diese Frage sind hybride Entwicklungs-Frameworks wie z.B. PhoneGap oder Titanium.

Diese Werkzeuge bieten eine einheitliche Programmiersprache, mit der Apps für unterschiedliche Zielplattformen entwickelt werden können.

Die Frameworks werden als Hybride bezeichnet, weil sie zum einen die Funktionalitäten nativer Apps anbieten können. Mit vollem Zugriff auf die Hardware können sie die Kamera, GPS-Modul usw. nutzen. Zum anderen werden sie jedoch nicht in der nativen iPhone- oder Android-Programmiersprache, also Objective-C oder Java geschrieben. Bei den genannten Frameworks arbeitet man mit JavaScript, CSS und HTML5.

Mit diesem Ansatz erreicht man recht schnell brauchbare Ergebnisse, ohne sich in die Besonderheiten einzelner mobiler Plattformen einarbeiten zu müssen.

Diesen Vorteil erkauft man sich jedoch damit, dass sich die App später nicht genau wie eine native App “anfühlt”.

Womit wir zu den Nachteilen hybrider Apps kommen.

Nachteile

PhoneGap bildet die echten Bedienelemente von iOS und Android lediglich nach. Es verwendet eine WebKit-Engine, die JavaScript, HTML und CSS auf den mobilen Geräten zur Laufzeit interpretiert. Im Vergleich zu kompilierten, nativen Apps hat man also einen Geschwindigkeits-Nachteil. Das macht sich direkt bei der Bedienung bemerkbar. Zwischen dem Antippen des Touch-Screens und der Reaktion der App gibt es meist merkbare Latenzen. Titanium verwendet zumindest native Bedienelemente, die Implementierung der Anwendungslogik erfolgt aber auch hier mittels JavaScript.

Dazu kommt, dass viele Programmierfehler bei interpretiertem Code erst zur Laufzeit, also während der Benutzung, zutage treten.

Der Build-Prozess gestaltet sich ebenfalls etwas komplizierter. Wird eine PhoneGap-App für Android entwickelt, kann dies mit der IDE Eclipse erfolgen. Eclipse erzeugt eine APK-Datei, die mit eine Android-SmartPhone direkt verwendet werden kann. Soll die gleiche App jetzt auf das iPhone gebracht werden, benötigt man entweder die dazu gehörige IDE Xcode oder einen kostenpflichtigen, Cloud-basierten Dienst von PhoneGap. Das gleiche gilt auch für Titanium.

Mehr Entwicklungsaufwand fällt an, wenn die App trotz der Verwendung eines hybriden Frameworks nativ aussehen soll – also, wenn sie auf einem iPhone genauso aussehen soll wie eine native iPhone-App und auf einem Android genau so wie eine native Android-App. In diesem Fall muss sie für jede unterstützte Plattform eine eigene Benutzeroberfläche zur Verfügung stellen.

Auf die Software-Qualität kommt es an

Diese Nachteile sind jedoch beherrschbar, wenn die Entwickler sorgfältig arbeiten und hinreichender Aufwand ins Qualitätsmanagement gesteckt wird. Dies ist gerade bei mobilen Apps besonders kritisch, da es über die Rating-Funktionen in den App-Stores und -Markets sehr schnell und für die ganze Welt sichtbar, gnadenloses Feedback der Anwender gibt.

Insofern gelten bei der App-Entwicklung dieselben Anforderungen an qualitativ hochwertige Software, die auch bei der Entwicklung von Nicht-App-Software schon immer gegolten haben.

Weblinks

• PhoneGap Webseite
• Titanium Webseite

Eine typische Vaadin-Applikation (aus Book of Vaadin, Getting started):

public void init() {
   final Window mainWindow =
      new Window("Myproject Application");

   Label label = new Label("Hello Vaadin user");
   mainWindow.addComponent(label);

   mainWindow.addComponent(
      new Button("What is the time?",
         new Button.ClickListener() {
         public void buttonClick(ClickEvent event) {
            mainWindow.showNotification(
               "The time is " + new Date());
         }
      }));

 setMainWindow(mainWindow);
}

Sobald die Anwendung etwas größer wird, bekommt man jedoch zwangsläufig die klassischen Stand-Alone-Anwendungsprobleme: verschachtelte Komponenten, ausgelagerte Handler, implementierte Listener, gekapselte Service-Facaden … ein Haufen Instanzen will erzeugt und verwaltet werden. Nebenbei arbeitet man auf 3 Scopes (Application, Session, Request), bemüht sich um Separation of Concern und achtet auf maximale Testbarkeit.
Das wird “per Hand” schnell unübersichtlich. Naheliegend ist, sich bei der Verwaltung der Instanzen helfen zu lassen. Wenn man das Pech hat, nicht auf JEE6 und CDI zurückgreifen zu können (konkret arbeiten wir nach wie vor auf JBoss 5.1), ist die Frage:

Wie?
Oder anders formuliert: Spring oder Guice?

Wir haben uns gegen Spring und für Guice entschieden. Ausschlaggebend waren die leichtgewichtige Integration (wenige Jars ins WEB-INF/lib – und fertig) und die Tatsache, dass wir ohnehin die Geschäftslogik mit EJB3 entwickeln, also für die diversen Spring-Erweiterungen in dem Bereich keinen Bedarf haben.

Die Kombination von Guice und Vaadin ist mit der guice-servlet-Extension eigentlich schnell gemacht. Der Teufel steckt dann natürlich wie so oft im Detail, weshalb wir mit diesem Blog etwas Licht ins Dunkel bringen wollen.

Grundgerüst

Wir verwenden Eclipse mit dem Vaadin Plugin und Maven. Ein neues Projekt lässt sich dann einfach mit “new Maven Project” und dem Archetype “vaadin-clean” erstellen. Wenn dieser noch nicht installiert ist, kann er wie folgt hinzugefügt werden:

Der Archetype ist leider, was die Versionsnummern angeht, etwas veraltet. im Beispielprojekt, das am Ende des Artikels heruntergeladen werden kann, sind die Einstellungen für das aktuelle Vaadin 6.7.6 angepasst.

Guicify

Guice benötigt einen Bootstrapper, der den Injector erzeugt, welcher dann die Erzeugung weiterer Instanzen übernimmt. Es wäre zwar möglich, diesen in der init()-Methode der Vaadin-Applikation aufzubauen und anschließend die Members der Application-Klasse injizieren zu lassen. Wesentlich eleganter und praktikabler ist es jedoch, bereits die Applikation selbst und somit alle Instanzen von Anfang an von Guice verwalten zu lassen.

Dazu muss ein Guice-Filter in der web.xml registriert werden und auf einen ServletContextListener umgeleitet werden.

web.xml

<display-name>vaadin-guice</display-name>

	<context-param>
		<description>Vaadin production mode</description>
		<param-name>productionMode</param-name>
		<param-value>false</param-value>
	</context-param>

	<filter>
		<filter-name>guice.filter</filter-name>
		<filter-class>com.google.inject.servlet.GuiceFilter</filter-class>
	</filter>

	<filter-mapping>
		<filter-name>guice.filter</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>

	<listener>
		<listener-class>de.holisticon.blog.vaadin.configuration.ApplicationServletContextListener</listener-class>
	</listener>

ApplicationServletContextListener.java und ApplicationModule.java

public class ApplicationServletContextListener extends GuiceServletContextListener {

    @Override
    protected Injector getInjector() {
        return Guice.createInjector(new ApplicationModule());
    }

}
public class ApplicationModule extends AbstractModule {
    private Properties properties = new Properties();
    public ApplicationModule() {
        properties.put("window.caption", "Main Application");
        properties.put("label.text", "Hello Vaadin user");
    }

    protected void configure() {
        install(new ServletModule() {
            protected void configureServlets() {
                serve("/*").with(ApplicationServlet.class);
                bind(Application.class).to(MainApplication.class).in(ServletScopes.SESSION);
            }
        });
        Names.bindProperties(binder(), properties);
    }

    @Provides
    @Named("MainWindow")
    public Window provideMainWindow(@Named("window.caption") String windowCaption) {
        return new Window(windowCaption); // liefert das MainWindow mit konfiguriertem Titel
    }
}

Nun wird jeder Zugriff auf “vaadin-guice/*” von Guice verwaltet und an eine Instanz der MainApplication geroutet. Die MainApplication liegt im Scope “Session”, jeder User bekommt also eine eigene Instanz erzeugt. Nun können wir die Beispiel-Anwendung auf Injektion umstellen:

MainApplication.java

public class MainApplication extends Application {
    @Inject @Named("MainWindow")
    private Window mainWindow; // Window mit konfigurierter Caption

    @Inject @Named("label.text")
    private String labelText;

    @Inject
    private Provider<Date> date;

    @Override
    public void init() {
        setMainWindow(mainWindow);
        mainWindow.addComponent(new Label(labelText));

        mainWindow.addComponent(
                new Button("What is the time?",
                        new Button.ClickListener() {
                            public void buttonClick(ClickEvent event) {
                                mainWindow.showNotification("The time is " + date.get());
                            }
                        }));
    }
}

Nach Start der Anwendung mit mvn jetty:run können wir das Ergebnis im Browser begutachten:

Wird der Einsatz von @Inject auf allen verwendeten Komponenten und Handlern konsequent durchgezogen, kann mit einfachen Mitteln eine transparente, lose gekoppelte Rich Internet Application aufgebaut werden, bei der jede Instanz genau die Dependencies erhält, die sie benötigt.

Fazit

Vaadin und Guice kooperieren hervorragend. Das Injection-Verhalten ist transparent und programmatisch durch Erweiterung der Modules konfigurierbar.
Zu beachten bleibt: Da die Applikation im Session Scope läuft, ist bei Zugriff auf Request-spezifische Daten (etwa die Request-Parameter) besondere Vorsicht angeraten: auf keinen Fall dürfen solche Elemente als Instanzfelder der Applikation gespeichert werden. Guice-Provider können jedoch eingesetzt werden, um diese Scope-Grenze zu umgehen.
Im Gegensatz zu CDI werden keine Anforderungen an den Servlet-Container gestellt, so dass die Entwicklung leicht mit Tomcat oder Jetty erfolgen kann.
Werden die (seit Guice 3.0 unterstützten) JSR330 Annotationen verwendet, ist sogar ein späterer Umzug in einen CDI bzw. Spring Container möglich.

Das komplette Maven-Beispielprojekt kann hier heruntergeladen werden

Den ganzen zweiten Tag lang besuchten wir den Business-Track. Darüber, ob das an dem beeindruckenden Vortrag von Herrn Konjovic über die Paid-mobile-Content-Strategie von Axel Springer am Vortag lag, lässt sich streiten.

“Es ist ja nur eine App” – oder vielleicht doch nicht?

Der zweite Tag startete für uns mit einem Vortrag von Dr. Ralf Carbon vom Fraunhofer Institut. Neben einem Ausblick in die unterschiedlichen Arten von Apps (Consumer / Business) stellte er die Konzepte zweier vom Fraunhofer Institut betreuten Mobile-Projekte vor.

Beeindruckend war der Nutzen, der im Bereich der Landwirtschaft durch verschiedene Apps für John Deere erzielt werden konnte. So gibt es Apps für die Wartung und den Service der Maschinen, eine App für den Landwirt, der auf seinem iPad die Task-Planung vornimmt und eine für den Arbeiter auf dem Feld, der durch eine iPhone-App diese Tasks bekommt und bei der Umsetzung, durch Standortermittlung (bin ich auf dem richtigen Feld?) etc. unterstützt wird. Hier fällt auf, dass für jeden individuellen Anwendungsfall eine eigenständige App gebaut wurde, die nur auf den Nutzen des jeweiligen Anwenders reduziert ist. Ergo kommt es bei Apps stets auf den Kontext an.

Ebenfalls spannend war der Exkurs zu Lufthansa Systems. Hier wurde eine App realisiert, die Piloten das Leben dahingehend erleichtert, dass sie ihre Karten nicht mehr in riesigen Aktenordnern in ihren Pilotenkoffern hinter sich herziehen und bei jeder Änderung neu in ihre Ordner einpflegen müssen. Eine App verwaltet dieses Kartenmaterial automatisch, stellt es dar und übernimmt auch die Aktualisierung des Kartenmaterials bei Änderungen.

Neben der Vorstellung der beiden realisierten Projekte wurde der Prozess namens “mConcAppt”, den das Fraunhofer Institut für die App-Entwicklung erstellt hat (und selbstverständlich auch jedem vorschlägt), vorgestellt.

Er soll helfen, eine Antwort auf die zentralen Fragen der App-Entwicklung zu finden.

• Welche Anforderungen habe ich an das Testen?
• Welche an die User Experience?
• Welche an das Variantenmanagement (Apps für spezifische Kontexte, verschiedene Plattformen)?
• Gibt es ein Mobilitätspotential für den Workflow, den Geschäftsprozess, die Aufgaben etc?
• Ist es die “richtige” App für den Score?
• Ist das Backend für den mobilen Anwendungsfall geeignet?
  Interessant ist hier das erwähnte Verhältnis von 80 zu 20, wenn es um den Arbeitsaufwand von Backend-Entwicklung und Frontend-Entwicklung geht. Dieses Verhältnis können wir nur bestätigen.
• Welche Architektur ist die richtige für meine App (Nativ, Hybrid oder Web)?
• Welche Anforderung stelle ich an die Interaktion (UI, UX etc.)?

Der “mConcAppt”-Prozess beginnt dabei mit einem eintägigen Workshop zur Anforderungserfassung mit Kunde, Anwender, Fachabteilung etc., um in den folgenden zwei bis drei Wochen ein komplettes Konzept für die App zu erarbeiten.

Sehr große Erfolge haben sie dabei mit einfachen Prototypen in Form von Bleistiftzeichnungen und Wireframetools wie Balsamiq erzielt.

Klingt für uns alles sehr stark nach Wasserfall, auch wenn Herr Dr. Carbon erwähnte, dass es mehrere Zyklen in den einzelnen Schritten von “mConcAppt” gibt. Interessant wäre, wie sich das Ganze mit agilen Methoden in Einklang bringen ließe.

Die Mobile-Plattform der Zukunft: Facebook

Martin Szugat gab uns einen Einblick die App-Welt von Facebook und nannte dabei viele interessante Fakten zu Facebook.

• In den USA verbringen die Leute 16% ihrer Online-Zeit auf Facebook
• 57% der Smartphone User sind bei Facebook
• 47% der Zeit verbringen die Amerikaner mit Spiele- und 32% mit Soziale-Netzwerke-Apps
• Als Nutzer zählt Facebook nur Nutzer, die innerhalb der letzten drei Tage online waren
• 7.000.000 Webseiten sind mit Facebook verbunden
• Jeden Tag kommen 10.000 hinzu
• 20 Millionen Facebook-Apps werden pro Tag installiert

All diese Fakten unterstreichen, dass über Facebook sehr viele Menschen erreicht werden können und dass Facebook sehr tief im Web “verankert” ist.

Ebenfalls erklärte er das neue Marketing-Buzzword “SoLoMo”. Die Leute wollen sich vernetzen (Social), wollen zeigen, wo sie sind bzw. sagen, was um sie herum los ist (Local) und wollen das auch noch alles mobil machen (Mobile). Als Beispiele, die “SoLoMo” sehr gut umsetzen, nannte er Glancee und Badoo. Einen Dienst, der eine “neue Ebene” in Facebook einführt, indem er Leute mit gleichen Interessen zusammenführt und eine etwas andere Dating-Plattform. Gemeinsam haben beide, dass sie in Verbindung mit Facebook extrem geringe Customer Acquisition Costs haben.

Nach einem Exkurs ins Marketing wurden die Technik von Facebook Apps und die Zukunft von Facebook thematisiert.

Facebook Apps könnnen bei Facebook einfach via iFrame eingebunden werden, d.h., der App-Anbieter muss sich selbst um das Hosting etc. kümmern. Jeder Nutzer muss die Daten, die eine App nutzen darf, explizit freigeben, es macht also den Eindruck, als ob ordentlich mit den Daten umgegangen wird.

Werden Apps für mobile Endgeräte erstellt, so können diese via HTML5 oder Nativ realisiert werden. Als Vorteil von HTML5 wurde erwähnt, dass eine APP nur einmal geschrieben werden muss und so für Desktop und für Mobile eingesetzt werden kann. Vorteilhaft ist auch, dass der Nutzer seine Daten nur einmal freigeben muss.

Interessant ist, dass Facebook die Anforderung “Social by Design” an Apps stellt, es Kampagnen-Apps somit schwer haben.

Am Ende gab Herr Szugat noch einen Ausblick in zukünftige, neue Features von Facebook. Da wären der Open Graph, welcher den App Entwicklern ermöglicht, einen Nutzer mit einer Aktion zu einem Objekt in Beziehung zu setzen (z.B. Frau Wunderlich hört Little Dragon), da ein “Like” nicht mehr aussagekräftig genug für gezielte Marketingaktionen ist. Auch auf die neue Online-Währung Credits, die Facebook etablieren möchte, wurde eingegangen. Auch hier ist interessant, dass, wann immer bei Facebook gezahlt werden soll, auch diese Credits als Zahlungsvariante angegeben werden müssen. Dabei verdient Facebook ganz nebenbei 30% mit.

Facebook stellt folglich eine echte Alternative zu App Stores bzw. zu einer eigenen mobilen Webseite dar, da viele Nutzer erreicht und auf mehreren Kanälen z.B. durch nur eine HTML5-App angesprochen werden können. Wenn Facebook Credits von den Nutzern angenommen wird, gibt es zusätzlich eine neue Internet-Währung.

Werbung auf mobilen Plattformen – mehr Relevanz für nachhaltig erfolgreiche Geschäftsmodelle

Herr Markus Breuer startete mit der Aussage “advertising sucks” und variierte diese Aussage noch zu “too much advertising sucks”, “stupid advertising sucks” und “irrelevant advertising sucks”.

Er ging auf eine Statistik ein, die wir auf der Konferenz schon mehrfach gesehen hatten: Ab 2014 werden mehr mobile Endgeräte als “klassische” Rechner genutzt werden. Diese Zahl ist umso bedeutender, wenn man bedenkt, dass Apps und mobile Webseiten derzeit nahezu werbefrei sind. “Mobile – It’s a wonderful world?” Wir als Nutzer würden selbstverständlich sagen: ja, aber “kostenfreier” Content wird in der Regel durch Werbung finanziert. Die schöne neue Welt wird folglich leider nicht so bleiben.

Nach einem Exkurs, dass sich mit Android schwerer Geld verdienen lässt als mit iOS (3% Paid Apps vs. 17%), stellte er das Werbekonzept vor, das nugg.ad anbietet.

Um das “sucks” in “advertising sucks” zu entkräften, müsse Werbung effektiv gemacht werden. Dies soll durch Targeting erreicht werden. Das Verhalten des Nutzers wird durch Cookies und andere Technologien, “die jeder Entwickler kennt”, beobachtet und analysiert; ab und zu werden Nutzer zusätzlich durch Umfragen um weitere Informationen gebeten. Ziel ist es, dem Nutzer Werbung zu zeigen, die zu Ihm passt bzw. die die Marketingabteilungen als zur Zielgruppe passend definieren.

Neue Herausforderungen zum Thema Mobil sind jetzt natürlich, wie dieses Beobachten des Nutzers auf mobilen Endgeräten geschehen kann. Konkrete Lösungsansätze wurde aber leider noch nicht vorgestellt. Es bleibt spannend.

UX-Webdesign für Tablets. Eine Anleitung

Christian Kuhn legte den Teilnehmern User Experience durch Unterstützung zahlreicher Werbevideos nahe. Nach der Viedeoshow gab er Hinweise auf Dokumente, Tools und Links, die helfen, um eine User Experience, die diesen Namen auch verdient, umzusetzen:

• Tablet-screendesign.info/ – eine Liste aller gängigen Tablets mit Auflösung, Betriebssystem etc.
• iMockups – eine Software, um Wireframes für Apps und Webseiten zu erstellen
• Die User Experience Design Guidelines von Windows Phone 7 und iOS
• Onswipe – ein Tool zur Realisierung der Tablet-Unterstützung von Webinhalten
• Loadtimer – für das Testen der Ladezeiten auf mobilen Endgeräten
• Aside – ein in HTML5 umgesetztes Magazin als gelungenes Beispiel

Für das Gelingen von User Experience in der Praxis gab es folgende Tipps:

• unterschiedliche mobile Betriebsysteme unterstützen unterschiedliche Anzahl an Gesten – es gibt dafür leider noch keinen Standard
• UX der Hardware, des Betriebsystems und der Webseite sind von Bedeutung
• Um Bereitstellung der Schriftart kümmern – einige mobile Betriebsysteme nehmen sonst eigene
• Informationen weglassen – Tablet first
• 1 cm Platz um Navigationselemente
• Responsive Design – evtl. jedoch nicht für mobile Version
• Einsatz Adaptive Images
• Minimalistisches & helles Design

Interactive TV – mit HTML5 auf den 2nd Screen

Andreas Lohmann gab uns einen Einblick in die Welt des interaktiven TVs. Neben den Anfängen von Interactive TV durch Text, Home Shopping und der Gameshow Hugo zeigte er uns, wohin die Reise geht. Zu 2nd Screens, die wir in Form von Smartphones oder Tablets in Zukunft nutzen können, um uns am Geschehen im TV zu beteiligen.

Fazit

Betrachte ich den zweiten Tag der Konferenz in Summe, nehme ich mit, dass es bei Apps stets auf den Kontext ankommt, das Thema Facebook Apps in Zukunft auch für uns spannend wird, “advertising sucks”, auf Tablets Content + Context = King gilt und beim interaktiven Fernsehen Context King ist.

Selbstverständlich bedanken wir uns bei den Sprechern, Ausstellern und Organisatoren für eine gelungene Konferenz.

Die Eröffnung der MobileTechCon 2012

Die Konferenz wurde durch Sebastian Meyen vom Software&Support-Verlag eröffnet. Er übergab die Session an Maks Giordano von Nunatak. Wer vom Design mobiler Applikationen spricht, meint dabei meist das Design von grafischen Oberflächen. Dass Audio genauso wichtig sein kann, liegt schon in der Historie der Telekommunikation begründet. Mobile Anwendungen laufen auf modernen Telefonen. Telefone wurden erfunden, um Sprache zu übertragen.

Manfred Lutzky von Fraunhofer IIS stellte den AAC-ELD-Codec vor. Dieser Codec ist ein Full HD Voice-Codec, der heute schon in Apple Facetime verwendet wird und in iOS 5 auch Entwicklern von Apps zur Verfügung steht. Der AAC-ELD-Codec ähnelt dem AAC-Codec, ist aber auf geringe Verzögerungen optimiert, was wichtig für die Real-Time-Kommunikation ist.

Philipp Eibach stellte sein neues Startup wahwah.fm vor. Eibach war schon an der Gründung von last.fm beteiligt und ist schon lange im Bereich Social Music unterwegs. Auf dem Smartphone hört jeder Musik für sich allein. Das Ziel von wahwah.fm ist, dass Musik wieder gemeinsam und zusammen gehört wird. So lässt sich Musik von Bekannten und Unbekannten entdecken. In wahwah.fm kann jeder Nutzer mit seiner Playlist auf Sendung gehen. Jeder Nutzer ist damit ein eigener, kleiner Radiosender. Andere Nutzer können sich in diese Sendung einklinken und mithören. Hörer einer laufenden Sendung können über Chats etc. interagieren. Die Location eines Senders lässt sich bei der Suche nach Sendern berücksichtigen. wahwah.fm ist eine prima Möglichkeit, Musik neu zu entdecken.

Michael Breidenbrücker von Reality Jockey Ltd. zeigte RjDj. RjDj lässt einen Nutzer selbst Musik erschaffen. Dabei verwendet RjDj nicht ein klassisches User Interface, sondern bezieht das komplette Sensor-Netzwerk des Smartphones ein. Musik wird also durch die Location, die Bewegung des Nutzers und sein Umfeld erschaffen. Der Nutzer taucht so in eine audiovisuelle Umgebung ein, in der die Intensität der Immersion sehr hoch ist. Auf Basis von RjDj wurden bereits weitere Apps entwickelt – wie die Audio-App zum Film Inception, die in Zusammenarbeit mit dem Soundtrack-Komponisten Hans Zimmer und dem Regisseur Christopher Nolan entstanden sind.

Anika Brinkmann, die als Kommunikationsdesigner Mobile-Knowledge.de verantwortet, eröffnete den Mobile Web-Track. Sie gab einen allgemeinen Überblick über die Themen des Tracks: Was bedeutet „Always on“? Hat always online nur gute oder auch unangenehme Seiten wie die allzeitige Bereitschaft von Arbeitnehmern, die mit modernen Kommunikationsendgeräten ausgestattet werden? Ist „Always on“ nur ein Versprechen oder schon heute Realität? Gibt es immer noch die Schere zwischen Stadt und Land, was die Netzabdeckung von UMTS und LTE angeht? Der Footprint (die Größe) der Seiten wächst im Moment noch stärker als die verfügbare mobile Bandbreite. Was nutzt die Cloud, wenn gerade keine Verbindung zum Internet hergestellt werden kann? Wie muss mit Nutzerdaten umgegangen werden – besonders im Spannungsfeld zwischen den Wünschen des Marketings und den Anforderungen des Datenschutzes? Wie befreie ich Daten aus Datensilos wie SAP oder gängigen CRM-Systemen? Content (sprich: Daten) muss in unterschiedlichen Kontexten unterschiedlich genutzt werden können. Daher muss er in offenen Formaten (kein Flash) und in unterschiedlichen Ausprägungen (z.B. auch in hoher Auflösung für Retina-Displays) vorliegen, um genutzt werden zu können. Um all diese Fragen zu beantworten, sollte zunächst eine Strategie erarbeitet werden, aus der wiederum Konzepte entwickelt werden können. Content sollte sowohl für’s Web als auch für mobile Anwendungen verwendet werden können. Dabei sollte man auf offene, zukunftssichere Plattformen statt auf proprietäre Technologien setzen. Wir sind hier und jetzt dabei, ein neues Level der Kommunikation zu erreichen. Zu den Technologien, mit dem dies umgesetzt werden wird, gehören sicherlich HTML5 und CSS3.

Ulrich Schmidt von sevenval zeigte die Offlinemöglichkeiten von HTML5-Webapplikationen. Der Grund, warum man überhaupt Offline-fähige Applikationen braucht, ist die unvollständige Netzabdeckung. Gerade wenn man beispielsweise in der Bahn unterwegs oder im Ausland-Urlaub ist, dann hat man oft kein Netz. Offline zu sein ist ein temporäres Problem, das durch HTML5 gelöst werden kann. Konzeptionell ist zwischen Daten und Funktionen zu trennen: Entweder man kann nur Daten oder nur Funktionen offline vorhalten. Oder man kann eine komplett Offline-fähige Webapplikation erstellen. Technologien für ein „Aktives Offline“ für Daten sind Local Storage, das als Cookie-Ersatz in allen Browsern läuft, WebSQL, das inzwischen deprecated ist aber zumindest auf iOS und Android zur Verfügung steht, und IndexDB, die in neueren Browsern (allerdings noch nicht in mobilen Browsern) als Weiterentwicklung von Local Storage und WebSQL angesehen werden kann. Als Bleeding Edge kann die FileSystem API angesehen werden, die ab Chrome 13 einen direkten Zugriff aufs Filesystem zur Ablage von Binärdaten erlaubt. „Passives Offline“ für Funktionalität (JavaScript) und Ressourcen (HTML, CSS, Bilder) bietet der Application Cache. Die Herausforderung bei der Verwendung des Application Caches ist es, diesen „aktuell“ zu halten und das Update-Verhalten sinnvoll zu implementieren. Der Application Cache schlägt HTTP-Header (außer beim Firefox). Die Schritte zur Erstellung einer Offline-fähigen Webapplikation sind laut Schmidt zuerst das Erstellen von Layout und Struktur (analog zu einer normalen Webapplikation), danach das Einführen von Local Storage zur Speicherung der Daten und anschließend die Verwendung des Application Caches zur Speicherung des bereits erstellten Layouts und der Struktur. Der Vortrag schloss mit Empfehlungen aus der Praxis zum Umgehen von Fallstricken.

Sven Günther von it-agile stellte die API des Zeitungskiosks in iOS 5 vor. Zeitschriften-Apps lassen sich mit NewsstandKit implementieren. Dieses bietet Features wie Push Notificiation und Background Downloads. Außerdem lässt sich programmatisch das Programm-Icon verändern, so dass das Cover der aktuellen Ausgabe als Icon verwendet werden kann. Payments lassen sich über das StoreKit abwickeln. Zur Anzeige von Content sind WebViews ungeeignet, da sich mit WebViews nur schwer die Anmutung einer Zeitung oder eines Magazins nachahmen lässt. Besser geeignet dazu sind CoreText und der UIPageViewController.

Torsten Drees präsentierte die MEAP (Mobile Enterprise Application Plattform), die mit einer Multi-Channel-Architektur die Herausforderung aktueller Enterprise Mobility Trends lösen soll. Eine Implementierung der MEAP ist die Magic Integration Plattform von Magic Software. Diese Präsentation kann als reiner Marketing-Vortrag bewertet werden.

Georg Konjovic, der als Director Premium Content die Konzern-weite Paid Content-Stratgie bei Axel Springer verantwortet, präsentierte die Ziele des Verlags. ASV sieht sinkende Print-Reichweiten nicht als Gefahr, sondern als neue Chance für den Qualitätsjournalismus. Die Paid Content-Stragie vom Axel Springer Verlag äußert sich in ca. 70 Apps (teilweise HD-Apps für das iPad), der Plattform iKiosk (ePapers im Portable Document Format, der iKiosk steht für andere Verlagshäuser offen), einem News-Aggregator (myEdition), der sich zurzeit in einer Closed Beta befindet, und zahlreichen News-Sites. Die größte Herausforderung ist die Schaffung neuer Abo-Modelle bzw. die Migration der Nutzer von kostenlosen Web-Diensten zu Nutzern kostenpflichtiger Dienste. Anders als in den USA entwickelt sich der Markt für Qualitätsjournalismus in Deutschland positiv. Vor allem Nutzer des iPads haben eine hohe Zahlungsbereitschaft. Alle zukünftigen Angebote bei Axels Springer sollen ein Preisschild bzw. einen Abo-Preis haben.

Rosemarie Wirtsmüller von Antenna International zeige Apps für Museumsbesucher. Diese Apps sind viel mehr als reine eGuides. Sie informieren den Nutzer schon vor dem Besuch des Museums (Pre-Visit-Kontakt) und unterstützen in bei der Nachbereitung (Post-Visit-Kontakt). Dies äußert sich auch in den Download-Zahlen. Diese Apps werden sogar von Nutzern verwendet, die gar nicht das Museum besuchen, sondern sich mit der App über das Thema einer Ausstellung selbst lange nach der eigentlichen Ausstellung informieren möchen.

Dass diese Frage alles andere als trivial und doch manchmal ganz leicht zu beantworten ist, haben wir kürzlich im Projekt erfahren.

Als Payload (engl. für „Nutzlast“) bezeichnet man üblicherweise die Daten, die in einem Prozess von Aktivität zu Aktivität transportiert werden. In vielen Fällen ist die Payload eine XML-Struktur, die den Transport beliebiger Daten zulässt. Eine Aktivität nimmt die Payload, führt darauf eine Operation aus (dies kann alles sein: von einer lokalen XSL-Transformation bis zum Aufruf eines Webservices) und schreibt das Ergebnis zurück in die Payload, worauf die nächste Aktivität dann ihrerseits operiert.

Extrem 1: Payload mit IDs

In unserem Projekt ist die BPE, in unserem Fall die inubit Suite, aufgesetzt auf einer serviceorientierten, mit EJB3 realisierten Architektur, die in einem JBoss Application Server läuft. Geschäftslogik findet nur in der Business Service-Schicht statt, die BPE übernimmt ausschließlich die Prozesssteuerung und orchestriert im Wesentlichen die Business Services, die sie über Webservices aufruft. Die Tatsache, dass die zugrunde liegende SOA in Hinblick auf ihre Schnittstellen sehr homogen ist, hat dazu geführt, dass die Prozesse mit einer sehr schlanken Payload auskommen. Wir schleusen in den meisten Fällen nur die IDs von Fachobjekten durch den Prozess, die dann an die Services gereicht werden.

Dieses Vorgehen stellt gewisse Anforderungen an die Business-Service-Schicht. Diese muss nämlich alle Daten, die sie benötigt, anhand der IDs, die sie vom Prozess bekommt, über Domain Services aus der Datenbank beschaffen und die Änderungen nach der Verarbeitung über Domain Services auch wieder persistieren.

Extrem 2: Payload mit Fachobjekten

Das andere Extrem ist es, komplette Fachobjekte am Beginn des Prozesses einmal über einen Service in den Prozess zu laden und dann in der Payload mitzuführen. Die Objekte werden dann an die Services gereicht, die dann nur noch die Änderungen durchführen und das manipulierte Objekt an den Prozess zurückgeben müssen. Der Prozess muss dann an geeigneter Stelle die Objekte persistieren. In einer heterogenen Welt könnte der Prozess so auch Schnittstellen bedienen, die unterschiedliche Strukturen erwarten, indem die Fachobjekte ggf. in die jeweilige Zielstruktur gemapped werden.

Auf der Service-Schicht würde dieses Vorgehen einerseits Datenbankzugriffe, andererseits remote calls auf die Domain Service-Schicht sparen.

And the winner is…?

Wir haben kürzlich beide Varianten auf ihr Laufzeitverhalten untersucht. Das Ergebnis war eindeutig: Die Ersparnis an Datenbankzugriffen und remote calls wird durch die Verwaltung der Payload in der BPE, bei der große XML-Strukturen häufig in das Filesystem geschrieben und wieder geladen werden, bei weitem neutralisiert. Die Variante mit Fachobjekten war in unseren Tests bis zu fünf Mal langsamer als die Variante mit IDs. Die Ergebnisse bei der Laufzeit waren so eindeutig, dass wir weiterführende Untersuchungen, z.B. in Richtung Netzlast, gar nicht mehr angestellt haben.

Was wir daraus lernen können

Mindestens genauso interessant wie das eigentliche Ergebnis der Untersuchung waren aber die Erkenntnisse, die ich als Nebenprodukt gewinnen konnte. Die eine wie die andere Variante hätte nämlich erheblichen Einfluss auf die gesamte Architektur und das Prozessdesign.

Persistiert jeder Service immer alle Änderungen sofort, braucht man sich keine Gedanken darüber zu machen, zu welcher Zeit man welchen Datenzustand benötigt und wann manuelle Synchpoints aus dem Prozess heraus nötig sind. Möglicherweise reicht es dabei gar nicht aus, am Anfang des Prozesses zu laden und am Ende zu speichern. Gibt es im Prozess manuelle Rückkopplungen mit Mitarbeitern, so muss vor diesen gespeichert werden, damit der Mitarbeiter auf dem aktuellen Stand aufsetzt.

Dazu kommt, dass die Fachobjekte in der BPE, z.B. als XSD, modelliert werden müssen. Existiert in der SOA ein Versionskonzept, das den parallelen Betrieb verschiedener Versionen eines Services erlaubt, so muss dieses in der BPE entsprechend nachgebildet werden. Außerdem wird ein Konzept für den Transport von Fachobjekten über die (Web-)Service-Schnittstellen hinaus notwendig. Setzt man auf abstrakte DTOs (seit EJB3 manchmal als Anti-Patterns verschrien), entsteht zusätzliches Mapping auf der Service-Schicht, das sowohl zur Entwicklungs- als auch Laufzeit Aufwand bereitet. Werden echte JPA-Entitäten verwendet, verliert man die lose Kopplung, die den Charme einer SOA ausmacht, da die (Web-)Service-Consumer direkt von Änderungen an den Entitäten abhängig sind.

Auf der anderen Seite muss man sagen, dass eine Payload, die nur auf IDs operiert, eine homogene Servicelandschaft voraussetzt, in der alle Services mit diesen IDs auch umgehen können und Zugriff auf die Daten haben. Werden Dritt- oder Legacysysteme angebunden, so müssen möglicherweise Fachobjekte durch den Prozess geschleust werden, um diese Systeme zu bedienen.

Fazit

Eine eindeutige Empfehlung für den einen oder anderen Weg kann es an dieser Stelle nicht geben. Ich möchte aber die Sinne dafür schärfen, dass diese Entscheidung durchaus weitreichende Folgen haben kann und gründliche Überlegungen erfordert.

Beispiele für das Szenario gibt es viele. Es ist z.B. denkbar, dass eine Loop-Activity Bewerbungen für einen Zeitraum entgegennimmt und in einer Liste sammelt. Diese werden dann zusammen in der HRM-Abteilung bearbeitet und später einzeln auf die Fachbereiche verteilt. In unserem rein technischen Beispiel warten wir auf die Eingabe von fünf Namen, die wir in einer einfachen Parallel-Ausführung und dann in einem parallelen Sub-Prozess einzeln anzeigen.

Unser Prozess beinhaltet eine Liste von Namen, die in der ersten Loop-Aufgabe abgefragt und über einen Connector der Namens-Liste hinzugefügt werden. Der zweite Schritt besteht aus einer einfachen Nutzer-Aufgabe, die für jeden Namen aufgerufen wird und diesen dann ausgibt. Hierzu wählt man die Aufgabe aus und selektiert unter “Advanced” die Einstellung “is Multi-Instantiated”. Es erscheinen zwei Felder, die das Instantiieren und das Zusammenführen von den Aufgaben-Instanzen organisieren. Der “Instantiator” ermittelt die Anzahl und Parameter für die Aufgaben-Instanzen, während der “Join Checker” überprüft, ob alle Aufgaben abgeschlossen wurden, die für die Fortführung des Prozesses nötig sind. Demnach läuft der Instantiator auch vor allen Enter-Methoden, und wir erzeugen uns für unser Beispiel einen ”Variable number von instances”-Connector. Wichtig ist, dass die lokalen Variablen in der Instantiator-Phase noch nicht zur Verfügung stehen.

Bonita: Mit "Variable number von instances" eine Liste auf eine lokale Variable mappen

Im Wizard-Verlauf müssen nun der Name einer lokalen Aufgaben-Variablen und die Liste der Werte angegeben werden. Die Variable können wir im Drop-Down über “Create data …” wie gewohnt erzeugen. Wichtig ist, dass unter “Name” kein GString angegeben wird, wie ihn Bonita fälschlich automatisch dort einfügt. Das heißt, der Name muss ohne Dollar und geschweifte Klammern in dem Feld stehen. Um die Werte nun zuzuweisen, muss man auf den Link “Set value as expression” klicken, um in eine Ansicht zu kommen, die nur eine Liste erwartet. Hier geben wir unsere Liste als GString an.

Über den Join Checker stellt Bonita fest, ob alle Aufgaben-Instanzen beendet wurden, und fährt dann mit dem Prozess fort. Hier kann ein einfacher “Percentage of completed instances”-Connector ausgewählt werden, den wir mit “1.00″ für 100% versehen. Dies soll schon genügen: Wir teilen über den Instantiator Anzahl und Werte der BPE mit, und diese Werte werden bei der Aufgaben-Instanziierung den lokalen Variablen zugewiesen. Wenn alle Aufgaben abgeschlossen, sprich alle Namen angezeigt wurden, führen wir die Arbeit fort.

Bei einem mehrfach ausgeführten Sub-Prozess kann man das Vorgehen fast analog anwenden. Es muss zusätzlich die lokale Variable der Aufgabe auf eine Variable des Sub-Prozesses gemapped werden, mit der dieser dann arbeiten kann.

Wir hatten nun die Anforderung, dass wir an der Aktivität die eigentliche Liste der Daten erst ermitteln mussten, um den Sub-Prozess mit mehreren Daten aufzurufen. Man könnte dies mit einer Java-Klasse lösen, die die MultiInstantiator-Klasse der Bonita-API erweitert. Um eine schon bestehende Methode nutzen zu können, entschieden wir uns für die Groovy/Java-Lösung. In diesem Fall muss man ein Groovy/Java-Code-Snippet schreiben, das eine Liste von Aufgaben-Variablen zurückgibt. Konkret: List<Map<String, Object>>. Für jeden Listen-Eintrag wird eine Instanz gestartet, und die lokalen Variablen der Aufgabe werden durch Einträge aus der Map gefüllt. Für unser Namens-Beispiel sieht unser Java-Snippet so aus:

List<Map<String, Object>> initParams = new ArrayList<Map<String, Object>>(); // Liste aus Parametern.

for (Object processVar : listOfNames) {
  Map<String, Object> entry = new HashMap<String, Object>();
  entry.put("name", processVar);
  initParams.add(entry);
}
return initParams;

Bonita: Groovy-Instantiator mit einem Java-Snippet befüllen

Für Groovy und Java-Code wählt man den “Groovy”-Connector unter Instantiator. Hier erwartet Bonita ein Code-Snippet, das dann ausgeführt wird. Sehr tückisch ist auch hier, dass Bonita gern GStrings bei der Verwendung des Expression-Editors einfügt. So wird der komplette Code nach dem Verlassen des Expression-Editors, der  auch Code-Highlighting und Hilfe beim Import von Klassen bietet, in einen GString gewrapped. Dieser kann dann nicht ausgeführt werden – es müssen manuell alle GStrings entfernt werden. (Dies gilt auch für Variablen im Snippet, da der Inhalt ansonsten später als Groovy-Code ausgewertet wird). Sollte man dies mal übersehen, wird der Prozess an der Stelle abbrechen. Man erhält in der engine.log eine Fehlermeldung wie:

org.ow2.bonita.util.BonitaRuntimeException: Unable to find a method with name: setScript and parameters: [classjava.util.ArrayList=[{a=1, b=1}, {a=2, b=2}, {c=3, c=3}, {d=4, d=4}],] in connector: class org.bonitasoft.connectors.bonita.instantiators.GroovyInstantiator
    at org.ow2.bonita.definition.activity.AbstractActivity.instantiateMultiInstanceActivity(SourceFile:225)
    at org.ow2.bonita.definition.activity.AbstractActivity.execute(SourceFile:168)

Bonita: Lokale Variablen auf SubProcess mappen

Das ganze Beispiel kann als Bonita-Prozess herunter geladen werden.

Das Original-Beispiel

Ist man ganz naiv und denkt, man schaut sich einfach das Beispiel der Sencha Touch Dokumentation an, bringt es in den eigenen Kontext und kann dieses direkt ausführen, fällt man erst einmal auf die Nase und bekommt bei der Ausführung den folgenden Fehler:

Ext.data.JsonReader.getResponseData: Unable to parse JSON returned by Server.

Der JavaScript-Code, der den Store aufbauen sollte:

var store1 = new Ext.data.JsonStore({
    // store configs
    autoDestroy: true,
    storeId: 'myStore',

    proxy: {
        type: 'ajax',
        url: 'jsonTest.json',
        reader: {
            type: 'json',
            root: 'images',
            idProperty: 'name'
        }
    },

    //alternatively, a Ext.data.Model name can be given
    fields : ['name', "url", {
				name : 'size',
				type : 'float'
			}, {
				name : 'lastmod',
				type : 'date'
    }]
});

		store1.load();

Die JSON-Datei, die geladen werden sollte:

{
    images: [
        {name: 'Image one', url:'/GetImage.php?id=1', size:46.5,
            lastmod: new Date(2007, 10, 29)},
        {name: 'Image Two', url:'/GetImage.php?id=2', size:43.2,
            lastmod: new Date(2007, 10, 30)}
    ]
}

Nach ein wenig Googeln ließ sich ermitteln, dass man sich strikt an den JSON-Syntax halten muss: Die Attributnamen, die Attribute bei Strings und die Wurzel des dictionary müssen folglich in Hochkommata gesetzt werden. Da ich kein PHP-Skript ausführen möchte, sondern nur eine JSON-Datei laden möchte, muss ich auch das Datum als String darstellen.

Das laufende Beispiel

Die neue JSON-Datei sieht also wie folgt aus:

{
    "images": [
        {"name": "Image one", "url":"/GetImage.php?id=1", "size":46.5,
            "lastmod": "2007-10-29"},
        {"name": "Image Two", "url":"/GetImage.php?id=2", "size":43.2,
           "lastmod": "2007-10-30"}
    ]
}

Im JavaScript-Code muss lediglich angegeben werden, in welchem Format das Datum interpretiert werden soll.

  fields: ['name', "url",  {name:'size', type: 'float'},
    {name:'lastmod', type:'date', dateFormat:'Y-m-d'}]

Und schon läuft der Code.

Das Problem mit dem Proxy

Ein zweiter Fehler, auf den wir häufig bei unseren ersten Gehversuchen gestoßen sind, war auf einen nicht konfigurierten Proxy zurückzuführen:

Error: You are using a ServerProxy but have not supplied it with a url.

Man findet im Netz auch Codeschnipsel wie den folgenden falschen, der den oben genannten Fehler provoziert:

window.store1 = new Ext.data.JsonStore({
  // store configs
  autoDestroy : true,
  storeId : 'myStore',
  url : 'jsonTest.json',
  root : 'images',
  //alternatively, a Ext.data.Model name can be given
  fields : ['name', "url", {
    name : 'size',
    type : 'float'
    }, {
	name : 'lastmod',
	type : 'date',
	dateFormat : 'Y-m-d'
  }]
});

Ergo ist es wichtig, einen entsprechenden Proxy zu definieren.

Zusammenfassung und Beispielcode

Um mit Sencha Touch JSON-Dateien zu laden, ist streng die JSON-Syntax einzuhalten und gegebenenfalls muss ein Proxy definiert werden. Ein lauffähiges Beispiel, bestehend aus den Dateien jsonTest.html, jsonTest.js und jsonTest.json, kann hier heruntergeladen werden. Um das Beispiel auszuführen, benötigt man natürlich zusätzlich Sencha Touch.