Zum Inhalt springen

A Happy New Year 2013!

2013 – das erste Jahr mit 4 unterschiedlichen Ziffern seit…. seit 1987!

Mein letzter Blog Artikel war über das Jahr 2012. Was können wir von 2013 erwarten?

image

Mit Windows 8 wurde im letzten Jahr eine neue Ära eingeleutet. Applikationen werden einfacher, fokussiert auf eine bestimmte Rolle. Nicht nur das macht die Bedienung über Touch einfacher. Dabei wird aber die Kommunikation zwischen unterschiedlichen Apps viel wichtiger.

Das neue Microsoft Design hat nicht nur Einfluß auf Windows Store Apps, sondern auch auf Desktop Apps (übrigends können Desktop Apps auch über den Windows Store gefunden werden, und neue modern style Apps müssen nicht zwangsweise über den Windows Store installiert werden).

Zu Windows 8 erwarte ich für 2013 viele neue Apps. Nicht nur Consumer-Apps, sondern auch Business Apps. Bei der Build wurden schon Apps von SAP, Citrix, Hyland, Greenway Medical, und anderen vorgestellt. Weitere werden kommen. Mit der Entwicklung von LOB Apps wird es zu vielen neuen Ideen kommen – auch für die User produktivere Buchhaltungs-Apps.

Es wird eine zeitlang dauern (wahrscheinlich länger als 2013), aber mit der Zeit wird die neue Oberfläche die Oberhand gewinnen. In Wirklichkeit brauchen schon heute viele User nicht mehr als Windows RT. Mit weiteren Apps wird Windows RT die Zukunft.

Viele neue Windows Store Apps in 2013

Windows Blue war schon im Gespräch. Was es wirklich ist wird wohl 2013 klären. Ganz egal was Windows Blue wirklich ist, ich glaube mal an schnellere Updates. Windows Azure hat es vorgezeigt. Visual Studio ist auch schon im 3/4-Monats Update-Zyklus. Warum sollte da nicht auch Windows selbst öfters Updates liefern.

Mit Windows Phone 8 wurde das Betriebssystem vom Phone dem Desktop angeglichen. Dabei gibt es aber schon noch Unterschiede, und wichtige Features bei der Entwicklung von Windows Store Apps stehen beim Windows Phone noch nicht zur Verfügung. JavaScript Projekt-Templates fehlen noch wie auch so Kleinigkeiten wie die HttpClient Klasse (System.Net.Http). Auch hier erwarte ich Updates im neuen Jahr.

Öfters Updates für Windows, Windows Phone, Visual Studio

Da sind wir schon bei der Entwicklung. Bei Microsoft ist der Schwerpunkt bei Windows Store Apps. Da erwarte ich Updates zu Libraries, viele neue Features. Neue Features im speziellen auch für LOB Apps.

JavaScript wird dabei auch immer wichtiger. Nicht nur für die Client-Entwicklung, sondern auch am Server. Windows Azure Mobile Services könnnen auf der Server-Seite mit Hilfe von Node.js erweitert werden – z.B. zum Zugriff auf Table und Blob Storage. Und die Probleme von JavaScript werden mit TypeScript gelöst.

image

C++ wird auch wieder wichtiger. Für 2013 habe ich bereits Anfragen zu C++11 Workshops Smile

image

C++11 und TypeScript

Bei der Hardware steht das Microsoft Surface Pro in den Startlöchern.

image

Ich habe bereites ein Microsoft Surface RT. In Österreich war das gar nicht so einfach zu bekommen, Mittlerweile kann es hier auch über den Microsoft Store Deutschland bestellt werden, da wird jetzt auch nach Österreich geliefert. Für mich erfüllt die RT Version alles was ich mir von diesem Device erwarte. Für die Entwicklung mit Visual Studio brauche ich aber ein größeres Touch Gerät. Da haben die Hersteller aber mit Power-Devices und Touch allerdings ausgelassen. Jetzt sind aber neue Devices im Anrollen.

Eine Option ist das Lenovo Thinkpad X1 Carbon Touch

image

eine andere Option das HP Spectre XT TouchSmart

image

Microsoft Surface Pro oder ein Power-Device wie Lenovo Thinkpad X1 Carbon Touch oder HP Spectre XT TouchSmart?

2012 hatte ich das Buch Professional C# 2012 and .NET 4.5 fertig gestellt. Für 2013 hoffe ich dass sich das gut verkauft – und arbeite natürlich auch schon an einem neuen Werk. Aber da ist es zu früh darüber zu sprechen Winking smile

image

Professional C# 2012 and .NET 4.5

Damit wünsche ich allen ein spannendes Neues Jahr 2013,

viel Erfolg und

vor allem Gesundheit!

Christian

CN innovation

Prosit 2013!

2012 war ein Jahr mit vielen wichtigen neuen Produkt-Releases: Windows 8, Windows Server 8, Office 2013, Windows Phone 8, Visual Studio 2012, SQL Server 2012, Microsoft Surface… Was können wir 2013 erwarten? Zuerst ein Rückblick 2012.

Zuerst mal ein persönlicher Rückblick 2012

Bei mir gab es im Jahr 2012 viel Nachfrage nach WPF Workshops (wie auch schon 2011), aber auch ASP.NET MVC und HTML5 war gefragt – und auch zu Windows Store Apps gab es die ersten Workshops. Und Parallel Programming war 2012 ein heißes Thema.

Mit meinen eigenen Websites bin ich 2012 auf Windows Azure umgestiegen: u.a. laufen z.B. http://www.kantine.at und http://www.cninnovation.com seit 2012 mit Windows Azure. Gehosted wird das ganze mit Windows Azure Websites und mit SQL Azure. Blob Storage für Bilder und Database-Backups nicht zu vergessen.

image

image

Und die ersten Apps sind auch im Store:

Picture Search zur Suche von Bildern mit Slide Show über Bing Search

image

Und Kantine mit den Menüs der Woche (erst wieder ab 7. Jänner geöffnet)

image

Was uns im nächsten Jahr erwartet dann im ersten Blogeintrag im Jahr 2013.

Ich wünsche einen guten Rutsch!

Christian

CN innovation

Picture Search im Windows Store

Noch ein schnelles Weihnachtsgeschenk? Picture Search gibt es jetzt im Windows Store!

Keine 24 Stunden nach Submit der App in den Store wurde die App online gestellt!

Picture Search verwendet Bing Search um Bilder zu finden. Zum Start der App muß nur eine Bing Id eingegeben werden, und los geht’s!

Picture Search im Store

image_thumb[1]

Jeder Begriff kann für die Suche nach Bildern eingegeben werden – natürlich in der Search Charms bar.

Nach Eingabe der Bing Id kann die Suche losgehen:

picturesearch4_thumb[2]

Wechsel in die Suchergebnisse zeigt Thumbnails aller Bilder eines Suchbegriffes:

image_thumb[4]

Bilder können natürlich auch groß angezeigt werden – mit Wechsel von Bild zu Bild:

picturesearch6_thumb[2]

Über die AppBar kann auch gleich die Website des Bildes geöffnet werden:

picturesearch7_thumb[2]

Und da gibt es dann auch Informationen zu den Bildern:

picturesearch8_thumb[2]

Sharing der Bilder ist über die Charms Bar auch möglich!

Try it out and have fun!

Christian

CN innovation

Windows Store App Picture Search Teil 2 – Windows Runtime Komponenten

Picture Search ist eine Windows Store Sample App zum Suchen von Bildern über Bing Search. Im ersten Teil der Serie wurde der Server implementiert – ein Service das mit Hilfe der ASP.NET Web API das Bing Search für die Suche verwendet. Im zweiten Teil wird dieses Service aufgerufen. In diesem Artikel geht es jetzt nicht nur um den Aufruf des Services, sondern auch die Implementierung in einer Windows Runtime Komponente.

image

Libraries für Windows Store Apps

Für Libraries stehen bei Windows Store Apps die mit C# und XAML erstellt werden mehrere Optionen zur Verfügung:

  • Class Library (Windows Store Apps)
  • Windows Runtime Component
  • Portable Class Library

Die Class Library (Windows Store Apps) ist eine .NET Library wie wir sie von .NET Applikationen kennen – aber reduziert auf das .NET Subset das für Windows Store apps zur Verfügung steht.

Die Portable Class Library ist im Add New Project dialog nicht in der Kategorie der Windows Store templates zu finden. Stattdessen ist es in der Windows Kategorie. Das ist auch eine Library die nicht auf Windows Store apps reduziert ist. Diese Library steht auch für Windows desktop apps, und Silverlight apps zur Verfügung. Bei der Konfiguration dieser Library kann eingestellt werden für welche Technologie (inklusive Xbox 360) Applikationen erstellt werden. Dementsprechend wird das Subset der zur Verfügung stehenden .NET Klassen und Methoden reduziert oder erweitert.

image

Die dritte Option ist Windows Runtime Component. Im Unterschied zu Class Library und Portable Class Library steht diese Variante nicht nur für .NET Applikationen zur Verfügung. Diese Library kann auch von Windows Store apps die mit anderen Technologien erstellt werden zum Einsatz kommen, z.B. von JavaScript. Dementsprechend erfordert das aber eine andere Handhabung.

Erstellen einer Windows Runtime Component mit C# und verwenden dieser mit C++ oder JavaScript Apps bedeutet auch dass die .NET Runtime im C++ oder JavaScript Projekt geladen werden muß. Eine Alternative hier wäre es die Windows Runtime Component mit C++ zu implementieren.

Creating a Windows Runtime Component

Windows Runtime Components können mit dem Visual Studio Project Template Windows Runtime Component erstellt werden:

image

Nur sealed Types

Eine wichtige Einschränkung bei diesem Library-Typ ist dass alle public types sealed sein müssen – eine Ausnahme gibt es nur für UI Komponenten.

PictureInformation repräsentiert die Daten die vom Service übernommen werden: Title, Url, ThumbnailUrl und Source. Außer dass diese Klasse sealed ist, unterscheidet sich diese Klasse nicht von normalen .NET Klassen. Properties können von Windows Runtime Komponenten direkt angeboten werden.

public sealed class PictureInformation
{
  public string Title { get; set; }
  public string Url { get; set; }
  public string ThumbnailUrl { get; set; }
  public string Source { get; set; }
}

Converting a JSON Array to an Object List

Die zweite Klasse in diesem Assembly ist SearchManager. Diese Klasse ist wie auch PictureInformation sealed.

Die Methode GetImagesAsyncInternal macht einen Aufruf zum Web Service. Wie auch im ersten Teil der Serie wird die .NET 4.5 HttpClient Klasse für den Aufruf zum Service verwendet. GetStringAsync liefert das JSON Ergebnis vom Service.

Ein JSON String kann mit Hilfe von Klassen im Namespace Windows.Data.Json geparsed werden. Zum Verarbeiten von JSON und XML Daten – Daten die oft von Services kommen – bietet die Windows Runtime die Namespaces Windows.Data.Json, Windows.Data.Xml.Dom und Windows.Data.Xml.Xsl.

private async Task<IEnumerable<PictureInformation>> GetImagesAsyncInternal(string searchTerm)
{
  string urlRequest = url + searchTerm;
  var client = new HttpClient();
  string jsonResult = await client.GetStringAsync(urlRequest);

  var results = await Task.Run<IEnumerable<PictureInformation>>(() =>
  {
    var searchItems = new List<PictureInformation>();

    JsonArray result;
    if (JsonArray.TryParse(jsonResult, out result))
    {
        foreach (var jsonItem in result)
        {
            JsonObject jsonObj = jsonItem.GetObject();

            var searchItem = new PictureInformation
            {
                Title = jsonObj["Title"].GetString(),
                Url = jsonObj["Url"].GetString(),
                Source = jsonObj["Source"].GetString(),
                ThumbnailUrl = jsonObj["ThumbnailUrl"].GetString()
            };
            searchItems.Add(searchItem);
        }
    }
    return searchItems;
  });

  return results;
}

 

Die Methode GetImagesAsyncInternal verwendet die C#5 async und await Keywords für den Aufruf von asynchronen Methoden. Dementsprechend liefert die Methode einen Task zurück. Der Aufrufer kann beim Aufruf dieser Methode auch die Task continuation mit dem async Keyword verwenden um den Caller Thread nicht zu blockieren. Ist diese Methode aber public deklariert, gibt es einen Compiler Fehler dass der Type Task kein gültiger Windows Runtime Type ist. Bei public Methoden innerhalb von Windows Runtime Components sind nur Windows Runtime kompatible Typen erlaubt.

Der Task kann aber recht einfach – mit Hilfe der Extension Methode AsAsyncOperation – auf einen Windows Runtime kompatiblen Type umgewandelt werden. AsAsyncOperation ist eine Extension Methode für die Task Klasse und retourniert IAsyncOperation. IAsyncOperation ist das Interface der Windows Runtime (Namespace Windows.Foundation) für asynchrone Aufrufe, und kann auch mit C# 5 async und await genutzt werden.

public IAsyncOperation<IEnumerable<PictureInformation>> GetImagesAsync(string searchTerm)
{
  Task<IEnumerable<PictureInformation>> t = GetImagesAsyncInternal(searchTerm);
  return t.AsAsyncOperation();
}

Summary

Windows Runtime Components sind Libraries für Windows Store apps die sowohl mit .NET als auch mit JavaScript verwendet werden können. Dabei gibt es aber die Einschränkung auf Windows Runtime Typen in der Signatur. Mit Hilfe von kleinen Hilfsmitteln wie Extension Methoden für den Task ist das aber einfach möglich.

Christian

CN innovation

Mehr Infos zu Windows Store Apps in meinem Buch Professional C# 5 and .NET 4.5, und in meinen Windows Store App Workshops.

Artikel dieser Serie:

Teil 1: Web API – Suche mit Bing

Teil 2: Windows Runtime Components

Teil 3: Layout

Teil 4: Settings

Teil 5: Search

Teil 6: Sharing

Picture Search Teil 1: Suche mit Bing

Picture Search ist eine Windows Store Sample App. Wie der Name sagt, kann man mit dieser App Bilder suchen – mit Hilfe von Services wie Bing Search (oder zukünftig auch anderen wie Flickr). In diesem Blog wird dieser Artikel-Serie wird diese App Schritt für Schritt aufgebaut – gestartet mit der Server-seitigen Implementierung über Windows-runtime Komponenten bis User Interface mit einer Grid View Control und Search und Share Contracts.

Der erste Teil dieser Serie zeigt die Server-seitige Implementierung mit Hilfe der ASP.NET Web API, das ganze gehostet unter Windows Azure. Dieses Service wird dann im nächsten Teil von einer Windows Store App verwendet.

image

Erstellen des Services mit der ASP.NET Web API

Gestartet wird mit einer ASP.NET MVC 4 Web Application:

Bei diesem Template gibt es das Web API Project Template:

Dieses Projekt-Template erzeugt eine ValuesController Klasse im Verzeichnis Controller. In der Sample App wird diese Klasse aber nicht verwendet, stattdessen wird ein BingSearchController erstellt:

Der BingSearchController definiert die Get Methode für einen HTTP GET Request. Bei diesem GET Request wird der Suchbegriff im URL Request mitegegeben. Die Methode retourniert eine Liste von PictureInformation Objekten. In der Implementierung wird die SearchManager Klasse genutzt die selbst einen Request zum Bing Service macht.

public async Task<IEnumerable<PictureInformation>> Get(string id)
{
  SearchManager mgr = new SearchManager();
  IEnumerable<PictureInformation> result = await mgr.SearchImagesAsync(id);
  return result;
}

 

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, „Courier New“, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Das default routing und die Get Methode in der BingSearchController Klasse bestimmt die URL http://<server>/api/bingsearch/<searchTerm&gt;.

Für die Implementierung ses Controllers werden noch die Klassen SearchManager und PictureInformation benötigt.

Das Data Transfer Objekt

Die Klasse PictureInformation ist ein einfacher Datenhalter mit Title, Url, und ThumbnailUrl.

public class PictureInformation
{
  public string Title { get; set; }
  public string Url { get; set; }
  public string ThumbnailUrl { get; set; }
  public string Source { get; set; }
}

Contract für Image Requests

Das Picture Search Service kann unterschiedliche Picture Search Provider verwenden, z.B. Bing und Flickr. Im Buch Professional C# 2012 and .NET 4.5 gibt es Implementierungen von beiden dieser Services. Dieses Sample verwendet nur Bing Search.

Um unterschiedliche Implementierungen einfach zu bewerkstelligen wird das interface IImageRequest definiert. Mit diesem Interface retourniert der Search Provider einen Link zur Suchabfrage. Dieser Link beinhaltet den Suchbegriff. Sowohl Bing als auch Flickr liefern bei der Suche XML zurück. dieser XML Content kann über die Parse Methode des IImageRequest Interfaces in eine Collection von PictureInformation Objekte umgewandelt werden.

public interface IImageRequest
{
  string SearchTerm { get; set; }
  string Url { get; }

  IEnumerable<PictureInformation> Parse(string xml);

  ICredentials Credentials { get; }
}

 

Bing Search Request

Die Klasse BingRequest implementiert das Interface IImageRequest – für eine Suche mittels Bing. Um diese Klasse verwendet werden zu können ist es notwendig den Application Identifier einzutragen. Dieser Identifier ist mit einer Registrierung bei der Bing Search API im Windows Azure Marketplace verfügbar: https://datamarket.azure.com/dataset/bing/search. Bis zu 5000 Transaktionen sind im Monat kostenlos.

Die wichtigsten Teile dieser Klasse sind die Url Property und die Parse Methode. Die Url Property liefert den Link zum Bing Service inklusive des Suchbegriffs. Die Parse Methode konvertiert XML in eine Objektliste – mit Hilfe von LINQ to XML.

public class BingRequest : IImageRequest
{
    private const string AppId = "Enter your Bing App-id here!";

    public BingRequest()
    {
        Count = 50;
        Offset = 0;
    }

    private string searchTerm;
    public string SearchTerm
    {
        get { return searchTerm; }
        set { searchTerm = value; }
    }

    public string Url
    {
        get
        {
            return string.Format("https://api.datamarket.azure.com/Data.ashx/Bing/Search/v1/Image?Query=%27{0}%27&$top={1}&$skip={2}&$format=Atom", SearchTerm, Count, Offset);
        }
    }

    public int Count { get; set; }
    public int Offset { get; set; }

    public IEnumerable<PictureInformation> Parse(string xml)
    {
        XElement respXml = XElement.Parse(xml);
        XNamespace d = XNamespace.Get("http://schemas.microsoft.com/ado/2007/08/dataservices&quot;);
        XNamespace m = XNamespace.Get("http://schemas.microsoft.com/ado/2007/08/dataservices/metadata&quot;);

        return (from item in respXml.Descendants(m + "properties")
                select new PictureInformation
                {
                    Title = new String(item.Element(d + "Title").Value.Cast<char>().Take(50).ToArray()),
                    Url = item.Element(d + "MediaUrl").Value,
                    ThumbnailUrl = item.Element(d + "Thumbnail").Element(d + "MediaUrl").Value,
                    Source = "Bing"
                }).ToList();
    }

    public ICredentials Credentials
    {
        get
        {
            return new NetworkCredential(AppId, AppId);
        }
    }
}

Aufruf von Bing Search

Vom Web API Controller wird die SearchManager Klasse verwendet. In der SearchImagesAsync Methode erfolgt ein asynchroner GET Request zum Bing Service. Für den Request wird die Klasse HttpClient verwendet, eine neue Klasse mit .NET 4.5. Diese Klasse bietet nur asynchrone Methoden um den aufrufenden Thread nicht zu blockieren.

public class SearchManager
{
  public async Task<IEnumerable<PictureInformation>> SearchImagesAsync(string searchTerm)
  {
    var request = new BingRequest();
    request.SearchTerm = searchTerm;
    
    var client = new HttpClient(
      new HttpClientHandler
      {
        Credentials = request.Credentials
      });
      
    HttpResponseMessage response = await client.GetAsync(request.Url);
    string resp = await response.Content.ReadAsStringAsync();
    IEnumerable<PictureInformation> images = null;
    await Task.Run(() =>
    {
      images = request.Parse(resp);
    });

    return images;
  }
}

Statt der Methode GetAsync und folgend ReadAsStringAsync kann auch die einfachere Methode GetStringAsync verwendet werden.

Aufruf vom Search Service

Mit der Implementierung vom ASP.NET Web API Service kann die Bildersuche bereits gestartet werden. Simple HTTP GET Requests können einfach mit Hilfe eines Web Browsers gemacht werden. Der Request /api/bingsearch/Ferrari">http://<server>/api/bingsearch/Ferrari liefert beim IE JSDON Daten, z.B. diese Collection die durch die PictureInformation Klasse definiert wurde:

[{"Title":"Voici une belle photo de Ferrari de qualité",
"Url":"http://images-et-photos.com/files/ferrari1.jpg",
"ThumbnailUrl":"http://ts1.mm.bing.net/th?id=H.4902048858114356&pid=15.1",
"Source":"Bing"},
{"Title":"Name: ferrari pictures.jpgViews: 110204Size:337.4",
"Url":"http://www.whitegadget.com/attachments/pc-wallpapers/75212d1315377041-ferrari-ferrari-pictures.jpg",
"ThumbnailUrl":"http://ts2.mm.bing.net/th?id=I.4894034425284685&pid=15.1&W=160&H=120",
"Source":"Bing"},
{"Title":"Ferrari Enzo Ferrari Photos:",
"Url":"http://world-viewer.com/data_images/ferrari-enzo-ferrari/ferrari-enzo-ferrari-04.jpg",
"ThumbnailUrl":"http://ts3.mm.bing.net/th?id=I.4935837306587618&pid=15.1&W=160&H=120",
"Source":"Bing"},

Im nächsten Artikel dieser Serie erstelle ich eine Windows Runtime Komponente die dieses Web Service aufruft.

Christian

CN innovation

Weitere Informationen für die Web API und Windows Store Apps in meinen Workshops und meinem Buch Professional C# 2012 and .NET 4.5.

Microsoft shuts down Silverlight.net–was ändert sich wirklich?

Die Website http//www.silverlight.net wird jetzt auf einen MSDN Link umdirigiert. John Callaham hat darüber geschrieben. Doch was bedeutet es wirklich für die Silverlight-Entwicklung wenn keine neuen Versionen von Microsoft mehr kommen? Meiner Meinung nach ist der Nachfolger von Silverlight bereits da. Dazu muß man aber etwas in die Geschichte on Silverlight zurück blättern. In diesem Artikel gibt es meine Gedanken dazu.

silverbeach

WPF war zuerst da

Die Entwicklung mit Vektor-basierten Graphiken (statt Pixel-basierten) hat mit WPF gestartet. Windows Presentation Foundation (WPF) war ein Schwerpunkten der Neuerungen von .NET 3.0 (neben Windows Communication Foundation (WCF) und Windows Workflow Foundation (WF)).

Controls bei denen das UI von der Funktionalität getrennt waren und mit Templates alles beliebig umdesigned werden konnte, Data Binding das wirklich in verschiedensten Szenarien funktionierte (im Gegensatz zum Data Binding bei Windows Forms) – der Gestaltung vom UI waren keine Grenzen mehr gesetzt.

Das war so im Jahr 2006. Visual Studio gab´s damals noch kein neues, sondern nur erweiterte Tools zum Visual Studio 2005. Mit .NET 3.5 hab es dann auch das richtige Toolset mit Visual Studio 2008.

Codename WPF/E

Dann kam Silverlight mit dem ursprünglichen Codenamen WPF/E für WPF/Everywhere. Everywhere war auch die Zielsetzung von Silverlight. Nicht nur das Moonlight welches Silverlight auf Linux und andere Unix/X11 Derivate brachte, ich erinnere mich auch an ein Silverlight unter Symbian. Eben everywhere.

Die erste Version konnte auch noch nicht viel – nicht einmal Button controls gab es, und auch kein .NET. XAML war hier – mit Shapes – und das ganze programmiert mit JavaScript. Animationen waren klarerweise schon hier, es konnte als Konkurrenzprodukt zu Flash betrachtet werden. Videos waren bei Silverlight aber damals schon besser. Und DRM auch ein wichtiges Thema. Das war 2007.

In Version 2 gab es dann .NET und Button Controls. Mit der Entwicklung von Silverlight ging es rasant weiter. Für neue Versionen brauchten nicht lange warten. Silverlight 3 bereits im Jahr 2009 mit DataGrid, TreeView, data forms und paginations…

HTML5 – Everywhere

Beim Start von Silverlight war der Erfolg von HTML5 noch nicht absehbar. Seit 1997 gab es die HTML4 recommendation, und dann die Teilung zwischen W3C und der WHATWG mit strictem Markup oder alles doch wieder ganz offen. Nachdem es bis 1999 (HTML 4.01) mit der HTML Entwicklung rasant gegangen ist hat es dann bis 2008 zu einem sinnvollen Working Draft von HTML5 gedauert. Da waren aber dann wieder auch alle dabei – auch Microsoft.

Statt Silverlight Everywhere hat sich HTML Everywhere etabliert.

Silverlight for Windows

Damit hat Silverlight dann wieder einen anderen Weg eingeschlagen. Erweiterungen für Windows. Mit Silverlight 4 (2010) kam COM Interop. Es ist jetzt möglich Office von Silverlight zu steuern. Silverlight 5 (2011) hat dann praktisch die ganze Windows API für Silverlight mit Platform/Invoke geöffnet. Damit ist die Zielsetzung von Everywhere aber natürliche nicht mehr gegeben.

WPF/RT

Silverlight hatte den Codenamen WPF/E. Ein Derivat von WPF mit XAML Syntax. Der Nachfolger von verwendet weiterhin XAML. Diesmal sind die XAML Controls nicht von JavaScript anprogrammierbar (wie bei Silverlight 1), und die Controls sind nicht mit .NET implementiert – stattdessen sind sie native. Native für Windows. Windows Store Apps können mit XAML und C# programmiert werden. Das ganze unter Windows und Windows RT. Deshalb meine Anspielung an WPF/RT.

XAML – XAML – XAML

Ob es jetzt WPF, Silverlight, oder Metro (sorry, Windows Store Apps) heißt – wir können auf dem gleichen Wissen aufbauen und XAML und C# für die Entwicklung einsetzen.

Natürlich ist es heute noch nicht möglich alle Applikationen auf Windows Store Apps umzustellen, Windows 8 ist noch nicht überall verfügbar. WPF ist ein mächtiges Werkzeug für Desktop Applikationen – auch mit viel Neuigkeiten bei WPF 4.5. Silverlight wird noch auf viele Jahre weiterhin unterstützt. Und mit Windows Store Apps kann ein Subset der Funktionalität einer Rich Desktop App für die neue Oberfläche erstellt werden. Und dabei ist es nicht nur möglich auf dem XAML Wissen aufzubauen, auch Code kann zwischen diesen Technologien geshared werden.

Christian

CN innovation

Image © Christian Mueringer | Dreamstime.com

Start in eine neue Ära

Im Dezember 1993 hat Microsoft in Anaheim die Win32 API vorgestellt. Im Juli 2000 wurde .NET und C# angekündigt. Hmmm… Seit 12 Jahren programmiere ich jetzt schon C# und .NET. September 2011 war das große Datum für Windows Store apps (damals noch Metro) und die Windows Runtime.

Jedes Jahrzehnt gibt es eine größere Änderung in der Applikations-Architektur. Windows 8 ist released, und jetzt sind wir wieder in einem neuen Abschnitt.

newera

Mit Windows RT stehen nur noch Windows Store Apps (plus einer abgespeckten Version von Office) zur Verfügung. Für einen großen Teil der User reicht das vollauf. Ein Web Browser, Emails, Word, und Excel…ist alles was benötigt wird. Das Microsoft Surface mit Windows RT ist da voll ausreichend.

Natürlich gibt es noch viele User die mehr brauchen. Viele Applikationen die heute am Desktop laufen haben noch keine Alternativen im Store. Viele sind auch als neue Applikationen mit dem Microsoft Design undenkbar. Doch ist das wirklich so? Es braucht einen neuen Denkansatz für die neuen Apps.

Outlook ist ein Vertreter der alten Garde, eine große, mächtige Applikation die Email, Kalender, Kontakte und Tasks anbietet. Solch große Apps sind im Store heute nicht verfügbar, wir brauchen sie aber auch nicht wirklich. Eine App für Emails, eine für den Kalender, eine für Kontakte, und eine für Tasks. Statt einer großen App viele kleine. Dabei ist das Zusammenspiel der Apps aber wichtig. Ich möchte einen Kontakt in der Person-App auswählen, und ihm ein Email schicken – oder einen Termin vereinbaren und damit einen Kalender-Eintrag machen. Von der Email App wiederum möchte ich Kontakte auswählen können. Das Zusammenspiel ist hier ganz essentiell um Apps wertvoller zu machen.

Wie einfach ist es den Kalender von Outlook gegen eine andere Implementierung auszutauschen? Mit kleineren App-Einheiten und Contracts die zwischen den Apps genutzt werden wird das wirklich möglich.

Beim Arbeiten mit dem neuen Design, der Funktonalität von Windows Store Apps werden noch viele neue Ideen entstehen. Applikationen die heute noch mit dem neuen UI undenkbar scheinen werden neue Wege aufzeigen, und viel User-freundlichere Apps möglich machen.

Ich glaube daran und sehe spannenden Jahren in der Softwareentwicklung entgegen.

Mit dem Start in diese neue Ära möchte ich meine deutschsprachigen Kunden und die Community vermehrt unterstützen – von mir gibt es jetzt nicht nur mehr den Englisch-Sprachigen Weblog, ab jetzt auch auf Deutsch!

Und das startet schon in Kürze mit einer Artikelserie über die Entwicklung einer Windows Store Picture Search App.

Christian

CN innovation

Futurezone-Artikel “Start in neue Ära”: Entwickler loben Windows 8

Abgebildetes Foto © Yakobchuk | Dreamstime.com