Es gibt aktuell zu viele Varianten Daten zu einer Windows 8 Store App (METRO) zu bringen. Dafür fehlt nach wie vor der direkte Zugriff auf einen SQL Datenbank.

In diesem Blog habe ich untersucht wie man einen RIA Service, bekannt aus Silverlight, mit Windows 8 verbindet. Es kommt Visual Studio 2012 zum Einsatz.

Zunächst habe ich ein Web Projekt angelegt. Bei Verwendung des MVC Templates scheint es Probleme zu geben, denen ich später auf den Grund gehe.

Im ASP.NET Web wurde die Datenbank Nortwhind.sdf in das Verzeichnis APP_DATA kopiert.

Als nächstes erzeugt man ein Datenmodell mit Entity Framework.

Man clickt sich durch die Dialoge (immer nur bestätigen)  bis man beim auswählen der Tabellen ist. Für das folgende Beispiel kommt die Customers zum Einsatz.

Im Entity Framework hat sich seit der Version 4.1 eine Änderung ergeben (Stichwort dbcontext ) die nicht kompatibel zu RIA Services ist. Deswegen muss man im Modell die Code Generation Eigenschaft ändern auf Default und die beiden .tt Dateien löschen.

Der Dialog wird nur angezeigt, wenn keine Tabelle im Model ausgewählt ist. Die .tt Dateien sieht man im Visual Studio Solution Explorer nur wenn “Show All Files” ausgewählt. Das Icon findet sich in der oberen Leiste des Visual Studio Explorer  ca in der Mitte, leicht rechts.

Weiter geht's mit der Erstellung des RIA Services. Das Template dazu ist  “Domain Service Class”.

Ganz wichtig ist den Odata Endpoint zu aktivieren, weil nur dann die Proxy Generierung im Windows 8 Projekt Erfolg haben wird.

Zum Test kann der RIA Service direkt im Webbrowser aufgerufen werden. Die URL  setzt sich zusammen aus Projektname- Domainserviceklasse .SVC. Der Pfadteil “Services” ist willkürlich, da ein HTTP Module den Request filtert.

http://localhost:19668/services/WebApplication1-domainservice1.svc/odata/

Mit Zusatz $metadata sieht man das Schema.

Nun kann man das Windows 8 Store Projekt zur Solution hinzufügen und dann per Add Service Reference den RIA Service hinzufügen.

Nun die Frage, wie programmiert man so was an. Doku habe ich keine gefunden die RIA Services und Winrt zusammen zeigt. Allerdings scheint der Proxy recht ähnlich zu funktionieren wie bei WCF Dataservices (noch ein Service Layer).

Zur Anzeige wird ein XAML Listview Control verwendet. Die Zeile mit DisplayMemberpath wird man normalerweise per XAML Deklaration erledigen.

Der erste VB.NET Code Block wird entweder bei Pageload oder auf Button Click ausgeführt. Eine Eigenart von RIA Services ist, der SET Anhang an den Tabellennamen. So ruft man auch die URL direkt auf.

