Innerhalb des 3ten Semesters haben wir, die Masterklasse Mobile, die Aufgabe ein Gruppenprojekt umzusetzten. Zusammen wurde entschieden, dieses mit Flutter umzusetzen. Eine Flutter Library, welche verschiedene Sensoren auslesen kann und roh oder interpretiert zurückgibt.

https://github.com/hraschan/flutter_sensor_library

Außerdem haben wir uns hier entschieden, dass es eine “Beispiel App” dafür geben soll, die die Anwendung der Library präsentiert.

https://github.com/hraschan/flutter_sensor_library_app

Flutter

Da wir alle zuvor kaum bis gar keine Erfahrung mit Flutter gemacht haben, wurde von Mario und Maximilian ein Workshop vorbereitet, der uns die Grundlagen präsentiert hat und in welchem wir gemeinsam das Setup des Projekts durchführten.

Flutter an sich ist ein Open-Souce-Framework von Google, das zur Erstellung von nativ kompilierten Anwendungen verwendet wird. Bei Flutter gibt es viele Bibliotheken für Standard-UI-Elemente, die bei Android oder iOS benötigt werden. Für Desktop Webanwendungen kann das Framework auch eingesetzt werden.

Das Framework wird also primär für iOS und Android Applikationen verwendet. Für die Entwicklung wird die Programmiersprache “Dart” verwendet, diese wurde ebenfalls von Google entwicklet.

Was kann die Library

Die Library bietet verschiedene Klassen und Methodensammlungen an, um die Sensoren eines Mobilgeräts nutzen zu können. Dabei beruht sie bei den meisten Sensoren auf bereits vorhandenen Librarys, verarbeitet diese und gibt die Daten, wenn gewünscht, gesammelt an eine Flutter App weiter. Zudem bietet die Library auch interpretierte bzw. aus mehreren Sensoren zusammengefasste Daten, wie bspw. die Höhenmeter an, die aus dem aktuellen Luftdruck (Barometer) und dem Luftdruck auf Seehöhe ausgerechnet werden.

Aufgerufen kann die Funktionalität über gewisse Wrapper-Klassen, je nachdem ob Bewegungs-Daten (Movement), Positions-Daten (Position) oder Umgebungs-Daten (Environment) benötigt werden. Außerdem können die nativen Sensoren einzeln aufgerufen werden. Dabei muss immer angegeben werden, in welchem Zeitintervall die jeweilige Klasse Daten zurückliefern soll.

Movement mvmnt = Movement(inMillis: 2000);
mvmnt.getMovementType(true).forEach((element) {print(element.fwd);});

Mit diesem einfachen Code-Beispiel kann alle 2 Sekunden abgefragt werden, ob sich das Gerät in den letzten zwei Sekunden nach vorne bewegt hat. Mit der Übergabe des Boolean (in dem Fall true) kann festgelegt werden, ob die aktuelle Fortbewegung zum Zeitpunkt der Abfrage oder die interpolierten Daten seit der letzten Abfrage wiedergegeben werden sollen.

Die Bespielapplikation

Um die Andwendung der Library zu vereinfachen, wurde ein Beispielapplikation geschaffen, welche die einzelnen Verwendungszwecke zeigen soll. Hier einige Screenshots der Anwendung:

Personal Learnings

Armin

Mein Learning aus dem Gruppenprojekt ist die Einführung in Flutter. Ich habe mit diesem Framework zuvor noch keine Projekte umsetzen können. Ehrlichgesagt finde ich das Framework recht unübersichtlich und ich finde es gibt Frameworks, die um Einiges besser konzipiert sind als Flutter. Dennoch habe ich dieses Learning für die Zukunft mitnehmen können und da Flutter recht bekannt ist, ist auch diese Erfahrung von Wert.

Bettina

Für mich war Flutter vollkommenes Neuland. Bei diesem Projekt konnte ich hier einiges lernen. Von Projektstruktur über Codeaufbau, Widget Aufbau, Verwendung von Libraries sowie die Nutzung verschiedener Simulatoren.

