Ein erster Blick auf Windows 10 01.10.2014

Matthias Jauernig
Matthias Jauernig, Principal eXpert

Lange war vor allem über den Namen der neuen Windows-Version spekuliert worden. Und so war der Name Windows 10 wohl eine der größeren Überraschungen der gestrigen Ankündigung von Microsoft, auch weil viele Features bereits vorab durchgesickert waren.

Auf einem recht privaten Presse-Event wurde ein erster Blick auf Windows 10 gewährt. Dabei konzentrierten sich die Redmonder vor allem auf die Features für Business-User, die auf der klassischen Desktop-Oberfläche sichtbar werden, der unter Windows 10 wieder mehr Beachtung erfährt. Hier ein kurzer Überblick…

8664.Windows_Product_Family_930Event741x416_7AD60659

Einige Neuerungen

  • Windowed Apps: Apps lassen sich im Fenster auf dem Desktop ausführen.
  • Startmenü: Das Startmenü ist zurück, wobei es nun noch weiter anpassbar ist und das "alte" Startmenü aus Windows 7 mit dem Startscreen von Windows 8 vereint
  • Virtuelle Desktops: Möglichkeit der Erstellung separater Desktop-Oberflächen, auf denen Anwendungen getrennt voneinander platziert werden können.
  • Snap Assist: Unterstützung von Benutzern beim "Snap" von Apps nebeneinander auf dem Desktop. Wenn eine Anwendung wie in Windows 7 gesnapped wird, werden im dadurch entstehenden “freien Raum” die anderen offenen Anwendungen angezeigt, die diesen Raum füllen können.
  • Task View: Kleiner Helfer in der Taskbar, womit eine Übersicht aller offenen Anwendungen angezeigt werden kann. Möglichkeit zum Switchen des virtuellen Desktops.
  • Command Prompt: Ja wirklich! Microsoft hat die Kommandozeile verbessert, sodass jetzt gängige Tastaturkürzel wie z.B. Strg+C und Strg+V funktionieren. Dass wir das noch erleben dürfen…
  • Continuum: Für 2-in-1 Geräte (Detachables, ...) gedacht. Wenn die Tastatur abgenommen wird, aktiviert sich ein "Tablet-Modus", in dem Apps standardmäßig im Vollbild ausgeführt werden und z.B. auch die Icons auf der Taskbar größer sind. Zudem wird statt dem Startmenü ein angepasster Startscreen angezeigt, wenn der Home-Button gedrückt wird. Wird die Tastatur wieder angedockt, aktiviert sich der "normale" Maus/Tastatur-Modus.
Windows 10 “Continuum” Modus

Fahrplan und weitere Fakten

  • Windows 10 soll im 2. Halbjahr 2015 veröffentlich werden.
  • Davor kommt noch eine Consumer Preview Anfang 2015.
  • Ab heute (01.10.) Abend soll eine erste Preview-Version zur Installation von http://preview.windows.com heruntergeladen werden können.
  • Im April 2015 findet die nächste BUILD-Entwicklerkonferenz statt, auf der auch die “Developer Story” weiter erläutert werden wird.
  • Windows 10 soll es nicht nur für PCs und Tablets geben, sondern auch für Phones (ja, Windows Phone heißt damit bald nur noch "Windows") und darüber hinaus für kleine Internet-of-Things Devices. Das heißt nicht “eine UI für alle”, sondern eine Produktfamilie mit maßgeschneiderten Funktionen für jeden Gerätetyp.
  • Universelle Programmierplattform mit weiter verbesserten universellen Apps.
  • Vereinheitlicher Store für alle Gerätetypen.
  • Weitere Infos für Business-Benutzer.

 

Wer die Ankündigung in voller Länge (knapp 40min) sehen will, kann dies hier tun:

Windows 10 Ankündigung
Share |

Visual Studio Tipp: Paste as JSON/XML 29.09.2014

Matthias Jauernig
Matthias Jauernig, Principal eXpert

Neulich habe ich eine kleine nette Funktion in Visual Studio 2013 entdeckt.

Aufgabe: Ich habe eine komplexe Datenstruktur in JSON und will diese zur weiteren Verarbeitung in eine C#-Klasse überführen.

Lösung 1 (trivial): Die Klasse händisch anlegen :-P

