Das open source Projekt ist eine Kombination aus CSS Framework und JavaScript UI Library. Es  beinhaltet mobile UI Komponenten, um ein natives Look-and-Feel mit HTML5 und CSS zu erreichen. Für die JavaScript Funktionalitäten verwendet Ionic Angular.js als MVC Framework.

CSS Komponenten

Alle Stylesheets die Ionic mitliefert sind in Sass geschrieben und übersichtlich strukturiert. Durch die Verwendung von Variablen ist es einfach das default Styling an das eigene Design anzupassen. Standardmäßig sind alle Komponenten im iOS Style gehalten. Die Verwendung der fertigen Ionic CSS Klassen hat den Vorteil schnell und einfach ein natives Aussehen der App zu erreichen. Alle üblichen Höhen, Breiten, Schatten, Abrundungen etc. sind bereits definiert, wodurch sich der Entwickler viel Arbeit spart die Komponenten selbst nachzubasteln.

Die fertig gestylten HTML5 Komponenten umfassen:

• Buttons
• Listen
• Formulare
• Checkboxen
• Checkboxen im iOS Switch Style
• Slider
• Selektboxen

Zusätzlich liefert das Framework Icons und ein fertiges Grid System.

JS Komponenten

Doch nicht nur statische Komponenten stellt Ionic zur Verfügung. Bei den JS Steuerelementen wird dem Entwickler vor allem die Schwierigkeit abgenommen, ein natives Look-and-Feel zu kreieren. Denn nicht nur das typische Aussehen, auch das Verhalten der Komponenten und deren Effekte ist wichtig, um die vom Benutzer durch andere Apps gewohnte Usability zu erreichen.

Werden die mitgelieferten Elemente richtig verwendet, ergibt sich dieses Verhalten automatisch. Ein gutes Beispiel dafür ist die Navigationsbar. Das Routing wird in Ionic über so genannte States realisiert. Diese verweisen auf verschiedene Views und stellen das Pendant zu verschiedenen View Controllern im nativen Development dar. Die Definition der States geschieht im Angular Routing Stil:

.state 'mainView',
  url: "/"
  templateUrl: "js/states/mainView.html"

Das Template mainView.html wird also beim Aufruf der root Url so wie beim JS Aufruf des mainView States gerendert.
Wer bereits mit Angular.js vertraut ist kennt das Konzept zu einer View gehörige Controller einfach im Template im Attribut ng-controller anzugeben. Alternativ könnte dieser auch bereits bei der Statedefinition angegeben werden.

Während diese Templates in Angular üblicherweise in ein <ng-view> Element gerendert werden, liefert Ionic ein custom Element namens <ion-nav-view>. Darin wird dann das entsprechende <ion-view> Element je nach State dargestellt (jedes Template das eine View repräsentiert sollte in ein <ion-view> Element gewrapped sein). Hält man sich an diese Ver­schach­te­lung wird automatisch eine Navigationbar erstellt welche Zurück-Button und Titel automatisch richtig setzt.  Das Verhalten eines nativen Navigation Controllers wird genau nachgestellt, inklusive üblichen Slide-Effekt zur nächsten View, wenn sich der State ändert.

Weitere praktische JavaScript Komponenten werden in der Doku genau beschrieben.

Durch die Verwendung von Angular.js können auch alle praktischen Möglichkeiten die das Framework bietet verwendet werden. Two-way data binding, Filter, eigene Factories und viele zeitsparende Direktiven wie ng-repeat sind für die Entwicklung der Webapplikation vorhanden.

Probleme in der Praxis

Abgesehen von den Problemen die bei der Verwandlung von Webapps in hybrid Apps generell bestehen (vor allem Unterschiede in den verschiedenen Plattformen), gibt es ein paar Schwierigkeiten die beim Entwickeln des Webteils mit Ionic auftreten können:

• Datenaustausch zwischen States
  Es gibt mehrere Möglichkeiten Daten zwischen verschiedenen States auszutauschen. Über die URL können Parameter übergeben werden oder die Daten können in eine Variable in einem übergeordneten Scope gespeichert werden. Handelt es sich bei den Controllern die Daten austauschen möchten um Parent- und Childcontroller, kann über Funktionen wie emit() und broadcast() eine Nachricht geschickt werden auf die der jeweils andere Controller hören kann. Eine weitere Möglichkeit wäre die Daten in den Local Storage abzulegen, wodurch beliebig viele Komponenten darauf Zugriff hätten. Für das einfache Weitergeben von temporären Daten erscheinen alle diese Möglichkeiten unzufriedenstellend.
