Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03480.jsonl.gz/2266

Ein grosser Vorteil bei der nativen App-Entwicklung liegt in der Performance und dem nativen "Look and Feel" der Apps. Durch die Verwendung unterschiedlicher Programmiersprachen bei jeder Plattform werden dadurch natürlich einige Features mehrfach implementiert, was einen Mehraufwand darstellen kann. Wir probieren dieses Problem ironischerweise mit einer weiteren Programmiersprache zu lösen.
Auf den gängigen Mobile-Plattformen iOS, Android und Windows Phone ist es möglich C/C++-Libraries einzubinden und die Funktionalität dieser Libraries zu gebrauchen. So können Algorithmen oder Teile der Businesslogik in eine in C++ geschriebene “Shared Library” ausgelagert werden, die dann in allen Plattformen integriert werden können.
Dies klingt ja alles toll, aber will man heute wirklich noch C++ verwenden? Ein berühmtes Zitat von Bjarne Stroustroup, dem Erfinder von C++, lautet: “C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.” Auch wer einmal mit C oder C++ zu tun hatte, denkt da vor allem an Pointer, Memory Management und die damit verbundenen Probleme von Memory Leaks und die allgemein längere Kompilier- und Entwicklungszeit.
Um diese Probleme in den Griff zu kriegen, wird bei Ubique moderner C++ Code geschrieben. Wir verwenden die neusten Standards C++11 und C++14 und setzen auf die Standard Template Library (STL) mit ihren zahlreichen Datenstrukturen und Algorithmen. So ist es uns möglich auch in C++ effizient performante Libraries zu entwickeln.
Ein Beispiel wie C++-Code bei Ubique aussieht, zeigt das nachfolgende Codebeispiel. Hier kommen Lambda-Funktionen und Algorithmen aus der STL zum Einsatz, so dass man meinen könnte, es sei mit einer Scriptsprache wie Python geschrieben.
// Finde alle Elemente mit Wert > 5 std::vector<int> numbers { 1, 2, 15, 20, 25, 35, 45, 50 }; auto greaterThan5Count = std::count_if(numbers.begin(), numbers.end(), [](int x) { return (x > 5); }); std::cout << "Number of elements greater than 5: " << greaterThan5Count;
Um die Architektur unserer "Shared Library" zu beschreiben, ist folgender Vergleich naheliegend: Die “Shared Library” ist ein lokales Backend ohne Latenz. Wir behandeln nämlich die Aufrufe in die Shared Library wie ein Backend, das jedoch lokal ist. Dabei gibt auch die “Shared Library” Errorcodes zurück wie ein Server. Weil aber kein Request an einen Server geschickt werden muss, bekommt der Benutzer keine "Lädt Daten…" Nachricht zu sehen und merkt von diesem lokalen Backend gar nichts.
Bei Viadi, der schnellen Fahrplan-App, kommt ein lokales Backend zum ersten Mal zum Zug. Dort ist zum Beispiel die ganze Logik des Auto-Vervollständigens der Stationsnamen in einer in C++ geschriebenen “Shared Library” gelöst. Da wir eine aufwändigere Logik haben um aus einer Benutzereingabe eine Reihe von Stationen zurückzugeben ist das eine perfekte Anwendung für eine “Shared Library”, da dieser Code sonst in allen Smartphone-Clients hätte einzeln implementiert und bei einer Veränderung an drei Orten angepasst werden müssen.
Ein anderes Einsatzgebiet ist die Verschlüsselung: Eine state-of-the-art Implementation einiger Verschlüsselungsfunktionen findet sich in der Library NaCl (sprich: Salt). Eine “Shared Library” hilft uns natürlich auch hier in der Entwicklungszeit. Durch die Verwendung der gleichen kryptographischen Funktionen haben wir zusätzlich die Garantie, dass verschlüsselte Dateien unter allen Plattformen exportiert und importiert werden können.
Wir sind mit dieser Idee nicht alleine. Eine grosse Neuigkeit gab es dieses Jahr von den Entwicklern bei Dropbox, die ein Framework namens Djinni für die Kommunikation zwischen C++ und den Client-Sprachen Java und Objective-C veröffentlicht haben.