diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..6a29c65
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+~*
diff --git a/Angular-for-all b/Angular-for-all
deleted file mode 100644
index 8b13789..0000000
--- a/Angular-for-all
+++ /dev/null
@@ -1 +0,0 @@
-
diff --git a/Angular2-for-all-platforms.md b/Angular2-for-all-platforms.md
index 5507ea3..4076728 100644
--- a/Angular2-for-all-platforms.md
+++ b/Angular2-for-all-platforms.md
@@ -4,9 +4,10 @@ Angular is the most popular framework for building client side web applications
Over the last few years it enabled over 1 million developers to build great Single Page Web Applications.
However the framework was always limited to the web only, which meant that you would have to use totally different tools/languages/frameworks if you needed to target desktop and mobile applications as well.
+
## Platform agnostic architecture
-This is where Angular 2 comes into play. The new version is completely platform agnostic, which means that it is designed to be used with various different platforms (be it web, mobile or desktop).
+This is where Angular 2 comes into play. The new version is completely platform agnostic, which means that it is designed to be used with various different platforms (be it web, mobile, desktop or even all kind of [IoT devices](https://medium.com/@urish/building-simon-with-angular2-iot-fceb78bb18e5)).
In simple terms the architecture is split into two parts:
- Platform agnostic - where your markup (HTML) is parsed by a Dom Adapter and then compiled into a set of Proto Views. This process is not specific to any platforms and most of its pieces can be shared between platforms.
- Platform specific - here is where the magic happens. To target each platform you need a Platform Specific Renderer, which based on the Proto Views generates a Visual Tree (used to display the UI). The Renderer is also responsible for propagating the changes and events between the Proto Views and the Visual Tree.
@@ -15,7 +16,12 @@ In simple terms the architecture is split into two parts:
With this architecture in place it was a matter of creating the necessary extensions to target different platforms.
+
## Adding mobile to the picture
+
+
+
+
This opened up the doors to [NativeScript](https://www.nativescript.org/), an Open Source framework for building iOS, Android and ([soon](https://www.nativescript.org/blog/details/nativescript-runtime-preview-for-windows-10)) Windows Universal apps with 100% Native UI.
Since the middle of 2015 both the Angular and the NativeScript teams have been working on bringing the two together. This resulted in the creation of NativeScript 2.0 ([news](http://sdtimes.com/nativescript-2-0-brings-mobile-strategy-options-angularjs-developers/)).
@@ -24,8 +30,11 @@ As a result NativeScript uses HTML as the markup to define the UI structure and
Here is how this fits in the Angular 2 architecture.
+
## Why NativeScript
+
+
### It works with Angular 2
You can use all of the [Angular 2 syntax](https://angular.io/docs/ts/latest/guide/template-syntax.html#) and get a mobile app as a result:
```HTML
@@ -93,20 +102,31 @@ Obviously no abstraction layer can cover all the possible functions available on
For example if you run the below ***JavaScript*** code on Android, you will get a new instance of a file object.
```JavaScript
-function openFile(url) {
+function openFile() {
var myFile = new java.io.File("filePath.txt");
return myFile;
}
```
-## Single codebase for all
-> Should I include this part??? or would this be too much???
## Want to learn more?
+
+[](http://www.developer-week.de/)
+
There will be a couple of talks about NativeScript at DWX, which are really worth attending.
- * [Introduction to NativeScript](http://www.developer-week.de/Programm/Veranstaltung/(event)/20557) on Monday 20-June at 17:00 - in this talk you will learn what NativeScript is made of, how it works inside and you will see some JavaScript examples on how to build mobile apps with it.
- * [Native Mobile Apps mit NativeScript und Angular 2.0](http://www.developer-week.de/Programm/Veranstaltung/(event)/20683) on Wednesday 22-June at 9:00 - in this talk you will learn how we built the NativeScript 2.0, how does it work with Angular 2 and how to aim for a shared code base between mobile and web apps.
+ * [Introduction to NativeScript][1] on Monday 20-June at 17:00 - in this talk you will learn what NativeScript is made of, how it works inside and you will see some JavaScript examples on how to build mobile apps with it.
+ * [Native Mobile Apps mit NativeScript und Angular 2.0][2] on Wednesday 22-June at 9:00 - in this talk you will learn how we built the NativeScript 2.0, how does it work with Angular 2 and how to aim for a shared code base between mobile and web apps.
There is a great [Getting Started guide](http://docs.nativescript.org/angular/tutorial/ng-chapter-0), which you can follow to build a Native iOS and Android mobile app with Angular2 and NativeScript.
-
+
+[1]: http://www.developer-week.de/Programm/Veranstaltung/(event)/20557
+[2]: http://www.developer-week.de/Programm/Veranstaltung/(event)/20683
+
+---
+
+[](https://twitter.com/sebawita)
+[Sebastian Witalec](https://twitter.com/sebawita), Technical Evangelist for Telerik, a Progress company
+
+[](https://twitter.com/johanneshoppe)
+[Johannes Hoppe](https://twitter.com/johanneshoppe), Telerik Developer Expert
\ No newline at end of file
diff --git a/Angular2-fuer-alle-Plattformen.md b/Angular2-fuer-alle-Plattformen.md
new file mode 100644
index 0000000..bb1dc32
--- /dev/null
+++ b/Angular2-fuer-alle-Plattformen.md
@@ -0,0 +1,136 @@
+# Mobile Apps mit Angular 2 entwickeln
+
+In den letzten Jahre haben mehr als eine Million Entwickler erfolgreich mit AngularJS Single-Page-Anwendungen erstellt. Angular ist damit das populärste Framework um client-seitige Webanwendungen zu entwickeln (siehe z.B. [Stack Overflow](http://stackoverflow.com/research/developer-survey-2016#most-popular-technologies-per-occupation)). Allerdings blieb das Framework dabei bislang immer auf das Web beschränkt. Das bedeutet, dass man bis dato völlig andere Tools, Programmiersprachen und Frameworks benötigte, um Anwendungen für den Desktop oder für mobile Geräte an den Start zu bringen.
+
+
+## Plattformunabhängige Architektur
+
+Hier wird Angular 2 interessant. Der komplette Rewrite von AngularJS 1 wurde stark auf Plattformunabhängigkeit ausgerichtet. Das bedeutet, dass das Framework so entworfen wurde, dass diverse Plattformen angesprochen werden können (sei es Web, Mobil, Desktop und sogar [IoT-Geräte](https://medium.com/@urish/building-simon-with-angular2-iot-fceb78bb18e5)).
+Vereinfacht ausgedrückt ist die Angular-2-Architektur in zwei Teile aufgeteilt:
+
+- __Plattform-unabhängiger Teil__: hier wir das Markup (HTML) durch einen DOM-Adapter geparst und in so genannte „Proto Views“ compiliert. Dieser Prozess ist nicht spezifisch für eine Zielplattform und die meisten Funktionen können in den verschiedenen Plattformen genutzt werden
+- __Plattform-spezifischer Teil__: hier geschieht die Magie. Es werden plattformspezifische Renderer verwendet, um die unterschiedlichen Zielplattformen abzubilden. Jene Renderer haben die Aufgabe, aus den „Proto Views“ einen „Visual Tree“ zu generieren. Dieser kann dann verwendet werden, um die Oberfläche anzuzeigen. Der Renderer ist ebenso dafür verantwortlich, Änderungen und Events zwischen „Proto Views“ und „Visual Tree“ auszutauschen.
+
+
+
+
+Durch diese durchdachte Architektur ist es möglich, neue Ziele zu definieren. Es müssen nur die notwendigen Erweiterungen implementiert werden.
+
+
+## Native Mobile Anwendungen
+
+
+
+Auf Grundlage der plattformunabhängigen Architektur von Angular kann [NativeScript](https://www.nativescript.org/) seine Stärken zeigen. NativeScript ist ein Open-Source-Framework, mit dem man native Apps für iOS, Android und [bald](https://www.nativescript.org/blog/details/nativescript-runtime-preview-for-windows-10) auch Windows 10 bzw. Windows Phone 10 entwickeln kann. „Nativ“ bedeutet, dass tatsächlich echte native UI-Elemente aus der JavaScript-Umgebung heraus angesprochen werden können. Seit Mitte 2015 arbeiten das Angular-Team und das NativeScript-Team zusammen, um beide Frameworks miteinander zu verbinden. Das Ergebnis dieser Zusammenarbeit ist NativeScript 2.0 ([News](http://sdtimes.com/nativescript-2-0-brings-mobile-strategy-options-angularjs-developers/)).
+
+Die Lösung für Angular 2 besteht darin, dass sehr spezielles Markup in HTML definiert wird. Diese Markup kann dann vom DOM-Adapter „Parse5“ geparst werden. Den größten Anteil an der Umsetzung nimmt der „NativeScript Renderer“ ein. Dieser garantiert nicht zuletzt den Austausch zwischen „Proto Views“ und den nativen UI Komponenten der jeweiligen Platform:
+
+
+
+
+## Warum NativeScript?
+
+
+
+### Kurzum: es funktioniert wunderbar mit Angular 2
+
+Wenn man erstmal die neue [Template-Syntax](https://angular.io/docs/ts/latest/guide/template-syntax.html) von Angular gelernt hat, dann kann man das bestehende Wissen auf eine NativeScript-App übertragen. Hier ist ein einfaches Beispiel, wie ein Button verarbeitet wird. Es fällt auf, dass dies Komponente kein normales HTML beinhaltet:
+
+```HTML
+@Component({
+ selector: "my-app",
+ template: `
+
+
+
+
+
+
+
+ `
+})
+export class MyComponent {
+ counter: number = 0;
+ onTap() {
+ this.counter++;
+ }
+}
+```
+
+### Abstraktionsschicht
+
+NativeScript hat eine beträchtliche Abstraktionsschicht an Board, welche die Unterschiede zwischen den unterstützen Zielplattformen (iOS, Android, UWP) ausbügelt. Hierdurch kann man mit einer einzigen Code-Basis alle nennenswerten Geräte bedienen. Besonders wichtig ist eine gescheite UI-Abstraktion, bei der jede [UI-Komponente](http://docs.nativescript.org/ui/ui-views) eine eigene native Implementierung besitzen muss. Zum Glück müssen wir nicht diese spezifische Implementierungen selbst entwickeln. Es wurde bereits eine grundlegende Auswahl an Bedienelementen vom NativeScript-Team umsetzt. So können wir folgendes Markup definieren und erhalten eine ***native Oberfläche***, die in allen Betriebsystemen die jeweils zu erwarteten Bedienelemente besitzt:
+
+```HTML
+@Component({
+ selector: "my-app",
+ template: `
+
+
+
+
+
+
+
+
+
+ `
+})
+```
+
+Weiterhin bietet das NPM-Paket „**T**elerik **N**ative**S**cript Core Modules“ (kurz: [tns-core-modules](https://github.com/NativeScript/NativeScript/tree/master/tns-core-modules)) eine reiche Auswahl an Funktionalitäten, die man gemeinhin für die App-Entwicklung benötigt. Möchte man z.B. ein Foto mit der Kamera machen, so muss man lediglich das entsprechende [Kamera-Modul](https://docs.nativescript.org/hardware/camera#using-the-camera-module-to-take-a-picture) mit `require` laden und es aufrufen. Wie die Kamera in den jeweiligen Betriebssystemen aufgerufen werden muss, braucht uns dann nicht mehr zu interessieren.
+
+
+```JavaScript
+import {Image} from "ui/image";
+import cameraModule = require("camera");
+
+cameraModule.takePicture().then(picture => {
+ console.log("Result is an image source instance");
+ var image = new Image();
+ image.imageSource = picture;
+});
+```
+
+Wenn Sie allerding neugierig sind, was unter Android ([Github](https://github.com/NativeScript/NativeScript/blob/master/tns-core-modules/camera/camera.android.ts#L9-L111)) oder iOS ([Github](https://github.com/NativeScript/NativeScript/blob/master/tns-core-modules/camera/camera.ios.ts#L82-L126)) passiert, wenn die Methode `takePicture` aufgerufen wird, dann schauen sich am einfach das [Github-Repository](https://github.com/NativeScript/NativeScript/tree/master/tns-core-modules) an. Dort sind alle Core-Komponenten gesammelt.
+
+
+### Direkter Zugriff auf Native APIs
+
+Natürlich kann keine Abstraktionsschicht alle möglichen Funktionen abdecken. Ebenso möchte man womöglich für bestimmte Aufgaben eine native Fremdbibliothek eines Drittanbieters einbinden. Unter NativeScript stellt dies kein Problem dar. Es ist nämlich stets möglich, direkt aus **JavaScript** heraus Android- oder iOS-APIs anzusprechen. Zum Beispiel wird folgender Quelltext unter Android (und nur unter Android) eine Instanz des Datei-Objekts erzeugen:
+
+```JavaScript
+function openFile() {
+ var myFile = new java.io.File("filePath.txt");
+ return myFile;
+}
+```
+
+Das Beste an der gezeigten Syntax ist die Tatsache, dass sowohl Namespaces, als auch Attribute und Typen sowie die gesamten Konventionen bei der Benennung dem Pendant aus der Android- bzw. iOS-Dokumentation entspricht. Dasselbe gilt für Fremdbibliotheken. So lässt sich mit geringem Aufwand ein Code-Fragment aus den Dokumentationen oder dem Netz per Copy-and-Paste zum Laufen bringen. Hinter den Kulissen verwendet NativeScript „Reflection“, um eine Liste von APIs aufzubauen, die auf der aktuellen Plattform zur Verfügung stehen und zum globalen Gültigkeitsbereich hinzugefügt werden. Gibt es eine API auf dem Endgerät, dann kann man diese auch aufrufen!
+
+
+## Lust auf mehr?
+
+[](http://www.developer-week.de/)
+
+Auf der DWX-Developer Week 2016 wird es zwei Vorträge zu NativeScript geben.
+
+* [Introduction to NativeScript][1], 20.06.2016 17:00 - 18:00 Uhr, Track: Cross-Plattform
+ In diesem Talk erfahren Sie, wie NativeScript aufgebaut ist, wie es funktioniert und vor allem wie man performante mobile Apps mit dem Framework entwickeln kann.
+* [Native Mobile Apps mit NativeScript und Angular 2][2], 22.06.2016 09:00 - 10:00 Uhr, Track: Mobile Architekturen
+ In diesem schauen wir uns das Zusammenspiel zwischen NativeScript und Angular 2 genauer an. Als besonderes Schmankerl zeigen wir Ihnen, wie man auf Grundlage von Angular Code für mobile Apps und Webanwendungen wiederverwenden kann.
+
+
+Sie sollten auch den ausführlichen [Getting Started guide](http://docs.nativescript.org/angular/tutorial/ng-chapter-0) durchlesen. Hier erfahren Sie alles Notwendige, um native Apps für iOS und Android auf Basis von Angular2 und NativeScript zu entwickeln.
+
+
+[1]: http://www.developer-week.de/Programm/Veranstaltung/(event)/20557
+[2]: http://www.developer-week.de/Programm/Veranstaltung/(event)/20683
+
+---
+
+[](https://twitter.com/sebawita)
+[Sebastian Witalec](https://twitter.com/sebawita), Technical Evangelist for Telerik, a Progress company
+
+[](https://twitter.com/johanneshoppe)
+[Johannes Hoppe](https://twitter.com/johanneshoppe), Telerik Developer Expert
\ No newline at end of file
diff --git a/Introduction-to-Nativescript.md b/Introduction-to-Nativescript.md
index 598a7b1..45b6f47 100644
--- a/Introduction-to-Nativescript.md
+++ b/Introduction-to-Nativescript.md
@@ -16,7 +16,7 @@ However NativeScript belongs to the JavaScript Native category of building mobil
# Why NativeScript?
## Skills reuse
-If you already know **JavaScript**, *(optionally)* **TypesScript** and **CSS**, then you already have a big chunk of skills required to build mobile apps. You don't need to learn **Xcode**, **Java** and **C#** to target multiple platforms.
+If you already know **JavaScript**, *(optionally)* **TypesScript** and **CSS**, then you already have a big chunk of skills required to build mobile apps. You don't need to learn **Objective-C**, **Swift**, **Java** and/or **C#** to target multiple platforms.
Further more if you are coming from the Angular backgroud, you coud use NativeScript with **Angular 2.0**. We will come back to this point in a moment, as this is a real game changer.
@@ -45,9 +45,10 @@ You get the best of the two worlds, a great piece of technology supported by a s
# Abstraction Layer
NativeScript lets you target multiple platforms without you having to write a single line of a platform specific code.
-This can be achieved thanks to **tns-core-modules** (available from npm) an **Abstraction Layer** that contains platform specific implementation for each supported platfrom. It provides with modules that cover many different aspects of a mobile app from **UI abstraction**, through **Device Sensors** to **Hardaware Access** and many more.
+This can be achieved thanks to **tns-core-modules** (available from npm) an **Abstraction Layer** that contains platform specific implementation for each supported platfrom. It provides with modules that cover many different aspects of a mobile app from **UI abstraction**, through **Device Sensors** to **Hardware Access** and many more.
-
+
+
Thanks to the **tns core modules** you no longer need to think on how to perform the same operation using 3 different Platform APIs, but instead you can concentrate on the what and not how.
@@ -130,7 +131,7 @@ This means that now you have another way of using NativeScript. You can build yo
For example if you want to add a login screen to your app you could do it in the following steps:
-### 1) Create a UserService Component, which will contain the code to login.
+### 1) Create a UserService class, which will contain the code to login.
```JavaScript
import {Injectable} from "angular2/core";
@@ -182,9 +183,10 @@ export class LoginPage {
```HTML
-
+
-
+
+
```
@@ -192,22 +194,10 @@ With a bit of extra styling the Login Screen should look something like this:
-
-
-
-> Reword this somehow
+# Reword this somehow
Angular 2 provides the architecture and mechanisms for the application logic to communicate with the UI components, while NativeScript provides the mechanism to interact with the Native APIs and Native UI components.
->You get the best of the two worlds: NativeScript's access to the Native UI and API and Angular's mechanisms.
-
-
-# How does this change your mobile strategy
+You get the best of the two worlds: NativeScript's access to the Native UI and API and Angular's mechanisms.
-## The bigger picture > Mobile/Web/Desktop
-
-## Dev team setup
-
-# Other
## Getting started pointers -> http://docs.nativescript.org/getting-started
-## Performance – Native UI ???
diff --git a/Mobile-Apps-mit-NativeScript-und-Angular-2-entwickeln.docx b/Mobile-Apps-mit-NativeScript-und-Angular-2-entwickeln.docx
new file mode 100644
index 0000000..03610b6
Binary files /dev/null and b/Mobile-Apps-mit-NativeScript-und-Angular-2-entwickeln.docx differ
diff --git a/NativeScript-Angular2-dotnetpro.md b/NativeScript-Angular2-dotnetpro.md
new file mode 100644
index 0000000..387960f
--- /dev/null
+++ b/NativeScript-Angular2-dotnetpro.md
@@ -0,0 +1,329 @@
+# Mobile Apps mit NativeScript und Angular 2 entwickeln
+## Das Beste aus allen Welten
+
+### Statt eigenständige, native Apps für die mobilen Betriebssysteme zu erstellen, können Sie auf hybride Apps auf Basis von HTML und JavaScript setzen. Dabei sind Beschränkungen schwer zu vermeiden. Das Open-Source Framework NativeScript schickt sich an, die letzten vorhandenen Grenzen einzureißen: echte native Apps auf Basis von JavaScript.
+
+Die Anforderungen an moderne Apps sind unter anderem eine ansprechende Ästhetik, ein plattformspezifisches Nutzererlebnis und natürlich bestmögliche Performance. Normalerweise werden hierzu eigenständige Apps für die beiden großen mobilen Betriebssysteme erstellt. Doch parallele Entwicklungen erzeugen gleichzeitig erhöhte Kosten. Eine Antwort darauf sind hybride Apps auf Basis von HTML und JavaScript. Das bedeutet automatisch aber ein paar technische Beschränkungen. Durch NativeScript von Telerik (ein Unternehmen von Progress Software) ist es möglich, direkt mit JavaScript native Apps zu entwickeln. Diese Apps sind nicht mehr von Lösungen unterscheidbar, die klassisch auf Basis von Objective-C bzw. Swift oder Java entwickelt worden sind. Sie verfügen über eine beachtliche Geschwindigkeit und verwenden die normalen Bedienelemente des jeweiligen mobilen Betriebssystems.
+
+
+> [Abb. 1] Zwei NativeScript-Screens unter iOS
+
+
+
+#### Was ist NativeScript?
+
+NativeScript ist ein Open-Source Framework zur Entwicklung von mobilen Apps [1]. Neben der Programmiersprache JavaScript wird auch die JavaScript-Obermenge TypeScript direkt unterstützt. Aktuell stehen als Zielplattform sowohl Android als auch iOS zur Verfügung. Seit der jüngsten Version 1.7 (März 2016) ist auch ein Support für universelle Windows-Plattform Apps (UWP) hinzugekommen. Jene universellen Apps sind auf Windows Phone 10 und Windows 10 ausführbar. Momentan wird die neueste Zielplattform aber noch als „proof of concept” eingestuft. Zum aktuellen Zeitpunkt sind nur NativeScript-Apps für Android und iOS reif für den produktiven Einsatz.
+
+Auf den ersten flüchtigen Blick scheint das Framework eine weitere Variante des hybriden Ansatzes zu sein. Das bekannteste hybride Framework dürfte Apache Cordova (ehemals PhoneGap genannt) sein [2], das den Einsatz von HTML und JavaScript zur App-Entwicklung salonfähig gemacht hat. Cordova lässt Webanwendungen in einem Browser laufen und ermöglicht über Schnittstellen ebenso den Zugriff auf native Funktionen. Sofern Sie mit dem SPA-Framework AngularJS vertraut sind, steht Ihnen z.B. durch Einsatz des Ionic-Frameworks eine populäre und weit verbreitete Lösung zur Verfügung. Durch den Einsatz von vorbereiteten Themes und eigenem graphischen Geschick muten die fertigen Apps anschließend wie native Anwendungen an. Ein grundlegendes Problem ergibt sich jedoch prinzipiell immer: Eine hybride App ist und bleibt eine Website, die nur den Anschein erweckt, es handle sich um eine native Anwendung.
+
+Im Gegensatz dazu reiht sich NativeScript in eine neue Disziplin ein. In dieser Disziplin geht es darum, JavaScript als vollwertige Programmiersprache für Apps zu etablieren. Weitere Frameworks, die native Apps mit JavaScript ermöglichen, sind React Native von Facebook und Appcelerator Titanium. Bei allen drei Lösungen fällt der Umweg über HTML und das DOM schlicht weg. Die Frameworks ermöglichen die direkte Verwendung von nativen UI-Elementen aus der JavaScript-Umgebung heraus. Bei NativeScript für Android ist diese Umgebung Googles V8-Engine [3]. Unter iOS sowie unter Windows kommt JavaScriptCore zum Einsatz [4].
+
+
+> [Abb. 2] Die verwendeten JavaScript Virtual Machines
+
+##### Tipp: Sollten Sie skeptisch hinsichtlich der Performance sein, dann probieren Sie doch einfach die „Examples NativeScript” Apps im Google Play Store [5] oder iTunes [6] aus. Die App enthält eine Sammlung von graphischen Beispielen, welche die breiten Anwendungsmöglichkeiten von NativeScript demonstrieren.
+
+
+
+#### Warum NativeScript?
+
+Die technische Grundlage mag zwar spannend sein, doch im Projektalltag zählen praktische Gründe. Eine Reihe von Gegebenheiten spricht für den Einsatz von NativeScript.
+
+__Wiederverwendung von bestehende Skills:__ Das Erlernen einer neuen Programmiersprache zum Zwecke der App-Entwicklung ist anstrengend und aufwändig. Der Erwerb von Grundlagen einer Programmiersprache ist dabei noch das kleinere Problem. Der eigentliche Aufwand liegt im Detail. Es ist ein mühsamer und intensiver Prozess, bis ein Neueinsteiger tatsächlich alle Aspekte einer Programmierwelt kennt und sicher beherrschen kann. Während dieser Einarbeitung steht der Programmierer natürlich nicht mehr mit dem gewohnten Potential und der üblichen Kapazität
+zur Verfügung.
+
+Wenn Sie hingegen schon einmal eine Anwendung für das Web entwickelt haben, so sind sie unweigerlich mit JavaScript, ggf. sogar mit TypeScript und auf jeden Fall mit CSS in Berührung gekommen. Damit steht Ihnen bereits ein großer Teil des notwendigen Wissens zur Verfügung. Das dedizierte Erlernen von Objective-C, Swift, Java und/oder C# entfällt. Sollten Sie sich zudem mit den neuesten Trends zur Webentwicklung beschäftigen, dann wird für Sie die Unterstützung von Angular 2.0 von großem Interesse sein. Auf diese spannende Allianz von NativeScript und AngularJS werden wir im zweiten Teil dieses Artikels noch intensiver eingehen.
+
+**Wiederverwendung von bestehendem Code:** Durch den Einsatz der Programmiersprache JavaScript bietet es sich an, bestehende Geschäftslogik oder Bibliotheken aus dem Internet weiter zu verwenden. Mit dem Repository NPM steht ein großer Fundus aus kurzen Schnipseln bis ganzen Bibliotheken zur Auswahl. Es gilt lediglich zu beachten, dass in NativeScript kein DOM existiert. Das ist aber prinzipiell kein Problem, denn diese Restriktion gilt auch für alle üblichen Node.js-Pakete. Wenn Sie zum Beispiel ein Datum formatieren wollen, dann können Sie dafür die bekannte Bibliothek „moment” nutzen. Nach einer Installation per `npm install moment` steht Ihnen die Funktionalität wie üblich zu Verfügung:
+
+```javascript
+// JavaScript
+var moment = require("moment");
+var formattedTime = new moment().format("HH:mm:ss");
+```
+> Listing 1: Verwendung eines NPM-Pakets
+
+Es ist weiterhin möglich, bestehende native Fremdbibliotheken für Android und iOS anzusprechen. Das bedeutet, dass Sie nicht in der JavaScript- bzw. NativeScript-Welt gefangen sind. Wenn es notwendig ist, können Sie auch sehr plattformspezifischen Code aufrufen. Von diesem Prinzip macht auch die KomponentenSammlung „UI for NativeScript” Gebrauch [7]. Die bestehenden Komponenten-Sammlungen sind hier vom Hersteller mit einem JavaScript-Wrapper vereinheitlicht worden.
+
+**Direkter Zugriff auf native APIs:** Manchmal werden Sie einfach nicht drum herum kommen und Sie müssen doch tief in das Betriebssystem abtauchen. Für diese Fälle bietet NativeScript den direkten Zugriff auf native APIs aus JavaScript heraus an. Das ist ein großer Vorteil gegenüber React Native und Appcelerator, wo dies nicht so einfach möglich ist. Diesen Aspekt werden wir gleich noch einmal näher beleuchten.
+
+**Open Source:** Die Gretchenfrage in Sachen Software lässt sich bei NativeScript ohne Bauchschmerzen beantworten. Ja, das Framework ist Open-Source. Es steht unter der „Apache License, Version 2.0” (ASLv2), welche die Kombination mit proprietärem Code erlaubt. Das NativeScript-Team selbst besteht aus rund 35 Köpfen. Das Team wiederum wird von einer aktiven Community unterstützt, die auf Github die Fortentwicklung über Bug-Reports und Pull-Requests antreibt [8]. Es ist problemlos möglich, einen kompletten NativeScript-Workflow mittels der „NativeScipt-CLI” aufzubauen [9]. Wenn Sie es jedoch etwas komfortabler wünschen oder kommerziellen Support benötigen, so gibt es von Progress entsprechende kostenpflichtige Angebote. Lizenzpflichtig sind ebenso die erweiterte Komponenten-Sammlung „UI for NativeScript Pro” und die integrierte Entwicklungsumgebung „Telerik Plattform”.
+
+##### Hinweis: Das Unternehmen Telerik wurde Ende 2014 vollständig von Progress Software akquiriert. Schrittweise werden nun die Telerik-Produkte unter dem neuen Namen „Progress“ fortgeführt. Dies wird ggf. auch in Zukunft Einfluss auf die Namen der NPM-Pakete haben.
+
+
+
+#### Hinter den Kulissen
+
+Wie ist es möglich, unter Verwendung einer einzigen Code-Basis mehrere Plattformen anzusprechen? Die Grundlage hierfür bietet das NPM-Paket „**T**elerik **N**ativeScript **C**ore Modules” (kurz: „tns-core-modules”). Die darin enthaltenen Module bilden eine Abstraktionsschicht, die spezifische Implantierungen für die unterstützten Plattformen enthalten. Hier finden sich Module für die unterschiedlichen Aspekte der mobilen Entwicklung, von UI-Abstraktion zu Gerätesensoren bis hin zum Hardware-Zugriff (siehe Abbildung 3).
+
+
+
+> [Abb. 3] Die Abstraktionsschicht in einer Übersicht
+
+Da die NativeScript-Module in TypeScript geschrieben sind, bieten kompatible Entwicklungsumgebungen dank der Typ-Definition eine komfortable automatische Code-Vervollständigung und Syntax-Prüfungen an. Eigene Module können Sie im selben Stil erstellen und das Software-Ökosystem erweitern (siehe [10]).
+
+**UI-Abstraktion:** Die Gestaltung von Oberflächen wird natürlich nicht durch eine Aneinanderreihung von JavaScript-Befehlen realisiert. Stattdessen definieren Sie die Oberfläche in einem spezifischen XML-Dialekt. Tags wie `Button`, `TextField`, `DatePicker` werden hierbei in die jeweiligen Oberflächenelemente umgewandelt:
+
+```xml
+
+
+
+
+
+
+
+
+```
+> Listing 2: Eine einfache Seite mit Text und Button
+
+Beim Build der Anwendung wird jeder Tag durch das jeweilige native Äquivalent ersetzt. So wird etwa aus dem „TextField” je nach Plattform `android.widget.EditText` (bei Android) bzw. `UITextField` (bei iOS).
+
+
+#### Plattformspezifischer Code
+
+Es gibt Situationen, in denen der Aufruf von plattformspezifischem Code notwendig wird. Das kann zum Beispiel der Fall sein, wenn eine Funktionalität tatsächlich nur auf der jeweiligen Plattform existiert, wenn eine native Fremdbibliothek eingebunden werden soll oder das gewünschte Feature tatsächlich einfach noch nicht über ein Core-Modul implementiert wurde. Hier kommt der Zugriff auf die „Native API” ins Spiel. Die native Welt kann dabei so aufgerufen werden, als ob es sich um normale JavaScript-Methoden handeln würde.
+
+Als Beispiel soll das Datum der letzten Modifikation einer Datei ermittelt werden. Diese Funktionalität wird für Android und iOS gänzlich anders umgesetzt (siehe **Listing 3 und 4**).
+
+```javascript
+// JavaScript
+var fileManager = NSFileManager.defaultManager();
+var attributes = fileManager.attributesOfItemAtPathError(path);
+var lastModifiedDate = attributes.objectForKey(this.keyModificationTime);
+```
+> Listing 3: Zugriff auf das Datum der letzten Modifikation unter iOS
+
+
+```javascript
+// JavaScript
+var javaFile = new java.io.File(path);
+var lastModifiedDate = new Date(javaFile.lastModified());
+```
+> Listing 4: Zugriff auf das Datum der letzten Modifikation unter Android
+
+Das Beste an der gezeigten Syntax ist die Tatsache, dass sowohl Namespaces als auch Attribute und Typen sowie die gesamten Konventionen bei der Benennung dem Pendant aus der Android-bzw. iOS-Dokumentation entsprechen. Dasselbe gilt für Fremd-bibliotheken. So bringen Sie mit geringem Aufwand ein Code-Fragment aus den Dokumentationen oder dem Netz per Copy-and-Paste zum Laufen. Hinter den Kulissen verwendet NativeScript „Reflection”, um eine Liste von APIs aufzubauen, die auf der aktuellen Plattform zur Verfügung stehen und zum globalen Gültigkeitsbereich hinzugefügt werden. Die Details zu der verwendeten Technik können sie in einem detailierten Artikel nachvollziehen [11].
+
+
+#### Styling
+
+Bei der Gestaltung von Webseiten trennt man Struktur (HTML) und Design (CSS). Das direkte Styling von Elementen würde viel zu unübersichtlich sein und zu redundanten Deklarationen führen. Ganz ähnlich verhält es sich bei der Gestaltung einer NativeScript-App. Das Framework folgt hierbei den Spezifikationen von CSS und verwendet die bekannte Syntax, das Prinzip der kaskadierten Regeln und eine Auswahl an Selektoren und Deklarationen.
+
+Mittels CSS lassen sich einfache Dinge wie Hintergrundfarbe und Schriftgröße bis hin zu komplexen Animationen realisieren (siehe **Listing 5 und 6**).
+
+```css
+/* CSS */
+.small-label {
+ font-size: 20;
+ color: #284848;
+ horizontal-align: center;
+}
+```
+> Listing 5: Anpassung von Hintergrundfarbe und Schriftgröße per CSS
+
+```css
+/* CSS */
+.button1:highlighted {
+ animation-duration: 1s;
+ animation-name: test;
+}
+
+@keyframes test {
+ from { transform: none; }
+ 20% { transform: rotate(45); }
+ 50% { transform: rotate(50) scale(1.2, 1.2) translate(50, 0); }
+ 100% { transform: rotate(0) scale(1.5, 1.5) translate(100, 0); }
+}
+```
+> Listing 6: Einen Button per CSS animieren
+
+Das Styling per CSS ist bei NativeScript im Vergleich zum Browser jedoch sehr limitiert. Es handelt sich hierbei um eine übersichtliche Teilmenge des bekannten Browser-CSS. Dies liegt nicht zuletzt auch darin begründet, dass die verfügbaren Eigenschaften dem gemeinsamen Nenner der drei verfügbaren Plattformen entsprechen müssen.
+
+
+#### Angular 2
+
+
+> [Abb. 4] NativeScript loves Angular
+
+In den letzten Jahre haben mehr als eine Million Entwickler erfolgreich mit AngularJS Single-Page-Anwendungen erstellt. Angular ist damit das populärste Framework um client-seitige Webanwendungen zu entwickeln. Allerdings blieb das Framework dabei bislang immer auf das Web beschränkt. Das bedeutet, dass man bis dato völlig andere Tools, Programmiersprachen und Frameworks benötigte, um Anwendungen für den Desktop oder für mobile Geräte an den Start zu bringen. Die Version 2 von AngularJS wurde hingegen als komplette Neuentwicklung konzipiert. Dieser komplette Rewrite wurde stark auf Plattformunabhängigkeit ausgerichtet. Das bedeutet, dass das Framework so entworfen wurde, dass diverse Plattformen angesprochen werden können - sei es Web, Mobil, Desktop und sogar IoT-Geräte [12].
+
+NativeScript wurde als reines JavaScript-Framework geschaffen, das User-Interfaces per XML definiert und mit CSS formatiert. Beide Frameworks haben in der Kombination ein großes Potential. Das wurde recht schnell auch von Google und Progress erkannt. Seit Mitte 2015 arbeiten daher das Angular-Team und das NativeScript-Team zusammen um beide Frameworks miteinander zu verbinden. Dabei ist es eine gute Fügung, dass beide Projekte auf TypeScript setzen. Das Ergebnis der Zusammenarbeit beider Teams ist die "Angular 2 Rendering Architecture" [13], welche stark durch NativeScript 2 geprägt ist. Vereinfacht ausgedrückt ist die Angular-2-Architektur hierbei in zwei Teile aufgeteilt:
+
+- __Plattform-unabhängiger Teil__: hier wir das Markup (HTML) durch einen DOM-Adapter geparst und in so genannte „Proto Views“ compiliert. Dieser Prozess ist nicht spezifisch für eine Zielplattform und die meisten Funktionen können in den verschiedenen Plattformen genutzt werden
+- __Plattform-spezifischer Teil__: hier geschieht die Magie. Es werden plattformspezifische Renderer verwendet, um die unterschiedlichen Zielplattformen abzubilden. Jene Renderer haben die Aufgabe, aus den „Proto Views“ einen „Visual Tree“ zu generieren. Dieser kann dann verwendet werden, um die Oberfläche anzuzeigen. Der Renderer ist ebenso dafür verantwortlich, Änderungen und Events zwischen „Proto Views“ und „Visual Tree“ auszutauschen.
+
+
+
+> [Abb. 5] Die Rendering-Architektur von Angular 2
+
+Durch diese durchdachte Architektur ist es möglich, neue Ziele zu definieren. Es müssen nur die notwendigen Erweiterungen implementiert werden. Hier wird es aus architektonischer Sicht interessant.
+
+
+#### Angular 2 als Native App
+
+Auf Grundlage der plattformunabhängigen Architektur kann NativeScript sich nahtlos integrieren. Die Lösung besteht darin, dass das bereits bekannte NativeScript-Markup in HTML-Dokumenten definiert wird und der "Dom Adaper" sowie der "Renderer" ausgetauscht werden. Das NativeScript-Markup profiert dabei von der prägnanten Template-Syntax von Angular 2. Jenes Markup kann dann vom DOM-Adapter „Parse5“ geparst werden. Den größten Anteil an der Umsetzung nimmt der „NativeScript Renderer“ ein. Dieser garantiert nicht zuletzt den Austausch zwischen „Proto Views“ und den nativen UI Komponenten der jeweiligen Platform:
+
+
+> [Abb. 6] Die Rendering-Architektur von Angular 2 mit NativeScript
+
+Wenn man erstmal die neue Template-Syntax von Angular 2 gelernt hat, dann kann man das Wissen auf eine NativeScript-App übertragen. Es wäre natürlich möglich direkt mit purem JavaScript eine NativeScript-App zu entwickeln. Allerdings gewöhnt man sich schnell an den Komfort von Angular 2. Technische Aspekte wie "Dependency Injection" und "Change Detection" sind sehr einfach und verständlich in Angular 2 umgesetzt.
+
+
+#### Eine Beispiel-Anwendung
+
+Als kleines Beispiel setzen wir einen Login-Screen mit Angular 2 und NativeScript 2 um. Sollten Sie noch nie mit Angular 2 in Berührung gekommen sein, verschafft Ihnen der offizielle „5-Minuten-Schnellstart” einen guten Überblick [14]. Zunächst benötigen wir eine Klasse mit dem Namen `UserService`, welche die Logik für die Anmeldung beinhaltet und die Zugangsdaten zum Backend senden soll (**Listing 7**).
+
+```typescript
+// TypeScript
+import {Injectable} from "@angular/core";
+
+@Injectable()
+export class UserService {
+ login(userName: String, password: String) {
+ return doSomeMagicHereAndReturnPromise();
+ }
+}
+```
+> Listing 7: Der UserService kapselt die eigentliche Login-Funktionalität
+
+
+Die wichtigsten Grundbausteine in Angular 2 sind Komponenten. Komponenten definieren ganze Seiten, einzelne UI-Elemente und Routen. Eine Komponente hat immer ein Template, das aber im Falle von NativeScript kein normales HTML beinhaltet. Angular 2 sorgt auch gleich noch per „Dependendy-Injection” (DI) für die Verdrahtung von UserService und Komponente, so dass wir uns um die Initialisierung des UserService nicht zu kümmern brauchen (**Listing 8**).
+
+```typescript
+// TypeScript
+import {UserService} from "./user.service";
+@Component({
+ selector: "my-app",
+ providers: [UserService],
+ templateUrl: "pages/login/login.html"
+})
+export class LoginPage {
+ userName: String;
+ password: String;
+
+ constructor(private _userService: UserService) {
+ this.username = "user@example.org";
+ this.password = "password";
+ }
+
+ login() {
+ this._userService.login(this.username, this.password)
+ .subscribe(
+ () => doSomethingOnSuccessfulLogin (),
+ (error) => alert("Unfortunately we could not find your account.")
+ );
+ }
+}
+```
+> Listing 8: Die Komponente LoginPage verknüpft die Geschäftslogik mit dem UI
+
+
+Die Komponente `LoginPage` agiert als Bindeglied zwischen UserService und dem Template. Auf die Methode `login` sowie auf die beiden Eigenschaften „username” und „passwort” können wir nun im Template zugreifen.
+
+Zum Schluss müssen wir nur noch einen Screen im Template definieren (**Listing 9**). Der bereits vorgestellte XML-Dialekt zur Definition der Oberfläche kommt auch hier zum Einsatz. Die [eckigen] und (runden) Klammern sind der Template-Syntax von Angular 2 geschuldet. Es handelt sich um so genannte „Bindings”, die als Verknüpfung mit der Komponente dienen. Da die Verwendung dieser Klammern kein valides XML ergeben würde, deklarieren wir das Markup lieber als HTML statt als XML. Ob es sich nun um HTML oder XML handelt, praktisch gesehen ergibt sich hieraus aber kein wirklicher Unterschied. Die Bindings hauchen der Oberfläche Leben ein. Wird in dem Textfeld die Eingabe geändert, so wird die Änderung sofort in der Komponente publik gemacht. Eine Betätigung des Buttons ruft anschließend die Login-Methode auf.
+
+```html
+
+
+
+
+
+
+
+
+```
+> Listing 9: Das Template der Komponente LoginPage
+
+Nun stellt sich die Frage, an welcher Stelle die Unterscheidung zwischen einer "normalen" Web-Anwendung und einer nativen Anwendung geschieht. Die Antwort lautet: beim "Boostrapping". Eine normale Angular 2 Anwendung startet mit der üblichen `bootstrap` Methode durch (Listing 10). Um die native Welt zu betreten, müssen wir hingegen die spezielle Methode `nativeScriptBootstrap` verwenden (Listing 11).
+
+```typescript
+// TypeScript
+import { bootstrap } from '@angular/platform-browser-dynamic';
+import { AppComponent } from './app/';
+bootstrap(AppComponent);
+```
+> Listing 10: Das normale Bootstrapping
+
+```typescript
+// TypeScript
+import { nativeScriptBootstrap } from "nativescript-angular/application";
+import { AppComponent } from './app/';
+nativeScriptBootstrap(AppComponent);
+```
+> Listing 11: Das Bootstrapping mit NativeScript
+
+
+Et voilà! Schon steht die erste Seite unserer Anwendung. Zusammen mit etwas zusätzlichem Styling ergibt sich ein fertiger Dialog (siehe **Abbildung 7**). Das hier gezeigte Beispiel ist übrigens ein angepasster Ausschnitt aus der offiziellen Demo-App „Groceries”, mit der Sie eine Einkaufsliste zusammenstellen und teilen können. Die App kann einmal mit purem NativeScript [15] und einmal in Kombination mit Angular 2 [16] nachprogrammiert werden. Hier wird auch die Installation der notwendigen Abhängigkeiten – vor allem das iOS SDK und das Android SDK – detailliert beschrieben.
+
+
+
+> [Abb. 7] Die finale Login-Seite unter Android und iOS
+
+
+### Editoren
+
+Als Leser der dotnetpro werden Sie sicher eine IDE von Microsoft im Einsatz haben. Wie schaut es daher mit der Unterstützung für NativeScript aus?
+
+#### 1. Visual Studio
+
+
+> [Abb. 8] Installation des Telerik AppBuilder
+
+Ab Visual Studio 2013 kann man per Extension die Unterstützung von NativeScript aktivieren. Installiert werden muss lediglich die **"AppBuilder Extension for Visual Studio"**. Hierbei benötigt man allerdings eine Account bei der kostenpflichtigen Lösung "Telerik Platform". Die Telerik Platform ist das Flagschiff von Progress, wenn es um die Entwicklung von mobilen Apps geht. Einer der Services ist z.B. das Kompilieren in der Cloud, was ziemlich praktisch ist, wenn man keinen Mac zur Verfügung hat.
+
+
+> [Abb. 9] HelloWorld mit NativeScript
+
+#### 2. Visual Studio Code
+
+
+> [Abb. 10] Visual Studio Code mit NativeScript
+
+Der kleine Bruder von Visual Studio ist komplett Open-Source. Genau so verhält es sich mit der NativeScript Extension für Visul Studio Code. Man muss lediglich "F1" drücken und mit `ext install` nach "NativeScript" suchen. Während die Lösung von Visual Studio auf dem "AppBuilder" basiert, ist die Grundlage für Visual Studio Code die NativeScript-CLI [9]. Diese muss als globales NPM-Paket installiert sein. Zusätzlich sollte man genügend Zeit für das Setup einplanen, denn das benötigte Android SDK von Google ist nicht gerade leichtgewichtig. Die komplette Installation haben wir für Sie in einem separaten Blogpost beschrieben [17]. Naturgemäß kann man unter Windows keine iOS Apps kompilieren. Allerdings ist Visual Studio Code auch auf OS X zuhause. Wer einen Mac sein Eigen nennt, der kann sowohl Android- als auch iOS-Anwendungen auf seinem Rechner bauen. Hier wird dann zusätzlich XCode benötigt, die vollständige Installations-Einleitung finden Sie unter Link [18].
+
+
+> [Abb. 11] NativeScript Angular 2 code snippets
+
+Sie sollten übrigens unbedingt die "NativeScript + Angular 2 Snippets" ausprobieren. Die Ersparen Ihnen eine gehörige Menge an Tipparbeit.
+
+
+### Fazit
+
+Der Einstieg in die App-Entwicklung mit NativeScript ist für einen Webentwickler nicht sonderlich schwer. Angular 2 gibt der Anwendung eine solide Architektur vor und sorgt dafür, dass Geschäftslogik und Oberflächenelemente sauber getrennt bleiben. NativeScript wiederum liefert die Mechanismen, um mit nativen APIs und nativen UI-Elementen zu interagieren. Sie erhalten das Beste aus allen Welten: JavaScript bzw. TypeScript als Programmiersprache, Angular 2 als Oberflächenframework und das native Look-and-Feel, das schlussendlich dem Anwender gefallen wird.
+
+
+
+
+# Auf einen Blick
+
+
+**Johannes Hoppe** ist selbstständiger IT-Berater, Softwareentwickler und Trainer für .NET und AngularJS. 2015 wurde er von Progress als "Telerik Developer Expert" ausgezeichnet. Er ist Leiter der .NET User Group Rhein-Neckar und unterrichtet als Lehrbeauftragter der DHBW Mosbach. Johannes schreibt über seine Trainings und Vorträge in seinem Blog (http://blog.johanneshoppe.de/). Demnächst wird sein Buch zu Angular 2 beim dpunkt.verlag erscheinen.
+
+
+
+
+**Sebastian Witalec** ist Technical Evangelist bei Progress und hat über acht Jahre Erfahrung in der Softwareentwicklung. Sein Fokus liegt seit einigen Jahren auf der Cross-Plattform-Mobile-Entwicklung. Dadurch lernte er Apache Cordova und NativeScript kennen. Er lebt in London und arbeitet dort eng mit verschiedenen Entwicklercommunitys zusammen.
+
+
+
+
+#### Links
+
+[1] NativeScript: https://www.nativescript.org/
+[2] Apache Cordova: https://cordova.apache.org/
+[3] Google V8: https://developers.google.com/v8/
+[4] JavaScriptCore: http://trac.webkit.org/wiki/JavaScriptCore
+[5] Examples NativeScript, Goolge Play: https://play.google.com/store/apps/details?id=org.nativescript.nativescriptmarketplacedemo
+[6] Examples NativeScript, iTunes: https://itunes.apple.com/us/app/examples-nativescript/id1046772499?mt=8
+[7] NativeScript Telerik UI: https://www.npmjs.com/package/nativescript-telerik-ui
+[8] NativeScript auf Github: https://github.com/NativeScript/NativeScript
+[9] NativeScript CLI auf NPM: https://www.npmjs.com/package/nativescript
+[10] Building Your Own NativeScript Modules for npm: http://developer.telerik.com/featured/building-your-own-nativescript-modules-for-npm/
+[11] How NativeScript Works: http://developer.telerik.com/featured/nativescript-works/
+[12] Building Simon with Angular2-IoT: https://medium.com/@urish/building-simon-with-angular2-iot-fceb78bb18e5#.rfk659fc9
+[13] Angular 2 Rendering Architecture: https://docs.google.com/document/d/1M9FmT05Q6qpsjgvH1XvCm840yn2eWEg0PMskSQz7k4E/edit
+[14] Angular 2 - 5 Min Quickstart: https://angular.io/docs/ts/latest/quickstart.html
+[15] NativeScript Getting Started Guide: http://docs.nativescript.org/tutorial/chapter-0
+[16] Building Apps with NativeScript and Angular 2: http://docs.nativescript.org/angular/tutorial/ng-chapter-0.html
+[17] Johannes Hoppe - Setting Up Android Emulators for NativeScript Development: http://blog.johanneshoppe.de/2016/06/setting-up-android-emulators-for-nativescript-development/
+[18] NativeScript - Set Up Your System: http://docs.nativescript.org/angular/start/quick-setup
\ No newline at end of file
diff --git a/images/Abstraction-Layer.png b/images/Abstraction-Layer.png
deleted file mode 100644
index abfd134..0000000
Binary files a/images/Abstraction-Layer.png and /dev/null differ
diff --git a/images/Abstraction-Layer_v2.png b/images/Abstraction-Layer_v2.png
new file mode 100644
index 0000000..c24972d
Binary files /dev/null and b/images/Abstraction-Layer_v2.png differ
diff --git a/images/Angular2-platform-agnostic.png b/images/Angular2-platform-agnostic.png
index 976dc24..e52fc04 100644
Binary files a/images/Angular2-platform-agnostic.png and b/images/Angular2-platform-agnostic.png differ
diff --git a/images/Angular2-platform-agnostic_DE.png b/images/Angular2-platform-agnostic_DE.png
new file mode 100644
index 0000000..30ee490
Binary files /dev/null and b/images/Angular2-platform-agnostic_DE.png differ
diff --git a/images/Angular2-with-NativeScript.png b/images/Angular2-with-NativeScript.png
index c4d76bc..e35f9bf 100644
Binary files a/images/Angular2-with-NativeScript.png and b/images/Angular2-with-NativeScript.png differ
diff --git a/images/Angular2-with-NativeScript_DE.png b/images/Angular2-with-NativeScript_DE.png
new file mode 100644
index 0000000..22120a3
Binary files /dev/null and b/images/Angular2-with-NativeScript_DE.png differ
diff --git a/images/AngularMultiPlatform.png b/images/AngularMultiPlatform.png
deleted file mode 100644
index 2f863a7..0000000
Binary files a/images/AngularMultiPlatform.png and /dev/null differ
diff --git a/images/JavaScript-VM.png b/images/JavaScript-VM.png
index bf06153..4ba6a6e 100644
Binary files a/images/JavaScript-VM.png and b/images/JavaScript-VM.png differ
diff --git a/images/Johannes_Hoppe.png b/images/Johannes_Hoppe.png
new file mode 100644
index 0000000..1e00ce3
Binary files /dev/null and b/images/Johannes_Hoppe.png differ
diff --git a/images/Johannes_Hoppe_small.png b/images/Johannes_Hoppe_small.png
new file mode 100644
index 0000000..9752885
Binary files /dev/null and b/images/Johannes_Hoppe_small.png differ
diff --git a/images/LoginScreen.png b/images/LoginScreen.png
index ba5b292..1cc6183 100644
Binary files a/images/LoginScreen.png and b/images/LoginScreen.png differ
diff --git a/images/Screenshots.png b/images/Screenshots.png
index ff4df39..32f0f7b 100644
Binary files a/images/Screenshots.png and b/images/Screenshots.png differ
diff --git a/images/Sebastian_Witalec.jpg b/images/Sebastian_Witalec.jpg
new file mode 100644
index 0000000..0b3efe8
Binary files /dev/null and b/images/Sebastian_Witalec.jpg differ
diff --git a/images/Sebastian_Witalec_small.png b/images/Sebastian_Witalec_small.png
new file mode 100644
index 0000000..8668e48
Binary files /dev/null and b/images/Sebastian_Witalec_small.png differ
diff --git a/images/TeamSetup.png b/images/TeamSetup.png
deleted file mode 100644
index 08eebc3..0000000
Binary files a/images/TeamSetup.png and /dev/null differ
diff --git a/images/developer-week.jpg b/images/developer-week.jpg
new file mode 100644
index 0000000..f75a8c9
Binary files /dev/null and b/images/developer-week.jpg differ
diff --git a/images/how-does-this-work.png b/images/how-does-this-work.png
deleted file mode 100644
index e0e790c..0000000
Binary files a/images/how-does-this-work.png and /dev/null differ
diff --git a/images/nativescript-loves-angular.png b/images/nativescript-loves-angular.png
index c79df8f..da61632 100644
Binary files a/images/nativescript-loves-angular.png and b/images/nativescript-loves-angular.png differ
diff --git a/images/ng2-rendering-architecture.pptx b/images/ng2-rendering-architecture.pptx
new file mode 100644
index 0000000..1c3ce08
Binary files /dev/null and b/images/ng2-rendering-architecture.pptx differ
diff --git a/images/ui-for-nativescript-calendar.png b/images/ui-for-nativescript-calendar.png
deleted file mode 100644
index 12d43f0..0000000
Binary files a/images/ui-for-nativescript-calendar.png and /dev/null differ
diff --git a/images/visual_studio.png b/images/visual_studio.png
new file mode 100644
index 0000000..14033d1
Binary files /dev/null and b/images/visual_studio.png differ
diff --git a/images/visual_studio2.png b/images/visual_studio2.png
new file mode 100644
index 0000000..c5aefb8
Binary files /dev/null and b/images/visual_studio2.png differ
diff --git a/images/vscode1.png b/images/vscode1.png
new file mode 100644
index 0000000..09ab192
Binary files /dev/null and b/images/vscode1.png differ
diff --git a/images/vscode2.png b/images/vscode2.png
new file mode 100644
index 0000000..d950011
Binary files /dev/null and b/images/vscode2.png differ