Zugriff auf diese Tools erhält man über https://www.developer.nokia.com/Devices/Remote_device_access/.

Wählt man nun Remote Device Access aus und hat sich zuvor mit einem gültigen Nokia Developer Account eingeloggt, so erhält man folgende Darstellung nun angezeigt.

Über die hier dargestellten Geräte sind weitaus mehr in der Liste  vorhanden. Man sieht darüber hinaus den Softwarestand, wie auch die zugehörige Mobilfunknummern. Die hier dargestellte Liste ist natürlich nicht vollständig.

Wenn man ein entsprechendes Gerät für den Zugriff ausgesucht hat, kann man die Reservierung ganz simpel auswählen und Starten.

Es wird bei Bestätigung von “Start” eine Java Anwendung heruntergeladen und ausgeführt, in welcher ein digitales Zertifikat akzeptiert werden muss.

Danach ist folgende Anwendungsoberfläche sichtbar.

Über diese Oberfläche lässt sich nun das Gerät steuern. Zugegeben – entsprechend der zur Verfügung stehenden Bandbreite kann das Livebild vom Gerät sich verzögern / dabei ruckeln. Dafür ist es aber trotzdem ein physisches Gerät.

Man kann aber nicht nur auf das Dateisystem zugreifen, sondern auch Apps als XAP-Datei deployen, Screenshots anfertigen, sowie auch den Bildschirm filmen (installierten XVID Codec vorausgesetzt) und mit Sprache zu Schulungszwecken versehen. Auch die Qualität der übertragenen Oberfläche lässt sich anpassen. Verringert man diese auf die Stufe “1”, so wird nur noch ein Bild in Graustufen übertragen – dafür jedoch schneller.

Wird der Emulator nicht weiter benötigt, kann man diesen Schließen und die nicht genutzte Zeit wird einem für diesen Tag wieder gut geschrieben. Darüber hinaus werden alle auf dem Gerät vorgenommenen Änderungen gelöscht / zurückgesetzt.

Meine persönliche Meinung: Zwar ist die Verbindung ein wenig langsam, aber man kann vieles damit machen, was einem sonst nicht ermöglicht wird!

ViewModel

Zufälligerweise wurde diese Funktionalität bereits im ersten Teil der Konvertierung hinzugefügt. Dabei fand keinerlei Austausch mit Sascha zu diesem Thema stand; auch wurde der Quellcode vorab nicht gelesen, so dass nun 2 Lösungsansätze existieren, die ziemlich identisch sind. So besitzt das ViewModel nicht die Eigenschaft IsBusy, sondern Progressing. Über den Namen ließe sich wirklich streiten, jedoch ist der Zweck der Eigenschaft der Selbe: Es soll optisch den Anwender gegenüber angezeigt werden, dass eine Verarbeitung der Daten stattfindet. Dies soll ebenfalls mittels Datenbindung stattfinden. Dazu jedoch gleich mehr.

Den Ansatz, den hier von Sascha gewählt wurde, finde ich persönlich nicht vollständig. Zwar ist es für seinen Fall richtig darzustellen, dass die Kommunikation mit dem Server stattfindet, doch mein Wunsch ist es darüber hinaus, auch die clientseitige Verarbeitung zu erfassen. Zwar dürfte sich der Unterschied generell nur im Millisekundenbereich abspielen, doch wenn man sich einmal die LoadMessages-Methode im Detail anschaut, sieht man hier neben der Kommunikation eine weitere Verarbeitung der abgerufenen Nachrichten. Bei einer größeren Anzahl von Nachrichten (man denke hier beispielsweise nur einmal an WhatsApp), würde man eine potentiell lange Verarbeitungszeit mit der hier dargestellten Methode ebenfalls erfassen.

...
        private async void LoadMessages()
        {
            Progressing = true;
            RefreshCommand.IsEnabled = false;

            var error = String.Empty;
            try
            {

                var newMessages = await _messagesTable
                                            .OrderByDescending(m => m.CreatedAt)
                                            .Take(MaxMessageCount)
                                            .ToListAsync();

                // Perform a simple sync of the existing list using the Ids.
                var matched = new Queue<Message>();
                var removals = new Queue<Message>();

                foreach (var item in Messages)
                {
                    var didMatch = false;

                    foreach (var newMessage in newMessages)
                    {
                        if (newMessage.Id == item.Id)
                        {
                            matched.Enqueue(newMessage);
                            didMatch = true;
                            break;
                        }
                    }

                    // If no match, we should remove from Items collection
                    if (!didMatch)
                    {
                        removals.Enqueue(item);
                    }

                    // remove new items as quickly as soon as they're matched 
                    while (matched.Count > 0)
                    {
                        newMessages.Remove(matched.Dequeue());
                    }
                }

                while (removals.Count > 0)
                {
                    Messages.Remove(removals.Dequeue());
                }

                // add any remaining newItems - the must be genuinely new items
                foreach (var newMessage in newMessages)
                {
                    var pos = 0;
                    foreach (var message in Messages)
                    {
                        if (newMessage.CreatedAt.CompareTo(message.CreatedAt) < 0)
                            pos++;
                        else
                            break;
                    }
                    Messages.Insert(pos, newMessage);
                }
            }
            catch (Exception ex)
            {
                error = ex.Message;
            }
            if (!String.IsNullOrEmpty(error))
                MessageBox.Show(error,"Error while loading messages",MessageBoxButton.OK);
            RefreshCommand.IsEnabled = true;
            Progressing = false;
        }

