Schlagwort: Apps

Ende des Semesters an der TH Bingen

Letzten Donnerstag haben die Studenten meiner Blockveranstaltung zur Entwicklung von plattformneutralen Apps an der TH Bingen ihre Praxisarbeiten vorgestellt. Von den ursprünglich gut 25 – 30 Studenten waren am Ende der Remote-Blockveranstaltung über 6 Tage zu Beginn des Semesters noch so etwa 15 – 20 übrig, von denen etwa ein Duzend dann auch das Projekt abgegeben und in einer Teams-Sitzung vorgestellt haben. Zum Teil haben mich die Apps richtig beeindruckt.

Heute stelle ich noch die Bewertungen ein, schreibe meine Abrechnung und dann ist auch für mich meine Semester an der TH Bingen beendet. Mal sehen, ob ich diese Veranstaltung in den kommenden Semestern noch einmal halte, denn die Basis Cordova fällt so langsam ein bisschen aus der Zeit – auch wenn die verwendeten Webtechnologien und das Cordova-API einwandfrei funktionieren. Aber auch die Fachbereiche an der TH Bingen werden umstrukturiert und Mobile Computing, wo diese Veranstaltung bisher untergebracht war, wird in die „normale“ Informatik eingegliedert. Aber ich würde schon gerne wieder an der Hochschule eine Vorlesung halten – bis auf die extreme Bürokratie und maximal rückständige Verwaltung macht das immer wieder Spass.

Cordova-Vorlesung an der TH-Bingen

Seit Montag läuft meine Blockveranstaltung zur Entwicklung von plattformneutralen Apps an der TH Bingen. Remote und zu Beginn als Blockveranstaltung über 6 Tage mit ein paar Fragestunden über das Semester und am Ende im Juli einer Vorstellung der Semesterarbeit durch die Studis. Als Basis verwende ich wieder Cordova – auch wenn dessen „Aktualität“ bzw. Verbreitung etwas angekratzt ist. Aber man kann viel daran lernen und es funktioniert. Der Fokus liegt ja sowieso an den verwendeten Webtechnologien und dem Cordova-API.

Was ein Gefuddel für Android

Nachdem mir die Raspberry PIs als auch vergleichbare Platinen im Moment einfach zu teuer sind, habe ich mich daran gemacht, ein uraltes Notebook, dass ich vor einigen Monaten mit Deepin Linux neu eingerichtet habe, für die Cordova-Entwicklung einzurichten. Das ist zwar fertig, liegt aber sowieso da rum und einen Test war es mir wert.

Im Grunde geht das Einrichten von Cordova ja auch recht einfach, wenn es nicht die elenden Fallen geben würde.
Einmal ist da im Fall von Android das Problem mit der Java-Version. So richtig geht es – falls man für Android die App erstellen will – nur mit Java 8 bzw. dem JDK 8. Das Problem habe ich schon vor gefühlten Ewigkeiten bemerkt und mir immer damit geholfen, dass ich eben Java 8 installiert habe. Neben den aktuellen Versionen. Leider ist es dann aber blöde, weil man für Gradle-Skripte (zumindest die vorgefertigten von Cordova) die Default-Version von Java auch auf eben dieses Java 8 umstellen muss. Das geht in Linux (Debian, Ubuntu, Mint und Derivate) so:

sudo update-alternatives --config java

In der Folge kann man zwischen den installierten Java-Versionen auswählen und eine davon zur Default-Version machen. Aber dann muss man dann auch noch JAVA_HOME korrekt setzen. Etwa so:

env JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

oder

export JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