Mario

Die Vertiefung der Kenntnisse in Flutter nach dem gemeinsamen Workshop mit Maximilian ist bestimmt ein großer Lernzugewinn. Die Nutzung der Sprache Dart ist doch etwas ungewohnt, obwohl sie sehr an JavaScript angelehnt ist. Außerdem konnte ich bei der Konzeption einer Library sehr viel dazulernen. Die Erarbeitung einer Library und die Vorstellung anderer Entwicklerinnen als Nutzerinnen des eigenen Programms stellt einen Lerneffekt dar, den man in anderen Projektkontexten so nicht hat.

Maxi

Für mich hat dieses Projekt vor allem einen tieferen Einblick in Flutter ermöglicht. Auch habe ich das aufbauen einer eigenen Library bis jetzt noch nicht in dieser Form kennengelernt. Ich denke jedoch das es noch einiger Zeit bedarf um gute Lösungen mit der Technologie Flutter entwickeln zu können

Thomas

Bis zum Workshop von Mario und Maxi kannte ich weder Flatter noch Dart. Durch den Workshop konnte ich mir ein gutes Grundwissen aneignen und anschließend im Rahmen des Projekts tiefer in die Materie einsteigen. Im Großen und Ganzen habe ich einen guten Überblick über Flutter, Dart und verschiedener Sensoren bekommen.

Sebastian

Die Zusammenarbeit mit Mario und Maxi während der Ausarbeitung des Backends hat mir einige neue Erkenntnisse gebracht. Sowohl mit Flutter als auch mit Dart hatte ich vor diesem Projekt wenig zu tun gehabt. Daher war es für mich sehr erkenntnisreich, ein Projekt umzusetzen, beziehungsweise daran beteiligt zu sein. Auch der Gedanke eine eigene Library zu erstellen war für mich interessant, da ich diesen Aspekt des Programmierens bis dato nur von der anderen Seite gekannt habe. Ich bin gespannt, ob die Library in irgendeiner Form einen späteren Verwendungszweck finden wird.

The post Sensor Library appeared first on Mobile USTP MKL.

Kurz gesagt, zielt die vorgeschlagene Gesetzgebung darauf ab, die gemeinsame Nutzung von Daten zu erleichtern und einen Standard auf EU-Ebene zu setzen. Sie fordert die Hersteller auf, den Besitzer*innen von vernetzten Geräten Einblick in die von ihnen gesammelten Daten zu gewähren.

Wen Betrifft die neue Gesetzgebung?

Der Gesetzesentwurf gilt für alle Hersteller von Produkten und Dienstleistungen, wie z. B. Geräte für das Internet der Dinge und Anbieter von Cloud-Diensten in der EU. Alle Benutzer*innen ebendieser Produkte – also sowohl Unternehmen als auch Privatpersonen – werden betroffen sein.

Was bedeutet die neue Gesetzgebung?

Kurz gesagt, würde die neue Gesetzgebung bedeuten, dass Hersteller, die in der EU Daten sammeln, ebendiese an uneingeschränkt an jene zur Verfügung stellen müssen, die an deren Erstellung beteiligt waren. Dies schließt ebenfalls das Recht ein, gesammelte Daten an Dritte Parteien weiterzugeben. Nutzer*innen können gegebenenfalls sogar verlangen, die sie betreffenden Daten direkt an dritte Parteien weiterzugeben. Während also die Daten damit weitestgehend in den Besitz der sie betreffenden Personen übergehen, muss diese gemeinsame Nutzung von Daten weiterhin Geschäftsgeheimnisse respektieren und darf nicht mit dem ursprünglichen Inhaber der Daten konkurrieren.

Die neuen Vorschriften bedeuten auch, dass öffentliche und staatliche Stellen bei öffentlichen Notfällen oder rechtlichen Verpflichtungen Zugang zu privat gespeicherten Daten beantragen können, nicht aber bei der täglichen Strafverfolgung. Zu solchen Notfällen gehören Terroranschläge, Pandemien und Naturkatastrophen.