Die Methode ist somit ganz einfach: LoadMessages, SendMessage und RemoveSelectedMessage erhalten eine zusätzliche Zeile am Anfang und am Ende der Methode, worin der Wert in Progressing jeweils geändert wird. Dies ist simpel und effektiv.

View

Zur Darstellung, dass die App beschäftigt ist, wird ein ProgressIndicator verwendet. Dieser ist ähnlich zum ProgressRing.

Die Deklaration, inklusive Datenbindung, sieht in der MainPage.xaml, wie folgt aus.

<phone:PhoneApplicationPage
    x:Class="LetsTalkWP8.MainPage"
...
    shell:SystemTray.IsVisible="True">

    <shell:SystemTray.ProgressIndicator>
        <shell:ProgressIndicator IsIndeterminate="true" x:Name="indicator" 
                IsVisible="{Binding Progressing}" Text="Progressing" />
    </shell:SystemTray.ProgressIndicator>
...

Somit besitzt die App nun eine optische Anzeige in der oberen Systemleiste, wenn eine Verarbeitung der Daten stattfindet. Ist diese aktiv, so werden animierte durchlaufende Punkte mit dem Text “Progressing” dargestellt.

Den Sourcecode dieser App finden Sie hier unter GitHub im Ordner 01_LetsTalk_WP8_CRUD.