• History
  Nicht immer ist der Aufbau einer App so standardmäßig, dass die Navigationsbar den Zurück-Button immer zur richtigen Zeit anzeigt bzw nicht anzeigt. Das Vorhandensein des Buttons kann manuell eingestellt werden. Gibt es nun mehrere Möglichkeiten um auf den gleichen State zu gelangen und möchte man in einem Fall keinen Zurück-Button (da man beispielsweise vom Flyoutmenü kommt) und in einem anderen Fall doch (da man von einem anderen State zur View gelangt an den ein Zurückgelangen durchaus Sinn macht), muss diese View den Button manuell ein- und ausblenden abhängig vom vorhergehenden State. Sollche Sonderfälle können zwar umgesetzt werden, indem die vorhergegangenen State aus der $ionicHistory herausgelesen werden können und der Controller dann über if Anweisungen unterscheidet. Eine bequeme Möglichkeit für dieses Verhalten wird allerdings nicht angeboten.
• Performance
  Gerade, wenn die Applikation umfangreicher  wird leidet die Performance. Auch wenn die Entwicklung der Smartphones schnell voranschreitet, sind die Prozessoren und Arbeitsspeicher gerade in günstigen Geräten nicht so stark wie in Desktop Computern. Durch die vielen Scopes und Listener die durch Angular.js entstehen, werden komplexere Apps schnell zu anspruchsvoll für diese Smartphones. Spezielle Angular Plug-Ins die das ständige horchen auf Updates der Values wieder unterbinden verbessern die Performance. Das ist aber nicht gerade Sinn und Zweck, die Features eines Frameworks auszuschalten, um es verwenden zu können.

Auch, wenn es in der Praxis in sehr umfangreichen und individuellen Applikationen Schwierigkeiten gibt, die manuell und manchmal umständlicher als gewohnt gelöst werden müssen, kann ich das Framework durchaus empfehlen. Die Kombination von fertigen UI Elementen und Funktionen die speziell für mobile Apps kreiert wurden und die komfortable Programmierweise von Angular.js, ermöglichen zeitsparend Webapps zu entwickeln, die für den Benutzer nativen Applikationen sehr ähnlich sind. Wer nun neugierig geworden ist kann sich auf der Ionic Website das Projekt runterladen und in der Doku alle Komponenten und Funktionen finden die das Framework bietet.

The post Hybrid Apps mit Ionic erstellen appeared first on Mobile USTP MKL.

Am 8. Oktober 2014 haben wir daher mit acht Studienkollegen einen kurzen Usability-Test durchgeführt, um unseren iOS Prototyp zu testen. Dieser umfasste zu diesem Zeitpunkt neun Screens, die einen Event-Erstellungsprozess abbilden.

Der Test hat viele Erkenntnisse zu Tage gebracht. Einerseits wurden einige Bugs gefunden. Beispielsweise ist die App an manchen Stellen abgestürzt. Das was uns aber besonders wichtig war, waren Usability-, UX- oder Verständnis-Probleme.

Probleme

Desiree Zottl Problem
Nach dem Login, kamen die User auf den Start-Screen, welcher zu diesem Zeitpunkt nicht sehr viel zeigt, bis auf eine Box mit dem User-Profil und einem Button. Vier von acht Probanden, haben sich hier sehr gewundert, dass sie Desiree Zottl sind.

Start-Screen leitet auf keine Aktion hin
Auf dem Start-Screen waren viele User ein wenig verloren. Ohne den Hinweis, dass sie bitte jetzt ein neues Event anlegen sollen, hätte kaum jemand den grünen Button gefunden.

Durch Tastatur wichtige Funktion abgeschnitten
Beim Lösen mancher Aufgaben hatten die Probanden Probleme wichtige Funktionen zu erwischen, da sie durch die Tastatur oder Suchergebnisse abgeschnitten oder nicht erreichbar waren.

