Category: General Topics

Genau vor 1 Monat wurde die App Lieferscheinblock im App Store von Apple veröffentlicht. Die Zwischenbilanz ist erfreulich. Die Lieferschein App wird täglich mehrmals installiert und was ganz wichtig ist, aktiv benutzt! Kein Wunder, denn der Lieferscheinblock ist die einzige Lieferschein App für iPhone und iPad im AppStore die ein ganz einfaches Workflow unterstützt: Lieferschein ausfüllen, ggf. vom Kunden unterschreiben lassen und PDF abspeichern / per Email verschicken. Keine Anmeldung! Keine IT-Infrastruktur! Keine monatliche Kosten.

Die Lieferschein App ist in erster Linie für kleinere Betriebe interessant, e.g. Blumengeschäfte, Lieferdienste etc. Doch es gibt inzwischen auch die Anfragen von größeren Kunden, die eigene IT-Infrastruktur besitzen und in Erwägung ziehen, den elektronischen Lieferscheinblock in ihre logistische Prozesse einzubinden. Auch das ist kein Problem. Die Lieferschein App läßt sich an jede Schnittstelle ohne großen Aufwand anbinden. Die Lieferschein-Daten werden auf dem sicheren Wege automatisiert als JSON Objekt dahin geliefert, wo sie vom Kunden-System konsumiert werden.

Was eine App ist, weiß mittlerweile jeder. Doch wie entstehen Apps? Kann wirklich jeder Apps bauen? Lasst uns einen Blick hinter die Kulisse werfen.

Apps sind nichts anderes als Computer-Programme. Sie können klein aber auch richtig komplex sein. Das was auf den ersten Blick aus der Nutzersicht einfach erscheinen mag, muss nicht unbedingt so unter der Haube sein. Im Gegenteil, richtig professionelle Apps sind häufig schlicht im Design, nutzerfreudlich, so dass die Komplexität sich nicht sofort erkennen lässt.

Unabhängig von der Art der App, ob sie im Auftrag oder aus eigenem Interesse entwickelt wird, sieht der Prozess immer ähnlich aus. Zuerst werden Use-Cases definiert, i.e. das nach außen sichtbare Verhalten der App aus Sicht der Nutzer. Mit anderen Worten aus einer App-Idee wird eine konkrete Vorstellung, was man mit der App alles machen kann. Die ganz grobe Skizze wird  in einzelne funktionale Einheiten/Komponente aufgebrochen, welche später auch umgesetzt werden.

Im zweiten Schritt wird geschaut, welche Technologien für die Umsetzung genommen werden. Die Wahl der Technologien hängt stark von Anforderungen ab. Entscheidend dabei sind Fragen, soll es eine App für nur ein Platform z.B. iOS werden oder müssen mehrere Platformen unterstützt werden, wie viele Resources stehen zur Verfügung, wie viel Zeit steht zur Verfügung etc.

Die Umsetzung an sich ist ziemlich staightforward. Es können sich natürlich unterwegs unvorhersehbare technische Schwierigkeiten ergeben, aber meistens läßt sich dieser Abschnitt des Prozesses gut planen.

Anschließend kommt Testing und aufregender Moment des Ausrollens der App. Obwohl die Prozesskette relativ einfach ist, steck der Teufel im Detail. Über einzelne Schritte im App-Development Prozess kann man lange Artikel schreiben. Das Ziel dieses Postings ist aber erst mal einen generellen Eindruck über die App-Entwicklung zu vermitteln. Wer sich fürs Thema App-Entstehung mehr interessiert, kann sich gerne die Postings zu PolterApp und Cheat-Sheets App durchlesen. Das sind zwei Beispiele aus der Praxis mit konkreten Fragestellungen und konkreten Lösungsansätzen.

Last week I had a pleasant acquaintance with Adam Giemza, head of solution architecture and security at DB Schenker AG. He asked me about Progressive web and my opinion to it. Frankly speaking, I had no opinion at all, because I’m specialized more on native apps for iOS and Android. Of course, hybrid apps, mobile first approach, responsive design are the things I heard of and had even a bit experience with them. But what are Progressive web apps? I began to read about it.

The term “progressive web” appeared 2015  to describe web apps taking advantage of features supported by modern browsers, including Service Workers and Web App Manifests. Progressive web apps are:

• Progressive – Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet.
• Responsive – Fit any form factor: desktop, mobile, tablet, or forms yet to emerge.
• Connectivity independent – Service workers allow work offline, or on low quality networks.
• App-like – Feel like an app to the user with app-style interactions and navigation.
• Fresh – Always up-to-date thanks to the service worker update process.
• Safe – Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.
• Discoverable – Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
• Re-engageable – Make re-engagement easy through features like push notifications.
• Installable – Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
• Linkable – Easily shared via a URL and do not require complex installation.

As far as I understand the main difference to the hybrid apps, e.g. based on Cordova is that progressive web apps are not wrapped into some mobile application, but are more like a website. It is the web browser features, i.e. service worker and manifest which make these web application look and feel like native apps. And in opposite, the difference to a responsive web site is that progressive web apps can be used offline and look more “native”.

The concept of progressive web apps is very interesting. It is on one hand the next step towards cross platform development. On the other hand it is the step towards app distribution without app stores. I can think of many use cases where a progressive app has more advantages over native implementation for multiple platforms. Some examples of progressive web apps can be found here.