Ging unter Deepin als normaler User, aber komischer Weise hat das als root nicht funktioniert bzw. die Einstellungen wurden nicht übernommen. Letztendlich habe ich viel rumgebastelt, wieder viel gelernt, bin aber wie so oft im Grunde gescheitert.
Wobei das Problem mit Java 8 ist vermutlich ein ganz anderes, als man vermutet. Denn vor einigen Monaten hatte ich eine Schulung rund um Java EE gehalten und da hatten wir bei JSF ein ähnliches Problem. Die Meldung sah so aus als wäre die Version von Java nicht passend bzw. zu alt, obwohl sie neuer als die geforderte/angezeigte Version war. Ganz wie hier bei Cordova. Aber dann ist mir aufgefallen, dass die Versionsnummern in dem Framework nur einstellig (!) evaluiert wurden. Also Java 11 oder Java 17 werden als Java 1 interpretiert. So was vermute ich mittlerweile auch bei Cordova bzw. den Gradle-Skripten. Man müsste es mal mit Java 9 testen, aber dazu habe ich im Moment keine Zeit.
Letztendlich ist aber sowieso das Hauptproblem dieses elende Android-Gefuddel. Das Android-SDK und die Android-Tools etc. habe ich nach und nach alle installiert, aber ständig kam die Meldung, dass das Zeug nicht da wäre. Genaugenommen hat das Gradle-Skript diese Meldung gebracht. Letztendlich habe ich sogar das Android Studio auf dem uralten Notebook mit Deepin installiert, dort diverse Fernzugriffservice eingerichtet und gestartet, alle möglichen SDK-Versionen nachinstalliert und sogar ein Cordova-Template im Android Studio als Plugin eingerichtet.
Resultat – das Gradle-Skript weigert sich, die Android-Ressourcen zu finden. Und selbst das Android Studio nimmt dieses Gradle-Skript und kennt sich quasi dann selbst nicht mehr.

Irgendwann hatte ich die Faxen dicke, denn so schön Deepin Linux von der Oberfläche auch ist – es hat so ein paar Macken, die ich von der administrativen Seite nicht wirklich gut finde. Und der VNC- als auch RDP-Zugriff haben darauf ums Verrecken nicht funktioniert. Nur ssh – auch mit X-Umleitung von einem anderen Linux-Rechner.
Apropos anderer Linux-Rechner – das ist mein Terra-Notebook, auf dem ich Windows 10 und Mint Linux im Dualboot betreibe. Unter Windows habe ich das Cordova (auch für Android) mit Visual Studio 2017 im Griff (und im Prinzip auch mit dem Android Studio – das macht aber keinen Spass). Die Linux-Version kann ich aber seit Monaten nicht mehr aktualisieren oder da ein Programm installieren. Die Sache hier war für mich der Anlass, dass Problem mal anzugehen. Denn egal was ich probiert habe die letzte Zeit – mit der Fehlermeldung, dass die Quellen nicht zu lesen wären, haben sämtliche Aktualisierungsversuche als auch Installationsversuche abgebrochen.
Ich bin nun auf den Lösungsansatz gestoßen, dass man die Datei mit einem geeigneten Repo füllen sollte. Etwa das:

sudo nano /etc/apt/sources.list
deb http://de.archive.ubuntu.com/ubuntu bionic main restricted

Habe ich gemacht – keine Wirkung!
Dann habe ich endlich die Meldung genauer angesehen – Linux hat nicht die Datei /etc/apt/sources.list beim Installieren/Aktualisieren ausgelesen, sondern die Datei /etc/apt/sources.list.d/vivaldi.list.
Aus irgendeinem Grund wurde der Pfad umgebogen. Wo genau, habe ich noch nicht raus, aber einfach das Repo da reingeschrieben. Und gut ist es – aktualisieren und installieren geht wieder.
Jetzt kann ich auch mal den Linux-Rechner nutzen und versuchen, da Cordova-Apps für Android zu kompilieren. Wenn das auch da nicht geht, habe ich ja immer noch Visual Studio 2017 und meinen Docker-Container.

Und so ganz unwahrscheinlich ist es nicht, dass ich darauf beschränkt bleibe. Denn bei dem Mint-Linux ist node.js und damit auch npm in einer alten Version dabei. Was nicht schlimm wäre, wenn nicht jede Art der Installation, die ich versucht habe, immer diese uralte Version 8 installiert hätte. Mit apt bzw. apt-get entfernt, neu installiert, andere Quellen genommen, verschiedene Package-Manager ausprobiert -> immer die Version 8, obwohl es schon die Version 18 gibt. Ein Problem führt bei den ganzen Aktionen – wie eigentlich immer – zum nächsten.

Ich bin jetzt auf das Level zurückgegangen, dass ich die Quellcodes von Git geholt und dann bei mir neu kompiliert und installiert habe.

Also klassisch

git clone https://github.com/joyent/node.git

Und dann:

./configure
make
make install

Dazu gibt es im Netz eine ziemlich gute Anleitung.

Der kleine Hinweis dort, dass das Kompilieren ein „bisschen länger“ dauert, war aber untertrieben. Ich bin mit der Erwartung von vielleicht 30 Minuten maximal in den make-Befehl rein und nach gut 5 Stunden war noch kein Ende zu sehen. Das Zeug ist dann über Nacht durchgelaufen und heute morgen war es erledigt. Das dauert also brutal lang, wobei mein Terra-Notebook auch schon in die Jahre gekommen ist.

