Boehrsi.de - Blog

Im Rahmen meines BoehrsiTweetHub Projekts stolperte ich über das Problem, dass unter Windows gebaute Dart Binaries nicht unter Linux ausgeführt werden können. Diese Problematik ist auch auf GitHub als Issue open_in_new festgehalten und ich finde es spannend das ich darüber nicht schon viel früher gestolpert bin. Doch glücklicherweise war es trotz dessen durchaus einfach die gewünschte Binary zu erzeugen. Einen kleinen Guide findet ihr im unteren Teil der News. Sofern ihr Fragen, Ergänzungen oder ähnliches habt, meldet euch gerne in den Kommentaren.

Ende des letzten Monats erhielt ich die Information das IFTTT open_in_new leider die Twitter Integration für kostenlose Accounts deaktiviert. Ein Grund dafür dürfte sicherlich sein das die Twitter API selbst nun kostenpflichtig ist, sobald eine größere Anzahl an Requests benötigt wird. Was auch immer der konkrete Hintergrund dieser Entscheidung ist, für mich war klar das ein kostenpflichtiger Account nicht in Frage kommt. Denn auch wenn ich meine Blog Beiträge gerne via Twitter weiterleite, so ist meine Reichweite dort durchaus beschränkt und dafür Geld zu bezahlen würde sich einfach nicht lohnen.
Allerdings bin ich nun mal Softwareentwickler, habe einen Server und falls mal etwas nicht funktioniert überlege ich natürlich selber eine Lösung zu entwickeln. Schnell gedacht und tatsächlich auch schnell gemacht, denn am letzten Wochenende implementierte ich meine eigene Twitter Posting Lösung. Selbige unterstützt neben konfigurierbaren RSS Feeds nun auch GitHub Releases.

• BoehrsiTweetHub Projektseite open_in_new

Bereits Ende letzten Jahres wollte ich mein kleines Gewinnspiel Tool Raffle Companion für die Allgemeinheit verfügbar machen, doch wir wissen ja alles wie gut Pläne manchmal funktionieren. Nun hat es aber endlich geklappt und meine erste Windows App ist im Microsoft Store verfügbar open_in_new. Warum im Microsoft Store kann man nun fragen. Die Antwort ist relativ einfach, denn auf diesem Weg erhalte ich eine sichere, signierte und installierbare Version meines Tools, ohne umfangreiche jährliche Kosten für Zertifikate. Außerdem ist es einfach die App zu installieren und zu verwalten. Ich werde für die nächsten Releases prüfen ob ich zusätzlich ein simples ZIP Archiv anbieten kann, welches dann z.B. via GitHub verfügbar ist.

• Raffle Companion Projektseite open_in_new
• Raffle Companion im Microsoft Store open_in_new

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.