Er sagte, er hätte tausende Kunden, die bereit wären pro Monat 10,- € für die Nutzung einer kleinen App zu bezahlen. Seine Kunden könnten auch mit dem Smartphone ihre Fotos machen. Wenn es noch ein wenig Komfort dabei gäbe, würden die bestimmt zahlen. Für mich wären pro Kunden ein bis zwei Euro pro Monat drin. Wäre das nichts für mich?
Da war er wieder, der Mann mit der Idee und den Kunden. Meine Erfahrung sagte mir, dass das wohl nichts wird. Aber ich könnte etwas lernen. Wieder etwas in Java für Android und dann für IOS implementieren, kam für mich gar nicht infrage. Das hatte ich 2011 gemacht. Wir schreiben das Jahr 2018. Da gibt es bessere Möglichkeiten.
Eine progressive Web App verhält sich wie eine native App. Wenn das rund läuft, kann ich mit react native das auch native machen, wenn es denn sein sollte. Node.Js interessierte mich sowieso schon.
Ich war bereit für ein neues Abenteuer.
Wie immer war der Anfang furios. Schnell hatte ich node und npm installiert und auch schon die webcam Komponente heruntergeladen. Am Nachmittag liefe eine erste App, die meine USB Kamera für den mini Mac ansteuerte.
Nun fehlten nur noch die Einstellungen für den Zoom und das Licht. War das wirklich so einfach?
Der Teufel steckt im Detail
Mit dem Zusammenstöpseln von react Komponenten hatte ich zwar etwas, das ein Foto machte, aber einen Überblick, wie das funktionierte, hatte ich nicht. Bei npm, dem Pool für JavaScript Komponenten, stellen motivierte Programmierer und solche, die es werden wollen, ihre Pakete ein. Manchmal sind diese gut, meistens sind es mehr Übungen.
Die webcam Komponente war in dieser Beziehung nicht anders. Es gab den Hinweis auf Constraints zum Einstellen von Zoom und anderen Einstellungen. Aber wie funktionierte das genau?
Laut Google handelte es sich bei Mikrofon und Kamera um „mediadevices“, die der Browser anbietet. Es gab nur Beispiele in einfachem Javascript. Diese mediadevices können gefragt werden, welche Einstellungen möglich sind.
Um alle möglichen Smartphones zu unterstützen, galt es in die Innereien zu tauchen. Ich baute mir eine eigene Komponente und passte das entsprechend an.
Dazu verhalf mir die Umgebung von npm.
Die Umgebung
Unter npmjs findet sich eine Umgebung, mit der Liebhaber der Kommandozeile sofort loslegen können. Mit npm create legt man eine neue App an. Diese ist gefüllt mit „boilerplate“ Source Code. Bei npm start dauert es wenig, bevor im Browser „localhost:3000“ mit der Web App geöffnet wird.
Immerhin ist der Server in JavaScript geschrieben. Das gilt es zu kompilieren. Wenn die Umgebung einmal gestartet ist, aktualisiert die Anzeige, sobald im Source Code Änderungen gespeichert werden. Ich freute mich über die Anzeige der Syntaxfehler im JSX Source Code. Damit hatte ich nicht gerechnet. Bei einem Vorgängerprojekt zeigten sich die fehlerhaften Zeilen erst in der Entwicklerkonsole vom Browser. Hier demonstrierte einem die Webseite, wo der Fehler war.
Ich baute alles in 370 Zeilen Source Code zusammen. Mit ein wenig CSS war die erste Anwendung fertig. Nun kann der Benutzer seine Kamera einstellen und ein Foto machen. Wenn das Foto gut genug ist, kann er sich die Einstellungen merken.
Mehr habe ich für den ersten Prototyp nicht vorgesehen. Später kommt das Hochladen in die Cloud und Erzeugung von pdfs.
Beim Frontend verließ ich den Standardpfad:
Die App zeigt zunächst den Stream der Rückkamera an. Möglichkeiten zur Einstellung der Parameter überlagern diesen. Sofort übernimmt der Stream die geänderten Einstellungen. Ein Klick an den Einstellungen vorbei lässt die Einstellungen verschwinden. Wenn das Motiv stimmt, klickt der Anwender den roten Knopf.
Nun zeigt die Oberfläche das Foto an. Darüber ist der OK Knopf und der Cancel Knopf. Bei OK wird nach einem Namen für die Einstellungen gefragt. Unter diesem Namen merkt sich die App die Einstellungen.
Im Endbetrieb stellt der Anwender die Kamera nicht detailliert ein, sondern wählt mit einem Klick am oberen Rand des Stream die Einstellungen aus, die übernommen werden sollen.
Das implementierte ich per direktem Zugriff auf die <div> Elemente. Ich weiß, dass das eine Abkürzung war.
Der lange Entwicklungszyklus mit HTTPS
Leider braucht der Zugriff auf die Kamera eine „sichere“ Verbindung. Beim Chrome Browser gilt localhost als sicher, aber eine lokale IP-Nummer wie z.B. 192.168.2.0 nicht. Deswegen konnte ich die auf einem Smartphone im Produktionsmodus der Web App testen.
Hier zeigte sich wieder der JavaScript Anteil von npm. Es dauerte, bis unter dem Verzeichnis build alles gebaut war. Aber dann ging es mit sftp hinauf nach fotoapp.gawehns.de und von dort auf das Smartphone.
Wie fluchte ich, als bei den ersten Versuchen ein schwarzer Bildschirm auftauchte!
Zunächst versuchte ich über alerts eine Tracemöglichkeit zu bekommen. Dann entdeckte ich die remote Entwicklungskonsole von Chrome.
Scheitern
Bei meinem letzten Beitrag hatte ich schon der Kunst des richtigen Scheiterns erzählt. Mit der App scheiterte die Geschäftsidee nicht aus technischen Gründen. Nun liegt der Ball beim Geschäftspartner.
In jedem Fall habe ich etwas gelernt und kann die App auch für anderes verwenden.