#rTsd – Road to Surface Duo, das Entwicklertagebuch: Teil 5

• Tobias Scholze
• 17. Januar 2020
• • teilen

Willkommen zum ersten Tagebuch-Eintrag im neuen Jahr! Das “Surface Duo Jahr” 2020 hat begonnen, also wird es Zeit, ein neues Kapitel aufzuschlagen. Für alle, denen diese Artikelreihe noch unbekannt ist – das habt ihr bislang verpasst, könnt euch aber natürlich nachträglich einlesen:

• #rTsd – Road to Surface Duo, das Entwicklertagebuch: Teil 1 (Idee, Motivation und Gestaltung)
• #rTsd – Road to Surface Duo, das Entwicklertagebuch: Teil 2 (Erste Schritte in C# und XAML)
• #rTsd – Road to Surface Duo, das Entwicklertagebuch: Teil 3 (Fragen und Antworten)
• #rTsd – Road to Surface Duo, das Entwicklertagebuch: Teil 4 (Service und Navigation)
• #rTsd – (aktuell) Road to Surface Duo, das Entwicklertagebuch: Teil 5 (Aufräumarbeiten)

Tl;dr, Neue Features in Kürze erklärt

Für alle Leser, die in Eile sind, hier ein Abriss der neuen Features der #rTsd-App in Kürze. Manche dieser Funktionen sind im folgenden Beitrag ausführlicher erklärt. Den aktuellen Quelltext hierzu findet ihr wie immer auf GitHub.

Twitter Ticker hinzugefügt: Oberhalb der Liste der neuen Beiträge befindet sich nun ein Ticker mit den letzten Twitterbeiträgen von @drwindows_de. Ein Tap darauf führt zum ausgewählten Tweet im Web.

Listeneinträge nun abwechselnd abgerundet: Die jeweiligen „Tränen“-Formen der Listeneinträge sind nun abwechselnd an den Ecken abgerundet.

XAML-Pages vereinfacht und aufgeteilt: Es gibt nun mehr eigenständige Controls, welche zwar die Anzahl an verschiedenen Dateien erhöht, jedoch die Komplexität in diesen stark senkt.

Android-spezifische Werte gesetzt: Die App verfügt nun über sinn ergebende, für Android spezifische Einstellungen wie einen passenden Applikations- und Paketnamen.

Verbesserte Namensgebungen: Mit etwas Abstand sieht man oft, welche Klassen zu komplex oder irreführend benannt wurden. Diese wurden nun gerade gezogen als auch auf das Wichtigste reduziert.

Tickerndes Twitter

Um noch eine weitere Nachrichtenquelle als nur den RSS-Feed anzeigen zu können, sind nun auch in einer kleinen Zeile oberhalb der Listenansicht aller Beiträge die letzten Tweets des @drwindows_de Twitter Accounts ablesbar. Da ich für diese keine eigene platzfüllende Liste haben wollte ist dies als automatisch durchlaufender Ticker realisiert.

Twitter macht es immer schwerer, den Stream eines Accounts via API abzugreifen. Vor allem wollte ich bei dieser leicht nachzuprogrammierenden Community-App nicht mit personenbezogenen API-Token und Co hantieren.

Die erste Alternative war das Parsen der Webseite, was aber zu einer sehr stark over-engineered Implementation geführt hätte. Durch Zufall stieß ich auf den Dienst twitrss.me, welcher allein über einen Zusatz in der URL aus dem Twitter-Stream einen schönen und leicht handzuhabenden RSS-Feed macht. Hierzu muss ich sagen, dass ich solche undurchsichtigen Mittelsmanndienstleister in produktiven Umgebungen nicht einsetzen würde – für unser kleines Hobbyprojekt kam der Service jedoch genau zur richtigen Zeit. Der in der App hierfür hinterlegte Service ist der TwitRssService und befüllt Models vom Typ Tweet.

Spannend an der Umsetzung war jedoch das automatische und endlose „Tickern“ der Liste. Sie sollte nicht nur einmal durchlaufen, sondern nach dem letzten Tweet einfach wieder von vorne beginnen. Unter iOS ist dies einfach abgreifbar, unter Xamarin war dies anfangs etwas kompliziert mit diversen Command-Bindings.