Was bedeutet das für die Internationalen Tech-Giganten?

Die neue Gesetzgebung will auch “Schutzmaßnahmen gegen unrechtmäßige Datenübermittlung” treffen, die US-amerikanische oder andere ausländische Unternehmen betreffen könnten.

Nachdem der sogenannte “Privacy Shield”, der eigentlich den sicheren Datentransfer zwischen Europa und den USA garantieren sollte aufgrund eines von Datenschutzaktivisten Max Schrems erwirkten Urteils aufgrund fortwährender Verstöße annulliert wurde, wird der Data Act neue Rahmenbedingungen schaffen.

Es bleibt zu hoffen, dass Unternehmen wie “Meta” sich diesmal an bestehendes Europäisches Recht halten werden. Mark Zuckerberg hat in den letzten Monaten wiederholt öffentlich die Möglichkeit genannt, sein Unternehmen würde sich angesichts neuer Gesetzgebung aus Europa zurückziehen müssen. Dies kann eventuell als erstes Indiz dafür gesehen werden, dass der Data Act greifen wird.

The post Neuer Data Act der EU – Ein Überblick appeared first on Mobile USTP MKL.

Wir haben uns anfangs darauf geeinigt, dass Sebastian für das Backend und ich für das Frontend verantwortlich sind. Jedoch haben wir uns gegenseitig unter die Arme gegriffen, so konnten wir in Frontend und Backend Erfahrungen sammeln. Da wir letztes Semester das Grundgerüst, sowie eine noch nicht designte Testapplikation implementiert hatten, lag der Fokus dieses Semester auf neuem Design und Funktionen wie zum Beispiel eine neue Userverwaltung oder ein personalisierter Einstellungsbereich. Um unser Design adäquat umsetzen zu können, stellte sich bald heraus, dass sowohl Backend als auch Frontend grundliegende Umstrukturierungen durchlaufen musste, um das Design überhaupt zielführend umsetzen zu können.

Was haben wir erreicht?

Wir haben mit unserer Designerin Katja Seitz ein Rundum Konzept, von Zielgruppe, App Name bis zu einem Tutorial, das beim ersten Verwenden der App durchgespielt wird, kreiert. Wir haben Frontend und Backend von unserem Vorgängermodell aus letztem Semester umgebaut und performanter gemacht. Das Design wurde fast bis zur Gänze umgesetzt, wobei einzelne Seiten, die für die ersten Testungen nicht unbedingt notwendig sind, noch nicht umgesetzt wurden. Es wurden Tests im kleinen Rahmen durchgeführt. Diese wurden mit sehr positivem Feedback abgeschlossen wobei einzelne Kritikpunkte direkt in die Weiterarbeit aufgenommen wurden. Momentan befindet sich die Applikation bereits bei zwei Nutzer*innen im Einsatz und deren Feedback wird laufend in den Entwicklungsprozess miteinbezogen.

Ein*e Nutzer*in kann momentan:

• Kunden, Produkte und Lieferanten abrufen, anlegen, bearbeiten und löschen
• Rechnungen abrufen, erstellen, bearbeiten, löschen, Rechnungen als PDF downloaden
• Auf der Startseite nach Einnahmen Ausgaben filtern, nach Namen suchen, und Rechnungen nach Datum abrufen
  
  

Was wird noch umgesetzt?

Im Laufe der nächsten Monate planen wir, unter Zusammenarbeit mit einer*m Steuerberater*in einen individuellen Einführungsfragebogen zu entwickeln, der bei adäquater Beantwortung der Fragen, die Einstellungen in der Applikation korrekt vornimmt und den Nutzer*innen individuelle Hinweise in Bezug auf ihre steuerlichen Verpflichtungen, sowie Hinweise für effiziente Buchhaltung gibt. Des Weiteren wird es die Möglichkeit geben, Fotos von Rechnungen zu scannen und mittels AI automatisch ins System einzuspeisen. Außerdem erscheint es uns auf längere Sicht sinnvoll das Frontend auf Vue3 umzustellen, was eigentlich für das letzte halbe Jahr geplant war, jedoch aufgrund der verhältnismäßig niedrigen Priorität noch nicht geschehen ist.

