NativeScript: Eine Alternative zu Xamarin und Cordova

Cross-Platform Technologien setzen sich in den letzten Jahren verstärkt als Lösungsansatz durch, um Business Apps für mobile Geräte bereitzustellen. Neben den schon etablierten Lösungen wie Xamarin und Cordova gibt es ein breites Spektrum an alternativen Frameworks. In diesem Artikel möchte ich NativeScript vorstellen, ein Cross-Platform Framework, welches auf aktuellen Webtechnologien aufsetzt (Angular 2 und TypeScript) und diese mit nativen Views verknüpft.

Was ist NativeScript?

NativeScript ist eine Cross-Platform Lösung für native iOS, Android und UWP (aktuell noch Preview) Apps mit einer gemeinsamen Angular 2 bzw. JavaScript Code Basis. Der Name NativeScript fasst auch schon die grundlegende Idee hinter NativeScript gut zusammen: Zugriff auf native Controls der Plattform per JavaScript Code. NativeScript wurde von Telerik entwickelt, welches selber auch Control Libraries für Cordova (Kendo UI), als auch für Xamarin anbietet. NativeScript ist unter der Apache 2.0 Software License veröffentlicht worden und damit als Open Source Software kostenlos verfügbar. Telerik bietet zusätzliche, teilweise kostenpflichtige Controls im Rahmen der Control Library Telerik UI for NativeScript an.

 

Historie von NativeScript

nativescript

 

Zum ersten Mal öffentlich vorgestellt wurde NativeScript im Juni 2014. Im Mai 2015 gab es dann die 1.0 Version mit einer eigenen Implementierung des MVC Patterns. Richtig interessant wurde es dann im Mai diesen Jahres mit der 2.0 Version, welche zusätzlich auch Angular 2 unterstützt. Seit September gibt es eine 2.3 Version, die das finale Release von Angular 2 verwendet.

 

Abgrenzung zu Cordova

Wie unterscheidet sich NativeScript nun zum Beispiel von Cordova:

  • NativeScript verwendet nicht den WebView, sondern setzt direkt auf die nativen UI-Technologien. Dadurch werden die WebView spezifischen Probleme umgangen und man erreicht auch eine bessere Performance, welche der einer nativen App entspricht.
  • NativeScript verwendet direkt die nativen UI-Controls und versucht nicht, diese mit HTML, CSS und JavaScript nachzubauen.
  • Durch die Kombination mit einer ähnlichen Technologie wie NativeScript, nämlich Electron, ist es möglich, große Teile des Codes (alles bis auf die Views, Styles und plattformspezifische Services) auch für Desktop Anwendungen (Windows, Linux und Mac) wiederzuverwenden.
    .

 

Abgrenzung zu Xamarin

NativeScript ermöglicht ähnlich wie Xamarin die Entwicklung nativer UIs, verwendet aber TypeScript bzw. JavaScript als Programmiersprache anstelle von C#. Dadurch können im Gegensatz zu einer Xamarin Lösung, große Teile einer NativeScript Lösung für eine Webanwendung wiederverwendet werden. Speziell bei der Verwendung der Angular 2 Variante von NativeScript ist dies sehr einfach realisierbar.

Angular 2 Unterstützung

Die enge Verzahnung von NativeScript mit Angular 2 vereinfacht nicht nur den Code Reuse für andere Plattformen, sondern ermöglicht auch eine bessere Strukturierung des Code als es mit einem Plain JavaScript Code Ansatz der Fall wäre. Dies ist eine der Grundvoraussetzungen für die Entwicklung von mobilen Apps im Enterprise Umfeld, wenn die Code Maintenance ein wichtiges Kriterium ist.

Auch Ionic setzt in der aktuellen 2.0 Version direkt auf Angular 2 auf.

nativescript angular

 

Fazit

NativeScript erlaubt Apps mit nativen UIs auf Basis einer gemeinsamen TypeScript bzw. JavaScript Codebasis umzusetzen. Da es sich bei diesem Code mit Ausnahme der Views und Styles um normalen Angular 2 Code handelt, kann dieser Code sehr leicht für Webanwendungen und durch die Verwendung von Electron auch für native Desktopanwendungen wiederverwendet werden. Spannend wird, ob NativeScript sich im hart umkämpften Markt der Cross-Platform Technologien durchsetzen kann und ob zum Beispiel auch andere Anbieter neben Telerik Control Libraries dafür anbieten werden. Die enge Zusammenarbeit zwischen dem NativeScript und Angular 2 Team während der Integrationsphase von Angular 2 in das NativeScript Projekt zeigt, dass auch Google an dem Erfolg von NativeScript interessiert ist.

Dieser Flurfunkartikel bietet einen allgemeinen Überblick über die Cross-Platform Technologie NativeScript. Die technischen Grundlagen und notwendigen Architekturentscheidungen folgen in einem kommenden Artikel. Denn auch in einem NativeScript Projekt gilt wieder: “Die Architektur ist entscheidend!” Smiley

Xamarin.Forms im Praxiseinsatz: Die Xamarin Test Cloud

Eine der großen Herausforderungen in der Cross-Platform-Entwicklung ist es sicherzustellen, dass die zu entwickelnde App auf allen zu unterstützenden Geräten und OS-Versionen entsprechend funktioniert. Vor allem die Anzahl der unterschiedlichen Android Geräte und OS-Versionen ist beachtlich. Dieser Artikel beschreibt, wie die Xamarin Test Cloud durch automatisierte UI Acceptance Tests in der Cloud helfen kann, diese Fragmentierung zu meistern.

Features der Xamarin Test Cloud

Die Xamarin Test Cloud ermöglicht es eine App durch automatisierte UI Tests auf einer Vielzahl von physikalischen Geräten zu testen. Aktuell bietet die Xamarin Test Cloud 37 unterschiedliche Tablets und 137 Phones für die iOS und Android Plattform an. Windows Phone und Windows 8 werden nicht unterstützt. Die einzelnen Geräte stehen zusätzlich noch in unterschiedlichen OS-Versionen zur Verfügung. Eine detaillierte Übersicht findet man hier.

Für die Entwicklung der automatisierten UI Tests stellt Xamarin Unterstützung für zwei Frameworks zur Verfügung:

  • Xamarin.UITest: Dieses Framework ermöglicht die Entwicklung von in C# geschriebenen Tests unter der Verwendung von NUnit.
  • Calabash: Bei diesem Framework werden die Tests in Ruby geschrieben unter Verwendung von Cucumber. Cucumber ist ein Open Source Tool zur Unterstützung von Behavior Driven Development (BDD).

Im Folgenden konzentrieren wir uns auf das Xamarin.UITest Framework.

Notwendige Vorbereitungsschritte in der App

Damit die UI Tests mit der zu testenden App interagieren können, müssen die jeweiligen Controls über ein StyleId Property verfügen. Zusätzlich muss dieses Property noch in ein natives Property kopiert werden. Das genaue Vorgehen für iOS und Android ist im Detail hier beschrieben.

Entwicklung von Tests mit dem Xamarin.UITest Framework

Zunächst wird eine neue Class Library mit folgenden NuGet Packages angelegt:

Innerhalb der Class Library gibt es dann eine oder mehrere Klassen mit plattformunabhängigen Tests:

   1: public class CrossPlatformTests

   2:     {

   3:         protected IApp app;

   4:         

   5:         [SetUp]

   6:         public virtual void SetUp()

   7:         {

   8:             Assert.Ignore("This class requires a platform-specific bootstrapper" 

   9:             + " to override the `SetUp` method");

  10:         }

  11:  

  12:         [Test]

  13:         public void ClickingLoginButtonShouldShowErrorMessage()

  14:         {

  15:             Func<AppQuery, AppQuery> loginButton = c => c.Button("LoginButton");

  16:             Func<AppQuery, AppQuery> messageTextField = c => c.Id("message");

  17:  

  18:             this.app.Tap(loginButton);

  19:  

  20:             this.app.WaitForElement(messageTextField);

  21:             AppResult[] results = this.app.Query(messageTextField);

  22:  

  23:             this.app.Screenshot("Popup mit Fehlermeldung");

  24:  

  25:             Assert.AreEqual("Url, Benutzername und Passwort dürfen" 

  26:             + " nicht leer sein", results[0].Text);

  27:         }

  28:     }

