| Frohe Weihnachten! | 16.12.2011 |
Wir wünschen allen Flurfunk Lesern frohe und erholsame Weihnachten, einen guten Rutsch sowie alles Gute für das neue Jahr!
Bitte klickt auf das Bild, um die E-Card vollständig angezeigt zu bekommen!
(Lautsprecher anmachen. 
)
Der nächste Flurfunk-Beitrag erscheint am 04. Januar 2012.
| Jetzt am Kiosk: Dependency Injection Container Unity | 14.12.2011 |
Der von Microsofts patterns & practices Gruppe entwickelte Dependency Injection Container Unity erfährt immer größere Verbreitung. Doch häufig liegt sein wahres Potential brach.
Denn Unity ist nicht einfach nur ein fertiges Produkt, sondern auch von Grund auf auf Erweiterbarkeit und Flexibilität getrimmt. Doch diese Vielseitigkeit kommt zum Preis einer komplexen Architektur.
Unser Senior eXpert Sebastian Weber gibt im ersten von zwei Artikeln in der dotnetpro 01/2012 (ab 15. Dezember am Kiosk erhältlich) einen detaillierten Einblick in den Aufbau von Unity und das Zusammenspiel der dort eingesetzten Komponenten.
Mit dem Grundwissen aus diesem Artikel werden in der Fortsetzung verschiedene Erweiterungen für Unity vorgestellt, die dessen Funktionsumfang ausbauen und gleichzeitig als Inspiration für eigene Erweiterungen dienen können.
Wir wünschen viel Spaß beim Lesen und Ausprobieren…
| eXpert wird BASTA Speaker! | 13.12.2011 |
Nun ist es endlich offiziell!
Unser eXpert Daniel Tonagel wird am 01. März 2012 um 10:15 Uhr auf der BASTA! einen Vortrag zum Thema “Developer Productivity mit Visual Studio 11 und TFS 11” halten.
>Hier< gibt es weitere Infos zur Session.
Die BASTA! findet vom 27. Februar bis 02. März 2012 im Maritim Rhein-Main Hotel in Darmstadt statt. Weitere Infos unter www.basta.net
Wir drücken Daniel schon jetzt die Daumen für seinen Vortrag und wünschen ihm viel Spaß!
| Das Command Pattern in WPF und Silverlight | 12.12.2011 |
Commanding ist ein anerkanntes Pattern zur Entkopplung von Anzeige und Anzeigelogik. Bei WPF und Silverlight ist es ganz tief im System verankert und erlaubt flexible, deklarative Lösungen für häufig wiederkehrende Probleme.
Wenn man ihn einmal hat, dann will man ihn nie wieder hergeben! Gemeint ist der Commanding-Mechanismus von WPF und Silverlight. Windows Forms haben ihn nicht und man kann ihn dort auch nur mit viel Aufwand nachbauen.
Man nehme beispielsweise eine TextBox, die als Suchfeld dient. Mit dem abschließenden Druck auf die Eingabetaste soll die Suche gestartet werden. Mit WPF kann das so einfach aussehen:
1: <TextBox x:Name="searchTextBox">
2: <TextBox.InputBindings>
3: <KeyBinding Command="{Binding Search}" Key="Enter"/>
4: </TextBox.InputBindings>
5: </TextBox>
Damit bindet man das in der Property Search des ViewModels hinterlegte ICommand an den Auslöser “Eingabetaste gedrückt” des Textfeldes.
Aber hier ist noch nicht Schluss. Man kann diesen Command-Aufrufen auch zusätzliche Parameter mitgeben.
Man stelle sich eine ListBox vor, die Suchergebnisse im Stile der Infocards in der Outlook-Inbox anzeigt.
Ausgewählte Elemente aus dieser Suchliste sollen nun in die Zwischenablage kopiert werden, um sie in anderen Anwendungen zu verwenden. Es soll aber auch die Möglichkeit geben alle Suchergebnisse auf einen Schlag zu kopieren.
Also definieren wir ein entsprechendes Command das wir ganz wagemutig CopySearchResultsToClipboardCommand nennen.
1: public class CopySearchResultsToClipboardCommand : ICommand
2: {
3: public void Execute(object parameter)
4: {
5: Guard.AssertNotNull(parameter, "parameter");
6: var list = parameter as IList;
7: if (list != null)
8: {
9: var selectedSearchResults = list.OfType<SearchResult>();
10: string csv = CsvFormatter.ToCsv(selectedSearchResults);
11: Clipboard.SetText(csv, TextDataFormat.UnicodeText);
12: }
13: }
14: }
Dieses Command konvertiert die per Parameter übergebenen Datensätze in ein CSV-Format, das sowohl in einem Texteditor, als auch in Excel angezeigt werden kann.
Dieses Command wird in der Property Copy des ViewModels abgelegt.
1: public class ViewModel
2: {
3: public ICommand Copy { get; set; }
4: public MainWindowViewModel()
5: {
6: this.Copy = new CopySearchResultsToClipboardCommand();
7: }
8: }
Und jetzt kommt der interessante Teil. Wir binden das Command an die Tastenkombination CTRL+C
1: <Window.InputBindings>
2: <KeyBinding
3: Key="C"
4: Modifiers="Ctrl"
5: Command="{Binding Copy}"
6: CommandParameter="{Binding ElementName=searchResults, Path=SelectedItems}"/>
7: </Window.InputBindings>
an einen Copy-Button
1: <Button Content="Copy"
2: Command="{Binding Copy}"
3: CommandParameter="{Binding ElementName=searchResults, Path=SelectedItems}"/>
und an einen CopyAll-Button.
1: <Button
2: Content="Copy all"
3: Command="{Binding Copy}"
4: CommandParameter="{Binding ElementName=searchResults, Path=Items}"/>
Wo ist der Unterschied zwischen den Buttons? Richtig! Der CommandParameter wird einmal mit den Werten aus der Property SelectedItems der ListBox und das andere Mal mit denen aus Items gefüttert.
Damit haben wir deklarativ ein Problem gelöst, das unter WinForms etliche Zeilen Code und eine Menge Aufwand für eine saubere Trennung zwischen View und ViewModel gekostet hätte.
Und falls sich jemand fragt, warum wir nicht ApplicationCommands.Copy verwendet haben: Commands kapseln Verhalten. Aber man kann kein eigenes Command an die Stelle eines ApplicationCommands setzen. Über ein CommandBinding lassen sich nur EventHandler an diesen ApplicationCommands einhängen. Das kann man sicher auch “schön” hinbekommen, aber es erscheint unnötig kompliziert, wenn man mit einem eigenen ICommand bereits eine saubere Kapselung zur Hand hat. Der häufig bevorzugte Weg ist daher der, per Binding auf Commands zuzugreifen, die über Properties am ViewModel angeboten werden. Dafür ist WPF ja so gut bei Data/Command/Input-Binding :-)
| Windows 8: WinRT und die Auswirkungen | 09.12.2011 |
Im letzten Artikel wurde die Windows Runtime (WinRT) als moderne Ablösung der Win32-API und als Grundlage für die Entwicklung von Metro-Apps vorgestellt.
Dieser Blogbeitrag baut auf dem bestehenden Wissen zu WinRT auf, erweitert es und geht darauf ein, welche Zukunft .NET und Silverlight wohl beschert sein wird.
Die Ausführung von Metro-Apps auf Basis der WinRT findet ähnlich wie bei Silverlight-Anwendungen und bei Windows-Phone-Apps in einer Sandbox (App Execution Environment) statt, die nur eingeschränkten Zugriff auf die Systemressourcen gewährt. Jede Metro-App hat dabei einen abgeschotteten Speicherbereich, Dateisystem-Zugriffe finden nur auf diesen Speicher statt oder auf festgelegte Ordner wie z.B. “Bilder”, wenn der Nutzer dem zustimmt. Der Zugriff auf Geräte-Ressourcen wie die Ortungsfunkionen oder die Kamera und auf Funktionalität wie das Abrufen von Daten aus dem Internet muss in einem App-Manifest deklariert werden. Benutzer müssen dann bei Installation der Metro-App aus dem Windows Store (Marketplace) den Zugriff für die App freigeben, ansonsten wird die Installation abgebrochen.
Während es sich bei vielen Aufrufen in WinRT um direkte Betriebssystem-Calls handelt, schaltet sich ein Broker ein, sobald auf Ressourcen zugegriffen werden soll, die im App-Manifest deklariert sind bzw. wenn eine Benutzer-Freigabe erforderlich ist. Solche “Brokered API calls” und die Ausführungsumgebung von Metro-Apps allgemein werden in folgendem Schaubild dargestellt.
Sieht man sich noch einmal das Architektur-Diagramm der Windows-8-Plattform aus dem letzten Blogbeitrag an, so entdeckt man .NET nur als kleines Kästchen auf Seite der klassischen Desktop-Applikationen. Ist WinRT somit als Quasi-Ersatz für .NET zu sehen? Nein! Hier gilt es die Konzepte und Nutzung zu verstehen und klar zu unterscheiden.
.NET ist ein Managed Code Framework als separate Schicht, die auf dem Betriebssystem aufsetzt. In einer .NET-Sprache geschriebener Code läuft als Bytecode (CIL) in der .NET Runtime (CLR). WinRT setzt darunter an. Es ist eine native Bibliothek, die direkt in das Betriebssystem integriert ist. WinRT und .NET lassen sich somit gar nicht direkt miteinander vergleichen.
Was das Schaubild nicht zeigt: auch bei Metro-Apps verliert .NET nichts an Bedeutung. In C# geschriebene Apps werden weiterhin in der .NET Runtime ausgeführt, C#-Code kann weiterhin auf die Funktionalität des .NET Frameworks zugreifen, Entwicklern stehen damit weiterhin viele der gewohnten Klassen und Konzepte zur Verfügung. Es gibt allerdings eine große Einschränkung: nicht alle Funktionalität von .NET kann in Metro-Apps tatsächlich genutzt werden. Die Base Class Library (BCL) lässt sich in vollem Umfang nutzen, doch alle .NET-Komponenten, die das Sicherheits- und Ausführungskonzept von Metro-Apps unterwandern könnten, sind außen vor. Dazu gehören direkte Dateisystem-Zugriffe ebenso wie ADO.NET, ASP.NET, WPF etc..
Es ist also zu erkennen, dass .NET nichts an seiner Bedeutung einbüßt. Im Gegenteil wurde WinRT stark von .NET beeinflusst (Metadatensystem, Prinzipien wie Events, Generics etc., XAML in der Plattform) und Entwickler können zukünftig ihr vorhandenes .NET-Wissen verwenden, um sowohl klassische Desktop-Applikationen als auch neuartige Metro-Apps zu erstellen.
Totgeglaubte leben länger, möchte man mit einem Blick auf Silverlight sagen. Auch Silverlight wird unter Windows 8 fortbestehen, wenn auch nur für den klassischen Desktop. Dort laufen Silverlight-Anwendungen im Browser oder out-of-Browser wie bisher ohne Einschränkungen. Anders sieht es in der Metro-UI aus. Hier spielt Silverlight keine Rolle mehr, es können keine Metro-Apps mit Silverlight entwickelt werden und auch in der Metro-Version des Internet Explorers ist keine Ausführung von Silverlight-Anwendungen möglich, da der Metro-IE keine Plugins unterstützt.
Insgesamt bedeutet das, dass Silverlight bei der Programmierung von Metro-Apps als explizites Produkt keine Rolle mehr spielen wird. Die Technologie und die Konzepte von Silverlight leben in der Entwicklung von Metro-Apps allerdings weiter. Ähnlich wie bei Silverlight steht C#-Entwicklern ein abgespecktes .NET Framework zur Verfügung, die UI-Gestaltung/-Programmierung erfolgt in XAML, es ist ein hohes Maß an Asynchronität vorhanden und Applikationen laufen mit eingeschränkten Rechten in einer Sandbox. Das alles lässt einen Entwickler von C#-Metro-Apps denken, er programmiere in Silverlight und die Umgewöhnung fällt durch den hohen Wissensübertrag nicht schwer.
Silverlight wird somit sowohl als RIA-Technologie für Intranet-Anwendungen als auch als Plattform für Windows Phone weiterbestehen. Microsoft tut sich aktuell allerdings mit klaren Aussagen zur Zukunft von Silverlight schwer. Fakt ist: Silverlight 5 wird noch in 2011 veröffentlicht. Doch wie es danach weitergeht und ob ein Silverlight 6 kommen wird... dazu trifft Microsoft keine Aussagen. Laut informierten Quellen von Mary-Jo Foley soll es sich bei Silverlight 5 um das letzte große Silverlight-Release handeln. Man darf gespannt sein...
Weiterhin ist im Windows-Phone-Bereich zu erwarten, dass Microsoft das WinRT-Programmiermodell mittelfristig für Windows Phone adaptieren wird (= 1-2 Jahre, vielleicht schon in Windows Phone 8… s. auch hier). Ein Vorteil von iOS ist es, dass Anwendungen darauf sowohl für iPad als auch iPhone entwickelt werden können. Es ist nur folgerichtig, dass Microsoft die doch sehr ähnlichen Programmier- und Ausführungsmodelle von Windows und Windows Phone über kurz oder lang vereint. Windows-Phone-Apps werden dann zwar immernoch mit Silverlight entwickelt werden können (MS kann es sich hier nicht mit bestehenden App-Entwicklern verscherzen), seine Bedeutung dürfte zugunsten von WinRT aber stetig sinken.
HTML5 ist das Buzzword in der heutigen Welt der Webentwicklung. Mit seinen Fähigkeiten und den damit einhergehenden JavaScript-APIs rücken in HTML5 entwickelte Web-Anwendungen in puncto Funktionalität und Reaktionsverhalten deutlich zu klassischen Desktop-Applikationen und zu RIA-Anwendungen auf. Einen nicht unwesentlichen Beitrag dazu leisten moderne JavaScript-Bibliotheken wie jQuery, die Webanwendungen dynamischer machen und Entwicklern das Leben mit JavaScript erleichtern.
Bei JavaScript handelt es sich auch um eine von WinRT unterstützte Sprache, womit sich Metro-Apps unter Windows 8 mit HTML und JavaScript entwickeln lassen. Ausgeführt werden solche Apps wie jede andere Metro-App auch, das Rendering erfolgt dabei mit der Engine des Internet Explorer 10. Die WinRT-APIs werden über die JS-Bibliothek “WinJS” abstrahiert, die Entwicklern eine weitreichende Funktionalität für die Erstellung von Metro-Apps liefert.
In HTML/JS entwickelte Metro-Apps werden gemeinhin als “WinWebApps” bezeichnet. Es ist zu beachten, dass diese WinWebApps hochgradig von der windows-spezifischen WinJS-Bibliothek abhängen. Eine Plattformunabhängigkeit und somit eine Nutzung der WinWebApps als normale Web-Anwendungen im Browser ist damit per se erst einmal nicht gegeben. Zwar lassen sich auch “normale” Web-Anwendungen zu einer Metro-App wandeln, doch verlieren sie dann die Windows-8-typische Funktionalität in Form von WinJS.
Doch auch ohne Plattformunabhängigkeit macht das HTML/JS-Modell von Windows 8 Sinn. Microsoft holt damit die Massen an Web-Entwicklern mit ins Boot, die bisher bei der Entwicklung von Windows-Anwendungen außen vor blieben. Ebenso lassen sich in solchen WinWebApps praktisch alle bekannten JavaScript-Bibliotheken wie jQuery mit ihrer Funktionalität (Controls, Animationen, ...) weiter verwenden.
Die Ausführungsumgebung von Metro-Apps ähnelt der von Windows Phone, viele Konzepte sind von dieser Plattform und dem dortigen Programmiermodell mit Silverlight als Basis entlehnt. Silverlight lebt damit in Metro weiter, wenn auch nicht als explizit benannte Technologie. Und auch die Bedeutung von .NET sinkt mit Metro keineswegs. Die verfrühte Befürchtung einiger Entwickler, dass mit Windows 8 jetzt nur noch in HTML5/JavaScript entwickelt wird, war naiv und unbegründet. Nichtsdestotrotz steht mit HTML5/JavaScript ein Programmiermodell für Windows 8 zur Verfügung, das nicht zuletzt aufgrund der vielen verfügbaren JavaScript-Bibliotheken eine hohe Anziehungskraft ausübt.
In folgenden Beiträgen werde ich über meine Erfahrungen bei der Entwicklung der “SDX News”-Metro-App berichten, zum einen mit XAML/C#, zum anderen mit HTML5/JavaScript.
| Ja mei, des war a riesen Gaudi! Die SDX Weihnachtsfeier | 07.12.2011 |
Letzten Freitag war es endlich soweit, um 18:30 Uhr hieß es: “Griaß di!” Herzlich Willkommen auf der Ehrenhof Alm!
Nachdem sich die eXperts mit leckerem Glühwein und bayrischen Schmankerln gestärkt hatten, wurden zuerst einmal die Verhaltensregeln auf der Alm geklärt.
Während der folgenden bayrischen Disziplinen (Maßkrugstemmen, Wettsägen und Pflocknageln…) mussten die eXperts dann ihre “Almtauglichkeit” unter Beweis stellten. Das folgende Dessert hatten sie sich somit auch redlich verdient.
Hier die schönsten Bilder, des zünftigen Abends:
