Windows 8 ist da!

App oder Anwendung 10 Fragen als Entscheidungshilfe für neue Projekte in Windows 8
Kommentare

Über ein Jahr ist es nun her, dass wir auf der BUILD 2011 zum ersten Mal einen Blick auf Windows 8 werfen durften. Seitdem war die Microsoft-Welt geprägt von Vorfreude, Spannung, aber auch von Skepsis und Befürchtungen. Immerhin handelt es sich bei Windows 8 um eine echte Revolution: Kacheln anstelle von Fenstern, Touch statt Maus und Tastatur. Was hat es mit WinRT, der neuen Laufzeitumgebung für Windows Store Apps (damals noch als Metro Style Apps bezeichnet) auf sich und welches sind die Auswirkungen für .NET-Entwickler?

Mittlerweile sind wir ein wenig schlauer und wissen, dass die WinRT unser .NET Framework nicht ablösen, sondern lediglich ergänzen wird. Aus einer einheitlichen Umgebung sind zwei geworden: .NET für den Desktop, WinRT für Windows Store Apps. Entwickler müssen sich nun entscheiden, welche der beiden Varianten sie für ihr Projekt wählen: Möchten sie lieber eine klassische Desktop-Anwendung entwickeln oder eine moderne, touch-fokussierte Windows Store App?

Diese Frage steht im Zentrum der Veröffentlichung von Windows 8. Und da es nun endlich soweit ist und Microsofts neues Betriebssystem ab heute über die Ladentheke gehen wird, möchten wir Ihnen einen umfangreichen Ratgeber ans Herz legen. „App oder Anwendung?“ fragt Roman Schacherl in unserem Windows 8 Spezial. Dieses Sonderheft können Sie auf unserer Website bestellen und so mehr über die Entwicklung für Windows 8 erfahren.

Windows 8 Spezial

Der Artikel „App oder Anwendung?“ von Roman Schacherl ist erstmalig erschienen im Windows 8 Spezial

Der Schlussapplaus der BUILD-Keynote war noch nicht verklungen, da waren schon die ersten Untergangspropheten zur Stelle: „Die WinRT ist das Ende von .NET“. Eine ganze Woche wurde heiß diskutiert, wie die neuen Informationen einzuordnen sind und was die WinRT für .NET-Entwickler bedeutet. Ein Jahr später hier nun der Versuch, erste Erfahrungen und Tipps in einer Entscheidungshilfe für neue Projekte zusammenzufassen: Weiterhin auf .NET bauen? Oder möglichst rasch zur WinRT übersiedeln?

Bis vor Kurzem war die Welt der .NET-Entwickler noch übersichtlich: Es gab Desktopanwendungen und es gab Webanwendungen. Desktopanwendungen (Windows Forms oder WPF) bieten üblicherweise Vorteile in der Usability, ermöglichen den Zugriff auf das Dateisystem und externe Hardwarekomponenten, funktionieren auch offline – sind aber mitunter schwieriger zu verteilen und aktualisieren. Webanwendungen werden im Browser ausgeführt und bieten damit (im besten Fall) Plattformunabhängigkeit und keinen Installationsaufwand am Client. Dann hat sich Silverlight irgendwo dazwischen angesiedelt und für Windows-Feeling im Web gesorgt. Und Windows Phone 7 die Möglichkeit geboten, Smartphones mit .NET anzuprogrammieren. Das war uns .NET-Entwicklern soweit noch alles klar: Wir bekommen eine neue Zielumgebung (z. B. Smartphones) und können dank eines zusätzlichen SDKs mit unserem liebgewonnenen .NET dafür entwickeln. Theoretisch zumindest – in der Praxis hat dann Silverlight im Detail doch anders funktioniert als die WPF, und auch die Windows-Phone-Entwicklung hatte ihre Eigenheiten. Manche Klassen kamen dazu, viele andere weg – im Großen und Ganzen fühlte man sich aber wohl in der jeweiligen Umgebung. Ein „gemeinsames .NET“ gibt es aber schon lange nicht mehr, eher verschiedene Abwandlungen davon, im Microsoft-Sprachgebrauch „Profile“ genannt. Und dann kam WinRT zur Entwicklung von Windows-8-Apps. Windows-8-Apps? Windows-Anwendungen? Schon wieder eine neue GUI-Technologie und damit ein Nachfolger der WPF? Bei genauerem Hinsehen wurde klar, dass nicht nur an der Oberfläche gekratzt wurde, sondern auch Teile des .NET Frameworks komplett neu implementiert und nativ ins Betriebssystem integriert wurden. Also noch „schlimmer“? Ein Nachfolger von .NET?

