en
de

Wie verwende ich Code sowohl auf iOS, Azure und in WPF?

4 Juni 2013
| |
Lesezeit: 4 Minutes

Einleitung

In meinem aktuellen Projekt beschäftige ich mich intensiv mit dem Zusammenspiel von Monotouch / Azure und WPF. Dabei mussten wir einige Stolpersteine aus dem Weg räumen und haben auch noch weitere Steine vor uns. In diesem Blogbeitrag berichte ich über die Erfahrungen, welche wir dabei gemacht haben. Der Artikel bezieht sich deshalb nicht auf die aktuelle Version „Xamarin.iOS“ sondern auf die noch unter dem Namen MonoTouch bekannte Version. Die Aussagen in diesem Artikel stimmen aber auch für die neue Version. Wichtig zu wissen ist, dass in diesem Projekt der Desktop Client und das iPad gänzlich unterschiedliche Use Cases abbilden. Ansonsten könnte noch mehr Code geteilt werden.

Code Sharing

Modell

Einige der Modellklassen werden auf allen drei Systemen verwendet. Andere werden in Mono Touch nicht verwendet und sind dort auch nicht vorhanden.

Aufteilung Modelklassen

Aufteilung Modelklassen auf die verschiedenen Umgebungen

Natürlich gibt es auch Verbindungen von den geteilten Modellklassen auf ungeteilte. Dazu haben wir einige Klassen in Partial Classes aufgeteilt. Dies hat sich in der Praxis gut bewährt. Ich habe mich gegen Portable Libaries entschieden und wir binden die geteilten Dateien jeweils in eigene Projekte ein. Mit Portable Libraries wäre die Lösung mit Partial Classes nicht möglich und somit für unsere Anforderungen zu wenig flexibel.

Datenbank

Das Modell dient dank Entity Framework Code First gleichzeitig auch als DB Modell. Damit Monotouch keine DB spezifischen Klassen kennen muss, werden anstelle der Data Annotations die Naming Conventions verwendet, beispielsweise wird das Property für den Primary Key „Id“ benennt. Wo die Conventions nicht mehr ausreichen oder nicht passen, haben wir uns der Fluent API bedient. Mittels dieser API können Properties ignoriert oder als Muss Feld definiert werden, Relationen spezifiziert und noch viele weitere Eigenheiten des Datenbankmodells genauer angegeben werden. Die Modellklassen bleiben dabei aber frei von DB Code.

Für die Übertragung durch die Services hat es sich sehr bewährt, zusätzlich zu den Objekt Navigationsfeldern auch noch jeweils das Foreign Key Property anzugeben. Bei der Datenübertragung kann damit einiges optimiert werden. In der Praxis sieht das Ganze dann so aus:

namespace Shared // Wird von Azure, MonoTouch und WPF verwendet
{
    public class Model1
    {
        public long Id { get; set; }

        // Dieses Property soll im DB Model required sein
        public object PropertyYZ { get; set; }

        public Model2 NavigationLink { get; set; }

        public long NavigationLinkId { get; set; }
    }

    public class Model2
    {
        public long Id { get; set; }

        // Dieses Property soll für das DB Model ignoriert werden
        public bool PropertyXY { get; set; }

        public List<Model1> Model1Collection { get; set; }
    }
}

namespace AzureService // Wird nur von Azure verwendet
{
    public class DbModel : DbContext // DBContext ist die Basis Klasse für Code First
    {
        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();

            modelBuilder.Entity<Model1>().Property(m => m.PropertyYZ).IsRequired();

            modelBuilder.Entity<Model2>().Ignore(m => m.PropertyXY);

            modelBuilder.Entity<Model1>().HasOptional(m => m.NavigationLink).WithMany(m => m.Model1Collection).HasForeignKey(m => m.NavigationLinkId);
        }
    }
}

Services

Auch einige Azure Services werden sowohl vom iPad wie auch von der Desktop Applikation verwendet. Hier machten wir die Erfahrung, dass REST für uns der bessere gemeinsame Nenner ist, auch wenn MonoTouch prinzipiell WCF ebenfalls unterstützt und wir dies zuerst auch verwendet haben. Sowohl in MonoTouch wie auch in der WPF Applikation wird RestSharp als REST Client verwendet, welcher einfach aufgebaut ist, dabei aber alle nötigen Funktionen bietet. Die Zugriffe auf die Services werden aber auf beiden Plattformen jeweils einzeln implementiert, da sich gezeigt hat, dass die Daten auf den beiden Plattformen zu unterschiedlich verwendet werden. Bei ähnlicheren Anwendungsfällen würde hier nochmals ein grosses Synergiepotential begraben liegen.

Hilfsklassen

Einzelne Hilfsklassen werden ebenfalls auf allen drei Plattformen verwendet. Dem steht auch nichts im Wege, solange nur Bibliotheken/Namespaces verwendet werden, welche MonoTouch von Haus aus kennt oder wenn der Code eingebunden werden kann.

Mehrsprachigkeit

Für die Mehrsprachigkeit verwenden wir ein eigenes XML Format. Dieses wird im Blob Store von Azure gespeichert und dabei jeweils beim Starten der Desktopapplikation oder beim Synchronisieren der mobilen App auf die Geräte übertragen. Die Lokalisierung hat bei uns einige Eigenheiten, da teilweise auch Daten durch diese XML Dateien übersetzt werden. Dank des Code Sharing können aber sämtliche Klassen rund um das Thema Mehrsprachigkeit geteilt werden und Anpassungen werden somit auf beiden Plattformen automatisch übernommen.

Probleme

Die Schwierigkeit liegt in einem etwas grösseren Kommunikationsbedarf. Durch das Teilen der einzelnen Klasse kann von der MonoTouch Solution aus der Build der Visual Studio Solution gebrochen werden und umgekehrt ohne das es vom entsprechend Entwickler gleich realisiert wird. Noch etwas schwieriger wird es, wenn beispielsweise während der iPad Entwicklung eine Property in einer Modellklasse hinzugefügt wird. Der Build funktioniert noch, die Azure Services allerdings nicht mehr, da die Datenbank nicht mehr zum Modell passt. Da wir aber alle um einen Tisch sitzen, lassen sich diese Probleme einfach beheben.

Ausblick

Im nächsten Beitrag gehe ich detaillierter auf die Schwierigkeiten bezüglich Infrastruktur ein und welche Lösung wir dafür ausprobiert haben. Bereits am Anfang habe ich erwähnt, dass von Xamarin ein grosses Update für MonoTouch ausgeliefert wurde. Gleichzeitig wurde das Produkt auf Xamarin.iOS umbennent. Dieses Update wird uns einen grossen Teil der Infrastrukturprobleme lösen.

Links

http://www.xamarin.com/

http://www.windowsazure.com

http://restsharp.org/

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.