Switch unklar
Beim Hinzufügen eines Termins zu einem Event kann mit einem Switch zwischen ganztägigen und zeitabhängigen Terminen gewechselt werden. Hier war für einige Probanden unklar, ob der Switch gerade aktiv ist oder nicht.

Buttons teilweise zu klein
Einige der Buttons sind zu klein und mussten von den Testperson oft mehrmals gedrückt werden, bevor die Funktion ausgeführt wurde. Dies hat natürlich Verwirrung gestiftet, weil die Testpersonen den Eindruck hatten, dass etwas nicht funktioniert hat.

Pflichtfelder hervorheben
In einigen Fällen war es für die Probanden unklar, welche Felder ausgefüllt werden müssen und welche nicht. Es ist auch nicht eindeutig, ab wann ein Event ausreichend ausgefüllt ist, um es speichern zu können.

Viele Schritte
Einige Probanden haben angemerkt, dass es eventuell mühsam ist so viele Schritten durchlaufen zu müssen, wenn man die App oft nützt.

Zum Ausfüllen Extra-Klick notwendig
Bei den meisten Screens muss zuerst ein Plus-Button gedrückt werden, bevor die Felder ausgefüllt werden können. Ein Proband hat angemerkt, dass das eigentlich nicht notwendig ist und Zeit verbraucht.

Verwirrende Navigation bei Zusammenfassung
Tippt man von der Zusammenfassung auf einen der Bereiche, springt man quasi wieder zurück und muss dann alle folgenden Schritte erneut durchlaufen. Das hat bei einigen Probanden für Verwirrung gesorgt.

Lösungen

Start-Screen
Da der Start-Screen beim ersten Aufruf sehr leer ist soll er in Zukunft von Anfang an mehr dazu einladen neue Events anzulegen. Auch wollen wir eventuell auf das Anlagen eines Profils für Gatherer verzichten.

Wo zu Was
Um die Anzahl der Schritte bis zum Beenden des Erstellungsprozesses zu reduzieren und Events zu vereinfachen wird der “Wo”-Screen wegfallen und als einfaches Textfeld in den “Was”-Screen wandern.

Unklarheiten aufräumen
Einige Dinge, waren nicht zu 100% klar bei den Usern, die wollen wir in nächster Zeit versuchen auszuräumen.

The post Gatherer: der erst Test appeared first on Mobile USTP MKL.

Gulp verwendet Node.js streams, welche es schnell machen, da keine temporären Dateien auf die Festplatte geschrieben werden müssen. Gulp arbeitet so, wie man sich ein Buildsystem vorstellt. Die Quelldateien werden eingelesen, durch verschiedene Plugins geleitet, die sie modifizieren und am Ende werden die neuen Files ausgegeben. Wie eine jQuery Verkettung, welche verschiedene Aktionen in der angegebenen Reihenfolge ausführt.

Installation

Um Gulp über den Node Package Manger installieren zu können, muss bereits Node am Rechner verfügbar sein. Über folgenden Konsolenbefehl ist es dann möglich Gulp global im System zu installieren:

npm install gulp -g

Mac User müssen den Befehl eventuell mit sudo starten, um Administrationsrechte zu erlangen.

sudo npm install gulp -g

Danach können beliebig viele Plugins installiert werden, die für die Tasks, die später ausgeführt werden sollen, benötigt werden. Vom gulp-autoprefixer bis zu gulp-zip gibt es derzeit 717 praktische Plugins. Ein Sass-Compiler beispielsweise, kann über folgendes Kommando installiert werden:

npm install gulp-sass

Eine Liste aller verfügbaren Plugins findet sich unter http://gulpjs.com/plugins.

Gulpfile

Nun können wir unser gulpfile.js schreiben, in dem definiert wird, welche Tasks auf welche Files angewendet werden sollen.

Zuerst müssen wir alle Plugins die wir verwenden möchten laden.

var gulp = require ('gulp');
var sass = require ('gulp-sass');
var autoprefixer = require('gulp-autoprefixer');
...

Danach können wir beispielsweise einen Task auf unsere Styles anlegen, der die sass Files einliest, diese zu css kompiliert und durch den Autoprefixer laufen lässt. Am Ende sollen sie im Zielordner gespeichert werden.