Lösung 2: Visual Studio 2013 benutzen und in einer C#-Datei unter "Edit -> Paste Special" das JSON automatisch in C# überführen lassen (funktioniert auch für XML!).

PasteAsJson

Fazit: Es sind doch die kleinen Dinge, die immer wieder Freude bereiten :-)

Share |

Multi-Device-Hybrid Apps mit Visual Studio 2013 und Cordova 23.09.2014

Nico Bolender
Nico Bolender, .Net Enterprise Developer

Cordova ist mittlerweile bestimmt jedem ein Begriff. Es ist in der Regel das Framework, wenn es um die plattformübergreifende Entwicklung hybrider Anwendung mit HTML, JavaScript und CSS für mobile Geräte geht.

Dadurch dass es mittlerweile sogar eine Visual Studio Erweiterung gibt, zeigt die Bedeutung von Cordova. Ich will in diesem Beitrag kurz auf diese Erweiterung eingehen und den ein oder anderen nützlichen Hinweis für die Verwendung geben.

Plugins

Folgende Plugins sind für Cordova schon direkt vorhanden und können einzeln dazu geschaltet werden. Damit können die nativen Features mit JavaScript aufgerufen werden:

Installation

Damit man unter Visual Studio 2013 mit der Cordova Entwicklung loslegen kann, muss man sich zuerst die Erweiterung herunterladen:

http://msdn.microsoft.com/en-us/vstudio/dn722381.aspx

Nach der Installation befindet sich unter den Projekt-Templates ein neuer Eintrag zum Erstellen von einer Multi-Device-Hybrid App. Wählt man dieses aus kann man eine “Blank App” erzeugen lassen.

Ausführen

Hierbei erzeugt Visual Studio uns eine vordefinierte Projektstruktur und gibt uns auch neue Ausführoptionen zum Starten der Anwendung über F5.

image

Zum Debuggen der Anwendung kann entweder ein Device herangezogen werden, ein Emulator oder Ripple.

Ripple ist eine Browsererweiterung für Chrome, mit der das Ausführen von Cordova Anwendungen ermöglicht wird. Ich persönlich bin kein Freund davon, weil eigentlich alle Cordova Plug-Ins damit nicht funktionieren.

Für einen Test wählt man nun z.B. Windwos-AnyCPU und drückt F5. Cordova Anwendungen werden normalerweise über ein Command-Line-Tool erstellt. Diese Schritte werden jetzt im Hintergrund von Visual Studio übernommen. Visual Studio erzeugt nun also im Hintergrund für die ausgewählte Plattform die entsprechende Cordova Anwendung. Diese wird im Solution Verzeichnis unter dem Verzeichnis bld/Debug/platforms angelegt.

Wer sich mit Cordova auskennt, wird die Verzeichnisstruktur kennen, die sich unter bld/Debug befindet. Diese ist nämlich die übliche Struktur, die auch erzeugt wird, wenn über das Command-Line-Tool eine Cordova Anwendung erzeugt wird.

Nachdem die Anwendung erstellt und alle Plug-Ins heruntergeladen wurden, wird die Anwendung gestartet. Im Falle von Windows-AnyCPU ist es eine Windows 8 App.

Möchte man nun sehen wie das Ganze auf einem Android-Gerät aussieht wählt man einfach in den Ausführungsoptionen den entsprechenden Eintrag aus und drückt wieder auf F5.

Auch hier wird unter bld/Debug/platforms das entsprechende Projekt für Android erstellt.

Nach diesem Prozess wird die Anwendung gestartet (Je nachdem was man ausgewählt hat auf dem Device oder im Emulator).

So leicht wie bei Windows und Android kann man die iOS Version der App leider nicht erstellen. Hierfür wird ein Mac mit XCode und Entwicklerlizenz benötigt.

Auf dem Mac muss zudem noch ein Stück Software in Form einer NodeJS-Anwendung installiert werden, mit dieser das Visual Studio dann kommuniziert um die Anwendung von dem Entwicklungsrechner auf den Mac zu bekommen. Auf dem Mac wird dann das Project für XCode generiert (Die Installation der NodeJS-Anwendung ist in der Anleitung beschrieben, die bei der Installation dabei ist).
Laut Microsoft Dokumentation, soll die Anwendung automatisch auf das am Mac Angeschlossene Gerät deployed werden. In meinen Versuchen hat das leider nicht funktioniert. Ich musste auf dem Mac das XCode-Projekt öffnen und selber auf das Gerät deployen. Ich persönlich habe damit aber kein Problem.