Design

Sebastian Sander und ich haben uns im Rahmen der Lehrveranstaltung „Vertiefung Berufsfeld“ für den Zweig Gründen entschieden und hatten dadurch die Möglichkeit mit Katja Seitz aus der Masterklasse Grafik Design zusammenzuarbeiten.
Katja war für das allgemeine Design und Logo verantwortlich und wir sind mit dem Ergebnis sehr zufrieden.

Fazit Thomas Pohl

Für mich war das größte Learning, dass man von Anfang an ein durchgedachtes Konzept und Design benötigt, um unnötige Arbeiten zu vermeiden. Wir haben letztes Jahr begonnen ein Grundgerüst zu implementieren und haben dann einfach so weiter gemacht. Hätten wir direkt nach dem Prototyp alles komplett durchgeplant und begonnen zu designen, hätten wir uns eine Menge Umstrukturierungen erspart. Wobei das auch ein gutes Learning für mich war.

Große Learning waren auf jeden Fall auch in Vue, Vuex, Axios und allgemein in der Strukturierung des Backends zu beobachten.

Fazit Sebastian Sander

Die schrittweise Durchimplementierung eines Backends war für mich etwas Neues. Kleinere Beispielprojekte, wie der letzjährige Prototyp sind im Umfang kaum vergleichbar und es war motivierend, das eigene Projekt sukzessive wachsen zu sehen. Auch im Bereich der Kommunikation haben Thomas und ich uns definitiv weiterentwickelt – wir kommunizieren klar, was wir vom anderen brauchen und arbeiten dies dann relativ konsequent ab.

The post Receibra – Buchhaltung appeared first on Mobile USTP MKL.

Die gegenwärtige Situation

Schon seit 2016 sehen die WhatsApp Nutzungsbedingungen die Weitergabe von Userdaten zu Werbezwecken und zur Produktverbesserung an den Mutterkonzern Facebook vor. Allerdings mussten die Endnutze*Innen bisher dieser Weitergabe nicht zustimmen. Mit dem Inkrafttreten der neuen Nutzungsbedingungen am 15. Mai ermöglicht es WhatsApp Nutzer*Innen nach derzeitigem Stand nichtmehr, die Weitergabe von Daten zu untersagen. Dies gilt aber Aufgrund der Datenschutzgrundverordnung der Europäischen Union nur außerhalb von EU-Staaten. Außerhalb des Rechtsraumes der EU werden Daten von Usern, die die App nach 15. Mai noch verwenden, an alle Facebook Unternehmen weitergegeben.

Welche Daten sind betroffen?

Betroffen sind alle Daten, auf die vonseiten des Unternehmens zugegriffen wird. Das bedeutet Profilbilder, Telefonnummern, Adressbücher und Statusmeldungen, sowie Informationen zum eigenen Smartphone. Worauf explizit nicht zugegriffen werden kann sind die Inhalte der Chats selbst, da diese Ende-zu-Ende verschlüsselt sind und nur von den Benutzer*Innen gelesen werden können. Facebook beteuert außerdem, dass WhatsApp keinerlei Daten darüber speichert, wer mit wem über die App kommuniziert und dass auch geteilte Standorte für den Konzern nicht einsehbar sind.

Was sich ändert