Anyway – die Sache ging durch und nun habe ich node.js bzw. npm in der Version 18. Cordova ist damit auch eben fix installiert und wie es mit Android aussieht, schaue ich mir später an. Das ist ja die einzige kritische Stelle.

 

Vorteile und Graus der Virtualisierung – Docker & Co

Cordova

Da ich für das kommende Sommersemester an der Technischen Hochschule Bingen wieder einen Lehrauftrag zum Thema Cordova und plattformneutrale App-Entwicklung angenommen und gerade Zeit für die Vorbereitung habe, habe ich die letzten Tage in den aktuellen Stand von Cordova reingeschaut und meine alten Projekte und Matrialien zusammengetragen. Ich hatte dieses Thema eine ganze Weile schleifen lassen, da Python, Big Data, Web-Programmierung, Cobol, C# & „Was auch sonst immer“ die Arbeit in eine andere Richtung gelenkt hatten.

Die meisten Dinge, die ich die vergangenen Jahre zusammengestellt und programmiert habe, sind jedoch noch weitgehend auf Stand. Allerdings haben sich auch durchaus Sachen geändert. Daher bedarf die neue Vorlesung einiger Vorbereitung und eine Anpassung.

Zudem habe ich auch ganz einfach Lust, meine ganzen Apps zu aktualisieren. Parallel will ich aus einigen Apps  Python-Programme machen. Ohne konkrete Ziele, aber vielleicht kommen mir dabei ein paar neue Ideen und ich lerne natürlich was dazu – auch wenn das im Grunde aktuell ein reines Programmieren aufgrund von Zeit und Lust darstellt.

Anyway – bei Cordova gibt es ein paar Sachen, die mich schon stutzig gemacht und zu einigen Arbeiten im Hintergrund sowie grundsätzlichen Überlegungen genötigt haben. Das reine Installieren der neuen Version von Cordova mit npm geht wie gehabt und das Erstellen von Cordova-Projekten in dem Cordova-CLI auch. Ebenso das Hinzufügen der verschiedenen Plattformen und das Ausführen in dem Browser-Emulator ist unverändert. Die eigentlichen Quellcodes auf Basis von JavaScript & Co sowieso.

Aber wenn man etwa beim konkreten Kompilieren Android als Plattform für die Cordova-Apps haben will, wird das JDK 8 vorausgesetzt. Im Moment ist aber schon das JDK 15 aktuell und damit funktioniert es nicht. Zumindest bekomme ich es im Moment nicht hin, mit der derzeit aktuellen Java-Version Android-Apps zu erstellen. Ehrlich gesagt ist mir nicht einmal klar, ob das an Android (da soll ja Java auch sukzessive abgelöst werden) oder Cordova liegt. Wie angedeutet, habe ich die App-Entwicklung eine Weile aus den Augen verloren.

Und dann hatte ich das Android Studio bzw. das Android SDK als auch Xcode komplett von meinen Rechnern gelöscht, da ich eben das Entwickeln für Android und iOS die letzte Zeit nicht gebraucht hatte. Zumal ich mich sowieso auch dabei auf das Visual Studio committed hatte. Dabei kann man ja wunderbar auch Android- bzw. iOS-Apps erstellen.

Aber um die verschiedenen Möglichkeiten im Vorfeld der Vorlesung mal wieder auszutesten, werde ich auf meinem Mac vermutlich Xcode neu installieren (wenn ich die Sache mit meiner Apple-ID geklärt habe – die habe ich auslaufen lassen) und das Android Studio habe ich mittlerweile wieder neu installiert.

Aber irgendwie hat es bei meinem ersten naiven Versuch nicht funktioniert, damit Cordova-Projekte zu öffnen – oder besser –  zum Laufen zu bringen. Irgendwie mag ich das Android Studio aber auch nicht wirklich. Ich sollte der Sache zwar auf den Grund gehen, aber ich werde ja sowieso Visual Studio nehmen.