Dim svc As ServiceReference1.DomainService1 = 
New ServiceReference1.DomainService1(
New Uri(http://localhost:19668/services/WebApplication1-domainservice1.svc/odata/))

Private Sub Button_Click_1(sender As Object, e As RoutedEventArgs)
listview1.DisplayMemberPath = "Company_Name"
svc.BeginExecute(Of ServiceReference1.Customers) _
(New Uri("CustomersSet", UriKind.Relative), AddressOf fertig, svc)
End SubPublic Async Sub fertig(ByVal result As IAsyncResult)
Await Dispatcher.RunAsync(CoreDispatcherPriority.Normal, Sub()
listview1.ItemsSource = svc.EndExecute(Of ServiceReference1.Customers)(result).ToListEnd Sub)
End Sub

Ich würde diese Weg wählen wenn, entweder eine RIA Service Schicht vorhanden ist, oder man auch Silverlight Clients bedienen möchte. Schließlich wird die Welt noch länger brauchen bis jeder ein Windows 8 Device hat.

Die Verwendung von Styles ist in Windows 8 kaum anders als in Silverlight und vermutlich WPF. Mit Hilfe des Style Attributes kann der XAML Code in einer Page reduziert werden. Das wesentlich schlagkräftigere Argument wird aber die Wiederverwendung einer Style Vorlage sein. So kann man zb ein UIElement einmalig Designen und dann immer wieder verwenden. In der Datei StandardStyles.xaml befinden sich Z.B. die runden Buttons die man in der AppBar oft verwendet.

Einem Textblock Steuerelement kann so per Deklaration mit dem Schlüsselword StaticResource eine Vorlage (auch Theme) zugewiesen werden.

Die Definition der Vorlage kann in der XAML Page direkt, der APP.XAML oder meist in einem Ressource Dictionary vorgenommen werden. Dort werden ein Style für ein UIElement definiert und die Eigenschaften per Setter direkt gesetzt. Wichtig ist der Zieltyp.

Ein weiterer Style kann mittels BasedOn von einem anderen Style die Setter sozusagen erben.

<ResourceDictionaryxmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"xmlns:local="using:App1"><Style x:Key="demo1" TargetType="TextBlock"><Setter Property="FontSize" Value="16"></Setter></Style><Style x:Key="demo2" TargetType="TextBlock" BasedOn="{StaticResource demo1}"><Setter Property="FontFamily" Value="Impact"></Setter></Style></ResourceDictionary>

Dann muss das Dictionary in der app.xaml der Anwendung hinzugefügt werden.

<Applicationx:Class="App1.App"xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"xmlns:local="using:App1"xmlns:localData="using:App1.Data"><Application.Resources><ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="Common/StandardStyles.xaml"/>
<ResourceDictionary Source="Dictionary1.xaml"/>
</ResourceDictionary.MergedDictionaries>

Themes gibt es übrigens in Windows 8 styled Apps (METRO) wirklich. Sie heißen dark und light und sind in per Windows 8 System in C:\Program Files (x86)\Windows Kits\8.0\Include\winrt\xaml\design\ definiert.

Die Zuweisung erfolgt im ersten Element der app.xaml per RequestedTheme="Light".

Blogs und Journalisten schreiben den Tod von Silverlight herbei. Mangels aktuellen Aussagen von Microsoft, stellt sich die berechtige Frage nach der Zukunft von Technologien. Insbesonders, wenn diese integraler Bestandteil von aktuellen Software Projekten ist. Dieser Artikel geht also der simplen Frage nach, Entscheidungsgrundlagen zu finden. [Update] Silverlight 5 ist seit 9.Dezember fertig.

Silverlight 5 ist fertig, verfügbar und auch für die IOS Plattform als Plugin erhältlich. Lediglich Besitzern von Windows 2000 (Hallo Franz) bieten die Redmonder aktuell keinen Support mehr.[/Update]

Silverlight ist Tod. Ist es das, und wie viel Rolle spielt das eigentlich? Aufgrund der Abkündigung von Flash für mobile Plattformen (http://mashable.com/2011/11/11/flash-mobile-dead-adobe/ ) wurde die Diskussion neu angeheizt. Dabei kann man aus den News rauslesen, das Adobe in Zukunft auf HTML 5 und das Tooling dazu setzen wird.

Getrieben wird das Thema von der rasanten Verbreitung von Smartphones. Die Fragmentierung des Marktes in mindestens fünf relevanten Plattformen, lässt die Wirtschaftlichkeit von Anwendungen dramatisch sinken. Neben der Geiselhaft der APP Stores, ist die Multiplattform Strategie der Grund pro HTML 5. Spezifische Funktionen der Geräte, wie die genaue Auflösung im horizontalen oder Vertikalen Betrieb, werden weder von Flash noch Silverlight adressiert.

Die Community der Entwickler sieht das aus vielerlei Gründen ganz anders. So meint Frank Puscher im Dr. Web Magazin, das das, was die HTML5-Demos bislang zeigen, einem Flasher nur ein müdes Lächeln abringen (http://www.drweb.de/magazin/denkanstos-html5-gegen-mit-oder-fur-flash/)

Die grundsätzliche Diskussion ist aktuell allgegenwärtig, egal ob Microsoft Eco System oder wie hier PHP. Als Aufhänger wird fast immer die Zukunft rund um Tablets und Smartphones genommen. In Summe führt das dazu, das aktuell für die spezifische Plattform eine APP geschrieben wird und eben nicht ein ebenso mögliches Webinterface.

Die Marktdominanz von Apple ist zwar vorhanden, aber in relativer und noch schlimmer absoluter Stückzahl bei weitem nicht so ausgeprägt wie man anhand der Medien Präsenz glauben möchte.

<

http://gs.statcounter.com/#mobile_os-DE-weekly-201132-201141-bar

Weltweit ist Nokias Symbian OS mit 32% Marktführer und Android und iOS mit etwa 20% gleichauf. Das ist deshalb von eminenter Relevanz, da in der Regel Lösungen für eine bestimmte Plattform Entwickelt werden.

Code wird aber in einer Programmiersprache geschrieben. Software Entwickler neigen dazu ihre bestehende Kenntnisse und Beispiele längst möglich zu nutzen. Zusätzlich ist eine erhebliche Codebasis für bestehende Software vorhanden, die man weder umstellen möchte noch kann. Folglich sind Programmiersprachen wie VB 6 und FoxPro , die von Microsoft definitiv abgekündigt worden sind, noch immer reichlich präsent. Auch C++ erlebt eher wieder eine Renaissance. Das uralte, proprietäre und nicht standardisierte COM ist nach wie vor Core Bestandteil von Windows.

Programmiersprachen und deren Bibliotheken leben faktisch wesentlich länger als man glauben sollte. Änderungen in der Nutzung erfolgen viel langsamer als Technologie wechselt. Im Folgenden die Top Programmiersprachen und deren Tendenzen. (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

Für die weitere Betrachtung relevant-  Java Script belegt Platz 9 mit steigender Tendenz, aber ähnlich wie SQL das nur zwei Plätze dahinter liegt. Java, C++ und C# als typische Desktop Anwendungssprachen, belegen zusammen mindestens das zehnfache, wie JavaScript als HTML und Browser Sprache.

Da man Statistiken grundsätzlich misstrauen sollte, die Verifizierung durch Gulp (http://www.gulp.de/kb/tools/gulpometer.html). Hier sehen Sie Projektausschreibungen und die Programmiersprache dazu.

Windows basierte Desktops sind beinahe in Milliarden Stückzahl vorhanden. Davon ist noch immer ein großer Teil mit Windows XP ausgerüstet. Die Parität zwischen XP und Windows 7 ist im November 2011 erreicht worden, ganze 10 Jahre nach Lebensende von Windows XP.

Auf der anderen Seite erleben Smartphones eine dramatische Verbreitung. Die Erfolgsgeschichte nehme ich als gesetzt an. Am Ende dieser Entwicklung wird es nach einhelliger Meinung mehr Smartphones als Desktop PC geben.

Tablets

Aus meiner Sicht, ganz und gar nicht gesetzt, ist der dauerhafte Erfolg des Formfaktors „Tablet“ und damit dem Branchenprimus iPad. Namhafte Printmedien, sehen allerdings in dem digitalen Reader die Möglichkeit dem Verfall ihres Mediums  Zeitung zu stoppen

„Die neue App ist da: Ab sofort erscheint die "Süddeutsche Zeitung" vollständig digitalisiert für das iPad. Tablet-Nutzer können die Zeitung von morgen bereits am Vortag von 19 Uhr an lesen und multimedial erfahren. Interaktive Grafiken erklären auf Knopfdruck komplexe Zusammenhänge, die Texte sind um Bildergalerien und Videos erweitert. Und wenn die Kanzlerin mal wieder bis spät in die Nacht hinein tagt, erfahren Sie das auch - denn die digitale SZ wird zwischen 23 und 24 Uhr aktualisiert.“

Ganz ähnlich agieren andere führende Tageszeitungen und promoten teils auf den Titelseiten die iPad Ausgabe. Der so erzeugte Werbewert ist erstens für Apple völlig kostenfrei und zweitens eigentlich unbezahlbar.

Benutzer loben gerne die Akkulaufzeit, schneller Start, die Einfachheit und das geringe Gewicht. Aus meiner persönlichen Erfahrung mit iPad und auch der Windows 8 Variante, vergesse ich sehr häufig das Tablet einzupacken. Vieles wie Mail oder schneller Zugriff auf kleine Informationen wie Bahnfahrplan, geht mit dem Telefon ganz leidlich und ähnlich einfach wie mit iPad. Für anderes ist Tastatur und Maus für mich unverzichtbar. Darüber hinaus verwende ich seit Windows XP Tablet PCs und habe mich ganz erheblich an Stift und seit einiger Zeit auch an Touch gewöhnt. Da Smartphones immer leistungsfähiger und die Notebooks immer leichter werden, könnte es eng werden in der Mitte. Der Mitte der iPads.

Für reine Reader Aufgaben ist z.B. der Kindle von Amazon wesentlich besser geeignet und günstiger.

Wenn man nun über Plattformen nachdenkt, ist man auf der einen Seite mit Windows gut beraten und für den mobilen Part mit der hohen Reichweite von Smartphones zukunftsfähig.

HTML 5

Damit stellt sich die nächste Frage. Wie werden User Interface in Zukunft entworfen? Der Wunsch tendiert in Richtung, einmal für alle und alles. Hier kommt HTML 5 ins Spiel. Als Standard sollten sich doch alle daran halten. Doch leider ist HTML 5 selbst nach Jahren noch immer kein Standard und erfährt noch immer recht weitreichenden Änderungen auch in jüngster Zeit http://www.heise.de/newsticker/meldung/HTML-5-schon-vor-Veroeffentlichung-Zeit-los-1369751.html

Standards an sich bedeuten in der Regel den kleinsten gemeinsamen Nenner aller Beteiligten. Sie sind stabil aber wenig innovativ. Darüber hinaus kann man sich nie darauf verlassen, das ein Standard von allen auch gleich verstanden, interpretiert und angewandt wird. Standards beschreiben naturgemäß keine Implementierung. Exemplarisch sei hier das VIDEO Element angeführt. Das Codec ist nicht Bestandteil des Standards. Wer sicherstellen möchte, das seine Videos auf allen HTML 5 Browsern optimal lauffähig sind, muss aktuell diese in verschiedenen Codec’s vorrätig halten.

Microsoft hat für Windows 8 eine neue Shell Namens METRO angekündigt und pusht HTML 5 u.a. auch als deklarative UI Sprache für Windows APPs. Was die Microsoft Developer davon halten, kann man aus den Foreneinträge leicht ableiten. Entwickler bevorzugen offensichtlich deutlich XAML gegenüber HTML.

http://social.msdn.microsoft.com/Forums/en-us/category/windowsapps

Wenn man Microsoft Developer nach den Gründen pro XAML frägt, erhält man Aussagen wie „deutlich klarer und einfacher“. Darüber hinaus ist HTML auf Windows 8 weit vom ohnehin noch nicht verabschiedenden Standard entfernt. Ein für Windows 8 entworfenes Programm wird also auch nur dort funktionieren. Bleibt nur die Frage, wird WinRT, ähnlich eines Silverlight Plugins, heimlich auch für IOS entwickelt?

Es könnte also HTML 5 die Lösung für den Browser sein. Dazu ist es wichtig die Verbreitung der Browser zu betrachten. Nur moderne Browser unterstützen HTML 5 halbwegs http://html5test.com/. Der Markt ist hier sehr unterschiedlich. Browser wie Firefox und Chrome haben sehr kurze Lebenszyklen. Firefox 7 auf 8 hat nur rund einen Monat gedauert. Chrome ist gar schon bei Version 15. Viele normale Benutzer sind allerdings noch bei Internet Explorer 6, dem Browser mit dem schlechtesten Ruf.

Chrome User folgen dieser Philosophie und starten häufiger eine Aktualisierung. Allerdings hat auch Google durchaus Benutzer die bei einer Version hängen bleiben.

Chrome

Internet Explorer

http://www.browser-statistik.de/statistiken/versionen/

Am Ende wird es also immer einen Anteil Benutzer geben, die eine HTML 5 Website nicht komplett nutzen können. Übrigens eine Situation die auch heute für Silverlight und sogar Flash gilt.

Plugin Konzept

Browser Plugins werden allgemein totgeschrieben. Warum Silverlight als Plugin, wenn HTML 5 nativ dies auch machen kann? Eventuell sogar schneller und mit weniger Speicherverbrauch?

Dabei wird gerne vergessen, das Plugin ein essentielles Software Entwurfsmuster ist. OOP Entwickler übertreffen sich mit der Anwendung desselben in IOC oder Dependency Injection. Auch das Managed Extensibility Framework, das auch in Visual Studio zum Einsatz kommt, ist ein elegantes Konzept Software erweiterbar und damit wartbar zu gestalten. Auf dieses Konzept zu verzichten, heißt auf neue Funktionen verzichten und den User nicht das zu bieten, was technisch möglich wäre.

Mit HTML 5 soll dies plötzlich nicht mehr gelten?

Adobe nennt jedenfalls als wesentliche Gründe für die Einstellung von Flash auf mobile, die Fragmentierung des Marktes. Bei vielen verschiedenen Plattformen, Formfaktoren und auch Funktionen kann es am Ende nur auf den kleinesten gemeinsamen Nenner hinauslaufen, der mit HTML 5 bedient werden kann. Programmiert wird dann eben mit Java Script und nur damit.

Solcherlei HTML Apps beruhen heute sehr stark auf Online Verbindungen. Steht kein Internet zur Verfügung, dann geht Google Maps aber nicht. Auch die Bahnauskunft bleibt stumm.

Das mag im Privat Bereich, also dem Konsumenten, akzeptabel sein. Für den Business Kunden kann es Umsatzverlust oder Schaden bedeuten, wenn die Anwendung nur in neun von zehn Fällen funktioniert. Spätestens nach dem ersten relevanten Vorfall werden beim Management die Alarmglocken schrillen und der Schwenk auf eine 99,999% Plattform vollzogen.

Meine eigene Erfahrung mit Windows Phone 7,5 in dieser Hinsicht war die Musikerkennung. Ein super Feature wenn im Radio ein Hit läuft. Hat beim rumspielen ganz toll funktioniert nur das eine Mal, ja das eine Mal nicht.

Einige meiner Gesprächspartner, darunter namhafte Größen der .net Szene, schwenken aktuell auf  Android. Der Logik folgend, dorthin zu gehen, wo der Markt ist. Auch hier höre ich häufig, das man mit HTML 5 ja auch wieder Windows 8 und den Browser und damit letztendlich mehrere Plattformen adressieren kann.

Dieses Argument kommt bekannt vor. Bereits zu C++ Zeiten (später Java) wurde ins Feld geführt, damit für mehrere Betriebssysteme entwickeln zu können. Das stimmt auch im Ansatz, scheitert aber bisher immer im Detail. Librarys, Performance oder Formfaktoren sind nicht universell und optimal lösbar.

XAML

Microsoft hat zu Windows Vista Zeiten den Schwenk von Pixel orientieren UI’s mit WPF zu vektororientiert vollzogen. Der Logik der unterschiedlichen Auflösungen folgend ist man aber im Wesentlichen beim immer ähnlichen Querformat geblieben. Über das deutlich schlankere Framework Silverlight hat dieses Konzept bis heute letztendlich sogar den Weg auf die iOS Plattform gefunden.

Wenn man den Gerüchten glauben darf, wurde unter Ray Ozzie eine komplett neue Internet Strategie entworfen. Weg von .NET hin zu Standards, zu Open Source und der Cloud. Nach dem nicht ganz reibungsfreien Weggang des Chef Visionärs  im Oktober 2010 tut sich hier ein Vakuum auf, das auch nicht durch einen Nachfolger gefüllt wurde. Seine Entscheidungen pro HTML 5 wirken aber nach.

Erst im Juni  2011, gab es einem neuerlichen Schwenk zurück zu XAML. Die Abteilung für Windows (WinDiv), die sich bisher konsequent der .NET Entwicklung verschlossen hat, bekommt XAML zugeschlagen.

Am 24.Juni kursiert folgendes internes Mail

We’re pleased to announce the transition of the XAML
platform team from the Developer Division to the Windows team. While the
team has been working side-by-side with the Windows team for the entire project,
this step brings them into our team formally.

http://www.riagenic.com/archives/683

Dies vermutlich auch aufgrund massiver Proteste diverser Großkunden, die um ihre XAML Investitionen fürchten.

Microsoft spricht heute nicht mehr von WPF oder Silverlight sondern von XAML. Windows 8 METRO APPS können mit Silverlight oder XAML Wissen relativ leicht entwickelt werden. Man muss aber wissen, die Runtime und auch die UI Sprache sind unterschiedlich. Auch hier kein Write Once run everywhere.

Silverlight Everywhere

Hinzu kommt das Windows Phone 7 APPs mit Silverlight (einer Version 3+) entwickelt wird. Auch bei SharePoint oder Lightswitch ist Silverlight essentiell. Die neue Shell (METRO) für die Xbox basiert seit Anfang Dezember auf einer  Silverlight Version (Projekt Lakeview). Der neue Lync Client verwendet, nicht grundlos, was? Silverlight.

Silverlight 5 ist ebenso fertig und verfügbar. Die wesentlichste Ergänzung sind 3D, XAML Debugging und implizite Templates. Eigentlich ist Silverlight damit auch fertig. Wenige Tage zuvor hat Amazon die Umstellung seines Videodienstes lovefilm auf Silverlight bekannt gegeben. Tod?

Microsoft garantiert 10 Jahre kostenfreien Support für Ihre Produkte. Man kann also damit rechnen das auch die Browser 2021 noch ein funktionierendes Silverlight Plugin bekommen.

Ganz generell ist die Erfolgsgeschichte von Silverlight ohnehin weniger im Browser als im Bereich LOB zu suchen. Viele exzellente Geschäfts Anwendungen laufen in Firmen Intranets, meist sogar ohne Browser. Dafür spricht das  kleine Framework, einfaches Rollout und die schönen Grafik. 

Wirkliche Begeisterung hört man von Embeded Entwicklern, wenn sie die Möglichkeiten von C++ und Silverlight (ein 3er Derivat) auf Windows Embeded 7 sehen. Da die Redmonder diese Technologie sehr gut bei PKW Herstellern (z.b. Fiat Blue&Me, Ford Sync, BMW) platziert haben, ist es denkbar, dass die Anzeige am Autobildschirm in kürze mit Silverlight erfolgt.

Darum zurück zur Kernfrage, was soll man heute tun?

Von Microsoft hört man dazu keine Empfehlung. Als Markführer müssen sie ihre Position verteidigen und bleiben deshalb etwas zu oft in nebulösen Aussagen hängen. Meine Erfahrung über die Jahre ist, das Microsoft sehr wohl tut, was seine Kunden wollen. Auch wenn zuerst auf die Optimierung der Gewinne agiert wird, erkennt Microsoft mal mehr oder weniger schnell wenn Kunden abspringen zu drohen. Insofern wage ich zu behaupten, das es an Ihnen liegt ob Microsoft eine Version 6 von Silverlight veröffentlicht.

Faktisch ist es aber nicht wesentlich. Relevant ist, dass man mit Silverlight heute Anwendungen schreiben kann, die der Kinderstube entwachsen sind. Auch das Tooling kann man als gut bis sehr gut bezeichnen. Wenn die Target Plattform Windows heißt, wird eine Silverlight oder auch WPF Anwendung die heute geschrieben wird, auch noch in 10 Jahren laufen.

Wenn man näher an das Betriebssystem will, Stichwort pinvoke oder ganz spezielle Performance Anforderungen hat, dann ist beim HTML Standard ohnehin ganz früh die Luft raus.

Aber tatsächlich gibt es nach wie vor keine aktuelle belastbare und offizielle Aussage zur Zukunft von Silverlight. Auch bei direkten Kontakt mit den Produktteams gibt es nicht einmal unter dem Siegel der Verschwiegenheit Antworten zur Frage nach der Zukunft von Silverlight.

Das letzte was offiziell dazu erklärt wurde, stammt von Bob Muglia Ende 2010 als Reaktion auf vorangegangene Ereignisse.

“Silverlight is very important and strategic to Microsoft. We’re working hard on the next release of Silverlight, and it will continue to be cross-browser and cross-platform, and run on Windows and Mac.Silverlight is a core application development platform for Windows, and it’s the development platform for Windows Phone.”

http://blogs.msdn.com/b/silverlight/archive/2010/11/01/pdc-and-silverlight.aspx

Bob Muglia verließ rund zwei Monate danach Microsoft.

Gefühlt würde ich sagen, Microsoft hält sich bewusst alle Optionen offen. Silverlight eine Erfolgs Geschichte. Andere Projekte aus Redmond der letzten Jahre kommen da bei weitem nicht hin.

Aber Silverlight ist auch nicht die Silberkugel. Für einige Konzepte aus METRO und WinRT gibt es keine Entsprechung  in Silverlight. Die Strom und Ressourcen Sparkonzepte von METRO sind bestechend und nicht mit Silverlight abbildbar.  Auch das Problem des umschalten zwischen Hochformat und Querformat ist konzeptionell nur mit Windows 8 METRO gelöst.

Der Ein und Umstieg für WPF und XAML Entwickler ist möglich, aber nicht so einfach wie man trotz XAML und .NET Expertise glauben würde. Man darf nicht vergessen, das man gegen und mit gänzlich anderen Librarys programmiert.

Ich freue mich über jedes Feedback und Diskussion und werde den Artikel mit diesem Input kontinuierlich updaten.

Wenn man in Silverlight ein Proxy Objekt, per Add Service Reference, von Visual Studio erstellen lässt, stellt sich die Frage nicht. Was ist aber wenn man REST Services verwendet und nicht auf eine WCF Infrastruktur zurück greifen möchte? Dann macht man eben shared code.

Ganz einfach im Silverlight Projekt ein bestehendes Element hinzufügen, hier die Klasse Kunde aus dem Silverlight Web Projekt

Ganz wichtig als Link!

Kaum wo kommen aktuell die Emotionen so hoch wie bei der Frage ob HTML 5 gut oder schlecht sei und wie das ganz zu positionieren ist. Ausgelöst wurde die Diskussion von Bob Muglia (zwischenzeitlich auf der Microsoft Drop List) der sozusagen Silverlight abgekündigt hat.

Was bisher geschah:

Microsoft wirft Silverlight als WPF light in den Markt. Nach anfänglicher Skepsis und der ungeklärten Situation zu Flash, ist Silverlight seit der Version 3 eine Erfolgs Geschichte und verdrängt WPF Clientanwendungen. Anfänglich wurden ca alle 9 Monate neue Versionen auf den Markt gebracht. Inzwischen wartet die Fan Gemeinde ein Jahr alleine auf eine Beta von SL5.

Sozusagen als parallel Handlung hat Microsoft Windows phone 7 mit einer Silverlight Version 3.5 gepuscht. Persönlich halte ich Silverlight auf WIndows phone eher für ein mini WPF, da es nicht im Browser läuft sondern sozusagen native.

Nach endlosen Silverlight is dead Diskussionen und der fehlenden Roadmap kommt nun ein neues Blog Posting dazu, das mehr Fragen aufwirft als es beantwortet.

Auffällig ist, das sämtliche Microsoft Evangelisten das Lied von HTML 5 singen und auch andere Aktivitäten in dieser Richtung zu erkennen sind. Nun stellt sich mir die Frage, warum tut Microsoft das und was gibt es dabei zu gewinnen?

Fassen wir einmal zusammen was so an Argumenten kolportiert wird:

• HTML 5 ist ein Standard
• Silverlight ist ein Plugin
• HTML 5 hat den größeren Reach (Ipad und co)
• Silverlight hat schnellere Innovationen
• Silverlight hat mehr Features
• HTML 5 ist weit davon entfernt fertig zu sein
• HTML 5 hat keine Tools
• Wer will schon Jscript
• Wir haben schon mehr als genug UI Technologien

Alles schön und gut, aber ohne Belang für den Endkunden und den Lieferanten. Fakt ist, ich habe genug Möglichkeiten UI’s zu bauen. Mir fehlt auch nichts. Schön wäre wenn es SL Plugin für ein WIndows mobile 6.5 gäbe (das wäre der Wahnsinn). Ich kenne .NET, WPF, Silverlight, Services. Ich weis wie agil das W3C Konsortium in der Vergangenheit war und wie sehr sich Standards durchgesetzt haben. Ich halte auch SOAP für einen Irrtum.

Egal wie der technische Vergleich zwischen X und Y heute ausfällt, relevant ist die Zukunft. Dazu versuche ich immer zu verstehen, was das Geschäftsmodell ist um abschätzen zu können ob ein Invest Zukunft hat. Also reduziere ich alles auf die Frage: Wer gewinnt oder was gewinnt Microsoft, wenn HTML 5 ein sensationeller Erfolg wird. Was würde das bedeuten? Ein Großteil der UIs müsste mit HTML 5 geschrieben werden um die write once- run everywhere (schon mal gehört?) Versprechen zu halten. Denkbar ist das z.B. Windows 8 eine HMTL Runtime Shell ala Browser erhält.

Entwickler schreiben einmal eine Anwendung und können die auf jeden Device laufen lassen. Wie soll das gehen? Verschiedene Hardware, Screen Resolution. Es kann nur auf einen Minimal Konsens rauslaufen. Ganz nebenbei bekommt jeder meinen Source Code…

Apple: Wenn man die Anwendung im Browser laufen lassen kann, braucht man den AppStore nicht mehr und damit auch kein Geld dort ausgeben.

Microsoft: Wer braucht noch Windows, wenn Anwendungen überall laufen? Und Browser sehen eh alle gleich aus und Firefox ist viel cooler.

Telefon Hersteller: Wo ist mein USP? Wo ist mein Longtail business?

Google/Facebook: Das Geld liegt im Online Advertising. Bereits heute sind die APP’s hier integraler Bestandteil des Business.

User: Wirklich schicke Anwendungen lassen sich mit Flash oder Silverlight viel besser bauen. Wenn mein Device das Plugin hat und ggf updated ist eh alles fein. Oder auf wie vielen Clients läuft Flash?

Nun lenkt Microsoft Ressourcen nach HTML 5. So werden wohl Tools erstellt. Es wird gemunkelt die nächste Lightswitch Version wird HTML 5 rendern. Diese Ressourcen werden woanders fehlen. Ich bin der Meinung das schon heute viel zu viel nicht mal halb fertiges in den Markt geworfen wird. Sind wir doch mal ehrlich WebMatrix oder LightSwitch sind doch nicht wirklich zu gebrauchen. Oder die Story mit ASP.NET MVC oder Windows phone. Die Qualität der Doku hat ohnehin einen historischen Tiefpunkt erreicht.

Bleibt noch die Cloud oder Windows Azure als Hoffnungsträger aus dem Lizenzbusiness ein Mietbusiness zu machen. Im Markt kann es keiner mehr hören. Monatlich neue Features. Alles in allem keine wirkliche Marktrelevanz. Stellt sich also Microsoft unter dem Mantel der “alles Standard” Story den Zugang zu ihren Azure Diensten vor?

Am Ende sind wir alle ratlos. Es gibt keine Slides mehr die eine 5 Jahres Roadmap zeigen. Und die Kunden sind verunsichert. Was ich dabei beobachte ist, das es für den Kunden im Zweifel nicht HTML 5 oder Silverlight lautet, wenn schon Schift, dann gleich zu Android oder sonstwo. Ist ja ohnehin schon egal. Und das ist glaube ich eines der Hauptargumente. Der Markt sieht seine Invests in .NET wertlos werden.

Im Grunde ist es doch wirklich total egal, welchen Browser man verwendet. Ob der eine auf meiner 8GB Ram Maschine mit 4 Kernprozessor schneller oder langsamer ist, interessiert doch nur Microsoft Bascher und gelangweilte Redakteure. Ich war mit IE immer glücklich. Trotzdem habe ich Firefox und Chrome drauf. Chrome geht gar nicht, da ich Google und Datenschutz … lassen wir das.

Ich unterrichte noch immer Silverlight Kurse. Und eines erzähle ich meine Schulungsteilnehmern immer. “the wire never lies” (© by unbekannt). Und jeder Web Guy verwendet Fiddler um HTTP Traffic zu visualisieren oder Microsoft NetMon wenn man es genau wissen will.

Was mich seit IE7 in diesem Zusammenhang nervt, ist das Proxy verhalten von IE. Kurz gesagt localhost Zugriffe gehen nicht an Fiddler. Einer der möglichen Workarounds (http://ipv4.fiddler…) wird gerne vom Layer 8 vergeigt.

Die gute Neuigkeit ist, das IE9 nun in den Developer Tools, den Netzwerk Sniffer schon drin hat. Einfach F12 drücken

Dann im Menü Netzwerk die Aufzeichnung starten.

Beim Aufruf von Websites gibt es da ganz tolle Ballen Grafiken rechts. Genauso findet sich dort Detailinfos wie Time to First Byte usw. In meinem Fall habe ich die üblichen RIA Services konsumiert. Da kann man viel falsch machen und so erfährt Der Entwickler binnen wenigen Sekunden wo er weiter Fehler suchen muss.

Im folgenden Screen Shot kann man erkennen das der Service da ist und grundsätzlich antwortet.

Im Reiter Antworttext wird dann der Inhalt des Requests dargestellt. Das Binary Encoding von RIA ist zeigt die Daten auch in Klartext. So kann man Anzahl der Datensätze und übertragene Felder erkennen.

Das ganz funktioniert aber klarerweise nur für inbrowser Silverlight Anwendungen und wenn der Browser Network Stack verwendet wird. Da dies die Standard Einstellung ist, sollte es auf anhieb klappen. In allen anderen Fällen empfehle ich Fiddler.

Noch so ein kleines Problem mit großer Wirkung und fast hätte ich IE 9 die Schuld gegeben. In einem Silverlight Projekt funktioniert das debuggen von JScript Code aus HTML oder ASPX Seiten nicht.

Man kann leider nur Silverlight oder Jscript debuggen. Die Entscheidung wird in den Projekt Einstellungen des Web Projektes vorgenommen.

In meinem folgenden WCF Data Services Beispiel wird gezeigt wie man eine Relation erzeugt. Basis ist ein EF Modell mit der Northwind Datenbank und der Order Order_details Verknüpfung.

In der Code Date des Services (svc.vb svc.cs) wird konfiguriert, welche Tabellen letztendlich mit welchen Rechten nach Außen zur Verfügung gestellt werden.

 Public Shared Sub InitializeService(ByVal config As DataServiceConfiguration)
config.SetEntitySetAccessRule("*", EntitySetRights.AllRead Or 
EntitySetRights.WriteMerge Or EntitySetRights.WriteReplace)
config.SetEntitySetAccessRule("Order_Details", EntitySetRights.AllRead Or EntitySetRights.AllWrite)
config.SetServiceOperationAccessRule("*", ServiceOperationRights.All)
config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2
End Sub

Ein Aufruf des Data Services im Browser liefert nun auch schon die möglichen Querys zurück

Per REST und GET kann nun so z.B. per

http://localhost:1892/WcfDataService1.svc/Orders

eine Liste aller Bestellungen im ATOM Format abgerufen werden. Mittels

werden dann die Detail Datensätze zu einer bestimmten Order ausgegeben. Die REST Abfragen sind Case Sensitiv!

Ich habe in der MSDN ein gutes Beispiel für User generated Content gefunden. http://msdn.microsoft.com/de-de/library/system.windows.data.binding.converter(v=vs.95).aspx

Leider ist der Hinweis auf x: Static vollkommener Unsinn. Das gibt es nur in WPF und nicht in Silverlight 4.

Nun zum eigentlichen Problem. Um eine Information über alle Usercontrols hinweg gemeinsam zu nutzen bietet sich eine statische Klasse an.

Public Class tln1Public Shared Property tln As TeilnehmerEnd Class

Die Klasse wird instanziert und gefüllt

tln1.tln = New Teilnehmer
tln1.tln.TeilnehmerName = "Hannes"

In XAML kann muss dann der Umweg über eine statische Resource genommen werden.

xmlns:local="clr-namespace:myAppli1"><UserControl.Resources><local:tln1 x:Key="sharedClass"></local:tln1></UserControl.Resources><Grid x:Name="LayoutRoot" Background="White"><TextBlock Text="{Binding tln.TeilnehmerName,Source={StaticResource sharedClass}}"/>

Dieses Posting dient mehr einem Test. Kann ich per Livewriter in Blogengine.net eine Silverlight Anwendung einbetten? Dazu habe ich die XAP zu Skydrive hochgeladen und einfach das Objekt Element in den Source Code eingefügt.

Leider klappt das nicht, auch mit Dropbox kein Erfolg.

Der Grund liegt im Content Type den die Sites verwenden. Microsoft unterbindet aus Sicherheitsgründen die Ausführung von SL Anwendungen wenn diese nicht mit dem Mime Type application/x-silverlight-app ausgeliefert werden. Per Fiddler kann man erkennen das dies in den beiden Fällen binary-octectStream ist. Eine Stellungnahme eines Microsoft Mitarbeiters dazu argumentiert in Richtung Cross Site Scripting.

Also habe ich nun auf einem Webserver eine WebDav Freigabe eingerichtet um eine XAP absolut einbinden zu können. Da es sich dabei um einen Cross Domain zugriff handelt muss im Object Element in der HTMl Seite das Attribut  EnableHTMLAccess true sein.

<div id="silverlightControlHost"><object data="data:application/x-silverlight-2," type="application/x-silverlight-2" 
width="100%" height="100%">
<param name="source" value="http://rep3yw.sn2.livefilestore.com/y1p-3lkOJ
kwNvtJpPn519--LFQuzOsqxheZwrbysnIeNy17zopoGITZHb5QgOQt_u-d
2ibTpzfhQW0F_lwvAc4yfhx0Z/SilverlightApplication1.xap" />
<param name="onError" value="onSilverlightError" />
<param name="background" value="white" />
<param name="enableHtmlAccess" value="true" />
<param name="minRuntimeVersion" value="4.0.50826.0" />

Zusätzlich muss im SilverllightProjekt in der Dataei Appmanifestxml das Attribut ExternalCallersFromCorssDomain passend sein.

<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
ExternalCallersFromCrossDomain="ScriptableOnly"

im nächsten Post werde ich beschrieben, was es nun mit der TouchME Listbox auf sich hat.