Für Nutzer*Innen innerhalb der EU eigentlich garnichts – die DSGVO macht die neuen Nutzungsbestimmungen in der EU nicht umsetzbar. Für die meisten Nutzer außerhalb der EU prinzipiell auch nichts. Alle, die nach 2016 ihr Konto eröffnet haben, oder nicht in den 30 Tagen nach Inkrafttreten der Nutzungsbedingungen von 2016 aktiv einen sogenannten „Opt-Out“ vorgenommen haben – also die Weitergabe ihrer Daten explizit verboten haben – ändert sich auch nichts – denn für sie gelten die neuen Nutzungsbedingungen ohnehin schon. Wer dies damals getan hat, dessen Daten wurden auch bis jetzt nicht weitergegeben, was sich ab Mai dann schon ändert.

Alternativen

Wer aufgrund der derzeitigen Diskussion dennoch genug von WhatsApp hat, ist damit sicher nicht allein und auch nicht im Unrecht. Es gibt zahlreiche alternative Messenger Applikationen, die die Privatsphäre der Nutze*Innen in den Vordergrund stellen. Allen voran Signal. Die von Führenden Securityspezialist*Innen empfohlene Messengerapp ist open-source und macht Sicherheit und Privatsphäre zum obersten Gut. Weitere alternativen sind Threema, Wire oder Wickr, sowie auch Telegram, wobei von dessen Verwendung unter Augenmerk auf Privatsphäre eher abzuraten ist.

The post Die neues WhatsApp AGBs im Überblick appeared first on Mobile USTP MKL.

Einleitung

Vor- und Nachteile plattformübergreifender Ansätze

Plattformübergreifende Ansätze im Überblick

Web Applikationen

Hybrid Applikationen

Interpretierte Applikationen

Conclusio

Literaturverzeichnis

Einleitung

Das rasante Wachstum der Mobilfunkbranche ist nach wie vor nicht zu bremsen. Bereits im Jahr 2020 nutzen laut Hochrechnungen 3,5 Milliarden Menschen ein Smartphone. Das sind rund 50% der Erdbevölkerung. [1] Mit der steigenden Zahl mobiler Benutzer steigt auch der Bedarf an Websites und Applikationen, die für die jeweiligen Plattformen optimiert sind. Diese Tools kosten- und zeiteffizient zu entwickeln ist von elementarer Bedeutung geworden. Da aber Mobile Plattformen nicht alle gleich sind, sondern es gegenwärtig zumindest zwei große Betriebssysteme gibt – nämlich iOS mit ungefähr 30% und Android mit 70% –  ist der Entwicklungsaufwand für Applikationen, die auf mehreren Plattformen laufen sollen hoch. [2] Für die spezifische Entwicklung von Applikationen für die genannten Plattformen sind bei Entwicklern Kenntnisse in verschiedenen Programmiersprachen notwendig. Während für die Entwicklung unter Android Kenntnisse in den Programmiersprachen Java und/oder Kotlin notwendig sind, erfordert die iOS Entwicklung Kenntnisse in Objective-C oder Swift. Daher erfordert native Entwicklung für mehrere Plattformen entsprechend viel Aufwand in Zeit und Geld. Um diesem Problem aus dem Weg zu gehen, wurden in den vergangenen Jahren zahlreiche Möglichkeiten geschaffen, Anwendungen plattformübergreifend lauffähig zu machen, ohne den Quelltext maßgeblich adaptieren zu müssen. Hier gibt es einige Faktoren, die in Hinblick auf Benutzerfreundlichkeit, Stabilität und Kosten berücksichtigt werden müssen. Der folgende Artikel wird versuchen, einige dieser Möglichkeiten zu erläutern und deren Vor- und Nachteile gegenüber einander, sowie gegenüber der nativen Entwicklung zu beleuchten.

Vor- und Nachteile plattformübergreifender Ansätze

Eine der maßgeblichsten Entscheidungen bei der Entwicklung einer Applikation ist immer die, für die Zielplattform, aus welcher sich dann zumindest schon die Auswahl an möglichen Entwicklungsumgebungen, Frameworks und Programmiersprachen eingrenzt. Falls beispielsweise nur für eine Plattform – wie Android – entwickelt werden soll, ist vermutlich die native Entwicklung mit Java oder Kotlin der richtige Weg.  Bei mehreren Zielsystemen sollte, um Zeit und Kosten zu sparen allerdings auf eine Alternative zurückgegriffen werden.

