Boehrsi.de - Blog

Morgen Abend ist es soweit und die diesjährige Google I/O startet. Ab 19 Uhr startet die Keynote und danach geht es auf acht Kanälen live weiter. Solltet ihr keine Zeit haben ist dies kein Problem. Alle Sessions werden danach, wie schon gewohnt, via Youtube verfügbar sein. Doch vor allem die Keynote ist mir immer mal wieder ein paar Stunden Live-Streaming wert. Ich werde das ganze gemeinsam mit Kollegen auf der Arbeit schauen und bin gespannt was es dieses Mal interessantes rund um Android, Firebase, Google Home und all die weiteren spannenden Google Themen geben wird. Ich denke es wird das eine oder andere zu erwartende geben, aber vielleicht auch ein paar Überraschungen. Alle nötigen Links gibt es in den Related Links.

• Google I/O Website open_in_new
• News zum Thema im Google Blog open_in_new

Android ist vielfältig und so auch die Carrier und Hersteller die die Geräte vertreiben und bauen. Damit man ein Gerät nutzen kann muss die Android-Software an die Hardware angepasst werden, durch Treiber und ähnliches. Anschließend kommen weitere Anpassungen vom konkreten Hersteller des Geräts hinzu und auch der Carrier packt oben drauf noch etwas Code. Alles in allem ist recht viel Arbeit nötig und dies ist vor allem bei Updates ein Problem. Denn sobald sich der Android Unterbau ändert müssen sehr viele Stellschrauben gedreht werden, bis alles wieder läuft. Dieser Aufwand ist teilweise hoch und zeitaufwendig, sodass dieser Punkt sicherlich bezüglich schlechter Updatepolitik eine gewisse Relevanz hat. Google will dagegen mit dem neuen Vendor Interface vorgehen, was mit Android O integriert wird. Es schafft eine Abstraktionsebene, sodass Vendor spezifischer Code bei einem Update quasi gar nicht mehr angefasst werden muss, denn die darunterliegende API kann weiterhin unverändert angesprochen werden. Im Prinzip tut man hier dasselbe was man schon für die App Entwickler tut. Denn sofern nicht umfangreiche Änderungen vorgenommen werden, kann man seine alte App bei der Veröffentlichung einer neuen Android Version auch ohne Probleme auf dieser nutzen. Kleinere Anpassungen sind natürlich weiterhin nötig und neue Features funktionieren natürlich auch nur nach Integration selbiger. Ich hoffe das Vendor Interface wird ein Erfolg und bringt etwas mehr Updates für uns alle und selbige vor allem schneller.

• Beitrag im Android Developer Blog zum Thema (englisch) open_in_new

Eines meiner größeren aktuellen Projekte ist eine Webplattform. Diese stellt eine API zur Verfügung und ist zusätzlich auch als Website verfügbar. Die API wird mittels einer Android und iOS App bedient. Das Ganze ist umfangreich, muss flexibel sein und eine gewisse Portion Sicherheit sollte auch an Bord sein. Dadurch das ich auf der Arbeit bereits Erfahrungen mit Spring Boot sammeln konnte, war dies auch meine erste Wahl für dieses Projekt. Ich hatte mich vorher zwar bezüglich Alternativen umgeschaut, aber Spring erschien mir am passendsten. Durch die umfangreiche Integration der Spring Tool Suite open_in_new in Eclipse ist letzteres auch meine erste Wahl für die Entwicklung von Spring Boot Projekten. IntelliJ Idea schließt zwar auf, doch diverse Kleinigkeiten, wie z.B. der automatische Neustart des Servers, Anzeige der Beans und diverse weitere Dinge, machen Eclipse hier etwas effektiver für mich. Ich schaue zwar immer wieder mal über den Tellerrand, aber die nahezu nahtlose Integration in Eclipse ist wirklich praktisch.

• Eclipse Homepage open_in_new
• IntelliJ IDEA Homepage open_in_new

Der Lifecycle einer Android App ist für Entwickler einer solchen kontinuierlich relevant. Soll heißen man muss immer wieder darauf achten wann man Aktionen durchführt. Dies gilt auch wenn man die eigentliche Logik, so wie es sein sollte, von der UI trennt. Denn die Eigenheiten des Android Systems sollten beachtet werden, sonst gibt es spätestens wenn Speichermangel herrscht und die App vom System weggeräumt wird Probleme beim erneuten Aufrufen. Allerdings gibt es nicht nur ein bis zwei Methoden die beachtet werden sollten, sondern diverse und diese unterscheiden sich auch noch für Activities und Fragments. Aus diesem Grund kann ich euch das GitHub Projekt android-lifecycle ans Herzen legen. Selbiges findet ihr in den Related Links. Es stellt bildlich und vor allem übersichtlich die Abläufe dar und erläutert die Zusammenhänge zusätzlich mit einigen wenigen Worten. Immer wieder hilfreich es als Tab offen zu haben oder vielleicht sogar in ausgedruckter Form.

• android-lifecycle GitHub Projekt open_in_new

Vektorgrafiken sind durchaus praktisch und vielseitig, denn sie lassen sich skalieren und anderweitig manipulieren, sodass sie bestens zu den Anforderungen von so mancher App passen. Solltet ihr nun, ähnlich wie ich, nicht für jede App neue Icons machen wollen und zusätzlich das Material Design Icon Set gut finden, dann solltet ihr unter Umständen weiterlesen. Denn vielleicht ist es noch nicht bei allen angekommen, dass man mit wenigen Klicks direkt in Android Studio besagtes Icon Set mittels eines Dialogs open_in_new durchsuchen und einbinden kann. Also keine manuelle Suche mehr auf der Material Icons Website open_in_new, mit anschließendem kopieren und anpassen. Ich selber nutze die Funktion seitdem ich sie entdeckt habe sehr umfangreich, denn ein einheitliches Icon Schema über diverse Android Apps hinweg, macht in meinem Kopf durchaus Sinn. Vor allem spart man sich mit dem integrierten Dialog aber einiges an überflüssiger Arbeit. Solltet ihr übrigens selbst Vektorgrafiken erstellt haben, so könnt ihr diese ebenfalls über den Dialog einbinden.

• Beitrag in der Android Studio Dokumentation zum Thema (englisch) open_in_new

Das Android Ökosystem ist eines der größten und diverse Anbieter arbeiten in diesem Bereich. Diverse Patente aus extrem vielen Bereichen gehören mit zu diesem Ökosystem und auch wenn man mit dem selben System arbeitet, so heißt dies nicht das man auch im Bereich Patente zusammenarbeitet. Denn auch wenn man gemeinsam neue Software und Hardware entwickelt, so möchte jeder für sich doch seinen Umsatz und vor allem Gewinn machen. Trotzdem haben sich nun unter anderem Google, Samsung, HTC und LG zusammengeschlossen und tauschen untereinander Android relevante Patente aus. Somit soll eine schnellere und bessere Weiterentwicklung stattfinden und Patentstreits in diesem Bereich sollen der Vergangenheit angehören. Ich hoffe die Gruppe erweitert sich noch weiter, denn auch wenn Patente durchaus ihre Berechtigung haben, sie sollten sinnvoll eingesetzt werden und Weiterentwicklungen nicht blockieren.

• Beitrag im Google Blog zum Thema (englisch) open_in_new

Während man eine Website baut kommt es hin und wieder vor das man Inhalte vertikal in einem Bereich zentrieren möchte. Dabei gibt es den Fall das Text zentriert werden soll oder aber Blockelemente. Für beide Fälle sind unterschiedliche Herangehensweisen nötig. Zusätzlich ist die Frage ob man die Größe der Elemente kennt und ob weitere Parameter relevant sind von Bedeutung. Je nach Fall baut man sich dann etwas auf, was mitunter eher wie ein Hack anmutet, als wie eine ordentliche Implementierung. Will man dann noch ältere Techniken unterstützen muss man noch einmal anders vorgehen. Diese ganzen Fälle, in einem übersichtlichen Formular welches am Ende Code ausspuckt, gibt es in den Related Links auf der Website howtocenterincss.com. Man wählt einfach alle zutreffenden Punkte aus und schon hat man ein Code-Snippet. Ich habe die Seite erst gestern genutzt und bin zufrieden.

• HowToCenterInCSS.com open_in_new