gulp.task('styles', function() {
  return gulp.src('assets/styles/*.scss')
    .pipe(sass({outputStyle: 'expanded'}))
    .pipe(autoprefixer('last 2 version', 'ie8'))
    .pipe(gulp.dest('dist/styles'));
});

Die verschiedenen Plugins können verschieden konfiguriert werden. Dies ist in der jeweiligen Dokumentation beschrieben.

Um diesen Task nun immer automatisch auszuführen, wenn Änderungen in den sass Files vorgenommen wurden, kann ein entsprechender watch Task angelegt werden.

gulp.task('watch', function() {
  gulp.watch('assets/styles/*.scss', ['styles']);
});

Nun in der Konsole den watch Task nur noch über

gulp watch

starten.

Slush

So wie Yeoman bereits Gerüste für Grunt Tasks generiert, kann ein Gulp Projekt mit Slush automatisiert angelegt werden. Die Dokumentation dazu findet sich unter http://slushjs.github.io. Alle praktischen Tasks für Webapps, Angular Apps und viele viele mehr, können über die Generatoren automatisch angelegt werden. Eine Liste aller Generatoren ist unter http://slushjs.github.io/generators verfügbar.

The post gulp.js – The streaming build system appeared first on Mobile USTP MKL.

Die Themen der Konferenz waren sehr vielfältig. Das Spektrum reichte von Entwickler-Themen wie Angular JS und weiteren JavaScript Vorträgen über Responsive Web Design und SASS bis hin zu User Interface Design und Daten Visualisierung. Dadurch konnte sich jede/r die interessantesten Themen heraussuchen.

Einer der spannendsten Vorträge war der des Gründers des bekannten Smashing Magazine, Vitaly Friedman (Twitter: @smashingmag), über Responsive Web Design. Der Talk mit dem Titel “Real-Life Responsive Web Design” deckte sehr viele wichtige Aspekte ab, die heutzutage für die Erstellung von flexiblen Web-Projekten wichtig sind.

Auch sehr spannend war der Vortrag von Monica Dinculescu (Twitter: @notwaldorf). Sie arbeitet bei Google an der Entwicklung des eigenen Browsers Chrome und sprach über sechs Tricks, wie Google seine Chrome User glücklich macht. Damit gab sie einen spannenden Einblick hinter die Kulissen der Arbeit von Google.

Die Designer/innen und Entwickler/innen der Masterklasse Mobiles Internet konnten sehr viel aus den verschiedenen Vorträgen mitnehmen und werden auch bei der nächsten Konferenz in Österreich wieder dabei sein.

The post codefront.io appeared first on Mobile USTP MKL.

Lea Verou hielt eine der beiden Keynote Vorträge mit dem Thema “The Chroma Zone Engineering Color on the Web”. Dabei zeigte sie die unterschiedlichsten Methoden der Farbimplementierung in CSS auf. Neben der Analyse des Farbraumes RGB und der Erweiterung um den Alphakanal RGBA, erklärte sie auch die anderen Möglichkeiten um Farbwerte auszudrücken, wie HSL (Hue, Saturation, Luminance) und HSLA (Hue, Saturation, Luminance, Alpha). Neben zahlreichen nützlichen Javascript und Sass Funktionen zur Berechnung der Farbwerte stelle sie auch die Neuerungen im neuen W3C Color Modul 4 vor. So ist vorgesehen, dass es eine neue Möglichkeit für den Ausdruck der Farbwerte gibt, nämlich HWB, diese Möglichkeit kennt man auch aus Photoshop. Außerdem gibt es erstmalig Variablen direkt im CSS. So gibt es dann die neue Variable currentColor, die verwendet werden kann um die aktuelle Farbe in einer Regel wieder zu verwenden. Außerdem gibt es eine Funktion gray() über die mit der Angabe von Prozenten der Grauton direkt im CSS gesteuert werden kann. Die Neuerungen werden kaum von Browsern unterstützt, jedoch zeigte Lea Fallbacks um die Neuerungen jetzt schon zum implementieren. Alles in allem, war es ein sehr spannender Talk und Lea überzeugte nicht zuletzt mit einer interaktiven Präsentation und einigen Live-Code Beispielen.