Vorteile

Der plattformübergreifende Ansatz ermöglicht es, ein und denselben Code auf verschiedenen Betriebssystemen lauffähig zu machen. Hierfür gibt es verschiedene Ansätze von Webapplikationen, die im Browser laufen, bis zu Lösungen, die Container bereitstellen, in denen der Quelltext wie gewohnt ablaufen kann. In der Regel bieten diese Möglichkeiten den Vorteil, dass Syntax und Programmiersprache nicht angepasst werden müssen, was eine erhebliche Zeitersparnis mit sich bringt. Auch für die Arbeit nach Release des Produktes ergeben sich durch die Vereinheitlichung Vorteile. Zum Beispiel können größere Updates und Fehlerbehebungen für alle Plattformen entwickelt und gleichzeitig ausgerollt werden. Weiters gilt es zu erwähnen, dass viele Cross-Plattform Lösungen open-Source sind und von einer breiten Community stetig weiterentwickelt werden, wovon man als einzelner profitieren kann.[3]

Nachteile

Aufgrund ihres Aufbaus verhalten sich plattformübergreifen entwickelte Applikationen anders als native, welche so konzipiert sind, dass sie auf der jeweiligen Plattform perfekt funktionieren. Native Applikationen laufen im Vergleich schneller und arbeiten nahtlos mit dem Betriebssystem zusammen, wohingegen plattformübergreifende Lösungen immer eine Form der Schnittstelle – wie einen Browser oder einen Container – benötigen. Gerade bei Anwendungen mit hoher Komplexität kann ein nativer Ansatz vielversprechender sein. Auch in diversen App-Stores werden native Applikationen bevorzugt. [3]

Plattformübergreifende Ansätze im Überblick

Web Applikationen

Web Applikationen sind Anwendungen, die nicht den systeminternen Speicher des Geräts nutzen. Sie laufen, wie gewöhnliche Websites auf einem Server und der Inhalt wird in einem Webbrowser am Endgerät gerendert. Sie erfordern für gewöhnlich keine Installation und nutzen eine dreistufige Architektur – die Client-Schicht, in der sich der Endbenutzer bewegt, die Applikationsschicht, in der die Logik der Anwendung passiert und eine Persistenzschicht, in der die Daten abgelegt werden. [4]

Figure 1: 3 Schichten der Web-App [3]

Die Webapplikation ist prinzipiell auf eine Verbindung zum Server angewiesen und kann daher nur mit aktiver Internetverbindung benutzt werden. Sowohl der Code als auch die Daten, die die Anwendung benötigt befinden sich am Server und nur die fertigen Ansichten werden an den Endnutzer gesendet, um dann auf dem Endgerät gerendert zu werden. Nachdem die Webapplikation zur Kommunikation mit dem Server die Webprotokolle nutzt und in einem Browser gerendert wird, sind Kenntnisse in HTML, CSS und JavaScript unumgänglich für die Entwicklung. [5]

Modulare Front-end-Frameworks, wie Angular, ermöglichen seit der Einführung des HTML5 Standards 2014 die Entwicklung sehr viel komplexerer Webapplikationen. Frameworks wie Angular nutzen nicht das klassische MVC-Model sondern „Components“ und „Directives“ um den Aufbau beziehungsweise die Ansicht des DOM-trees zu steuern und dynamisch zu manipulieren. [6]

Vor- und Nachteile

Webapplikationen sind auf der größtmöglichen Anzahl an Geräten lauffähig, da sie ausschließlich eine Internetanbindung und einen zeitgemäßen Internetbrowser benötigen, um zu funktionieren. Die Entwicklungskosten sind gerade im Verhältnis zu nativen Applikationen sehr niedrig und die Komplexität einer Implementierung ist niedrig. Obwohl mit HTML5 der Zugriff auf die Geräte-APIs möglich ist, ist eine Veröffentlichung auf diversen App-Stores nicht möglich und die Sicherheit der Webapplikation ist verhältnismäßig niedrig im Vergleich zu anderen Lösungen. [3]

