Boehrsi.de - Blog

Es ist mal wieder Zeit für neue Versionen meiner Device Marketing Names Libraries für Android und Flutter. Die heute neu erschienenen Versionen (Dart / Flutter Version 0.6.5 open_in_new und Kotlin Version 0.4.4 open_in_new) bringen eine frische Gerätedatenbank, Aktualisierungen der Abhängigkeiten und kleinere Anpassungen mit sich. Die Gerätedatenbank stammt wie immer von meinem Device Identifiers Tool, welches ebenfalls vor kurzem aktualisiert wurde. Es hat im Rahmen des 0.5.0 Releases einige Build Optimierungen und Aktualisierungen von Abhängigkeiten erhalten.
Die Installation der jeweiligen Updates sollte unkritisch sein und unkompliziert von statten gehen. Wer sich genauer informieren will, kann dies wie immer direkt in den jeweiligen GitHub Repositories tun. Folgt dafür einfach wie gewohnt den Related Links. Falls es Fragen gibt können selbige gerne direkt hier in den Kommentaren gestellt werden.

• Device Marketing Names - Dart / Flutter Projektseite open_in_new
• Device Marketing Names - Dart / Flutter auf pub.dev open_in_new
• Device Marketing Names - Kotlin Projektseite open_in_new
• Device Marketing Names - Kotlin auf Maven Central open_in_new
• Device Identifiers Projektseite open_in_new

Die Art und Weise wie man Android Apps entwickelt hat sich in den letzten Jahren durchaus verändert. Es gibt eine große Anzahl an alten APIs und Konzepten, welche sich über die Jahre weiterentwickelt haben und entsprechend muss Google sowohl den Support der alten Geräte, aber auch die Weiterentwicklung der Plattform selbst balancieren. Hier wurde in den letzten Jahren vieles grundlegend neu gestaltet, z.B. mit den Jetpack / AndroidX open_in_new Bibliotheken, die die alten Support Libraries ersetzen oder auch mit Kotlin open_in_new statt Java als Hauptsprache und natürlich auch mit Compose open_in_new als frisches UI Framework.
Meiner Meinung nach wurde hier sehr viel sehr richtig gemacht und das ohne das Nutzer alter Geräte permanent auf der Strecke bleiben. Doch nun stellt sich die Frage, ob man bei derart vielen Neuerungen es schafft am Ball zu bleiben. Damit diese Frage mit ja beantwortet werden kann gibt es die Modern Android Development Webseite von Google. Hier findet ihr einen Überblick zu allem was neu ist, allem was als Best Practice angesehen werden kann und generell allem was modern und interessant ist. Sofern ihr also im Kontext der Android Entwicklung unterwegs seid, schaut doch mal dort vorbei. Den Link und entsprechend alle weiteren Informationen gibt es in den Related Links.

• Modern Android Development open_in_new

Heute geht es weiter mit meinem zweiten Game Devlog. Dieses Mal geht es um meine ersten Versuche Dinge umzusetzen und auszuprobieren. Dabei liegt der Fokus vor allem auf meinem initial genutzen Tooling. In der ersten Jahreshälfte 2022 erstellte ich Mockups und versuchte meine vage Idee zu konkretisieren. Dabei arbeitete ich viel analog, einfach auf Papier. Grund dafür war vor allem die Flexibilität ohne Tooling schnell Kleinigkeiten zu visualisieren. Später wechselte ich auf mein gutes altes Rocket Book open_in_new, denn hier habe ich die Freiheit analog zeichnen und schreiben zu können, kann aber gleichzeitig alles schnell und einfach digitalisieren.

• Projekt Space im Projektebereich open_in_new

Als Android Entwickler ist mir die Android Platform natürlich wichtig, denn sie ist die Basis für meine Entwicklungen und das sowohl für meine privaten, wie auch für meine beruflichen Projekte. Entsprechend bin ich der Meinung man sollte jede mögliche Art des Feedbacks nutzen, um eine positive Entwicklung der Platform zu unterstützen. Selbiges ist gerade mal wieder möglich, denn im Rahmen des Android Developer Survey 2023 geht es mal wieder darum Feedback zu sammeln, Schwerpunkte festzulegen und die generelle Stimmung zu erfassen. Sofern ihr euch in der Android Entwickler Welt bewegt, ist es vielleicht keine schlechte Idee die 10 bis 15 Minuten zu investieren. Ich habe selbiges bereits getan.

• Android Developer Survey 2023 open_in_new

In wenigen Stunden geht es los, die Google I/O steht vor der Tür. Heute um 19:00 Uhr startet Googles Event, welches erwartungsgemäß neue Android und Pixel Informationen hervorbringen wird. Ebenfalls ein ein relevantes Thema dürfte AI werden.
Neben generellen spannenden Neuigkeiten, gibt es natürlich auch wieder Sessions und Workshops für Entwickler. Egal ob Mobile, Web, AI oder Cloud, in allen Bereichen gibt es frische Inhalte, welche ihr live oder später via Youtube anschauen könnt. Folgt einfach den Related Links und stellt euch euer I/O Programm zusammen.
Ich werde das Event vermutlich nicht direkt live schauen können, da es einen terminlichen Konflikt gibt, aber vor allem die Keynotes werde ich sehr zeitnah nachholen. Ich freue mich vor allem auf neue Android und Flutter Ankündigungen, aber das Thema AI geht natürlich auch an mir nicht vorbei.

• Google I/O Website open_in_new
• Google I/O Programm open_in_new

In den letzten Tagen habe ich meine geplanten monatlichen Updates für meine Device Marketing Names Libraries vorbereitet. Nach etwas mehr Arbeit als gedacht konnte ich selbige nun online stellen und somit sind Version 0.6.3 open_in_new Device Marketing Names - Dart / Flutter und Version 0.4.3 open_in_new Device Marketing Names - Kotlin verfügbar.
Im Dart / Flutter Bereich gab es die gewohnten Updates von Abhängigkeiten und natürlich einen frischen Datensatz, welcher von meinem Device Identifiers Tool geliefert wird.
Die Kotlin Library war dieses Mal etwas mehr Aufwand, da sich mit Gradle 8 open_in_new und dem Android Gradle plugin (AGP) 8 open_in_new einige Dinge geändert haben. Durch diese Breaking Changes musste ich unter anderem die Einbindung von Jacoco open_in_new für die Auswertung der Tests umbauen und auch der Release Flow, welcher über das maven-publish Plugin realisiert wird, musste angepasst werden. Auch wenn das Ganze etwas aufwendiger war als gedacht, kann ich nun direkt auf das offizielle Jacoco Plugin setzen, der Release Flow wurde vereinfacht und einige Stellen im Code sind nun besser strukturiert. Diese Änderungen sollten sich für Nutzer der Library nicht bemerkbar machen, hier dürfte lediglich der aktualisierte Datensatz sichtbar werden.

• Device Marketing Names - Dart / Flutter Projektseite open_in_new
• Device Marketing Names - Dart / Flutter auf pub.dev open_in_new
• Device Marketing Names - Kotlin Projektseite open_in_new
• Device Marketing Names - Kotlin auf Maven Central open_in_new
• Device Identifiers Projektseite open_in_new

Ich bin durchaus ein Freund von Tests in der Softwareentwicklung, auch wenn ich sie ehrlicherweise zu selten nutze. Für mich persönlich ist wichtig wie und wofür man Tests einsetzt, denn einige Arten sind meiner Meinung nach nicht unbedingt das Gelbe vom Ei. Doch über das generelle für und wieder von verschiedenen Testarten möchte ich an dieser Stelle nicht sprechen, denn dafür bräuchte man eine komplette News-Sammlungen und würde vermutlich trotzdem die Hälfte nicht ausreichend betrachten.
Heute möchte ich auf einen Punkt eingehen der alle Arten von Tests mitunter extrem weniger relevant machen kann. Das Thema ist die Unzuverlässigkeit von Testergebnissen. Also Tests die manchmal funktionieren und dann doch wieder nicht und insofern bei der Auswertung unklare Ergebnisse generieren. Diese False Positives und False Negatives sorgen im Laufe der Zeit dafür, dass die Ergebnisse immer weniger ernst genommen werden und somit das Risiko besteht valide Probleme nicht zu erkennen.
Das Risiko derartiger Probleme ist sehr unterschiedlich und stark abhängig von der Art der Tests. Bei Unit Tests dürften solche Probleme eher selten auftreten, da man hier ja in sich geschlossene und lokale Funktionen testen soll. So umfangreicher der Test Flow, so problematischer wird das Ganze allerdings. Auch die Menge an externen Tools und involvierter Software und Hardware beeinflusst die Häufigkeit dieser Problematik maßgeblich. Wenn also Unit Tests eher selten Probleme in diesem Bereich haben, sind End to End Tests oder UI Tests eher anfällig für selbige.