Der neue Jack Compiler sollte Dinge vereinfachen und Overhead vermeiden. Doch scheinbar hat man die Pläne geändert, denn vor einigen Tagen wurde entsprechendes im Android Developer Blog kundgetan. Man wird sich von Jack verabschieden und dafür wieder auf die alten Bekannten javac und dx setzen. Dort ist die Integration von neuen Funktionen und die entsprechende Unterstützung in Android Studio besser umsetzbar und vor allem komplexere Dinge wie Annotation Processors und ähnliches können somit ohne großen Aufwand weiter genutzt und erweitert werden. Angekündigt wurde das ganze schon vor 14 Tagen, somit kann man schon bald mit Anpassungen in Android Studio rechnen. Vielleicht wird die finale Version 2.4 schon mit den entsprechenden Änderungen beim Build Tooling ausgestattet sein.

• Beitrag im Android Developer Blog zum Thema (englisch) open_in_new

Obwohl erst vor kurzem Version 2.3 final erschien gibt es nun bereits drei Preview Versionen von Android Studio 2.4. Im Unterbau wurde auf eine neue IntelliJ Version (2017.1) aktualisiert und Instant Run erhielt weitere Fehlerbehebungen. Im Bereich Build-System wurde das Incremental Dexing verbessert und vor allem bei größeren Projekten sollte die Zeit welche fürs Konfigurieren benötigt wird nun geringer sein. Ein neuer Device File Explorer soll es dem Nutzer außerdem ermöglichen einfach und schnell direkt auf dem Gerät Dateien zu manipulieren. Die Preview 2 beinhaltete Fehlerbehebungen für den Updateprozess von Android Studio selbst und die Preview 3 brachte neben einige Bug-Fixes Support für die Android O Developer Preview open_in_new. Aktuell nutze ich noch die stabile Version 2.3, werde aber vermutlich im Laufe der Woche aktualisieren. Zusätzlich kann noch erwähnt werden das die Android Studio Seite überarbeitet wurde und vor allem die Informationen zu den Preview Versionen nun wesentlich ansehnlicher präsentiert werden.

• Android Studio Release Update News open_in_new
• Android Studio Preview Download open_in_new
• Android Studio Homepage open_in_new

Ich nutze viel und umfangreich Lombok, ein Tool welches massiv die Erstellung von Boilerplate Code minimiert. Doch leider hatte ich nach den letzten Aktualisierungen von Eclipse (Neon.3) einige Probleme. In einem umfangreichen Spring Boot Projekt, mit Gradle als Build-Tool, wurden die von Lombok generierten Klassen nicht gefunden, allerdings nur wenn ich direkt in Eclipse alles ausführte. Via Shell oder via Gradle Task aus Eclipse heraus gab es keine Probleme. Da ich mit einem Spring Boot Projekt arbeite und dementsprechend auch die entsprechende Tool Suite open_in_new nutze, war es mir aber durchaus wichtig, dass das direkte bauen und neustarten via Eclipse funktioniert. Somit habe ich gestern und heute sehr viel herumprobiert. Dies beinhaltete alles zu aktualisieren (Eclipse und alle Abhängigkeiten innerhalb des Projekts), den Workspace komplett neu zu erstellen und das GIT erneut zu klonen, Lombok neu zu installieren und Anpassungen an der eclipse.ini vorzunehmen. Letzteres brachte dann auch den Erfolg, denn so simple wie auch unnötig die Lösung erscheint, mir half nach all den oben genannten Schritten für den javaagent einen absoluten Pfad anzugeben. Dies gilt auch wenn Lombok direkt im Eclipse Verzeichnis liegt, denn -javaagent:lombok.jar funktionierte nicht -javaagent:C:\Path\To\Your\lombok\lombok.jar hingegen ohne Probleme. Ich bin mir nicht sicher ob einer der weiteren erwähnte Punkte mit zur Lösung beigetragen hat, deswegen habe ich sie zur Sicherheit mit aufgeführt, aber erst nach dem Umstellen auf einen absoluten Pfad funktionierte alles. Solltet ihr also ähnliche Probleme haben, versucht dies auch mal.

• Lombok Website open_in_new
• Via GitHub.com open_in_new