Hybrid Applikationen

Hybride Applikationen sind, wie schon der Name verrät, Mischformen aus nativen Teilen kombiniert mit den klassischen Webtechnologien wie HTMLS, CSS und JavaScript. Für gewöhnlich funktionieren sie, indem ein nativer Container als Schnittstelle zwischen Betriebssystem und Webapplikation fungiert. Daraus ergibt sich eine wesentliche Eigenschaft der hybriden Applikationen – sie können installiert werden, obwohl sie ihre Logik, wie die Webapplikationen, von einem entfernten Server erhalten. Für die Entwicklung der Applikation selbst sind keine Kenntnisse über die Zielplattform notwendig, denn die Zugriffe auf die Hardware des Geräts erfolgen ausschließlich an das Cross-Platform-Tool – also den Container – dass die Aufrufe dann so übersetzt, dass sie zur jeweiligen Zielplattform passen. [3]

Figure 2: Vergleich Hybrid, Mobile und Nativ [7]

Vor- und Nachteile

Hybride Applikationen kombinieren viele der Vorteile von nativ programmierten Applikationen und Webapplikationen – sie sind lauffähig auf einer sehr großen Anzahl an Geräten, können auf die Gerätehardware zugreifen, können in App-Stores verfügbar gemacht werden und sind verhältnismäßig kostenschonend zu entwickeln. Nachteile gegenüber der nativen Applikation können sich vor allem im Userinterface ergeben, das natürlich trotzdem nicht nativ programmiert ist, und sich daher auch nie gänzlich so anfühlen wird. Auch eine Internetanbindung wird im Normalfall benötigt, um mit dem Server zu kommunizieren, woraus sich auch Sicherheitsaspekte ergeben. [3]

Interpretierte Applikationen

Bei interpretierten Applikationen wird der Quellcode mithilfe von JavaScript Engines – oder Java-Script-Interpretern – interpretiert. Der große Vorteil dieser Variante ist, dass Appliaktionen in JavaScript geschrieben, und dann für die jeweilige Oberfläche interpretiert werden können. Daher ist es möglich, native mobile Apps mit JavaScript zu entwickeln. Der Typ des Interpreters hängt von der Plattform ab – zum Beispiel JavaScriptCore bzw. Nitro von Apple oder V8 für Android.

Seit seiner Veröffentlichung im Jahr 2015 ist React Native das gängigste Framework für Interpretierte mobile Applikationen. Applikationen, die damit erstellt werden, sind zwar mit JavaScript programmiert, durch die Interpretation anhand des User Interface aber kaum oder garnicht von nativen Applikationen unterscheidbar. [3]

Figure 3: React Native Flow [8]

Der Kern von React native ermöglicht es – anders als bei ReactJS, das auf den DOM des Browsers zugreift – auf APIs in Swift oder Objective-C für iOS bzw. in Java oder Kotlin für Android zuzugreifen. Zusammen mit der Bridge wird auch eine JavaScript-Engine oder der Interpreter verwendet, um mit den UI-Elementen zu interagieren. React Native verwendet JavaScriptCore für iOS und V8 für Android als Interpreter. [3]

Vor und Nachteile

Interpretierte Applikationen kommen den Native in Sachen Interface schon sehr nahe, da sie prinzipiell die nativen UI-Elemente verwenden. Während die Entwicklungskosten nach wie vor wesentlich niedriger sind, als bei der nativen Entwicklung biten interpretierte Applikationen auch Vorteile in der Security und können ohne Probleme in App-Stores angeboten werden. Interpretierte Applikationen haben vollen Zugriff auf die Gerätehardware. Einzig in der Performance zeigen sich durch die Interpretation geringfügige Nachteile gegenüber von vornherein nativ entwickelten Applikationen. [3]