Wobei es da auch ein seltsames Problem gibt. In Visual Studio 2019 ist die Erweiterung für Cordova nicht mehr dabei und damit kann man weder Cordova-Projekte anlegen noch vorhandene Cordova-Projekte öffnen. Also musste ich die schon gelöschte Version 2017 von Visual Studio mit der Cordova-Erweiterung wieder auf meine Rechner aufspielen. Damit geht aber alles wunderbar und ich habe mittlerweile diverse Cordova-Apps erstellt, aus Visual Studio in verschiedenen Emulatoren sowie per USB-Debugging sogar direkt auf mehreren Geräten ausgeführt. Auch die Installation auf ein paar Testgeräten funktioniert problemlos. Seltsam sind die Begleiterscheinungen jedoch schon und ich bin nicht sicher, ob Cordova noch lange auf dem Markt bleibt. Was Cordova aber nicht als gute Basis für die kommende Vorlesung diskreditiert, um grundsätzlich die Erstellung von plattformneutralen Apps auf Basis von Webtechnologien zu lernen. Denn im Umfeld von Xamarin sind die gleichen Bedingungen/Probleme vorzufinden. Die Frage ist also wohl eher, ob Apps auf Basis von Webtechnologien sich auf Dauer etablieren oder nicht?

Wie dem auch sei – ich habe eigentlich keine Lust, das alte JDK 8 auf meine Rechner zu installieren und auch nicht die ganzen Emulatoren und SDKs von Android Studio auf Teufel komm raus zu konfigurieren. Entweder es geht „out-of-the-box“ wie bei Visual Studio 2017 oder die Sache kann mir im Grunde gestohlen bleiben. Es geht mir um die eigentlich Programmierung innerhalb des Cordova-Wrappers mit JavaScript und HTML/CSS und nicht um das Geraffel rundherum. Das hat mich schon immer an der App-Programmierung genervt.

Und da kam ich auf die Idee, eine andere Sache mal wieder aufzugreifen, die ich vor einigen Monaten angefangen, dann aber wegen anderer Dinge – wie so oft – beiseite gelegt habe: Docker.

Warum nicht einfach ein gut konfiguriertes Docker-Image für Cordova laden und dann ohne das ganze Installieren und Konfigurieren die Apps bauen? Das war meine Idee. Sollte doch einfach sein.

Und wie immer, wenn etwas auf den ersten Blick so einfach und logisch aussieht, steckt der Teufel im Detail. Genau genommen sind es in dem Fall sogar gleich mehrere Teufel gewesen.

Denn obwohl ich mich schon mit Docker beschäftigt und auch schon Images bzw. Container zum Laufen gebracht hatte, habe ich das Zeug zwischenzeitlich wieder von meinen Rechner gelöscht gehabt. Also musste ich Docker erst einmal „schnell“ installieren. Was (natürlich) wieder gar nicht schnell war und letztendlich sogar auf meinen Windows-Rechnern gescheitert ist. Weder unter Windows 10 Pro noch unter Windows 10 Home ist Docker bei mir richtig gelaufen. Natürlich kam ich bei den Problemen mit Windows 10 Pro sofort auf Hyper-V und diesen ganzen Virtualisierungs-Kram im Hintergrund von Windows, denn damit habe ich schon seit Jahren Ärger im Zusammenspiel mit VirtualBox und dem VMWare Player. Und auch wenn der VMWare Player ab der Version 16 wohl mit dem Hyper-V-Geraffel kann und auch Docker in Windows 10 Pro irgendwas mit Hyper-V macht und ich die Anleitungen für die ganzen Einstellungen umgesetzt habe, hat das Zeug irgendwelche Probleme mit den Rechten. Dazu kommt – bei Windows 10 Home gibt es ja kein Hyper-V und da muss man dann andere Sachen konfigurieren bzw. installieren. Alles doch ein elendes Gefuddel, was ich ja ausdrücklich vermeiden wollte und ich habe nach diversen Versuchen die Lust verloren.

Also auf meinen Linux-Rechner gewechselt, auf dem Docker erwartungsgemäß problemlos läuft. Zwischenzeitlich war ich auch in Eppstein und habe Docker mal auf meinem iMac getestet – auch keine Probleme. Also Docker sollte doch ein lohnenswerter Ansatz sein.

Aber dann bin ich auf das nächste blöde Problem gestoßen, erst einmal ein geeignetes Cordova-Image für Docker zu finden. Auf Git gibt es da was, aber der Git-Zugriff scheitert durch Rechteprobleme. Das Image scheint entweder gesperrt oder verschoben worden zu sein. Dann habe ich noch eine Anleitung gefunden, wie ich mir selbst ein Cordova-Image erstellen kann, aber das ist ja das Gegenteil von dem, was ich eigentlich wollte – keine Arbeit mit der blöden Konfiguration. Letztendlich habe ich nur ein Docker-Image gefunden, dass (angeblich) mit einem einfache Pull vom Docker Hub zu installieren wäre. Also so (vermutlich als root notwendig):