Schlussendlich entschied ich mich, den Ticker in eine extra ContentPage (Docs) aka Custom Control zu packen. In diesem in sich abgeschlossenen Bereich stoße ich direkt in der C# Code-Behind-Datei zur Page mittels einem Timer (Docs) eine Aktualisierung des ausgewählten Items an. Ganz ohne MVVM.

Die Logik für einen Endlosticker ist einfach, da sich hier der Index simpel über eine Modulo-Operation mit dem aktuellen Index als auch der Gesamtzahl aller Tweets, welche dargestellt werden, berechnet.

Die Krux an dieser Berechnung ist, dass ich die Tweets in der abgekapselten ContentPage nur aus der ItemSource der CarouselView (Docs) herleiten kann. Diese ist vom Typ IEnumerable (Docs), welche anders als bei Listen keine „Count“ Property besitzt. Jedes Mal diese über den Iterator zu berechnen, fand ich zu rechenaufwändig. So gebe ich diese nun, in meinen Augen unschön, von außen herein und nutze dazu eine selbst erstellte Bindable Property (Docs).

Alternierend abgerundet

Schon von Anfang an wollte ich, dass die Einträge in der Listenansicht nicht alle gleich abgerundete Ecken haben. Dieses Feature umzusetzen stellte sich für mich jedoch schwerer dar, als ich es mir zu Beginn ausgemalt habe.

Unter iOS, dem Entwicklungsökosystem, mit dem ich tagsüber mein Geld verdiene, habe ich vollen Zugriff auf den zum jeweiligen Zeitpunkt zu erstellenden Listeneintrag. Inklusive Index des jeweilig unter dem Eintrag liegenden Datenmodells als auch generell der Datenquelle als Liste oder Array.

Für die #rTsd-App musste ich, da ich keinen solch bequemen Zugriff habe, über einen eigens implementierten DataTemplateSelector (Docs, Quelltext) gehen, um entweder ein DataTemplate (Docs) für gerade oder ungerade Index (x % 2 == 0) der CollectionView (Docs) unterzuschieben.

Dieses Stück Quelltext steht auf meiner Liste der Elemente, welche ich stark überarbeiten möchte, wenn ich mehr Tiefenverständnis von Xamarin und XAML aufgebaut habe. Wir sind ja schließlich alle noch Anfänger. So oder so, es tut was es soll, wenn auch nicht auf dem idealen Weg realisiert.

Weniger komplexe Pages für bessere Übersicht

All diese Schritte bedingten neben einer Vereinfachung mancher XAML-Pages wie die für die Listenansicht auch die Aufsplittung in, in sich geschlossene, kleinere Controls (ContentPages) welche die ViewModels der eigentlichen Seiten entschlackten.

Durch die Vereinfachung fielen auch etliche Klassen weg. So spare ich mir deswegen im Moment eigene Event-Argumente für die CarouselView.

Wie geht es weiter?

Ich dachte ja schon im letzten Tagebucheintrag, dass die App „fertig“ ist, bis mehr konkrete Informationen über das Microsoft Surface Duo und die Entwicklung dafür vorliegen. Laut einem letztjährigen Blogbeitrag von Microsoft sollten diese schon bald im E-Mail-Posteingang aufschlagen. Aus diesem Grunde gehe ich davon aus, dass die gerätespezifische Anpassung der nächste größere Aufgabenbereich für die #rTsd-App sein wird.

Was wünscht ihr euch?

Gibt es ein Thema, ein Feature oder offene Fragen, welche ihr gern behandelt hättet? Schreibt diese einfach in die Kommentare und lasst uns dort das weitere Vorgehen miteinander zusammen erarbeiten. Ich freue mich wirklich, ein Teil dieser spannenden Dr. Windows Community sein zu können.

• Thema:

• News

Über den Autor

Tobias Scholze

Bayrischer Open Source- und Community-Enthusiast, Verfechter des neuen Microsoft und Wandler zwischen den Betriebssystemwelten. #communityrocks Von Herzen ein Nerd mit der festen Überzeugung, dass man gemeinsam und durch den Einsatz von moderner IT die Welt für jeden ein Stückchen besser machen kann.