Debuggen

Neben dem Vorteil, dass Visual Studio für einen die Command-Line bedient und sich um das Erzeugen der Anwendung sowie das Besorgen der Plugins bemüht, ist es sehr hilfreich das man die Anwendung einfach mit einem Breakpoint im Code Debuggen kann. Dies funktioniert sogar, wenn die Anwendung auf einem Android Gerät ausgeführt wird.

Windows 8.1

Aktuell wird für die Erzeugung der Windows App noch die Version 8 als Target Plattform gewählt. Wer das gerne ändern möchte kann dies in dem Template, welches für die Erzeugung der Windows Version herangezogen wird ändern. Das ist zum Beispiel unerlässlich wenn man eine eigene Version des InAppBrowsers entwickeln möchte, die das mx-webview-Control verwendet anstelle eines IFrames. Das mx-webview-Control ist nämlich erst ab Windows 8.1 verfügbar.

Das Template befindet sich unter:

C:\Users\Username\.cordova\lib\windows8\cordova\3.5.0\windows8\template

Dort öffnet man im Editor seiner Wahl die Datei CordovaApp.jsproj und ändert die TargetPlatformVersion auf 8.1.

Plugins und Custom Plugins

Ein Grund weshalb man überhaupt auf Cordova angewiesen ist, liegt darin dass man auf die nativen Eigenschaften eines Gerätes zugreifen will wie z.B. die Kamera, die Kontakte usw. diese werden bei Cordova über Plug-Ins zur Verfügung gestellt.

Mit der Visual Studio Extension für Cordova kann man vorgefertigte Plug-Ins über ein grafisches Interface dazu schalten oder wieder abschalten.

Möchte man allerdings eigene Plug-Ins bereitstellen, kann man das aktuell noch nicht über ein grafisches Interface erledigen.

Es muss händisch das Verzeichnis “plugins” im Root der Solution erzeugt werden. Dort hinein packt man dann in Unterordner seine Plug-Ins. Beim Builden (F5) werden diese Plug-Ins dann automatisch in der Anwendung registriert.

Fazit

Mit der Cordova Erweiterung Multi-Device-Hybrid Apps für Visual Studio 2013 ist das arbeiten mit Cordova erheblich erleichtert worden. Die Erweiterung nimmt einem viel Arbeit mit der Command-Line ab und erstellt Plattformen, Plug-Ins usw. per Knopfdruck. Auch wenn es aktuell noch in der Preview Version vorliegt, macht die Erweiterung einen guten Eindruck.

Share |

Office Day im September 18.09.2014

Svenja Henß
Svenja Henß, Senior Assistant

Nach der Sommerpause war es letzten Freitag wieder soweit: Office Day im Westhafenhaus. Smiley

Gestartet haben wir mit der Vorstellung unseres neuen Münchner eXperts Andi. Herzlich Willkommen im Team! Wir freuen uns auf die gemeinsame Zusammenarbeit.

Danach ging es wie immer mit Neuigkeiten aus den Bereichen Marketing und Vertrieb weiter, bevor die Sessions technischer wurden:

- Kunden-/Projekthandbuch
- Responsive Bootstrap
- knockoutJS + jQuery
- SSIS Unittesting

IMG_7668IMG_7669IMG_7672IMG_7675IMG_7682IMG_7683IMG_7692IMG_7684IMG_7686IMG_7688IMG_7691

Share |

SQL Server Reporting Services – Mehrere Datasets in einer Tabelle nutzen 16.09.2014

Viktor Ewert
Viktor Ewert, Principal BI eXpert

Nutzt man SQL Server Reporting Services für Dashboards, hat man oft die Anforderung mehrere Datasets in einer Steuerelement mit Datenbereich (Liste, Tabelle, Matrix, Diagramm, …) anzuzeigen. In Reporting Services wird aber per Default nur ein Dataset pro Datenbereich unterstützt. Es gibt trotzdem jedoch mehrere Möglichkeiten um Daten aus unterschiedlichen Datasets in einer Tabelle zusammenzufassen