Zusätzlich gibt es noch jeweils pro Plattform abgeleitet eine Klasse mit einem plattformspezifischen Setup und optional plattformspezifischen Tests:

   1: [TestFixture()]

   2:     public class AndroidTest : CrossPlatformTests

   3:     {

   4:         public string PathToAPK { get; set; }

   5:  

   6:  

   7:         [TestFixtureSetUp]

   8:         public void TestFixtureSetup()

   9:         {

  10:             string currentFile = new Uri(Assembly.GetExecutingAssembly().CodeBase).LocalPath;

  11:             var fi = new FileInfo(currentFile);

  12:             string dir = fi.Directory.Parent.Parent.Parent.FullName;

  13:             this.PathToAPK = Path.Combine(dir, "KMS.Forms.Android", 

  14:             "bin", "Release", "eisTIK.mobile.apk");

  15:         }

  16:  

  17:         [SetUp]

  18:         public override void SetUp()

  19:         {

  20:             this.app = ConfigureApp.Android.ApkFile(this.PathToAPK)

  21:             .ApiKey("ENTER-YOUR-API-KEY-HERE").StartApp();

  22:         }

  23:     }

Ein detailliertes Tutorial zum Erstellen der Tests findet man hier.

Lokales Testen

Diese Tests können lokal auch ohne einen Test Cloud Account ausgeführt werden. Dabei gelten folgende Einschränkungen:

  • iOS Tests können nur gegen einen IOS Simulator ausgeführt werden.
  • Android Tests können nur gegen den Android Emulator oder den Xamarin Android Player ausgeführt werden.
  • Die Laufzeit eines Testszenarios ist auf 15 Minuten begrenzt.

Weitere Information diesbezüglich findet man hier.



Cloud Testing