sudo docker pull beevelop/cordova:latest

Das Starten des Image soll dann einfach so funktionieren:

sudo docker run -it beevelop/cordova bash

Unter Windows habe ich wie gesagt Docker nicht stabil zum Laufen gebracht und das Image wurde angeblich nicht gefunden. Beim iMac muss ich es noch probieren, aber auf meinem Linux-Rechner ging der Pull einwandfrei. Bis 98% durch waren. Dann kam reproduzierbar immer wieder der Abbruch.

Mittlerweile war es Krieg – die Technik gegen mich. Oder umgekehrt. Und wenn etwas einfach nicht laufen will, werde ich zum Berserker. Auch wenn im Grunde alles Notwendige zur Vorlesung über Cordova mit Visual Studio bereit gestanden hat – ich lasse mich doch nicht von so einem Mist in die Knie zwingen.

Mein Mint Linux-Rechner ist noch in der Version 19 und das System wollte ich auch nicht verpfuschen. Von daher kam mir die Idee, meine Linux-VM (Mint Linux 20) unter Windows 10 zu verwenden. Nur konnte die plötzlich auf meiner Workstation mit VirtualBox nicht mehr gestartet werden und auch die Installation einer neuen Linux-VM ist gescheitert. Möglicherweise aufgrund der Hyper-V-Einstellungen und dem Kram, aber ich hatte einfach keinen Bock mehr auf das Gefummel. Also eine neue Version von VMWare-Player aufgespielt, dort eine Version von Mint-Linux 20 installiert und da ging dann der Pull des Docker-Images. Ohne Probleme. Wenn man „Von hinten durch das Auge“ wortwörtlich haben will, ist das diese Konstruktion – eine Virtualisierung in einer Virtualisierung.

Wer aber jetzt glaubt, die Sache wäre vorbei, täuscht sich. Denn in dem Cordova-Image war kein passendes JDK 8 dabei. Die Erstellung eines Cordova-Projekts ging damit problemlos, aber das geht ja auch in meiner normalen Cordova-CLI und damit bringt mich ein Docker-Image keinen Millimeter weiter.  Als ich eine Android-App kompilieren wollte, war war auch im Docker-Container Schicht im Schacht.

Aber es war mittlerweile schon lange persönlich und jetzt wollte ich es durchziehen. Also in dem Docker-Container das JDK 8 nachinstalliert. Das geht so:

apt-get update && apt-get install -y openjdk-8-jdk && apt-get install -y ant && apt-get install -y gradle && apt-get clean

Unter Umständen tut ein Update der Zertifikate noch gut (bei mir nicht notwendig gewesen):

apt-get update && apt-get install ca-certificates-java && apt-get clean && update-ca-certificates -f

Und letztendlich müssen u.U. die Umgebungsvariablen gesetzt werden (bei mir auch nicht mehr notwendig gewesen):

ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

oder

set JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

und dann:

export JAVA_HOME

Danach konnte ich endlich eine Android-App im Docker-Container kompilieren. Nur sind Docker-Systeme ja flüchtig und wenn der Docker-Container beendet wird, sind alle Änderungen samt der gespeicherten Daten weg. Also waren Snapshots des aktuellen Stands notwendig. Das geht aus einem zweiten Terminal heraus etwa so:

sudo docker commit -p 532a5b3584e8 container1

Dabei braucht man die ID oder den Namen des Docker-Containers.Bekommt man so:

sudo docker ps

Dann bekommt man was der Art angezeigt:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
532a5b3584e8 container1 „bash“ 19 minutes ago Up 19 minutes eloquent_liskov

Und dann muss die kompilierte App ja auch noch raus aus dem Docker-Container oder man muss was reinkopieren. Also stellte sich die Frage, wie man aus einem zweiten Terminal aus dem Clientsystem auf den Host rauskopiert oder umgekehrt? Das geht formal so (wieder mit sudo):

docker cp <SRC> <DEST>

Also konkret was der Art (in den Container):

sudo docker cp /home/ralph/Schreibtisch/www eloquent_liskov:/tmp/HalloWelt
sudo docker cp /home/ralph/Schreibtisch/rjsedv.jks eloquent_liskov:/tmp/HalloWelt
sudo docker cp /home/ralph/Schreibtisch/build.json 532a5b3584e8:/tmp/HalloWelt

Aus dem Container auf den Host geht für die generierte Android-App etwa so:

sudo docker cp eloquent_liskov:/tmp/HalloWelt/platforms/android/app/build/outputs/apk/debug/app-debug.apk /home/ralph/Schreibtisch

Die späteren Neustarts der Snapshots zeigten, dass noch (weitgehend) alle Daten waren und jetzt schien alles ok.

Pustekuchen. Denn auf meinem Notebook mit Windows 10 Home konnte der VMWare-Player die virtuelle Maschine nicht starten, die ich auf der Workstation erstellt hatte. Und ist auch beim Neuinstallieren eines Linux-Systems gescheitert. Irgendwas mit der Anzeige ging schief. Warum auch immer.

Also habe ich auf dem Notebook VirtualBox genommen, denn das ist dann dort im Gegensatz zum VMWare Player auch mit Linux als Clientsystem sauber gelaufen. In der damit erzeugten VM für Mint-Linux 20 das ganze Zeug mit Docker nochmal gemacht und das hat dann auch funktioniert.

Letztendlich hat das „Mal schnell“ zu gut einem vollen Tag Arbeit geführt, aber ungelöste Probleme lassen mir keine Ruhe und ich habe dabei vor allen Dingen wieder eine Menge gelernt. Vielleicht kann ich das neue Wissen ja nochmal brauchen.

 

Update: Irgendwann habe ich dann festgestellt, dass das Docker-Cordova-Image die Cordova-Version 9 verwendet hat und mittlerweile die Version 10 aktuell ist. Was im Grunde nicht schlimm ist, aber so kann man das dann im Container noch aktualisieren:

npm i -g cordova to update

 

 

Lehrauftrag TH Bingen

Für das kommende Sommersemester habe ich mal wieder einen Lehrauftrag an der Technischen Hochschule Bingen angenommen. Im Studiengang Mobile Computing, was ein Unterzweig des Informatik-Studiengangs ist. Thema ist die Erstellung von Apps mittels Web-Technologien und da werde ich Cordova als Basis nehmen. Dazu hatte ich auch 2016 und 2017 schon Lehraufträge an der TH übernommen und zudem ein Buch beim Springer-Verlag veröffentlicht. Die bisherigen Vorlesungen muss ich zwar aktualisieren und mich auch wieder richtig einarbeiten bzw. auf den aktuellen Stand bringen, aber weitgehend steht das Konzept.

Cordova

Aber im Gegensatz zu meinen Lehraufträgen an der Hochschule Rhein-Main in Wiesbaden, wo ich in den Jahren davor mehrere Semester Vorlesungen zu verschiedenen anderen IT-Themen rund um Programmierung im Web gehalten hatte, waren die Veranstaltungen an der TH Bingen immer Blockveranstaltungen vor dem eigentlichen Semester. So wird es auch dieses Mal wieder, denn regelmäßige Kurztermine über 2 oder 4 Unterrichtseinheiten über mehrere Wochen blockieren zu viele potentielle andere Aufträge. Auch wenn ich solche Schulungen in frühen Jahren mit Kursen an Volkshochschulen und dann später eben Vorlesungen an der Hochschule Rhein-Main oft gemacht habe, möchte ich das mittlerweile nicht mehr. Das rechnet sich nicht, ist zeitaufwändiger und zerpflückt über Wochen hinweg meine Tage. Auch das Ausweichen auf Wochenenden oder die späten Abendstunden, was bei mir in frühen Jahren über viele Jahre Usus war, vermeide ich mittlerweile. Zwar arbeite ich eigentlich durchgängig über das gesamte Jahr sowohl Nachts als auch am Wochenende, aber nicht mit Schulungen.

Aber die TH Bingen ist auf meine Vorschläge eingegangen und somit wird es für das SS 2021 eine Veranstaltung mit 7 vollen Tagen unmittelbar vor Semesterbeginn bzw. Ostern sowie einem Termin am Ende des Semesters, bei dem ich eine Überprüfung der praktischen Semesterarbeiten der Studenten vornehmen will. Auf diese Weise kann ich die Geschichte in meine übrigen Jobs unterbringen, zumal die gesamte Veranstaltung Corona-bedingt remote laufen wird und die Fahrtzeiten entfallen. Das spart einige Zeit, auch wenn Bingen ja von mir nicht weit weg und gut zu erreichen ist.

Nummer 4 lebt

Damit ist der letzte Teil der Saga draußen. Mit dem Videotraining App-Entwicklung mit iOS Grundkurs 4: Die Anwendungsarchitektur – Lebenszyklus einer Anwendung, Konzepte, anwendungsübergreifende und spezifische Ereignisse ist mein Zyklus an Trainings für Video2Brain rund die Entwicklung von Apps für iOS erst einmal abschlossen. Das waren ja alles Adaptionen von US-Vorlagen.
Der vierte Teil der Grundkursreihe stellt zunächst den Lebenszyklus einer iOS-Anwendung dar. Danach dreht sich alles um Konzepte in Aktion: Dazu sehen Sie, wie Sie anwendungsübergreifende Ereignisse überwachen und spezifische Ereignisse anzeigen lassen können. Weitere Themen sind das Debugging einer Sichthierarchie mittels des Debuggers in XCode, mit dessen Hilfe Sie Fehler in Ihrem Code schnell und einfach beheben können.

Das geht ja wie beim Bretzelbacken

Da wurde doch vor wenigen Tagen erst mein letztes Videotraining „App-Entwicklung mit iOS Grundkurs 2: Das User Interface“ veröffentlicht, da kommt schon der 3. Teil des Grundkurses hinterher. Video2Brain schafft die Produktion ja in einem rasanten Tempo. Es sind zwar von mir noch ein paar Sachen eingespielt und auf Lager bzw. in der Produktion, aber ich muss schleunigst mit der Planung für neues Futter beginnen, dünkt mir.
Der ausführliche Titel lautet bei dem neuen Training App Entwicklung mit iOS Grundkurs 3: Erweitertes UI-Design – Moderne Benutzeroberflächen, Storyboards, Auto-Layout. In dem Teil der Kursreihe dreht sich alles um Benutzeroberflächen: Das umfasst die Arbeit mit Storyboards, die Erstellung von Benutzeroberflächen für bestimmte Geräte und die Verwendung eines Auto-Layouts, um sicherzustellen, dass Ihre Entwürfe über mehrere Geräte, Auflösungen und Orientierungen hinweg konsistent sind und bleiben. Schritt für Schritt wird das Erlente in einer App live umgesetzt.

App-Entwicklung mit iOS Grundkurs 2: Das User Interface

Da isses ja :-).

Das zweite Training zur App-Entwicklung mit iOS ist draußen. Aufbauend auf den Kurs App-Entwicklung mit iOS Grundkurs 1: Meine erste eigene App – Tools und einfache Oberflächenelemente konzentriert sich der zweite Teil dieser Grundkursreihe (mit vollem Namen

App-Entwicklung mit iOS Grundkurs 2: Das User Interface – Bilder, Schieberegler, Schalter, Fortschrittsbalken und andere UI-Elemente kennen lernen und nutzen
) auf das Design der Benutzeroberfläche einer App. Sie sehen zunächst, wie man die verschiedenen UI-Objekte in iOS benutzt: Bilder, Auswahlmöglichkeiten, Schieberegler, Fortschrittsbalken, Schalter und viele mehr. Ausführlich geht es dann weiter mit dem Einsatz von Web-Ansichten. Das schließt das Laden von Daten aus einem String, einer Datei und einer URL ein. Schritt für Schritt entsteht so eine einfache Web-Browser-App.

Demovideos zu App-Entwicklung mit iOS Grundkurs 1

App-Entwicklung mit iOS Grundkurs 1: Meine erste eigene App
App-Entwicklung mit iOS Grundkurs 1: Meine erste eigene App

Vor wenigen Tagen ist ja mein erstes Videotraining zur Programmierung von iOS-Apps erschienen (App-Entwicklung mit iOS Grundkurs 1: Meine erste eigene App – Tools und einfache Oberflächenelemente). Es sollen in kurzen Abständen 3 Folgetrainings zur iOS-Programmierung nachkommen, die aufeinander aufbauen.

Nun gibt es zu solchen Trainings immer eine Reihe an Demovideos.

Schnittmenge zwischen Job und Hobby