Befinden sich die Datensets in einer Datenquelle, wie z. B. SQL Server, so kann man diese mit SQL Server-Bordmitteln (Unterabfragen, Joins, Stored Procedure) in ein Dataset zusammenführen. Sind die Datenquellen über verschiedene Systeme verteilt, kann man die Daten mit einer Linked-Server-Verknüpfung dennoch miteinander verknüpfen.Doch auch Reporting Services stellen einige Mittel zur Verknüpfung der Daten zur Verfügung.

Subreports

Eine Möglichkeit ist der Einsatz von Subreports bei der Verwendung von Liste, Tabelle oder Matrix. Dafür fügt man in einer Zelle des Steuerelements einen Subreport ein. In diesem Subreport kann man wiederrum alle möglichen Inhalte darstellen z.B. Tabellen, Textboxen usw. Diesen Tabellen kann man dann wiederrum die anderen Datasets als DataSource zuweisen. Der Nachteil dabei ist, dass man sich dann um Parameterübergabe usw. beim Aufruf des Subreports kümmern muss. Um nur bestimmte Informationen aus einem zweiten Dataset dazu zu mischen, viel zu viel Aufwand.

Lookup() 

Möchte man nur einen Wert aus einem anderen Dataset als dem in der Tabelle festgelegten anzeigen, kann man die Lookup Funktion http://msdn.microsoft.com/de-de/library/ee210531.aspx verwenden um Daten aus einem anderen Dataset einzubinden.

In meinem Beispiel werden in folgender Tabelle zwei Datasets benötigt, da das erste Dataset die Stammdaten und Audit-Informationen aus der Datenbank (dsDefault) holt und das zweite Dataset auf einen Analysis Services Cube (dsData) zugreift um die Kennzahlen zu selektieren.

image

Um die beiden Datasets zu verknüpfen wird das erste Dataset ganz normal in der Tabelle als Datasource hinterlegt. Bei den Zellen, die die Kennzahlen beinhalten ist dann folgende Formel hinterlegt:

   1: =Lookup
   2: (
   3:     Fields!CityCode.Value
   4:     ,Fields!City.Value
   5:     ,Fields!Count.Value
   6:     ,"dsData"
   7: )

Hinweis: Bekommt man folgenden Fehler beim Rendern des Reports liegt es daran, dass die beiden Felder nicht den selben Datentypen haben und nicht verglichen werden können.

Warning 44 [rsRuntimeErrorInExpression] The Value expression for the textrun ‘Textbox.Paragraphs[0].TextRuns[0]’ contains an error: Exception of type  'Microsoft.ReportingServices.ReportProcessing.ReportProcessingException_ComparisonError' was thrown.

 

Hier hilft eine Konvertierung der beiden Felder in den selben Datentyp und schon funktioniert es.

   1: =Lookup
   2: (
   3:     CStr(Fields!CityCode.Value)
   4:     ,CStr(Fields!City.Value)
   5:     ,Fields!FactCount.Value
   6:     ,"dsData”
   7: ")

Andere Möglichkeiten sind:

· die Verwendung von Custom Code in einen Bericht (beispiel siehe http://sqlserverbiblog.wordpress.com/2011/09/29/using-custom-code-to-synchronize-different-datasets)

· Data Processing Extension (Beispiel siehe: http://sqlmag.com/database-development/creating-custom-data-processing-extension)

Share |

Top 10 Fehler–#13: Missbrauch von String-Operationen 11.09.2014

Alexander Jung
Alexander Jung, Chief eXpert

Dies ist Teil 14 der kleinen Serie, die ich als Kommentar zum Blog-Beitrag Top 10 Mistakes that C# Programmers Make begonnen habe.

Wir sind bei den Themen angekommen, die mir in der Liste noch fehlen. Heute ein Evergreen Zwinkerndes Smiley

 

AJ’s Common Mistake #13: Misusing string operations

Es ist Grundwissen für jeden .NET-Entwickler: Ein String kann nicht verändert werden → wenn ich mehrere Strings verknüpfe muss eine neuer String gebaut werden mache ich das exzessiv, dann entstehen unnötig temporäre Objekte, die die Speicherverwaltung unter Druck setzen also bitte StringBuilder nutzen…

Und so heißt es dann auch in Improving .NET Application Performance and Scalability:

Excessive string concatenation results in many allocation and deallocation operations, because each time you perform an operation to change the string, a new one is created and the old one is subsequently collected by the garbage collector.

Auf der andere Seite gibt es dann noch String.Format (immer an die CultureInfo denken Zwinkerndes Smiley), das sehr gerne benutzt wird, um komplexer formatierte Strings aufzubereiten.

Theoretisch alles kein Problem.

 

Und die Praxis?

Da findet man Aussagen wie folgende:

“The StringBuilder.Append() method is much better than using the + operator.” (so)

“When concatenating more than three dynamic string values, use StringBuilder.” (so)

“String type in C# being immutable therefore the preferred way of string manipulation is through StringBuilder. […] Of course for simple usage where performance isn't too much of a concern use + or concat.” (so)

“string concatenation is extremely slow, because .NET creates extra copies of your string variables between the concat operations, in this case: two extra copies plus the final copy for the assignment.” (so)

I propose String.Concat uses StringBuilder so I think that performance argument fails here” (so)

Oder solche Perlen (aus einem Review, das ich kürzlich gemacht habe, auf das Notwendige reduziert):

   1: string.Format("{0}{1}", s1, s2))
   2:  

Oder Hilfsmethoden wie diese (aus dem Gedächtnis zitiert):

   1: string StringFormat(string format, string[] args)
   2: {
   3:     StringBuilder sb = new StringBuilder();
   4:     sb.AppendFormat(format, args);
   5:     return sb.ToString();
   6: }

Und wenn man dann nach dem Sinn fragt, kommt oft genug das (falsch verstandene!) Performance-Argument (das zudem nie belegt werden kann – wie lautet das Mantra jeder Optimierung? Messen! Messen! Messen!).

 

Die Fakten…

Solange eine Verkettung von Strings in einem Ausdruck passiert gilt:

  • Konstante Literale (also “Vorne ” + ” Hinten”) werden vom Compiler zusammengefasst, Laufzeitauswirkung gleich null.
  • Wenn Variablen ins Spiel kommen ist die Verwendung von “+” die effizienteste Variante. Der Compiler macht daraus String.Concat-Aufrufe, diese Methode direkt zu verwenden macht also technisch keinen Unterschied, schadet aber i.d.R. der Lesbarkeit. Und String.Concat kommt in diversen optimierten Varianten, die sowohl bzgl. Performance, als auch bzgl. Speicherbedarf das Optimum herausholen.

Die Verwendung von StringBuilder ist absolut sinnvoll, wenn komplexe Strings aus vielen Einzelbestandteilen in mehreren Aufrufen zusammengebaut werden. Anders ausgedrückt: Für eine Hand voll Verknüpfungen ist das Overkill. Wenn der Einsatz eines StringBuilder tatsächlich Sinn macht, sollte man ihm dann aber auch unter die Arme greifen, und ihm von Anfang an eine sinnvolle Kapazität spendieren.

Der folgende Hinweis unter Performance Considerations ist übrigens überholt:

“New data is appended to the buffer if room is available; otherwise, a new, larger buffer is allocated, data from the original buffer is copied to the new buffer, and the new data is appended to the new buffer.“

Das war in frühen .NET-Versionen so, mittlerweile nutzt StringBuilder eine verkettete Liste von Buffern und vermeidet so das Kopieren und den LOH.

String.Format schlussendlich macht absolut Sinn wenn man Texte aufbereiten muss die separat im Code abgelegt oder in Ressourcen ausgelagert sind. Ebenso, wenn die Platzhalter zusätzlich mit Formatanweisungen versehen sind.

Wenn man andererseits einfach nur Textfragmente aneinander hängt ist String.Format gegenüber “+” laufzeitmäßig deutlich im Nachteil. “Deutlich” sollte man aber relativ sehen. Bei einzelnen Aufrufen würde ich der Lesbarkeit immer den Vorzug geben. Erst wenn es um häufige Aufrufe geht, also z.B. in Schleifen, würde ich mir darüber Gedanken machen.

Wo String.Format zum echten Problem werden kann, sind Aufruf zum Logging. Zum einen sind diese Aufrufe dann sehr häufig, zum anderen sehe ich oft Code der den Aufruf von String.Format macht, selbst wenn das Logging gerade abgeschaltet ist. (Das sehen andere genauso.)

 

Zusammenfassend…

In den allermeisten Fällen macht man wenig falsch, wenn man der Lesbarkeit des Codes den Vorzug gibt. Also keine Angst von “+”. Davon abgesehen liegen die typischen Anwendungsgebiete für StringBuilder und String.Format eigentlich auf der Hand.

Wer hingegen mit dem Performance-Argument kommt, der sollte zumindest wissen, wie es um die Performance tatsächlich bestellt ist. Fakten statt Halbwissen ist das eine, Zahlen das andere (z.B. hier oder hier). Die beste Zusammenfassung dazu findet sich (IMHO) übrigens – wie so oft – bei Jeff: It. Just. Doesn't. Matter!

Share |

Top 10 Fehler–#12: Naiver Einsatz von Reflection 04.09.2014

Alexander Jung
Alexander Jung, Chief eXpert

Dies ist Teil 13 der kleinen Serie, die ich als Kommentar zum Blog-Beitrag Top 10 Mistakes that C# Programmers Make begonnen habe.

Und mittlerweile bin ich bei den Themen angekommen, die mir in der Liste noch fehlen. Ich zähle also munter weiter ;-)…

 

AJ’s Common Mistake #12: Naiver Einsatz von Reflection

Ich habe vor Jahren eine frühe Version von Spring.NET als DI-Container eingesetzt (Unity gab es damals noch nicht). Objekte wurden dort per Activator.CreateObject erzeugt – die dokumentierte, offensichtliche und nicht zu Letzt die langsamste Variante der Objekterzeugung. (Disclaimer: Ich weiß nicht, wie das heute in Spring.NET gelöst ist.)

Ich habe bei einem Kunden an einem Framework mitgearbeitet, das für die Beschreibung von HOST-Daten Attribute verwendete und die jedes mal via Type.GetCustomAttributes ausgelesen hat. Auch nicht die schnellste Variante.

Ein Kollege verwendete in seinem O/R-Mapper die üblichen Methoden GetValue, etc. um Datenstrukturen generisch zu lesen und zu schreiben. Suboptimal.

Die Beispiele habe ich ausgewählt, weil sie Reflection in wiederverwendbaren Komponenten an zentraler Stelle einsetzten. Das bringt natürlich entsprechende – im Bezug auf Performance leider negative – Auswirkungen mit sich. Die Liste ließe sich problemlos fortsetzen, insbesondere wenn man noch anwendungsspezifische Einsatzszenarien hinzunimmt.

 

Reflection ist ein sehr mächtiges Werkzeug, das sehr generische – und damit besser wiederverwendbare – Lösungen ermöglicht. Damit verknüpft ist aber ein Preisschild, das leider oft übersehen wird: Performance.

Bei Performance-Analysen, die ich immer mal wieder mache, ist Reflection (wenn es denn zum Einsatz kommt) eigentlich immer ein Kandidat für Optimierungen.

Die wichtigste Empfehlung ist zunächst, dass man sich über die Kosten von Reflection bewusst sein sollte. Im Debugger oder im UnitTests sieht das Ergebnis immer gut aus. Erst ein Performancetest, der den Aufruf 10.000 mal durchführt, wird das Zeitverhalten offensichtlich werden lassen.

Natürlich sollte man an dieser Stelle immer hinterfragen, wie oft der besagte Code in der Anwendung aufgerufen wird. Sporadische Aufrufe haben sicher kaum Einfluss auf das Laufzeitverhalten der Anwendung insgesamt.

Hat man ein Performance-Bottleneck identifiziert, gibt es je nach konkretem Fall verschiedene Lösungsansätze:

  • Andere Sprachmittel können zum Einsatz kommen. Gerade älterer Code kann womöglich durch Generics ohne Reflection gelöst werden. Auch der Einsatz von dynamic kann je nach Implementierung Vorteile bringen und kommt etwa bei ASP.NET MVC zum Einsatz.
  • Code-Generierung ist ein valider Ansatz, der z.B. von ASP.NET und Entity Framework ausgiebig genutzt wird. Mit T4-Templates kein Problem, auch für andere Themen.
  • Patterns können Sonderfälle effizienter abbilden, z.B. Factory-Ansätze wie Prototyp für die Objekterzeugung.
  • Für Meta-Informationen (etwa custom attributes) bietet sich Caching der Informationen an.
  • Dynamische Code-Generierung zur Laufzeit – von .NET etwas intern für regular expressions genutzt – ist dank dynamic methods auch ohne CodeDOM einfach verwendbar.

Weiterführende Informationen:

Beachten muss man dabei allerdings auch, dass Microsoft über die verschiedenen .NET-Versionen hinweg natürlich auch immer an der Performanceschraube gedreht hat. Es gilt also grundsätzlich das Mantra jeder Optimierung: Messen! Messen! Messen!

Share |

Offlinefähigkeit in mobilen Applikationen 01.09.2014

Lukasz Momot
Lukasz Momot, .NET Expert

Die Anzahl von mobilen Applikationen wächst heutzutage immer schneller an. Diese Feststellung gilt sowohl für die sog. Store-Apps (die öffentlich den Kunden zur Verfügung gestellt werden) als auch für Enterprise Applikationen, die in dem Backend des Unternehmens intergiert werden. Viele von diesen Anwendungen funktionieren aber nur dann, wenn eine Verbindung mit dem Internet besteht.

Manchmal, selbst im Fall von kurzen Verbindungsabbrüchen, ist die weitere Arbeit mit der Anwendung unmöglich. Dies kann allerdings in manchen Geschäftsszenarien nicht akzeptabel sein. Um die Benutzererfahrung zu verbessern und dieses Problem zu lösen, bieten viele Anwendungen Offlinefähigkeit an. Wenn man sich diese mobilen Anwendungen genauer anschaut, scheint die Verwendung des Begriffs der Offlinefähigkeit inkonsistent zu sein. Es gibt keine einheitliche Implementierung von Offlinefähigkeit.

Man kann folgende Varianten von Offlinefähigkeit unterschieden:

Varianten der Offlinefähigkeit

  • Variante 0: Keine Offlinefähigkeit

Die Anwendung hört auf zu funktionieren oder stürzt einfach ab, wenn sie die Verbindung verliert.

  • Variante 1: Erkennung von Verbindungsabbrüchen

Bei dieser Variante erkennt die Anwendung lediglich Verbindungsabbrüche. Die weitere Arbeit ist nicht möglich, aber die Applikation wird weiterhin ausgeführt und stürzt nicht ab. Der Benutzer wird aber eventuell eine Fehlermeldung bekommen.

  • Variante 2: Überwindung von kurzen Verbindungsabbrüchen

Die Applikation funktioniert trotz kurzfristiger Verbindungsabbrüche. In dieser Variante gibt es aber keine lokale Persistenz von Daten und Synchronisation mit dem Server. Die Anwendung kann beispielweise die Verbindung automatisch wiederherstellen. Daten hingegen werden zumindest teilweise auch in Voraus geladen werden, damit die App auch offline funktioniert.

  • Variante 3: „Echte“ Offlinefähigkeit

Die Anwendung ist ohne Internetverbindung funktionsfähig. Der Benutzer kann nicht nur Daten einsehen, sondern diese auch hinzufügen und löschen. Diese werden lokal auf dem Endgerät zwischengespeichert. Dazu müssen sie aber auch mit dem Server synchronisiert werden. Der Benutzer kann kontinuierlich arbeiten, ohne darauf zu achten, ob er gerade online oder offline ist. Diese letzte Variante ist die Schwierigste, wenn es um die praktische Umsetzung geht.

Bei der Implementierung der Offlinefähigkeit muss man sich also zunächst die Frage stellen, um welche Art von Offlinefähigkeit es sich handeln soll.

Sollte man sich für Variante 3 entscheiden, steht man vor einigen Herausforderungen:

  • Persistenz der lokalen Daten – unterschiedliche Plattformen bieten diverse Möglichkeiten der Datenpersistenz. Die können sowohl in relationaler, wie beispielsweise bei WebSQL oder SQLLite, als auch in unstrukturierter Form (z. B. im Filesystem) vorliegen.
  • Art und Weise der Integration mit dem bestehenden Backend – das heißt wie die Endanwendung auf dem Server integriert wird.
  • Synchronisierung von Daten – die Daten von sämtlichen Endgeräten müssen mit dem Server synchronisiert werden. Sämtliche Aspekte, wie z.B. Konflikterkennung und Konfliktlösung müssen sorgfältig durchdacht werden.

Die Architektur für diese Variante wird auf dem folgenden Bild schematisch dargestellt:

flurfunkOffline1

 

Fazit

Offlinefähigkeit ist ein sehr interessantes Feature, das die Benutzererfahrung mit mobilen Anwendungen erheblich verbessern kann. Wenn der Anwender ständigen Verbindungsabbrüchen ausgesetzt ist, scheint diese Funktionalität ein unabdingbares Element der modernen Entwicklung von mobilen Apps zu sein.

Für die Art der Umsetzung muss man sich entsprechend Gedanken machen, ob die einfachste Variante reicht oder ob das Businessszenario die echte Offlinefähigkeit notwendig macht. Der Fokus muss hierbei auf der Erkennung der Bedürfnisse des Kunden liegen, um die passende Variante zu wählen.

Share |

Surface Pro 3 – Microsoft hat geliefert! 28.08.2014

Werner Franz
Werner Franz, Vorstand

Seit heute Vormittag halte ich mit dem Surface Pro 3 das professionelle Device in den Händen, das ich schon mit der ersten Surface-Ankündigung erwartet hatte:

      • Professionelles Windows 8-Arbeitsgerät, als Tablet Couch-fähig
      • Leistungsstark (Intel Core 17, 8 GB, 512 GB SSD)
      • Absolut wertiges, edles Design
      • Leicht und kaum höher als ein Schreibblock
      • Cooler Sitft, der auf Knopfdruck OneNote öffnet
      • Abnehmbare Tastatur im SDX corporate blau
      • Dazu eine Surface Arc Touch Mouse

Fazit: Perfekt. Endlich die gelungene Symbiose von Laptop und Tablet mit Coolness-Faktor.

Surface-IIISurface-III-cSurface-III-b

Ach ja: Infos zu Windows 8 App Development gibt’s hier

Share |

Top 10 Fehler–#11: Neglecting FxCop/Static Code Analysis 27.08.2014

Alexander Jung
Alexander Jung, Chief eXpert

Dies ist Teil 12 der kleinen Serie, die ich als Kommentar zum Blog-Beitrag Top 10 Mistakes that C# Programmers Make begonnen habe.

Und mittlerweile bin ich bei den Themen angekommen, die mir in der Liste noch fehlen. 11 von 10 ist also kein Fehler ;-)…

 

AJ’s Common Mistake #11: Neglecting FxCop/Static Code Analysis

Es zieht sich wie ein roter Faden durch viele von Patrick’s “Common Mistakes”, wurde aber von ihm nie explizit adressiert: FxCop bzw. die in Visual Studio eingebaute Variante Code Analysis würde helfen!

Der Compiler kann Warnungen liefern wenn es um typische Fallen auf Sprachebenen geht, leere Anweisungen weil ein Semikolon zu viel gesetzt wurde und ähnliches. Aber sobald es um die korrekte Verwendung von Methoden geht, um Code-Idiome und Patterns, um Prüfungen von Randbedingungen etc., schlägt die Stunde von Werkzeugen zur statischen Code-Analyse, speziell FxCop.

Merker: Es gibt keinen Grund, FxCop nicht einzusetzen! Aber viele Gründe das zu tun!

Man sollte das auch von Anfang an tun; FxCop einzuschalten wenn ein Projekt schon einige Zeit entwickelt wurde führt häufig zu einer Flut von Fehlermeldungen.

Worüber man durchaus zumindest kurz nachdenken sollte ist die Frage, wie FxCop eingesetzt werden soll, sprich mit welchen Regeln. Selbst Microsoft bietet von sich aus schon unterschiedliche Regel-Sets an. Und in der Voreinstellung ist Microsoft hier (leider) sehr zögerlich. Die voreingestellten Managed Recommended Rules kann man sich nach meiner Erfahrung auch sparen. Selbst klassische Fehler, wie Enums ohne 0-Wert werden damit nicht geprüft. Andererseits sind “Microsoft All Rules” dem einen oder anderen dann vielleicht doch etwas zu viel des Guten. Bleibt die Definition eines eigenen Regelsets. Genau das wird aber seit Visual Studio sehr gut unterstützt.

Und wem das noch nicht reicht, der kann das Thema auch noch weiter ausreizen:

Share |