Windows Tailored

Krzysztof Cwalina, Principal Architect .NET Framework und Koautor der Framework Design Guidelines [1], versuchte bereits im Rahmen der BUILD-Konferenz einiges klar zu stellen, und die ganze Entwicklergemeinde starrte gebannt auf das Rednerpult. Genauer gesagt die halbe Entwicklergemeinde, denn der Besucherandrang war so groß, dass viele Teilnehmer vor den Türen stehend den lange ersehnten Wortspenden lauschten – oder auf die Videoaufzeichnung warteten [2]. Und Cwalina stellte klar, dass WinRT gedanklich wie ein .NET-Profil gesehen werden sollte. So wie das Windows-Phone-Profil alles zur Verfügung stellt, was man für die Windows-Phone-Entwicklung benötigt, so stellt die WinRT alles zur Verfügung, was man für die App-Entwicklung unter Windows 8 benötigt. Explizit nicht mit dem Fokus, alles aus .NET Bekannte bereitzustellen, sondern nur die für die App-Entwicklung relevanten Teile. Der Microsoft-interne Codename für das neue Profil lautete übrigens „Windows Tailored“: „Windows maßgeschneidert“.

Und daneben, darüber oder darum herum gibt es weiterhin das .NET Framework in seiner vollen Pracht. Für Enterprise-Szenarien, für klassische Desktopanwendungen, für Server und Services – für alles, wofür .NET auch jetzt steht. Aber wo genau liegen die Unterschiede? Wo macht es Sinn, bei einem neuen Projekt auf die „maßgeschneiderte“ Variante zu setzen – und ab wann sollte man zum .NET Framework greifen?

Frage 1: Auf welchen Geräten läuft die Software?

Wenn man nur einen Vorteil von Windows 8 nennen dürfte, wäre es wohl die Flexibilität hinsichtlich der Endgeräte. Windows 8 läuft nicht nur auf Desktop-PCs, sondern endlich auch auf Tablets (nein, bei Windows-7-Tablets kann man in diesem Zusammenhang nicht von „laufen“ sprechen). Windows Phone 8 ist angekündigt und wird ebenfalls in die WinRT-Familie aufgenommen. Es wird in Zukunft keine Rolle mehr spielen, auf welchem Gerät eine Aufgabe erledigt wird: Das nächstgelegene oder für die aktuelle Anforderung sinnvollste Gerät wird einfach verwendet – die App läuft überall. Auf der Couch sitzend, blättert man am Tablet durch die Bildergalerien, wechselt zum PC um mittels Maus einige rote Augen zu korrigieren. Beim abendlichen Familienfest werden die Bilder vom Smartphone an den Fernseher übertragen und präsentiert. An den nahtlosen Wechsel zwischen verschiedensten Endgeräten werden wir uns schnell und gern gewöhnen. Klassische .NET-Programme sind für diese Art von Anwendungen nicht wirklich prädestiniert. Weder ist es technisch einfach, ein und dasselbe Programm auf mehreren Zielplattformen auszuführen, noch ist die Verteilung über einen Store möglich. Es mangelt an einfachen Möglichkeiten, benutzerdefinierte Einstellungen über Rechnergrenzen hinweg zu synchronisieren.

Fazit: Wenn die Anwendung auf vielen unterschiedlichen Windows-Geräten laufen soll, spricht vieles für die WinRT.

Frage 2: Multi-Touch oder Maus/Tastatur?

Auf den ersten Blick ist diese Frage sehr eng mit Frage 1 gekoppelt: Smartphones und Tablets werden üblicherweise mit Touch bedient, Desktop-PCs üblicherweise mit Maus und Tastatur. Noch! Durch Windows 8 wird sich auch der Monitor-Sektor in den nächsten Jahren verändern. Multi-Touch-Displays sind schon jetzt erschwinglich, in absehbarer Zeit werden wir uns an die Fingerabdrücke auch am biederen 24-Zöller gewöhnt haben. Es gibt Aktionen, die mit Touch-Gesten intuitiver auszuführen sind als mit der Maus (und vice versa!) – und als Benutzer wird man schnell vergessen wollen, ob das aktuelle Endgerät auch Touch-Eingaben erlaubt (noch dazu, wenn die Windows-8-Oberfläche überall gleich aussieht). Gerade bei den wirklich intuitiven Gesten (Verkleinern/Vergrößern, Scrollen etc.) sollte die Software der Zukunft auf Touch adäquat reagieren. Eines der Marketing-Buzzwords der WinRT lautet „Touch first“. Alle Steuerelemente wurden für Touch optimiert, solange man die Standardkomponenten verwendet, bekommt man die Touch-Bedienung geschenkt.