(Picture Source: http://www.plaffo.com/2013/02/rumor-windows-phone-blue-potrebbe-ritardare-ed-essere-disponibile-solo-nel-2014/)

Why do I think I’m able to do these assumptions?

From what we learned with Windows Phone 8 is, that the Kernel is already running a Windows NT Kernel, and not, like before, a Windows CE Kernel. This means, that Windows 8 and Windows Phone 8 already have a common base to share. It seems to me more than obvious, that streamlining both plattforms is one designated goal to achieve, to reduce costs for developing, maintaing and especially testing Windows Phone. Especially having a different UI Layer (WP8: still Silverlight, W8: WinRT XAML) makes it more than hard creating Apps targeting both plattforms directly. This makes me believe, that the UI Layer will be shared here as well and my guess is, that it will happen with the “Blue Wave”.

Disclaimer: Please don’t sue me

The article is written to share personal opinion based on this post . I have no insider information what-so-ever on Windows 8.1, Windows Phone Blue, or any related technology.

This article compromises my personal conclusions from “leaked” information. No NDAs were harmed in the making of this article. I do not have and never had any pre-release access the components mentioned in this article. It was written and researched on my own time and has no affiliation with my employer.

The Base

Justin already dissected the parts in for the Windows 8.1 API, where I’ll only focus on the parts, that I think could be in the package for Windows Phone Developers. Therefore I’m just commenting my thoughts on the ToC.

1. Bluetooth 4.0 RfComm and GATT support
   With Windows 8 and Windows Phone 8, sharing Information between Modern UI Style Apps is impossible, as both share a different PeerFinder implementation. Therefore I guess, that App2App Communication between W8 and WP8 will be enabled.
2. VPN support for Modern UI apps
   This is a number one feature that Windows Phone Business Users are demanding since Windows Phone 7. So, if it is likely to come to Windows 8.1, I think it will come over to Windows Phone Blue as well.
3. Support for any External / USB device
   As there is already existing Support for Storage Cards within Windows Phone 8, my guess is, that this will be expanded for Windows Phone Blue as well. Having a Storage Card today working only with Readonly Access for registered filetypes doesn’t sound feasible anymore.
4. Camera: Low-lag cameras / HDR
   As Nokia is actually showing more and more devices, which have an incredible camera included, I guess that this feature might come with Windows Phone Blue as well
5. New App Type: GeoFenced activation
   If this comes to Windows 8.1, my best guess is, that this will be included in Windows Phone Blue as well. This is a feature, that a lot of Mobile Device Management (MDM) solutions offer, so having this out of the box would make Windows Phone Blue more attractive to Business users, who want to have such a control.
6. New App Type: Lock screen call
   Whoever tried to use Skype on Windows Phone 8 ran into this specific problem, so I’m guessing that this would be included as well for enhancing the user experience for those apps!

I hope sharing this ideas helps to get an idea, where the journey with Windows Phone Blue could take us.

Das interessante daran ist, dass man hier nicht nur, wie sonst, die Windows Phone 8 Features für Entwickler präsentiert (wie in der üblichen “App Developer Day”-Reihe), sondern insbesondere auf die Lumia eigene Entwicklungsbibliothek und Dienste eingegangen wird.

Ich werde es persönlich leider nicht schaffen dort hin zu kommen, aber wer die Zeit findet, sollte ruhig hier einmal vorbeischauen – falsch machen kann man da nichts.

Hier die zugehörige Agenda:

9:30       Nokia Lumia mit Windows Phone 8: neue Features für Entwickler
10:30     Kaffeepause
11:00     Location Based Services mit HERE-Karten
12:00     Mittagspause
13:00     Nutzung der PureView-Technologie über das Kamera-API
14:00     Neue Anwendungsfälle dank NFC und Bluetooth
15:00     Kaffeepause
15:30     Zugang zu Lumia Smartphones für Entwickler und Lumia Developer’s Library
16:30     Q&A
17:00     Ende der Veranstaltung

Die Kurzantwort: Eigentlich ist es eine fehlende Komponente, die fast jeder App-Entwickler benötigt: Eine Serverkomponente. Dabei rede ich hier nicht explizit von Windows, iOS oder Android Apps, sondern Apps im Allgemeinen. Meist möchte man Informationen einfach auf einem Server ablegen, ohne sich um einen Server, Datencontainer und andere infrastrukturelle Themen Gedanken zu machen. Dabei kann dies schnell teuer werden, wenn man einen ganzen Server betreiben muss. Dabei ist ein App Entwickler meist kein Serveradmin, so dass die Einrichtung schnell kompliziert werden kann und man den Kernfokus verliert. Dabei setzten hier genau die Windows Azure Mobile Services. Sie bieten eine Möglichkeit Daten einfach in einer Datentabelle abzulegen, ohne sich um Themen, wie Betriebssystem o.ä. zu kümmern.
Diese Dienste sind natürlich nicht nur auf Apps beschränkt – jede andere Technologie kann ebenfalls auf diese Dienste zugreifen, sofern Sie HTTP, REST und JSON unterstützt.
Sascha Dittmann, MVP für Windows Azure, began im April die Windows Azure Mobile Services näher zu beleuchten. So finden sich detaillierte Informationen, welche Technik bei den Mobile Services eingesetzt wird und welche Funktionen einem Entwickler zur Verfügung gestellt werden und wie man einen solchen Dienst mit ein paar einfachen Mausklicks erstellen kann, in diesem von ihm erstellten Artikel.

Um die Mobile Services und deren Funktionen beschreiben zu können, erstellt er eine aufeinander aufbauende Nachrichten-App für Windows 8 App namens “Let’s Talk”, angefangen mit den CRUD-Operationen, über Eingabevalidierung auf Serverseite, hin zu einer Windows Account Authentifizierung. Die Serie der Artikel findet man hier, der Sourcecode ist hier unter GitHub zu finden.

Das Projekt

Diese Reihe brachte mich auf die Idee, Saschas Spuren einfach mal zu folgen und eine “Let’s Talk WP8” App zu erstellen. Dies hat mehrere Gründe:

• Zu zeigen, wie eine Windows 8 App zu Windows Phone 8 “portiert” werden kann und dabei die Probleme aufzuzeigen
• Zu zeigen, wie das Windows 8 UI Konzept unter Windows Phone 8 umgesetzt werden kann
• Zu zeigen, wie einfach die Windows Azure Mobile Services zu verwenden sind.

Den Sourcecode zur ersten Windows Phone 8 App finden Sie ebenfalls auf GitHub unter dem Fork https://github.com/PeterNowakDe/LetsTalk.

Die Konvertierung

Die Konvertierung für sich genommen ist einfach, da in der Windows 8 App idealerweise MVVM für die Abstraktion der Schichten genutzt wird.

Eine ansprechende, an Windows Phone 8 angepasste UI zu entwerfen ist auch einfach. Schwieriger stellt sich da der vom System genutzte UI Layer dar, der eine simple Konvertierung nicht zulässt. So wird in der Windows 8 App der WinRT XAML Layer verwendet, während der XAML Layer von Windows Phone 8 immer noch auf Silverlight basiert. So sind viele Steuerelemente unterschiedlich, oder gar nicht erst vorhanden. Ist ein Steuerelement vorhanden, findet es sich dann meist auch in eine anderen Namespace wieder. Mehr dazu jedoch später.

Analog zur Windows 8 App wird in Visual Studio ein neues Projekt vom Typ Windows Phone App mit dem Namen  LetsTalkWP8 erstellt.

Danach wird auch hier das Windows Azure Mobile Services SDK via NuGet hinzugefügt.

Da die Pre-Release Version in den Quick Start Apps verwendet wird, und sich diese erheblich von der Stable Version unterscheidet, sollte bei NuGet der “Pre” Parameter verwendet werden:

Das Ausführen des Kommandos fügt folgende Bibliotheken dem Windows Phone Projekt hinzu.

Neben der Bibliothek für die Mobile Services werden noch einige weitere Hilfsbibliotheken für beispielsweise HTTP Kommunikation, wie auch die JSON Bibliothek von Newtonsoft hinzugefügt.

Model

Wie bei MVVM üblich unterteilen sich die Schichten in die View (also die UI), dem ViewModel (der Verbindung zwischen UI und Model) und dem Model selbst, welche somit die Datenschicht darstellt.

Ein solches Model ist hier die Klasse Message. Sie stellt die Nachrichten dar, die mit anderen Benutzern über den Server ausgetauscht werden. Dabei ist die Datenstruktur auch gleich die Datenstruktur, welche auf dem Server in Form einer Datentabelle angelegt wird .

Die Klasse besitzt folgende Felder und Eigenschaften:

Die Klasse, wie auch die Eigenschaften werden mit Attributen dekoriert, wie man es auch vom DataContract her kennt.

Das DataTable-Attribut aus dem Namespace Microsoft.WindowsAzure.MobileServices beschreibt, dass die Daten in einer Datentabelle mit dem Namen messages abgelegt werden. Die Klasse leitet zusätzlich von der Helferklasse BindableBase ab, die man im Ordner Common wiederfindet. Diese abstrakte Klasse implementiert generisch die Schnittstelle für INotifyPropertyChanged, um eine Zwei-Wege-Datenbindung mit der UI zu ermöglichen.

Die Eigenschaftsattribute der Klasse Message beschreiben, ob diese in JSON serialisiert  (JsonProperty), oder ignoriert (JsonIgnore) werden sollen.

Das Konvertieren der Klasse zu Windows Phone 8 ist relativ überschaubar. So sind hier primär die Referenzen der Namespaces anzupassen.

Daraus resultiert auch eine weitere Änderung am Quellcode im Getter der Methode UserImage. So wird aus:

_userImage = new BitmapImage(new Uri(App.BaseUri, _userImageUrl));

einfach

_userImage = new BitmapImage( new Uri(_userImageUrl,UriKind.RelativeOrAbsolute));

ViewModel

Als Basis für das MainPageViewModel wird die Schnittstelle IMainPageViewModel deklariert.

Diese Schnittstelle definiert neben einer ObservableCollection vom Typ Message, welche als Container für die dem Anwender darzustellenden Nachrichten verwendet wird, die Eigenschaften MessageText. Sie dient als Container für den vom Benutzer eingegebenen Text. Die Eigenschaft SelectedMessage beinhaltet die aktuell vom Anwender selektierte Nachricht.

Für die einzelnen CRUD-Operationen wird jeweils ein entsprechendes Objekt vom Typ DelegateCommand definiert:

• SendMessageCommand zum Erstellen (Create) einer Nachricht in den Windows Azure Mobile Services.
• RefreshCommand zum Aktualisieren / Lesen (Read) serverseitiger Nachrichten.
• DeleteMessage zu Löschen (Delete) einer serverseitigen Nachricht
• Eine Aktualisierung (Update) einer Nachricht findet hier keine Anwendung

Die Schnittstelle wird im ViewModel MainPageViewModel implementiert und hat folgende Struktur:

Zusätzlich leitet diese Klasse ebenfalls von BindableBase für die vereinfachte Datenbindung ab.

Die Methoden LoadMessages, SendMessage und RemoveSelectedMessage sind die implementierten Methoden zur Kommunikation mit den Windows Azure Mobile Services. Sie werden von den zugehörigen DelegateCommand-Objekten verwendet.

Zusätzlich existiert ein Objekt vom Typ DispatcherTimer, welcher alle 30 Sekunden die Nachrichten erneut vom Server liest. Der Einfachheit halber wurde hier auf eine Implementierung verzichtet, in welcher nur neue Nachrichten abgerufen werden.

Die Windows Azure Mobile Services Bibliothek wird primär im ViewModel verwendet. Dazu wird ein Objekt vom Typ MobileServiceClient global definiert und im Konstruktor instanziiert.

        private readonly MobileServiceClient _mobileServiceClient;
        private readonly IMobileServiceTable _messagesTable;
...
        public MainPageViewModel()
        {
            _mobileServiceClient = new MobileServiceClient(
                App.MobileServiceUrl,
                App.MobileServiceKey);

            _messagesTable = _mobileServiceClient.GetTable();
...

Als Parameter werden neben der von Windows Azure für den Dienst vergebene Url auch der ServiceKey übergeben. Diese sind als Konstanten in der App.xaml.cs definiert.

    public partial class App : Application
    {
        public const String MobileServiceUrl = "";
        public const String MobileServiceKey = "";
...

Über das Objekt vom Typ IMobileServiceTable wird auf die in den Windows Azure Mobile Services abgelegte Tabelle zugegriffen. Diese Referenz auf die Tabelle wird über die Methode GetTable abgerufen und in _messageTable abgelegt. Es dient primär zur Serverkommunikation.

...
        private async void LoadMessages()
        {
...
                var newMessages = await _messagesTable
                                            .OrderByDescending(m => m.CreatedAt)
                                            .Take(MaxMessageCount)
                                            .ToListAsync();

...
        }

        private async void SendMessage()
        {
...
            try
            {
                var message = new Message
                {
                    Body = MessageText,
                    CreatedAt = DateTime.Now,
                };

                MessageText = String.Empty;

                await _messagesTable.InsertAsync(message);
                Messages.Insert(0, message);
            }
            catch (Exception ex)
            {
                error = ex.Message;
            }
            if (!String.IsNullOrEmpty(error))
                MessageBox.Show(error, "Error while sending a message", MessageBoxButton.OK);
        }

        private async void RemoveSelectedMessage()
        {
            if (SelectedMessage == null) return;

            var error = String.Empty;
            try
            {
                var dialog = MessageBox.Show("Do you really want to delete the message:\n" + SelectedMessage.Body,
                    "Delete Message", MessageBoxButton.OKCancel);
                if (dialog == MessageBoxResult.OK)
                {
                    await _messagesTable.DeleteAsync(SelectedMessage);
                    Messages.Remove(SelectedMessage);
                    SelectedMessage = null;
                }
            }
            catch (Exception ex)
            {
                error = ex.Message;
            }
            if (!String.IsNullOrEmpty(error))
                MessageBox.Show(error, "Error while deleting a message", MessageBoxButton.OK);
        }

Für die CRUD-Operationen Zum Löschen und Einfügen eines neuen serverseitigen Eintrags werden die asynchronen Methoden DeleteAsync und InsertAsync verwendet. An diese wird das zu zugehörige Objekt vom Typ Message übergeben.

Die Operation wird auch direkt ausgeführt, so das die Änderungen auf dem Server sofort sichtbar sind.

Zum Abfragen der Daten wird eine LINQ-Abfrage genutzt. Diese wird entsprechend in eine REST-Abfrage beim Ausführen umgewandelt. So wird aus der oben dargestellten Abfrage, folgender Aufruf: GET https://yourinstance.azure-mobile.net/tables/messages?$orderby=createdAt%20desc&$top=50.

Die Unterschiede bei der Portierung sind auch hier eher gering. So werden folgende Namespaces gewechselt, bzw. hinzugefügt.

Darüber hinaus wird anstatt de asynchronen MessageDialog hier noch die synchrone MessageBox verwendet, da der MessageDialog unter WP8 nicht zur Verfügung steht.

Eine Erweiterung ist die Eigenschaft Progressing, die im Ursprungsprogramm nicht vorhanden ist. Diese wird in diese Klasse gesetzt, wenn eine Datenkommunikation mit dem Server stattfindet. Über einen Datenbindung wird dies dann über einen ProgressIndicator dem Anwender gegenüber dargestellt, das einer Verarbeitung / Kommunikation aktuell stattfindet.

In RemoveSelectedMessage wird nach Messages.Remove(SelectedMessage); noch SelectedMessage=null hinzugefügt. Dies verhindert einen Bug, wodurch eine bereits gelöschte Nachricht erneut gelöscht werden soll.

Im Ordner ViewModel existiert noch ein SampleMainPageViewModel, welches unter WP8 keine Anwendung findet, da dies in dieser Art und Weise nicht unterstützt wird.

Die View / UI

Die App-Oberfläche der Anwendung ist hinsichtlich der Portierung ein wenig aufwendiger. Grund hierfür ist einerseits der ungleiche UI Layer, aber auch der Aufbau der UI, welcher sich aufgrund der zur Verfügung stehenden Bildschirmgröße unterscheiden muss. Glücklicherweise gibt es unter WP8 keine SnapView, welche betrachtet werden muss. Die UI wird von einer breiten Form zu einer länglichen Form verändert, da es sich bei der App anbietet.

So wird aus

nun

Der größte Teil der Oberfläche ist übernommen und kaum verändert worden, so dass der Wiedererkennungswert sehr groß ist.

So wird das Hintergrundbild wieder verwendet, der Nachrichtenteil ist etwas verkleinert beibehalten worden und der Eingabeteil für neue Nachrichten ist unter den Nachrichtenbereich gewandert. Diesem wurde zusätzlich ein transparenter dunkler Hintergrund spendiert, um die Lesbarkeit des eingegebenen Textes zu erhöhen. Unter dem Eingabebereich befindet sich noch eine AppBar, über welche Nachrichten gelöscht, oder aktualisiert werden können. Für diese wurden Modern UI Icons aus dem Installationspaket des WP8 SDKs verwendet. Auch der sichtbare Appname wurde aus Platzgründen deutlich verkleinert.

Im Nachrichtenteil wurden ebenfalls aus Platzgründen Benutzername und Sendedatum untereinander gruppiert.

Das Profilbild wurde ein wenig verkleinert, damit so mehr Platz für die Nachrichten zur Verfügung steht.

Als Steuerelemente wurden hier die WP8 nativen Steuerelemente verwendet. Einzig die AppBar ist eine zusätzliche Komponente, da diese eine Datenbindung unterstützt.

Die für die Steuerelemente verwendeten Styles wurden auch für die neue Oberfläche optimiert. So findet man nun folgende Style Definition unter Common/Styles.xaml vor:

"http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:common="clr-namespace:LetsTalkWP8.Common">

    "BooleanToVisibilityConverter" />
    "TimeAgoConverter"/>
    "AccentColor" Color="#FF00A8D9"/>

    "SpeechBubble">
        "150">

                "30" />

                "130"/>

            "2" Width="120" Height="120">
                "{Binding UserImage}" Stretch="UniformToFill" AutomationProperties.Name="{Binding UserName}"/>

            "1" Fill="{StaticResource AccentColor}" RadiusX="25" RadiusY="25" Margin="0,5,5,0"/>

            "1" FontSize="16" Text="{Binding Body}" TextWrapping="Wrap" Margin="12,12,17,10"/>

            "M190,100 L130,130 L155,100" Fill="{StaticResource AccentColor}" HorizontalAlignment="Left" Height="50" Grid.Row="1" Stretch="Fill" UseLayoutRounding="False" VerticalAlignment="Bottom" Width="70" Grid.Column="1" Margin="0,-5,0,25"/>
            "1" Grid.Row="1">
                "16" Text="{Binding UserName}" HorizontalAlignment="Right" VerticalAlignment="Center" Margin="0"/>
                "16" Text="{Binding CreatedAt, Converter={StaticResource TimeAgoConverter}}" TextWrapping="NoWrap" HorizontalAlignment="Right" VerticalAlignment="Center" Margin="0"/>

Der erste Unterschied ist, dass in der XML-Namespace Deklaration anstatt using: noch “das alte” clr-namespace: verwendet wird. Dieses wird unter WP8 noch nicht unter unterstützt.

Der MergedDictionaries Anteil ist nicht vorhanden, da es in WP8 kein StandardStyles.xaml gibt.

Das SpeechBubble-DataTemplate wurde in seiner Größe und den definierten Dimensionen angepasst. Das darin enthaltene erste Border-Element besitzt hier keinen Hintergrund.

Das in de Grid geschachtelte Grid wurde durch ein simples StackPanel-Steuerelement ersetzt; die darin enthaltenen TextBlock-Elemente wurden rechtsbündig ausgerichtet.

Das nicht verwendete SpeechBubbleSnapped-DataTemplate wurde entfernt.

Damit diese Styles in der App verwendet werden, ist eine Anpassung der App.xaml notwendig, um diese der App bekannt zu machen.

So wird aus

    

        "clr-namespace:LetsTalkWP8" x:Key="LocalizedStrings"/>

nun

    

                "Common/Styles.xaml"/>

            "clr-namespace:LetsTalkWP8" x:Key="LocalizedStrings"/>

Zu guter Letzt fehlt noch die Definition der MainPage selbst.

"LetsTalkWP8.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
    xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:bar="clr-namespace:BindableApplicationBar;assembly=BindableApplicationBar" 
    mc:Ignorable="d"
    xmlns:common="clr-namespace:LetsTalkWP8.Common"
    xmlns:viewModels="clr-namespace:LetsTalkWP8.ViewModel"
    FontFamily="{StaticResource PhoneFontFamilyNormal}"
    FontSize="{StaticResource PhoneFontSizeNormal}"
    Foreground="{StaticResource PhoneForegroundBrush}"
    SupportedOrientations="Portrait" Orientation="Portrait"
    shell:SystemTray.IsVisible="True">

        "true" x:Name="indicator" IsVisible="{Binding Progressing}" Text="Downloading" />

    
    "LayoutRoot" Background="Transparent">

            "Auto"/>
            "*"/>

        "TitlePanel" Grid.Row="0" Margin="12,17,0,0" Height="27" VerticalAlignment="Top">
            "Let's Talk WP8" Style="{StaticResource PhoneTextNormalStyle}" Margin="12,0"/>

        
        "ContentPanel" Grid.Row="1" Margin="12,0,12,0">

                "/Assets/bg.jpg" Stretch="UniformToFill"/>

                "2*"/>
                "*"/>

            "lls" HorizontalAlignment="Left" VerticalAlignment="Top" Grid.Row="0"
                                    Margin="0"
                                    Padding="0,0,0,0"
                                    ItemsSource="{Binding Messages}"
                                    ItemTemplate="{StaticResource SpeechBubble}"
                                    SelectedItem="{Binding SelectedMessage, Mode=TwoWay}" Width="456"
                                    />
            "1" Background="#D8000000">
                "itemDetail"
                    Orientation="Vertical">
                    "MessageTextBox" Text="{Binding MessageText, Mode=TwoWay}"  MaxLength="140" TextWrapping="Wrap" FontSize="20" Height="150" />
                    "SendButton" Command="{Binding SendMessageCommand}" Content="Send" HorizontalAlignment="Right" Width="169" FontSize="20" Height="72"/>
                

            "Löschen"
                Command="{Binding DeleteMessageCommand}"
                IsEnabled="{Binding DeleteMessageCommand.IsEnabled}"
                IconUri="Assets/delete.png" />

            "Aktualisieren"
                Command="{Binding RefreshCommand}" 
                IsEnabled="{Binding RefreshCommand.IsEnabled}"
                IconUri="Assets/refresh.png" />

Anstatt einer LayoutAwarePage (Windows 8) wird hier eine PhoneApplicationPage als Basis verwendet. Diese unterstützt in diesem Fall auch nur den Portrait-Modus.

In der Deklaration der Seite wird der Datenkontext nicht gesetzt, da dies in der Codebehind-Datei, wie auch bei der Windows 8–App, geschieht.

Die verwendeten XML-Namespaces unterscheiden sich kaum voneinander. Unter WP8 ist neben den zusätzlichen phone:- und shell:-Namespace auch noch ein bar:-Namespace für die BindableApplicationBar definiert. Mehr Informationen zur BindableApplicationBar gibt es hier.

Diese kann einfach über die Package Manager Console mittels Install-Package BindableApplicationBar hinzugefügt werden. Die XAML-Deklaration ist selbsterklärend.

Als erstes Element in der Deklaration ist ein ProgressIndicator instanziiert, der wie zuvor Beschrieben für die optische Darstellung einer stattfindenden Datenkommunikation genutzt wird.

In der Windows 8 App wird im Ressourcenbereich eine CollectionViewSource deklariert, welche hier nicht genutzt wird. Grund hierfür ist, dass die Deklaration einer Designseite unter WP8 nicht unterstützt wird und aus diesem Grund auch dann nicht benötigt wird.

Die Aufteilung der Anwendungsoberfläche ist fast klassisch für eine Windows Phone 8 App. So wird diese in die Bereiche Kopfzeile und den Inhaltsbereich aufgeteilt, was dargestellt wird durch das Grid LayoutRoot, welches die beiden Grids TitlePanel und ContentPanel beinhaltet. Im TitlePanel ist nur das kleine TextBlock-Element mit dem App-Namen vorhanden, um Platz zu sparen.

Als Container für die Nachrichten wird ein LongListSelector-Steuerelement verwendet, da aktuell ein anderes Steuerelement hier keinen Sinn macht und die ListView unter WP8 nicht existiert. Leider besitzt der LongListSelector keine Möglichkeit eine Vorlage für ein SelectedItemDataTemplate zu erstellen, so dass man zwar ein Element aus der Liste auswählen kann, dies aber gegenüber dem Anwender optisch nicht wiedergespiegelt wird.

Wer genau hinschaut sieht auch, dass hier nicht das Steuerelement aus dem Framework verwendet wird. Dieses besitzt einen Bug, so dass eine Datenbindung für SelectedItem schlichtweg nicht möglich ist. Der Workaround ist unter Common/LongListSelector.cs zu finden.

Zusammenfassung

Die Migration hinsichtlich des Models und des ViewModels ist von Windows 8 nach Windows Phone 8 relativ schnell erledigt, auch wenn einige Namespaces angepasst und nicht vorhandene Elemente, wie beispielsweise dem asynchronen MessageDialog, durch alternative Elemente ersetzt werden müssen.

Der größte Aufwand ist jedoch die Migration der View. So ist nicht nur eine angepasste UI für die entsprechende Auflösung notwendig, sondern wahrscheinlich auch eine Neuentwicklung der UI nötig, da das Windows 8 WinRT XAML und das Windows Phone 8 “Silverlight” XAML von den unterstützten Funktionen und Steuerelementen sehr unterschiedlich sind.

Ich hoffe aber, das dieses erste Beispiel gezeigt hat, wie man es machen kann und nebenbei auch noch die Windows Mobile Azure Services ganz einfach einbindbar sind.

Inhaltlich präsentierten Sascha Dittmann (Microsoft MVP für Windows Azure) und Damir Dobric (Microsoft Integration MVP and Windows Azure VTSP) das, was ich von einem solchen Bootcamp erwarten würden: Einen “Rundflug” über die Microsoft Cloud mit einigen Exkursen, wie beispielsweise den Azure Websites, dem Azure Storage, den mobile Services und noch vielen weiteren mehr.

Mehr als ein Rundflug war aber auch nicht möglich, da jedes Modul für sich genommen eine mehrtätige Schulung füllt. Somit war auch der Begriff Bootcamp völlig richtig gewählt. Was leider auch ein wenig zu kurz kam waren die Hands-On Labs. Grund hierfür war einfach die miserable WiFi Verbindung, die für dieses Event zur Verfügung gestellt wurde. Damit dauerte das Deployen einer einfachen Website mehrere Minuten, was einfach nur Zeit schluckte. Dafür wurden dies Samples gemeinsam vorne am Beamer gemeinsam durchgearbeitet, was somit ein kleiner Trost war.

(Locations des Globale Azure Bootcamps, Quelle: http://globalwindowsazure.azurewebsites.net/)

Es gab aber noch ein zusätzliches Highlight: Das Global Render Lab (Hintergrundinformationen hier). In diesem wurden Aufnahmen eines Kinect Tiefensensors in eine virtuelle Szene gerendert. Das Rendering selbst wurde in Azure gemacht. Damit aber noch nicht genug, denn dieses Rendering wurde auf Standort- und Landesebene als Ranking zu einem virtuellen Wettstreit herangezogen.
Die Ergebnisse des Rendering sind hier zu sehen: http://renderlab.azurewebsites.net/

Wie zu vermuten war, war Deutschland natürlich zwischenzeitlich auf Platz eins beim Renderen, jedoch war gegenüber den USA bei uns auch die Kapazität irgendwann begrenzt, so dass Deutschland nur auf Platz 2 landete. Einen kleinen  Sieg konnte jedoch Berlin für sich verbuchen: Kein Standort renderte mehr als Berlin!

Das Event war also ein voller Erfolg. Gerne kann es hiervon nochmal ein “Reboot” geben, denn interessant war es auf jeden Fall.

Die Neuerungen in Kürze:

• Screenshots lassen sich einzeln nun direkt im Portal drehen
• Eine Submission kann nun abgebrochen werden, um vielleicht Aktualisierungen am Text, Bildmaterial o.ä. vorzunehmen
• Automatische Skalierung der Screenshot. Somit ist es nicht unbedingt notwendig für alle 3 Auflösungen (WXGA, 720p und WVGA) eigene Screenshots zur Verfügung zu stellen.

Die Neuigkeiten in voller Gänze gibt es hier.

Quelle: http://blogs.msdn.com/b/visualstudioalm/archive/2013/01/31/windows-phone-unit-tests-in-visual-studio-2012-update-2.aspx

Das hierfür notwendige Projekttemplate ist nun somit im Visual Studio zu finden. Die Tests selbst werden, wie auch bei anderen Projekten im Visual Studio, im zugehörigen Testframework geschrieben, die vom Windows Phone nun unterstützt werden. Kennt man diese Funktionalität bereits muss man hier nichts Neu lernen. Die Edition des Visual Studio ist ebenfalls uninteressant, da selbst die Express Edition unterstützt wird.

Auch das Ausführen der Unit Tests von der Konsole aus wird unterstützt.

Wo Licht ist, ist bekanntlich auch Schatten. So wird Windows Phone 7.x leider nicht unterstützt.

Weiter Informationen finden Sie hier: http://blogs.msdn.com/b/visualstudioalm/archive/2013/01/31/windows-phone-unit-tests-in-visual-studio-2012-update-2.aspx

Fast ein Jahr ist es her, dass der letzte Blogpost hier erschienen ist. Erschreckend! Doch es war ein schöner Anlass: Unser Updatekapitel zu Windows Phone 7.5 Refresh wurde veröffentlicht.

Doch danach wurde es ein wenig ruhig in diesem Blog. Weder das Update zu Windows 7.8 wurde behandelt, noch der Start von Windows Phone 8 begleitet. Dies führte u.a. auch dazu, dass ich seit April korrekterweise kein MVP für Windows Phone Development mehr bin.

Da ich aber seit Anfang April einen neuen Arbeitgeber habe, der mir nicht nur die Möglichkeit wieder in meinem Technologiestack unterwegs zu sein, sondern auch ein wenig etwas für die Community zu tun, war der erste Schritt diesen Blog einmal zu entstauben und auch wieder mit Leben zu füllen. Es wird auch wieder frischen Windows Phone 8 Content geben, über den ich  ich aktuell nicht sprechen mag / kann.

Somit fangen wir einmal ganz einfach an: Was interessiert euch an Windows Phone 8, sowohl Consumer- als auch Entwicklerseitig? Immer her damit – mal sehen, was sich davon machen lässt.
Würden euch eher englische oder deutsche Inhalte interessieren? Hinterlasst mir einfach ein Kommentar.

Bis dahin verbleibe ich mit den treffenden Worten meines neuen Chefs:

“Rock ‘n’ Roll!”

Quelle: http://pommesgabeln.de.tl/