Pascal Precht präsentierte in seiner ebenfalls interaktiven Präsentation Dependency Injection und Two-Way Data-Binding mit Angular.js. Darüber hinaus behandelte er das Thema Internationalisierung und Lokalisierung und zeigte, wie man über die Möglichkeiten von Angular hinaus, mit Angular-Translate Texte und Formate einfach asynchron laden und dynamisch anpassen kann.

Mikael Konutgan von All About Apps zeigte in einer Gegenüberstellung von Objective C mit Ruby, die von vielen unerwarteten Gemeinsamkeiten. Er verglich den Syntax der beiden Programmiersprachen und vermittelte den Zuschauern, das es viel mehr Ähnlichkeiten als Unterschiede gibt, vor allem wenn man von “modernen Objective C” ausgeht. Und für alle die den gewöhnungsbedürftigen Block Syntax von Objective C im Kopf behalten, verwies Mikael noch auf die Seite http://fuckingblocksyntax.com/, wo er selbst täglich nachschlägt. Seine Slides mit dem genauen Codevergleich sind unter https://speakerdeck.com/kmikael/objective-c-for-rubyists zu finden.

Steve Scott gab uns in seiner Keynote “Going Native” einen amüsanten Einblick in sämtlich Programmiersprachen, mit denen er selbst in der Vergangenheit gearbeitet hat bzw. heute noch arbeitet. Anhand dieses Streifzuges durch die Zeit zwischen 1987 bis heute zeigte Steve, wie sich die “native” Programmierung von damals, wo Entwickler Code auf Systemeben schrieben, im Vergleich zur Gegenwart, wo großteils Frameworks wie beispielsweise Cocoa Touch für iOS verwendet werden unterscheidet. Auch die Entwicklung von mobilen Webapplikationen setzte Steve in seiner Keynote auf dieselbe Ebene, wie die Entwicklung von “nativen” Apps für Plattformen wie iOS, Android oder Windows. Der Browser bietet in diesem Fall die Plattform und HTML, CSS und Javascript ein Framework zur Entwicklung von Applikationen. Den wesentlichen Vorteil von plattformspezifischen Apps sieht Steve vor allem in der User Experience, die aus seiner Sicht bei crossplatform Apps zu kurz kommt.

The post Das war die Kod.io 2014 in Linz appeared first on Mobile USTP MKL.

Backbone.js ist ein JavaScript Framework zum Entwickeln von Singe Page Applikationen und unterstützt die Kommunikation zum Server über eine RESTful API. Es besteht aus Models, Collections, Views und Router. Für die Verwendung ist nur die Einbindung von Underscore.js  erforderlich, allerdings können viele andere JavaScript Erweiterungen gut damit kombiniert werden.

Backbone Model

Das Model repräsentiert die Daten der Applikation und stellt die kleinste mögliche Einheit an Funktionalitäten dar. Um ein Backbone Model zu generieren, muss lediglich die Backbone Klasse Backbone.Model extendet werden, dann kann es mit eigenen Funktionalitäten erweitert werden. Eine Möglichkeit sind beispielsweise Defaultwerte für bestimmte Attribute des Models.

Möchte man das Model einfach vom Server übernehmen, ohne Funktionalitäten hinzuzufügen, reichen die folgenden Zeilen zum Generieren des Models.

var Event = Backbone.Model.extend({

});

return Event;

Backbone Collection

Eine Collection ist eine Gruppe von Models. Normalerweise enthält eine Collection einen Typ von Models und kann wie diese durch eigene Funktionalitäten erweitert werden. Man verwendet das “model” Property, um der Collection zu sagen, von welcher Modelklasse jedes Item in der Collection generiert werden soll.

var EventList = Backbone.Collection.extend({
  model: Event
});

return EventList;

Backbone View

Views zeigen die Daten der Applikation in der HTML Seite an. Dazu können Templates verwendet werden, die in der View definiert, oder von extern geladen werden können. Die initialize Funktion wird in Backbone beim Instanzieren vom Objekt immer aufgerufen. Davon ausgehend, können dann weitere Funktionen ausgeführt werden. Hier ein Beispiel für eine View, die den Titel des Models ausgibt.

