Verschiedene Smartphones haben unterschiedlichste Auflösungen. Möchte man sicherstellen, dass alle Icons in seiner App scharf dargestellt werden, muss man diese entweder in unterschiedlichen Auflösungen bereitstellen oder man verwendet skalierbare Vektorgrafiken, wie etwa SVG.

Ausserdem verwenden Android und iOS verschiedene Standards für die Grösse von Icons. Somit müssen diese pro Plattform eingepflegt werden. Dies bedeutet einen zusätzlichen Aufwand.

Doch wenn wir schon Code sowie UI mit Hilfe von Xamarin.Forms zwischen den verschiedenen Plattformen teilen, können wir dann nicht auch gleich die Icons wiederverwenden und wenn möglich gleich in Form von Vektorgrafiken?

Klar, das geht sogar recht gut. Obwohl Xamarin.Forms von sich aus keine SVG Grafiken unterstützt, können diese mit Hilfe von 3rd-party Libraries leicht eingebunden werden.

In einem Projekt, in welchem ich kürzlich gearbeitet habe, verwendete ich dazu FFImageLoading und SkiaSharp. Beide Libraries wurden bereits im Projekt benutzt, sodass nur noch das NuGet Package von Xamarin.FFImageLoading.Svg.Forms hinzugefügt werden musste. SkiaSharp ist eine Cross-Platform 2D-Grafik Library, welche auf der Skia-Grafikbibliothek von Google basiert.

FFImageLoading

FFImageLoading ist eine viel verwendete Library, wenn es darum geht Bilder aus dem Internet herzunterzuladen und anzuzeigen. Sie bietet eine Vielzahl von Funktionen wie etwa:

• Caching von Bildern
• Wiederholtes herunterladen von Bildern bei Fehlern
• Darstellung von Platzhalterbildern, wenn der Download fehlschlägt
• Skalierung und Transformierung von Bildern

Beispielanwendung

Ich habe ein kleines Demo-Projekt erstellt, in welchem ich zum einen lokal eingebundene SVG-Grafiken anzeige aber auch solche aus dem Internet.

FFImageLoading installieren und initialisieren

Als erstes muss FFImageLoading via NuGet zum Xamarin.Forms- sowie den Plattformprojekten hinzugefügt werden. Dies macht man entweder via NuGet Package Verwaltung oder einfach über die Konsole:

dotnet add package Xamarin.FFImageLoading.Svg.Forms --version 2.4.11.982

Um verwendet werden zu können, muss FFImageLoading beim Starten der App initialisiert werden. Am besten macht man dies noch vor der Initialisierung von Xamarin.Forms in der MainActivity oder im AppDelegate.

SVG Grafiken einbinden

Beim Hinzufügen von SVG Dateien zum Projekt, muss man darauf achten, dass man die Build Action auf “Embedded resource” stellt.

Aus Editoren exportiere SVG Grafiken enthalten oft viele redundante und nutzlose Informationen. Das können zum Beispiel Editor-Metadaten, Kommentare, ausgeblendete Elemente und Standardwerte sein. Diese können entfernt werden, ohne dass die Darstellung beeinträchtigt oder verändert wird. Dazu nutzt man am besten ein Tool wie etwa SVGO.

Die Grafiken können anschliessend direkt per Xaml eingebunden werden:

<ffimageloadingsvg:SvgCachedImage 
    Grid.Column="0" Grid.Row="0"
    WidthRequest="200" HeightRequest="200"
    ErrorPlaceholder="resource://XamarinFormsSvgSample.Resources.outline-warning-24px.svg"
    FadeAnimationForCachedImages="True"
    FadeAnimationEnabled="True"
    FadeAnimationDuration="100"
    Source="{Binding Item.IconUrl}" />

In diesem Beispiel verwende ich für den ErrorPlaceholder eine lokal hinterlegte SVG Grafik und als Source eine Url zu einem SVG im Internet.

Fazit

Mit FFImageLoading und SkiaSharp kann man auf sehr einfache Weise SVG Grafik in seine Xamarin.Forms App einbinden. Dadurch muss man seine Icons nicht für jede Plattform separat einpflegen. Weiter kann die Grösse der App verringert werden, da man nicht mehr dasselbe Icon in unterschiedlichen Auflösungen ausliefern muss. Allerdings muss man beachten, dass die Darstellung von SVG Grafiken etwas mehr Rechenleistung verlangt. Besonders in Zusammenhang mit einer ListView und mehreren SVG Grafiken pro Eintrag konnte ich beobachten, dass das Scrollen zum Teil etwas stockt. Bei der Verwendung von SVG Grafiken in der Toolbar oder in Tabs konnte ich jedoch keine Performance-Einbussen feststellen.

Google hat an der I/O 2018 das MotionLayout vorgestellt. Wie der Name erwarten lässt, ist das neue Layout für Animationen ausgelegt. Es basiert auf dem bereits bekannten CoordinatorLayout und kombiniert dessen Möglichkeit von Key-Frame Animationen mit dem Property Animation Framework. Somit eignet es sich sehr gut für die Animation von komplexen Layout-Änderungen.

Um das MotionLayout etwas besser kennen zu lernen, habe ich mich dazu entschieden, eine alte Demo-App von mir mit dem MotionLayout umzuschreiben. In dieser hatte ich demonstriert, wie man mit Hilfe vom CoordinatorLayout und dem TransitionManager eine Key-Frame Animation umsetzt. Details dazu findet man in einem früheren Blog-Beitrag.

Voraussetzungen

Das MotionLayout ist als Support Library verfügbar und ist bis zu API Level 18 (Android 4.3) abwärtskompatibel. Zum aktuellen Zeitpunkt gibt es noch keinen finalen Release sondern erst eine zweite Alpha Preview. Aus diesem Grund ist es gut möglich, dass es noch zu API Änderungen kommen kann. Um das Layout in einem Android Projekt verwenden zu können, reicht es, die folgende Abhängigkeit in der build.gralde Datei hinzuzufügen:

implementation 'com.android.support.constraint:constraint-layout:2.0.0-alpha2'

Funktionsweise des MotionLayout

Die Positionierung der Views eines MotionLayout definiert man neu mit Hilfe einer sogenannten MotionScene. Diese liegt in einer eigenen XML-Datei im res/xml Verzeichnis.

Darin werden die möglichen Zustände des Layouts beschrieben sowie der Animationsverlauf zwischen den Zuständen. Weiter kann man deklarativ das Verhalten bei Click- und Swipe-Gesten definieren.  Darin äussert sich auch ein weiterer Hauptunterschied vom MotionLayout zu den anderen Animation APIs von Android: eine laufende Animation kann aufgrund von Benutzereingaben fortlaufend gesteuert werden. Dies kann man gut in folgender Grafik nachvollziehen (man achte auf die Touch-Eingabe):

Dieses Beispiel konnte ohne eine Zeile Code rein durch ein MotionLayout (Source) und einer MotionScene (Source) implementiert werden. Die MotionScene enthält jeweils ein ConstraintSet für den ruhenden Startzustand und Endzustand des Layouts. Anschliessend wird in einer Transition die Zeitdauer und die Interpolation der Animation definiert:

<Transition
    android:id="@+id/my_transition"
    app:constraintSetEnd="@+id/ending_set"
    app:constraintSetStart="@+id/starting_set"
    app:duration="250"
    app:interpolator="linear">

    <OnSwipe
        app:dragDirection="dragUp"
        app:touchAnchorId="@+id/image_background"
        app:touchAnchorSide="bottom" />

</Transition>

Die Interaktivität mit der Swipe-Geste konnte einfach mit dem OnSwipe-Handler implementiert werden.

Weitere Informationen

Google hat mehrere sehr gute Beispiele zum MotionLayout veröffentlicht. Diese reichen von simplen Implementationen bis hin zu komplexe Animationsabläufen:

• https://github.com/googlesamples/android-ConstraintLayoutExamples

Weiter haben die Entwickler von Google auch mehrere, sehr detaillierte  Artikel veröffentlicht. Diese beschreiben z.B. das Animieren von eigenen Attributen und die Verwendung von Key-Frames:

• https://medium.com/google-developers/introduction-to-motionlayout-part-i-29208674b10d

Fazit

Obwohl das MotionLayout erst als Alpha Preview verfügbar ist und ich mir noch nicht jedes Detail genau anschauen konnte, bin ich davon sehr angetan. Besonders die deklarative Art, wie man den Verlauf von einem Layout zum anderen definieren kann, empfinde ich als angenehm. Google hat bekannt gegeben, dass mit der finalen Version des MotionLayouts auch ein Editor im Android Studio Designer erscheinen soll. Im Zusammenspiel mit diesem erhoffe ich mir einen schnellen Feedback-Loop bei der Implementierung von komplexen Animationsverläufen.