Es gibt hin und wieder Überschneidungen zwischen meinem Job und meinen Gleitschirm-Hobby. Gerade ist mal wieder so ein Tag. Dabei ist der Zusammenhang erstmal nicht offensichtlich, denn heute ist nur einfach mein neues Vario für das Gleitschirmfliegen angekommen. Das Vario – und das ist ja mein Aufhänger für diesen Post – hat es in sich und berührt auch meine fachliche Seite.

Ich habe ein Kobo Mini erstanden. Eigentlich nur ein ebook-Reader. Genau wie der Kindle. Der Kobo basiert auf einem Android/Linux-System und lässt sich hervorragend mit passender Hardware zu einem Vario aufrüsten. Ich habe das Gerät bei einem Fliegerkollegen im Einsatz gesehen und war sofort überzeugt. Das Display mit eInk-Technologie erlaubt ein perfektes Ablesen in
grellem Sonnenschein und aus jedem Winkel und zudem ist der Stromverbrauch sehr gering. Die Kommunikation kann kabellos über Bluetooth erfolgen, oder mit einem Kabel. Also eine super Basis. Dazu braucht es neben der Hardware aber noch gewisse weitere Software, damit das zu einem Vario wird.

Nun könnte ich meine Flieger-App, die ich mit Cordova für ein Buch als Referenz-App geschrieben habe, vermutlich auf das System sogar portieren.
Aber das ist gar nicht notwendig.
Die OpenSource Software XCSoar wurde entsprechend für diese Geräte angepasst. Da die Installation in jedem Fluggerät individuell gestaltet werden muss, ist auch hier etwas Arbeit notwendig, um das Teil zum Vario aufzurüsten. Wenn das jemand kann und die Zeit investieren möchte. Also Softwarearbeit (im Prinzip mein Job, aber auch Hardwarearbeit – und das mache ich nicht gerne). Ich wollte einfach ein neues Vario und deshalb habe ich nach einem entsprechenden schon konfigurierten Gerät gesucht und auf GGZ (Gebrauchtmarkt für Gleitschirme und Zubehör) wurde da ein aufgebaute Kobo Mini angeboten. Ich denke, dass ich bei den fertig zu kaufenden Standardvarios ein Vielfaches mehr bezahlen müsste, um etwas Gleichwertiges zu bekommen – selbst bei den Gebrauchtsangeboten.

Ich bin gespannt, wie sich das Gerät nutzen lässt und hoffe auf baldige fliegbare Bedinungen zum Ausprobieren.

Die Sache habe ich zum Anlass genommen und mein altes Vario Favorit von Aircotec auf ebay anzubieten. Ist schon eine ältere Version, aber immer noch zuverlässig. Optische Gebrauchspuren, aber technisch guter Zustand. Die zusätzliche Halterung kann am Gurtzeug befestigt werden. Das Vario ist ein Einsteigermodell ohne GPS, aber ich bin es über Jahre geflogen und kam gut damit zurecht.

Dazu auch gleich mein altes Gurtzeug Clever Karpofly. Das liegt seit Jahren im Keller nur rum (nach dem Motto – Ersatzgurtzeug für alle Fälle).

Das Gurtzeug ist m.E. noch ok, aber hat einige deutliche Gebrauchspuren bzw. kleine Beschädigungen (aber nicht an tragenden Teilen) und wird deshalb zum Groundhandlen oder Fliegen am Strand angeboten.

Mein neues Buch „Cordova – Entwicklung plattformneutraler Apps“ ist da

Gerade kamen die Belegexemplare meines neustes Buchs an. Thema ist Cordova – Entwicklung plattformneutraler Apps. Cordova - Ralph Steyer

Es geht darum, wie mit dem Cordova-Framework Apps einheitlich für verschiedene Plattformen und App-Stores erstellt werden können. Die Programmierung der Apps erfolgt dabei unter Einsatz von etablierten Web-Technologien wie HTML5, CSS3, JavaScript und Web-Frameworks sowie Web-APIs. Die Themen des Buches reichen dabei von dem ausführlichen Einrichten von Cordova-Projekten inkl. Fragen zur Hardware über die intensive Behandlung des Frameworks und seiner Bibliotheken samt des Aufbaus einer geeigneten Oberfläche einer App, den Zugriff auf typische Elemente eines modernen Smartphones (Geolocation, Orientierung, Kamera, Audiowiedergabe etc.) bis hin zum Vertrieb und der Vermarktung von Apps.
Erschienen ist es beim Springer-Verlag als Softcover für 34,99 € – ISBN 978-3-658-16723-3.