var EventListItemView = Backbone.View.extend({
  tagName:'li',
  template:_.template('<h1><%= title %></h1>'),

  initialize:function () {
    this.model.bind('change', this.render, this);
  },

  render:function () {
    $(this.el).html(this.template(this.model));
  return this;
  }

});

return EventListItemView;

Templates

Am Codebeispiel der View sieht man auch bereits die Verwendung des Underscore.js Template. Diese sind sehr nützlich, um HTML aus JSON Daten zu rendern und ermöglichen das Einfügen von Variablen durch Platzhalter <%= Variablenname %>. Ebenso kann beliebiger JavaScript Code ausgeführt werden  <% JavaScript Code %>. Die HTML Snippets können nicht nur direkt in der View geschrieben werden, sondern auch als sogenannte “Mikrotemplates”,  in der HTML Seite eingefügt  und durch die Id ausgewählt werden.

<script id="event" type="text/template">
  <h1><%= title %></h1>
  <div><%= description %></div>
</script>

Die Templates können auch in extra Files ausgelagert werden und vor allem bei Verwendung von Require.js und dem Require Text Modul, bei Bedarf einfach in die View geladen werden. Näheres dazu später im Beitrag unter “Verwendung von Require.js”.

Backbone Routing

Routen werden verwendet, um je nach URL, in der Applikation bestimmte Funktionen auszuführen und eine Browser-History zu erzeugen. Interpretiert wird dabei nur der Teil der URL nach dem Hash Tag. Damit kann auch der Einstiegspunkt zum Rendern der View erfolgen.

Im folgenden Beispiel würde die Url http://www.myDomain.at/#/events die EventListView rendern, für jede andere URL kann eine default Route durch *action definiert werden.

Dynamische Routenparameter können durch Doppelpunkt, zur Angabe eines Parameters, oder *,  zur Angabe beliebig vieler Parameter, definiert werden.

var appRouter = Backbone.Router.extend({
  routes : {
    'events' : 'showEvents',
    'events/:id' : 'showEvent',
    'download/*path' : 'downloadFile',
    '*action' : 'defaultRoute'
  },

  initialize: function() {
    Backbone.history.start({
      pushState: true
    });
   },

  showEvents: function() {
    // init EventListView
  },
  showEvent: function(id) {
    // init EventView
  },
  downloadFile: function(path) {
    // download File
  },
  defaultRoute: function() {
    // init default view
  }

});

return appRouter;

Verwendung von Require.js

Je nach Applikationsumfang kann es sehr viele Models, Collections und Views geben, welche nicht alle immer sofort und gleichzeitig benötigt werden und in der richtigen Reihenfolge integriert werden müssen, da sie voneinander abhängen.
Um dieses Problem zu lösen und die Ladezeiten gering zu halten, ermöglicht Require.js das modulare Laden von JavaScript Files. Durch die Angabe der Abhängigkeiten eines JavaScript Moduls werden die Files immer dann geladen, wenn sie benötigt werden.

Als Script Tag wird lediglich Require.js selbst eingebunden und im Attribut data-main der Pfad zum Einstiegspunkt angegeben.

<script type="text/javascript" src="/js/plugins/require.js" data-main="/js/main.js"></script>

In diesem Fall startet die Applikation in der main.js, in der es sich anbietet die Konfiguration für Require anzugeben. Beispielsweise können für die Pfade zu den einzelnen JavaScript Files sprechende Namen vergeben werden, um sie später leichter als Abhängigkeit in einem File angeben zu können.

require.config({
  paths: {
    // libraries
    jquery: 'js/jquery.min',
    underscore: 'js/underscore-min',
    backbone: 'js/backbone-min',
    // plugins
    text: 'js/plugins/text',
    // views
    eventListView: 'app/views/eventListView',
    eventListItemView: 'app/views/eventListItemView',
    // Models
    event: 'app/models/event',
    // collections
    eventList: 'app/collections/eventList',
    // routing
    router: 'app/routes/router'
  }
});

Danach wird in diesem Beispiel das Routing instanziert, welches ab diesem Zeitpunkt die Aktionen, in unserem Fall das Rendern der Views je nach Url, übernimmt. Durch die Angabe der Abhängigkeit im define wird das benötigte File automatisch geladen. Als Parameter wird der Funktion ein beliebiger Name übergeben, unter welchem das Router Modul dann zur Verfügung steht.