Touch ist aber keine Erfindung der WinRT. Schon mit .NET 4.0 haben WPF-Steuerelemente ebenfalls eine Touch-Unterstützung erhalten: Während eine aufgeklappte Combobox unter .NET 3.5 mit einer Wischgeste noch heillos überfordert ist, scrollt die gleiche Combobox unter .NET 4.0 mühelos nach unten. Und dass das Aussehen von Steuerelementen mittels WPF-Templates komplett frei gestaltet werden kann, ist hoffentlich für .NET-Entwickler kein Geheimnis mehr.

Fazit: Touch wird in Zukunft wichtiger – für alle Endgeräte. Die WinRT ist für Touch optimiert, aber auch die WPF bietet seit .NET 4.0 entsprechende Möglichkeiten und kann für Touch-Eingaben fit gemacht werden.

Frage 3: Windows 8 oder älter?

Jedes (zertifizierte) Windows-7-Programm wird auch unter Windows 8 laufen – gute Nachricht. Keine Windows-8-App wird unter Windows 7 laufen – schlechte Nachricht. Windows 7 ist das bisher erfolgreichste Betriebssystem von Microsoft und hat dennoch zwei Jahre gebraucht, bis es Windows XP den Rang an der Spitze abgerungen hat. Viele Unternehmen haben Vista ausgelassen und erst kürzlich auf Windows 7 umgestellt. Wer jetzt mit der Entwicklung einer neuen Software startet, muss sich gut überlegen, ob die potenziellen Kunden gewillt sind, frühzeitig auf Windows 8 umzusteigen. Im Consumer-Bereich wird das schneller der Fall sein als im Business-Umfeld, Unternehmen reagieren auf die neue Version ob der überschaubaren Enterprise-Vorteile noch etwas verhalten. Bis die deutlich schnellere Boot-Zeit von Windows 8 die Zeit für Umschulungen aufgrund des fehlenden Startmenüs hereingeholt hat, werden wohl einige Fingerabdrücke ihre Spuren hinterlassen.

Fazit: Wenn frühere Plattformen als Windows 8 unterstützt werden müssen, geht noch kein (Windows-)Weg an klassischem .NET vorbei.

Frage 4: Welches Anwendungsszenario?

Im Wesentlichen sprechen wir von einem Duell zwischen klassischen Desktopanwendungen (WPF) und Windows-8-Apps. Alle anderen Möglichkeiten aus dem .NET Framework sind in der „tailored“ Variante nicht enthalten: Webanwendungen (ASP.NET), Konsolenanwendungen, WCF-Services (serverseitig) etc. – die dafür notwendigen Bibliotheken sind ausschließlich im vollen .NET Framework verfügbar und können nicht in der WinRT verwendet werden.

Fazit: Die WinRT beschränkt sich auf die Entwicklung von Windows-8-Apps – alles andere bleibt zumindest vorerst ausschließlich .NET vorbehalten.

Frage 5: Wird direkter Datenbankzugriff benötigt?

Ein technisches Detail, das aber viele Lösungen im Business-Umfeld hart treffen wird: Es gibt in der WinRT keine Möglichkeit des lokalen Datenbankzugriffs (z. B. über das Entity Framework). Daten sollen entweder über Services oder per ODATA abgefragt werden, mehr ist im Moment nicht vorgesehen. Offlinefähigkeit kann nur über rein dateibasierte Datenbanken (z. B. SQLite), über eigene Persistierungsroutinen (XML etc.) oder über lokal in Windows laufende Services (mit Deployment-Schwierigkeiten) erreicht werden – so richtig komfortabel ist das alles nicht. Alleine an dieser Tatsache sieht man den Fokus der WinRT: Keine Enterprise-Anwendungen, sondern Apps, die bei etwaigem Datenzugriff auf eine ständige Internetverbindung vertrauen.

Fazit: Offlinedatenzugriff war bei der Konzeption der WinRT offenbar kein wesentliches Ziel und ist somit nur über Umwege erreichbar. Wer direkt auf die Datenbank zugreifen will, ist mit .NET besser bedient.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -