Das ConstraintLayout (CL) ist ein neu entwickeltes Layout von Google. Es befindet sich momentan noch in Beta-Status und setzt mindestens Android API Level 9 voraussetzt. Ähnlich wie beim RelativeLayout werden die Views relativ zu einander oder zum Layout selber ausgerichtet.

Warum das ConstraintLayout verwenden?

Die Verwendung des CL ermöglich es, auf verschachtelte ViewGroups zu verzichten. Insbesondere auf gewichteten LinearLayouts und RelativeLayouts. Mit jeder zusätzlichen Verschachtelung im Layout, kann die Anzahl der erforderlichen Render-Zyklen exponentiell steigen. Dies führt wiederum dazu, dass einzelne Frames ausgelassen werden müssen und Animationen dadurch abgehackt wirken.

Ein weiterer Grund ist der neue Layout Editor, welcher seit Android Studio 2.2 verfügbar ist. Dieser ist für die Entwicklung mit dem CL abgestimmt und soll dadurch eine möglich intuitive und effiziente Entwicklung des UIs ermöglichen.

Wie verwende ich das ConstraintLayout mit Xamarin?

Neben dem Installieren des entsprechenden NuGet Packages (Preview), muss auch das entsprechende Packet aus dem Android Support Repository herunter geladen werden. Dazu öffnet man in Android Studio die Einstellungen und wählt unter “Android SDK” das Tab “SDK Tools” aus. Um eine Auswahl der verschiedenen Versionen zu erhalten, sollte man ebenfalls “Show Package Details” markieren. Anschliessend kann man die gewünschten Versionen herunterladen.

Android Studio SDK Einstellungen

Da zur Zeit für Xamarin erst die Version 1.0.0-alpha9 als NuGet Packet verfügbar ist, wurde in diesem Fall auch diese Version in den SDK Tools angewählt und heruntergeladen.

Nun kann das CL auch in einem Xamarin.Android Projekt verwendet werden. Allerding unterstütz der Xamarin UI Designer das CL gar noch nicht. Daher muss der Layout Editor von Android Studio verwendet werden. Wie man dies genau macht, wir  in einem früheren Blog Post beschrieben.

Ein Beispiel Projekt kann unter folgendem Link heruntergeladen werden. Öffnet man das darin vorhandene Main.xml Layout in Android Studio, sieht man zum einen die Vorschau des Layout sowie die Blueprint-Ansicht. In dieser hat man die Möglichkeit, die Constraints anzupassen. Auf der Android Developer Website ist ausführlich erklärt, wie man den Designer bedient.

Vorschau im Layout Editor von Android Studio

Fazit

Obwohl sich das CL noch in Beta-Version befindet bzw. die Xamarin Bindings gar in Alpha-Version, macht es bereits einen guten Eindruck. Daher macht es definitiv Sinn, wenn mach sich bereits jetzt schon damit auseinander setzt. In Kombination mit dem Layout Editor von Android Studio, hat das CL definitiv das Potenzial, die UI Entwicklung zu beschleunigen sowie das Level an ViewGroup Verschachtelungen zu verringern.

Während der Entwicklung einer App kann schnell das Bedürfnis aufkommen, dass man neben der eigentlichen Version der App auch eine Beta- oder Preview-Version erstellen möchte. So können zum Beispiel neue Features zuerst von Beta-Testern getestet werden, bevor diese in die öffentliche Version einfliessen.

In folgendem Beispiel wird gezeigt, wie man mit Hilfe einer zweiten Build Konfiguration eine zusätzliche Version einer App erstellt. Beide Versionen sollen den gleichen Source Code und dieselbe Solution verwenden. Trotzdem sollen sie sich aber in folgenden Punkten unterscheiden:

• Beide App Versionen sollen sich parallel installieren lassen und sich in ihrem Namen unterscheiden.
• Die App Icons sollen sich unterscheiden, damit man die beiden Apps leicht auseinanderhalten kann.
• Die Apps sollen je nach Version einen anderen API Endpoint Ansprechen.

Das fertiggestellte Beispiel ist hier abgelegt.

Zusätzliche Build Konfiguration erstellen

1. Als erstes muss eine neue Build Konfiguration erstellt werden. Dazu öffnet man den Configuration Manager der Solution.
2. Nun muss ein neuer Name eingegeben werden. Es ist sinnvoll die Einstellungen der bestehenden Release Konfiguration zu übernehmen.
3. Anschliessen ist oben in der Toolbar die neu erstellte Konfiguration auswählbar

Parallele Installation und unterschiedliche App Namen

Der Package Name ist ein eindeutiges Identifikationsmerkmal für eine App. Möchte man eine zweite App Version parallel installieren, so muss diese zwingend einen anderen Package Namen besitzen. Aus diesem Grund, erstellt man zuerst ein neues AndroidManifest und kopiert den Inhalt des bereits bestehenden Manifests hinein. In diesem Beispiel wird dieses AndroidManifest.Preview.xml genannt. Anschliessend kann der Packange Name sowie das Application Label angepasst werden.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.demo.app.preview" android:versionCode="1" android:versionName="1.0">
  <uses-sdk android:minSdkVersion="16" />
  <application android:label="My App (Preview) "></application>
</manifest>

Damit nun das neue Manifest auch verwendet wird, muss die neue Build Konfiguration im der .csproj Datei des Android Projektes angepasst werden (AndroidManifest Attribut):

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release_Preview|AnyCPU'">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\Release_Preview\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <Optimize>true</Optimize>
    <DebugType>pdbonly</DebugType>
    <PlatformTarget>AnyCPU</PlatformTarget>
    <GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies>
    <ErrorReport>prompt</ErrorReport>
    <CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
    <AndroidManifest>Properties\AndroidManifest.Preview.xml</AndroidManifest>
  </PropertyGroup>

Unterschiedliche App Icons

Damit man die beiden App Versionen auf einen Blick unterscheiden kann, ist es wünschenswert, dass diese unterschiedlichen Icons besitzen. Dazu passt man ebenfalls die csproj-Datei des Android Projektes an, sodass je nach Build Konfiguration ein unterschiedliches Icon verwendet wird. Damit die Datei trotz des unterschiedlichen Namens korrekt eingebunden wird, muss zusätzlich das LogicalName-Attribut verwendet werden.

<ItemGroup Condition="'$(Configuration)'!='Release_Preview'">
    <AndroidResource Include="Resources\drawable\Icon.png" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)'=='Release_Preview'">
<AndroidResource Include="Resources\drawable\Icon.preview.png">
  <LogicalName>drawable\Icon.png</LogicalName>
</AndroidResource>
</ItemGroup>

Man kann nun jeweils ein APK in der Release Konfiguration und in der Release Preview Konfiguration erstellen und beide APKs auf einem Android Smartphone installieren. Dabei sollten die beide Apps nun einen unterschiedlichen Namen sowie unterschiedliche Icons besitzen (siehe Screenshot).

Unterschiedliche API Endpoints ansprechen

Neben unterschiedlichen App-Namen und Icon ist es oft auch erforderlich, dass sich die Apps in anderen Belangen unterscheiden. Möglicherweise möchte man in der Beta-Version der App nicht den API Endpoint der produktiven Umgebung verwenden, sondern jener der Beta- oder Integrationsumgebung.

Eine Möglichkeit dies zu implementieren, kann unter anderem das Verwenden von Compiler-Anweisungen sein. Diese können jedoch schnell über mehrere Dateien verteilt sein und zu unübersichtlichem Code führen.

Eine andere Option ist das Verwenden von XML-Konfigurationsdateien. Dadurch liegen alle Konfigurationen an einem zentralen Ort. Ausserdem kann eine XML Datei relativ einfach innerhalb eines automatisierten Build Prozess mit Hilfe von Build Scripts angepasst werden und bietet daher zusätzliche Flexibilität, wenn man Continuous Integration einsetzt.

Um den zusätzliche Aufwand möglichst gering zu halten, werden in diesem Beispiel zwei XML-Konfigurationsdateien erstellt, welche als String-Ressourcen im Android Projekt abgelegt werden. Diese heissen Configuration.xml sowie Configuration.Preview.xml. Zusätzlich muss wiederum die csproj-Datei des Android Projektes angepasst werden:

<ItemGroup Condition="'$(Configuration)'!='Release_Preview'">
  <AndroidResource Include="Resources\values\Configuration.xml" />
  <AndroidResource Include="Resources\drawable\Icon.png" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)'=='Release_Preview'">
  <AndroidResource Include="Resources\values\Configuration.Preview.xml" />
  <AndroidResource Include="Resources\drawable\Icon.preview.png">
    <LogicalName>drawable\Icon.png</LogicalName>
  </AndroidResource>
</ItemGroup>

Anschliessend kann die Konfiguration auch im Code verfügbar gemacht werden, indeman eine zusätzliche eine Service-Klasse erstellt:

internal class AndroidDefaultConfiguration : IDefaultConfiguration
{
  public string ApiBaseUrl => Application.Context.GetString(Resource.String.ApiBaseUrl);
}

Fazit

Mit Hilfe einer zusätzliche Build Konfiguration kann man ohne grossen Aufwand eine zusätzliche Beta- oder Preview-Version einer App erstellen. Weiter kann das zusätzliche Einbinden einer XML-Konfigurationsdatei eine elegante Lösung sein, um zusätzliche Unterscheidungsmerkmale einfach zu implementieren.