Nachdem die UI Tests lokal erfolgreich durchgelaufen sind, können anschließend die Tests und die zu testende App direkt aus Visual Studio (Rechtsklick auf das Projekt mit den UI Tests und Klick auf "Run in Test Cloud…) in die Xamarin Test Cloud geladen werden. Hier werden noch die zu verwendenden Geräte ausgewählt und der Testlauf wird in der Xamarin Test Cloud vorgemerkt.xamarin test cloud - device selection

Sobald die jeweiligen Geräte in der Xamarin Test Cloud verfügbar sind, starten die Tests und abschließend ist ein konsolidierter Report verfügbar:

xamarin test cloud - report

Für jeden fehlgeschlagenen Test wird auch automatisch ein Screenshot von dem jeweiligen Gerät angelegt:

xamarin test cloud - screenshots



Kosten

Xamarin lässt sich die Test Cloud teuer bezahlen. Die kleinste Lizenz (Basic) kostet 1.000 Dollar im Monat und beinhaltet monatlich 200 Teststunden. Diese Grenze erreicht man leicht: Bei einem täglich zu durchlaufenden Testszenario von 1h auf 10 ausgewählten Kombinationen von Geräten und OS-Versionen kommt man schon auf 300 Teststunden im Monat (1h x 30 Tage x 10 Kombinationen von Gerät und OS-Version).

Fazit

Die Xamarin Test Cloud stellt eine teure, aber überzeugende Möglichkeit dar, sicherzustellen, dass sich die entwickelte iOS und Android App auf möglichst vielen Geräten wie geplant verhält. Was leider noch fehlt ist die Unterstützung für Windows und Windows Phone Geräte.

Xamarin.Forms im Praxiseinsatz: Wie viel Code Sharing ist realistisch?

Einer der Vorteile von Xamarin.Forms gegenüber Xamarin.iOS und Xamarin.Android ist die plattformübergreifende Verwendung von Views. Dadurch wird der jeweilige Mehraufwand pro zu unterstützende Plattform geringer. Dieser Artikel beschreibt, welchen Prozentsatz an Code Sharing wir in einem aktuellen Xamarin.Forms Kundenprojekt realisieren konnten und gibt zusätzlich Tipps zum Erreichen eines solchen Prozentsatzes.

 

Code-Strukturierung in einem Xamarin.Forms Projekt

Im Allgemeinen besteht eine Xamarin.Forms Solution aus jeweils einem Projekt pro zu unterstützende Plattform und einem (oder mehreren) plattformübergreifenden Projekten. Für die plattformübergreifenden Projekte gibt es zwei unterschiedliche Lösungsansätze:

  • Shared Projects
  • Portable Class Libraries (PCL)

Shared Projects liegt die Idee zu Grunde, den enthaltenen Code für die jeweilige Plattform zu kopieren und erneut zu übersetzen. Auf diese Weise wird keine neue Assembly erzeugt, sondern der Code direkt in die Assembly des referenzierenden Projekts integriert. So kann der Code dieser Assembly auf mehreren Plattformen wiederverwendet werden und zugleich über Präprozessordirektiven oder partielle Methoden und Klassen in den nativen Projekten auf plattformspezifische Anforderungen eingegangen werden, ohne zusätzliche Abstraktionsschichten für die nativen Funktionen einbauen zu müssen. Solch ein Projekt hat allerdings den Nachteil, dass aufgrund der fehlenden oder zu starken Codetrennung die Übersicht im Code und somit die Wartbarkeit schnell verloren geht.

PCLs hingegen bieten die Möglichkeit, mit gemeinsamer Funktionalität ausgewählter Zielplattformen gemeinsamen Code in einer Assembly abzubilden. Da in dem Kundenprojekt das innerhalb einer Xamarin-kompatiblen PCL verfügbare Subset des .NET Frameworks ausreichend war und die meisten benötigten nativen Features als Plugins vorhanden waren, wurde der PCL Ansatz gewählt. Um ein möglich effizientes Code Sharing mit einer nativen Windows 8 App zu erreichen, wurde der plattformübergreifende Code auf zwei Projekte aufgeteilt. Diese Trennung hat es ermöglicht, Business-Logik und ViewModels mit einem alternativen UI Framework (in diesem Fall WinRT) wiederzuverwenden.

architektur

Die einzelnen Projekte beinhalten:

  • Portable-Projekt (PCL):
    • Business-Logik
    • ViewModels
  • Forms-Projekt (PCL):
    • Views
    • Converter
    • Plattformunabhängige Custom Controls
  • Forms.iOS (nativ) und Forms.Android (nativ) Projekt:
    • Plattformspezifische Startdatei (iOS: AppDelegate.cs, Android: MainActivity.cs)
    • Plattformspezifische Custom Control Renderer
    • Plattformspezifische Services

 

Code Sharing

Der folgende Screenshot zeigt die Aufteilung der Lines of Code auf die einzelnen Projekte:

lines of code

Für die iOS App ergibt sich damit ein plattformabhängiger Anteil von 13% (Forms.iOS / (Portable + Forms + Forms.iOS)). Für die Android App ergibt sich ein plattformabhängiger Anteil von 6% (Forms.Android / (Portable + Forms + Forms.Android)). Hierbei ist aber zu beachten, dass es sich bei den 13% bzw. 6% nicht um komplett selbst geschriebenen Code handelt, sondern vor allem um die Implementierung der benötigten Device Features (in dem Kundenprojekt zum Beispiel der Dateizugriff). Hierzu gibt es mehrere passende Quellen für alle gängigen Device Features:

Der tatsächlich plattformspezifische, selbst geschriebene Code war vor allem die Implementierung von  Custom Control Renderer, um die von Xamarin.Forms vorgegebene Visualisierung von UI Controls zu modifizieren. Ein Beispiel hierfür ist ein zusätzlich unter iOS notwendiger Disclosure Indicator für Listenelemente.

Fazit

Durch den Einsatz von Xamarin.Forms und einer durchdachten Code-Struktur ist es möglich, den plattformabhängigen Code auf ein Minimum zu reduzieren und dennoch native Oberflächen zu implementieren.

Xamarin.Forms im Praxiseinsatz: Unterschiede zwischen Xamarin.Forms XAML und Microsoft XAML

Nach der Einführung in Xamarin.Forms im vorherigen Artikel stehen in diesem und den folgenden Artikeln technische Details im Vordergrund. Den Anfang macht XAML.

Xamarin.Forms bietet neben der UI-Generierung durch C# Code auch XAML-Unterstützung an. Seit der Version 1.3 mit  der Einführung zahlreicher XAML-Features (Styles, Triggers, etc.) macht die XAML-Verwendung in einem Xamarin.Forms Projekt erstmalig Sinn. Dieser Artikel zeigt die Gemeinsamkeiten und Unterschiede zwischen Xamarin.Forms XAML und Microsoft XAML auf.

Toolunterstützung

Sowohl WPF-Entwickler als auch Windows Store App-Entwickler befinden sich in der komfortablen Situation, dass ihnen mehrere Tools zum Designen der XAML-Views zur Verfügung stehen: der XAML-Designer in Visual Studio als auch Blend. Für die XAML-Entwicklung mit Xamarin.Forms gibt es (noch) keinen Designer.

Standardmäßig bietet Visual Studio auch keine IntelliSense Unterstützung für Xamarin.Forms XAML an, im Xamarin Studio steht es jedoch zur Verfügung. Für Visual Studio gibt es aber die Möglichkeit die IntelliSense Unterstützung für Xamarin.Forms XAML nachzurüsten: entweder durch Verwendung von ReSharper 9 von JetBrains oder durch die kostenlose Xamarin.Forms Intellisense Extension.

Gemeinsame Sprachfeatures

Prinzipiell orientiert sich Xamarin.Forms  XAML an den Konzepten von Microsoft XAML. Die folgende Liste zeigt eine Auswahl von gemeinsamen Features:

Unterschiedliche Bezeichnungen für Controls

Da Xamarin.Forms eine plattformübergreifende Abstraktionsebene gegenüber den nativen Controls darstellt, verwendet Xamarin.Forms eigene Begriffe dafür:

Xamarin.Forms Windows Store App
StackLayout StackPanel
Label TextBlock
Entry TextBox

Eine Übersicht über alle von Xamarin.Forms angebotenen Controls findet man hier.

Unterschiede im Layout: Padding statt Margin

Xamarin.Forms Controls bieten keine Margin Property, um einen äußeren Rand zu definieren. Stattdessen kapselt man das Control in ein ContentView-Element und setzt von diesem die Padding Property entsprechend. Dadurch “simuliert” man einen äußeren Rand um das gekapselte Control. Durch die Nutzung des zusätzlichen Controls wird allerdings die Performance negativ beeinflusst.
Abhilfe kann aber auch schon die Nutzung der Spacing Property eines Containers (z. B. StackLayout) schaffen. Es definiert den Abstand von enthaltenen Kind-Elementen untereinander. Ein Grid Control bietet hier im speziellen für die Abstände zwischen Zeilen und Spalten die Properties RowSpacing und ColumnSpacing. Mehr Details dazu sowie Codebeispiele findet man hier.

Fehlende Features

Xamarin.Forms XAML bietet zwar Unterstützung für Data Templates an, es fehlt jedoch ein DataTemplateSelector. Oren Novotny hat hierfür eine einfache Lösung implementiert, welche wir auch in dem aktuellen Xamarin.Forms Projekt eingesetzt haben.

Ähnlich verhält es sich beim Data Binding mit Listen von Elementen. Xamarin.Forms bietet zwar das ListView-Control an, in manchen Situationen ist jedoch ein generischeres Control notwendig. Hierfür bietet sich der RepaterView aus dem Xamarin Forms Labs Open Source Project an.

Fazit

Im Vergleich zu den XAML-Features von Windows Store Apps oder gar WPF befindet sich das Xamarin.Forms XAML noch in den Kinderschuhen. Wenn man aber bedenkt, dass die API noch nicht einmal ein Jahr alt ist und es schon mehrere wichtige Releases gab, kann man davon ausgehen, dass immer mehr XAML-Features umgesetzt werden. Außerdem stellt Xamarin.Forms die einzige Möglichkeit dar unter Wiederverwendung seines vorhanden C# und XAML Knowhows native Apps für die Android und iOS Plattform zu entwickeln.

Xamarin.Forms im Praxiseinsatz: Einleitung

Immer mehr Unternehmen entscheiden sich, ihre Enterprise-Anwendungen für Mitarbeiter und/oder Kunden auch auf mobilen Geräten bereitzustellen. Neben der reinen nativen Entwicklung kommen diesbezüglich auch verstärkt plattformübergreifende Technologien wie zum Beispiel Xamarin oder Cordova zum Einsatz. Dieser Artikel fokussiert sich auf die Xamarin.Forms API und die Erfahrungen, die wir mit dieser innovativen Cross-Platform-Technologie sowohl in internen Projekten als auch in einem aktuellen Kundenprojekt gesammelt haben.

Ausgangssituation

Der Kunde hat eine bereits bestehende Windows Store App und möchte diese zusätzlich für das iPad und für Android Tablets bereitstellen. Da bei der Entwicklung der Windows Store App das Model-View-ViewModel (MVVM)-Muster verwendet wurde und sowohl die Geschäftslogik als auch die ViewModels bereits in eine plattformunabhängige Portable Class Library (PCL) ausgelagert wurden, stellt Xamarin.Forms in Bezug auf die Wiederverwendbarkeit die ideale Wahl dar. Bei einem Cordova-Ansatz hingegen könnte der vorhandene C# Code nicht wiederverwendet werden.

Was ist Xamarin?

Xamarin ist eine Plattform der gleichnamigen kalifornischen Firma. Es ermöglicht unter Verwendung von C#, native Apps für Android, iOS und MacOS zu entwickeln. Grundlage hierfür ist das Open-Source-Projekt Mono. Hierbei wird für jede Plattform spezifisch die UI in C# implementiert. Zur Laufzeit (Android) bzw. während des Kompiliervorgangs (iOS) entstehen daraus native Oberflächen. Die entsprechende Solution-Struktur in Visual Studio ist folgende:

xamarin solution

  • Die Portable Class Library beinhaltet die gemeinsame Geschäftslogik.
  • Pro Plattform gibt es ein eigenes Projekt mit
    • allen Views und
    • plattformspezifischer Logik.

xamarin

Was ist Xamarin.Forms?

Xamarin.Forms ist das aktuellste Produkt von Xamarin, welches zuerst im Mai letzten Jahres von Xamarin vorgestellt wurde. Bei Xamarin.Forms handelt es sich um ein .NET-basiertes UI Toolkit, mit dem Oberflächen entweder in C# oder einem speziellen XAML-Dialekt generisch definiert werden. Aus diesem Code entstehen während des Kompiliervorgangs jeweils plattformspezifische, native Oberflächen. Xamarin.Forms unterstützt die Plattformen iOS, Android und Windows Phone, aber (noch) nicht Windows Store Apps. Für eine zusätzliche Windows Store App müsste aktuell die UI komplett losgelöst von Xamarin.Forms parallel entwickelt werden. Geschäftslogik und ViewModels können jedoch zwischen dem Xamarin.Forms-Projekt und dem Windows Store App-Projekt entweder durch PCLs oder Shared Projects geteilt werden. Die zugehörige Solution-Struktur in Visual Studio ist folgende:

xamarin.forms solution

  • Die Portable Class Library beinhaltet die gemeinsame Geschäftslogik und die gemeinsamen Views.
  • Pro Plattform gibt es eine eigenes Projekt mit
    • plattformspezifischen Views und
    • plattformspezifischer Logik.

xamarin.forms solution[5]

Wie ist Xamarin.Forms aktuell zu bewerten?

Xamarin.Forms ist eine sehr aktuelle Technologie mit einem 1. Release am 28. Mai 2014. Ein für XAML-Entwickler wichtiges Release war die Version 1.3 zum Ende des letzten Jahres, da hier grundlegende XAML-Features (Styles, Triggers, etc.) geliefert wurden, wodurch die XAML-Verwendung bei Xamarin.Forms erstmalig sinnvoll wurde. Weitere notwendige XAML-Features (DataTemplateSelector, ItemsControl, etc.) sind immer noch nicht Bestandteil von Xamarin.Forms. Diese sind aber in der Zwischenzeit schon durch die Xamarin.Forms-Community entstanden und können problemlos in eigenen Projekten eingesetzt werden. Die genauen Unterschiede zwischen Xamarin.Forms XAML und Microsoft XAML werde ich in einem gesonderten Flurfunkartikel beschreiben.

Fazit

Xamarin stellt eine für zahlreiche Projekte interessante Technologie dar, um vorhandenes C# Knowhow und Code wiederzuverwenden. Vor allem durch den XAML-Ansatz von Xamarin.Forms ist es für WPF- bzw. Windows Store App-Entwickler schnell möglich, für Android und iOS Anwendungen zu schreiben. Dennoch kommt man bei größeren Anwendungen, bei plattformspezifischen Designdetails und auch in Fehlerfällen schnell an den Punkt, wo man punktuell die durch Xamarin.Forms geschaffene Abstraktionsebene verlassen muss und dann wieder tiefgreifendes Knowhow der jeweils zugrundeliegenden Plattform notwendig ist. Dies wird vor allem bei der Entwicklung für die Android-Plattform aufgrund der Vielzahl an unterschiedlichen Geräten schnell sichtbar. Die eben genannten technischen Aspekte werde ich in nachfolgenden Artikeln im Detail beleuchten.

WorkTime Pro im Windows Store erhältlich

div class=”articleAbstract”>Endlich ist es soweit: Nach harter Arbeit ist WorkTime Pro nun im Windows Store erhältlich. Nachdem wir Ende 2012 mit WorkTime unsere erste App in den Windows Store gestellt haben, wurde diese nun letzte Woche durch WorkTime Pro abgelöst.

WorkTime Pro ermöglicht eine professionelle Zeit- und Leistungserfassung mit entweder lokaler Datenhaltung oder via Microsoft Dynamics CRM. Arbeits-, Leistungs- und Fehlzeiten können in einer einzigen Buchung auf die eigene Firma und/oder den Kundenauftrag erfasst werden. Ein Dashboard liefert dem Mitarbeiter konsolidierte Informationen über gebuchte sowie noch offene Zeiten für alle Aufträge und Positionen.

wtpro

Während es bei der Entwicklung von WorkTime vor allem darum ging, erste Erfahrungen mit dem Windows Store zu sammeln, standen bei dem Projekt WorkTime Pro deutlich mehr Aspekte im Fokus:

  • Ablösen unseres fast 10 Jahre alten, intern verwendeten Zeiterfassungssystem
  • Verwendung von Microsoft CRM als Backend, aber auch die Möglichkeit einer lokalen Datenhaltung
  • Umsetzung der Microsoft Design Guidelines für eine Modern-UI Windows Store App und Zusammenarbeit mit einem externen Designer
  • Professionelle Softwareentwicklung unter Einsatz des Team Foundation Server 2012 für den gesamten Application Lifecycle und SCRUM als Vorgehensmodell

Das Ergebnis dieses Projekts ist nun im Windows Store verfügbar: Es gibt eine Trial-Version (maximal 50 Zeiteinträge und maximal 5 Aufträge) und eine uneingeschränkte Version für 4,99 €. Die Trial-Version kann jederzeit in eine Vollversion umgewandelt werden.

Wie immer freuen wir uns über jedes Feedback.

Hier können Sie sich tiefergehend informieren:
WorkTime Pro im Windows Store
WorkTime Pro im Internet
Architektur von WorkTime Pro