define(['router'], function(Router) {
  var myRouter = new Router;
});

Im File router.js müssen nun ebenfalls die Abhängigkeiten angegeben werden, damit die entsprechenden Datein geladen werden.

define([
  'jquery',
  'underscore',
  'backbone',
  'eventList',
  'eventListView'
], function($, _, Backbone, EventList, EventListView){
  var appRouter = Backbone.Router.extend({
    routes : {
      'events' : 'showEvents',
      ...

In allen anderen JavaScript Modulen verhält es sich gleich. Über define werden die Pfade oder die dafür vergebenen Namen angegeben, die zum Ausführen des Codes benötigt werden. Der gesamte Code des Moduls wird in eine Funktion gewrappt, die als Parameter die eigene Bezeichnung der abhängigen Module in der gleichen Reihenfolge wie im define nimmt.

Durch das Require.js Text Plugin ist es möglich, in einer View das benötigte Template von extern zu Laden. Über text! + die Url des Templates kann angegeben werden, welches HTML File integriert werden soll.

define([
 'jquery',
 'underscore',
 'backbone',
 'text!templates/event.html'
], function ($, _, Backbone, tmp) {
  var EventListItemView = Backbone.View.extend({
    tagName:'li',
    template:_.template(tmp)
  });
  return EventListItemView
});

Kombination mit Sails.js am Server

Nachdem das Model, die Collection und die View definiert wurden, müssen diese nun auch mit Models gefüllt werden. Die Daten dazu kommen von unserem Sails.js Server, der im Blogbeitrag Teil1: Sails.js Einführung in das Backend MVC Framework vorgestellt wurde.

Backbone bietet eine elegante Integration von RESTful Services. Stellt das Backend eine RESTful API zur Verfügung, welche Daten über GET abruft, über POST erstellt, über PUT updated und über DELETE löscht, ist es einfach, diese mit Backbone zu verwenden. Sails.js legt automatisch, sofern die REST Blueprints aktiviert sind, für jedes Model Routen mit diesem HTTP Methoden an. In ihrer Dokumentation nennen sie dieses System sogar die “Backbone Convention”. http://sailsjs.org/#!documentation/routes

# Backbone Conventions
    GET   :    /:controller              => findAll()
    GET   :    /:controller/read/:id     => find(id)
    POST  :    /:controller/create       => create()
    POST  :    /:controller/create/:id   => create(id)
    PUT   :    /:controller/update/:id   => update(id)
    DELETE:    /:controller/destroy/:id  => destroy(id)

Das Model sowie die Collections besitzen in Backbone ein Attribut url oder urlRoot, welches angibt, von welcher Server Adresse sie die Daten bekommen. Wir erweitern also unser Model und unsere Collection an Events von oben um dieses Attribut:

var Event = Backbone.Model.extend({
  urlRoot: '/event'
});

return Event;

var EventList = Backbone.Collection.extend({
  model: Event
  url: '/event'
});

return EventList;

Heißt das Model am Sails Server Event, lautet die dazu automatisch generierte Url /event. Diese Information reicht der Collection am Client, um all ihre Abfragen, Updates und Löschbefehle richtig zu adressieren.

Jedes Backbone Model besitzt die Methoden fetch(), save() and destroy(), wobei save einen create oder update Befehl bewirkt, je nachdem ob das Model bereits eine ID hat oder nicht.

Erweitert man also die Collection wieder und definiert eine initialize Funktion, die wie oben bereits erwähnt beim Instanzieren eines Objekts immer aufgerufen wird, kann man beispielsweise an dieser Stellte die fetch() Methode aufrufen, um die Daten vom Server zu holen.

var EventList = Backbone.Collection.extend({
  model: Event
  url: '/event',

  initialize: function() {
    this.fetch();
  }
});

return EventList;

Hier wird laut den HTTP Methoden, die Backbone und Sails verwenden, ein GET Befehl an die Url http://www.myDomain.at/event gesendet. Sails liefert dann ein JSON mit allen Events zurück, welche dann als Backbone Event Models am Client verfügbar sind.

Das Zusammenspiel von Client und Server erfolgt so automatisiert und es müssen keine manuellen Requests geschickt oder am Server abgefangen werden.

The post Teil 2: Sails.js mit Backbone.js am Client kombinieren appeared first on Mobile USTP MKL.

Im Rahmen einer Lehrveranstaltung an der FH lernte ich das Front-End Framework AngularJS kennen. Dabei habe ich ein paar sehr interessante Konzepte gefunden.

Gefällt mir

Das Routing

Der $routeProvider in Angular ermöglicht es Views, Controller und die aktuelle URL im Browser zusammen zu bringen. Durch das setzten der verschiedenen URLs je View ist das Vor- und Zurücknavigieren trotz Single-page application im Browser möglich.

app.config(function($routeProvider){
  $routeProvider.when('/home', {
    templateUrl: 'partials/home.html',
    controller: 'homeController'
  });

  $routeProvider.when('/events', {
    templateUrl: 'partials/events.html',
    controller: 'eventsController'
  });

  $routeProvider.otherwise({ redirectTo: '/home' });

});

Wenn man also http://myAngularApp/#events im Browser lädt, lädt Angular das entsprechende Template in das vorher dafür definiert Element und ruft den dazugehörigen Controller auf in dem sich die Logik zur View befindet.

Neben diesen statischen URLs ist es auch möglich in der URL Parameter zu definieren.

$routeProvider.when('/event/:eventTitle', {
  templateUrl: 'partials/eventDetail.html',
  controller: 'eventDetailController'
});

Somit kann das selbe Template mit unterschiedlichen Daten gefüllt werden und man erhält eine individuelle URL, was sich beispielsweise sehr gut für Detailansichten eignet.

Die View

Die Directive ng-View ergänzt das $route Service indem es das Template der aktuellen Route in das Grundlayout einfügt. Das Attribut ng-view gibt also an, wo im HTML Gerüst das jeweils geladene Template gerendert werden soll. Immer wenn sich die Route ändert, ändert sich auch die View nach den Konfigurationen des $route Service wie oben beschrieben.

<section id="content" ng-view>

</section>

Die Templates

Die oben erwähnten Templates sind die HTML Segmente die routenabhängig in das HTML Grundgerüst geladen werden. Sie können in eigene Files ausgelagert werden oder in script tags mit dem typ text/ng-template im gleichen Dokument liegen.

Die double curly brace Notation {{ }} ermöglicht Datenbindung an Ausdrücke im Markup. Diese werden jederzeit upgedated wenn sich der dazugehörige Wert an den sie gebunden sind ändert.

<h1> {{ title }} </h1>

<p> {{ message }} </p>

Schleife im Markup

Die ng-repeat Direktive wiederholt das Element auf das sie gesetzt wurde für jedes Objekt im Model. Somit kann das Markup für eine Liste direkt im HTML einmal geschrieben werden und wird dann automatisch wiederholt. Für mich ist das eine sehr nützliche Funktion und schönere Variante, als das Markup im JavaScript File zu schreiben und es dann in einer Schleife im JavaScript erst an ein Element im DOM zu hängen.

<ul>

  <li ng-repeat="event in events">

    <h1> {{ event.title }} </h1>

    <p>  {{ event.date }} {{ event.location }}</p>

  </li>

</ul>

Gefällt mir nicht

Viele Direktiven im HTML

Neben den notwendigen Direktiven um Model, View und Controller ans HTML zu binden und der praktischen ng-repeat Funktionalität, gibt es eine Vielzahl an weiterer Direktiven die als Attribute ins HTML geschrieben werden um Funktionalitäten auszulösen.

Durch ng-show=”!myFuntkion()” können beispielsweise Elemente angezeigt oder verborgen werden je nach Wert einer Variable oder Rückgabewert einer Funktion.

ng-click ist eine gängige Methode in Angular um click Events an Elemente zu binden, diese und weitere Attribute wie novalidate, ng-submit, ng-minlength, ng-maxlength, ng-hide, ng-list ….. und viele viele mehr verlagern für meinen Geschmack viel zu viel Logik ins Markup.

The post AngularJS – Meine ersten Eindrücke appeared first on Mobile USTP MKL.