Vor einiger Zeit beschrieb ich meinen relativ simplen, aber durchaus praktischen Umgang mit Checklisten. Diese Listen nutze ich nun seit mehr als einem Jahr für die Releases meiner Libraries im Android und Flutter Bereich und auch für App Releases.
Während ich einige meiner Libraries fast monatlich aktualisiere und somit “im Flow bin”, sind vor allem App Releases seltener. Insbesondere hier helfen mir die Checklisten nichts zu vergessen und sie machen mich sogar schneller, da ich einem roten Faden folgen kann. Zuletzt habe ich das beim Release der aktuellen Version der Tessa App gemerkt.

Generell ist es meiner Meinung nach hier egal welches Tooling man nutzt, wichtig ist etwas zu finden was sich schnell und einfach in die eigenen Flows integriert und dadurch eine Hilfestellung zu Abläufen und dem Fortschritt bietet. Denn dann ist eine Checkliste keine zusätzliche Arbeit, obwohl man sie ja pflegen muss, sondern eine nützliche Hilfestellung.
Falls ihr wiederkehrende komplexere Aufgaben habt, kann ich euch nur empfehlen mal einen Blick auf das Thema Checklisten zu werfen. Egal ob Softwareentwicklung, Server-Wartung oder Backups, ein roter Faden hat noch keinem geschadet und ein paar Haken sind wirklich schnell gesetzt. Solltet ihr bereits Checklisten einsetzen, würde mich euer Tooling und eure Herangehensweise sehr interessieren und über Kommentare würde ich mich sehr freuen.

Vor wenigen Stunden gab es mal wieder ein geplantes Update für die Tessa App. Ich versuche aktuell meinen „ein mal pro Quartal„ Release-Zyklus einzuhalten und bis dato funktioniert dies meist ganz gut.
Update 2.2.0 bringt ein überarbeitetes User Interface im Kontaktbereich und einen dedizierten Eintrag für die Statistik in der Hauptnavigation. Zuvor war der Statistik-Bereich nur indirekt erreichbar, was meiner Meinung nach eher unpraktisch war. Damit einher geht eine Änderung in der Kalenderansicht, welche die Anzeige der primären Aktivitätskategorie des jeweiligen Monats besser hervorhebt und dem Nutzer die Möglichkeit gibt schnell die dazugehörigen Aktivitäten zu überfliegen. Ebenfalls neu ist die Möglichkeit lokale Backups zu erstellen. Zuvor war es möglich seine Backups z.B. an Google Drive zu senden, was weiterhin eine Option ist, nun kann allerdings auch ein lokaler Geräteordner gewählt werden.

• Tessa - Reit-Assistent bei Google Play open_in_new
• Tessa - Reit-Assistent im Projektebereich open_in_new
• Tessa - Reit-Assitent Webseite open_in_new

Heute gibt es mal wieder ein kleines Update für meinen Blog, denn es hatte sich ein Fehler bei den Empfehlungen eingeschlichen. Das Resultat von selbigem war die fehlerhafte Anzeige der Übersicht aller Empfehlungen. Das Problem ist behoben, verschiedene weitere kleine Updates im Hintergrund wurden vorgenommen und alles sollte wieder ordnungsgemäß funktionieren. Sofern ihr Fehler findet, Anregungen habt oder einfach Feedback geben wollt, meldet euch gerne in den Kommentaren.