Conclusio

Dieser Artikel soll vor allem eine kurze Entscheidungshilfe bieten, wenn man vor der Entscheidung steht, ob und wie plattformübergreifend entwickelt werden soll. Es zeigt sich, dass verschiedene Ansätze mobile Applikationen für mehrere Plattformen zu entwickeln, vollkommen verschiedene Endprodukte ergeben. Letztendlich haben alle vorhandenen Ansätze ihre Daseinsberechtigung. Manche erfordern mehr Aufwand, ergebene aber letzten Endes ein Produkt, das von einer nativen Applikation kaum zu unterscheiden ist, andere sind im Entwicklungsaufwand sehr preiswert und erfüllen ebenso ihren Zweck. Welche Alternative die beste ist, kann letztendlich nur für einzelne Projekte bezogen auf deren spezielle Anforderungen beantwortet werden.

Literaturverzeichnis

[1]          T. F, „Marktanteile der führenden mobilen Betriebssysteme an der Internetnutzung mit Mobiltelefonen in Deutschland von Januar 2009 bis September 2020“, Nov. 12, 2020. https://de.statista.com/statistik/daten/studie/309656/umfrage/prognose-zur-anzahl-der-smartphone-nutzer-weltweit/.

[2]          T. F, „Anzahl der Smartphone-Nutzer weltweit von 2016 bis 2019 und Prognose bis 2023“, Nov. 10, 2020. https://de.statista.com/statistik/daten/studie/309656/umfrage/prognose-zur-anzahl-der-smartphone-nutzer-weltweit/.

[3]          K. Shah, H. Sinha, und P. Mishra, „Analysis of Cross-Platform Mobile App Development Tools“, in 2019 IEEE 5th International Conference for Convergence in Technology (I2CT), Bombay, India, März 2019, S. 1–7, doi: 10.1109/I2CT45611.2019.9033872.

[4]          S. Helal, J. Hammer, J. Zhang, und A. Khushraj, „A three-tier architecture for ubiquitous data access“, in Proceedings ACS/IEEE International Conference on Computer Systems and Applications, Beirut, Lebanon, 2001, S. 177–180, doi: 10.1109/AICCSA.2001.933971.

[5]          S. Xanthopoulos und S. Xinogalos, „A comparative analysis of cross-platform development approaches for mobile applications“, 2013.

[6]          „https://angular.io/guide/architecture“, Angular Docs, Nov. 10, 2020. https://angular.io/guide/architecture.

[7]          Y. Sani, „Recipe For Building A Hybrid Mobile App“, Nov. 10, 2020. https://medium.com/@saniyusuf/recipe-for-building-a-hybrid-mobile-app-506f34f54eb5.

[8]          J. Warén, „Cross-platform mobile software development with React Native“, S. 30, 2016.

The post Cross-Platform Developement im Vergleich appeared first on Mobile USTP MKL.

Seit 28. September 2020 ist es für Gastronomen in Wien verpflichtend Kundendaten bei Besuch im Lokal zu erfassen und mindestens 4 Wochen zu speichern. Um hierbei die Verwendung von Listen in Papierform und somit sowohl eine Menge Verwaltungsaufwand und auch ein erhöhtes Infektionsrisiko zu vermeiden, wurde eine digitale Lösung entwickelt. Diese wurde als Webformular, welches auf der bereits vorhandenen WordPress Seite eingebettet wurde, umgesetzt. Die Daten werden auf dem vorhandenen Server gespeichert und bei Bedarfsfall via phpmyadmin ausgelesen. Kunden gelangen mittels QR-Code, der auf Aufstellern auf den Tischen angebracht ist, schnell und einfach auf die betreffende Website.

In Verwendung ist das ganze in der “Halle” im Museumsquartier Wien (diehalle.at).

Sebastian Sander – it201521 – 1.10.2020

The post Corona Registrierung im MQ appeared first on Mobile USTP MKL.