Print Friendly

Generisches vs. Generiertes SDK

Das Internet ist heute voll von Services, die tolle Dinge können und vielleicht genau das haben, was man noch für sein perfektes Projekt benötigt. Um aber diese nutzen zu können, muss man sich zuallererst einmal mit der Schnittstelle (API) des Services auseinandersetzen. Das heisst viel lesen, coden und testen, bis alles funktioniert. Um diese eher lästige Einstiegshürde zu minimieren, bieten viele APIs parallel ein Software Development Kit (SDK) an. Dieses wird bereits in der Programmiersprache des eigenen Projekts ausgeliefert und kann mit relativ geringem Aufwand in den eigenen Client Code integriert werden.

Hier eine Gegenüberstellung Generisches vs. Generiertes SDK

Nun ist SDK nicht gleich SDK, und deshalb wollen wir euch an dieser Stelle eines der Hauptmerkmale erklären, das auch den apiOmat von anderen Backend as a Service Anbietern grundlegend unterscheidet. Sobald man nämlich als Nutzer einer API dort eigene Strukturen oder Modelle erzeugen kann stellt sich die Frage, wie diese in dem SDK widergespiegelt werden sollen. Dazu gibt es zwei Varianten:

Bei einem generischen SDK sind eigene Strukturen (Klassen, Modelle, etc) nicht enthalten. Die individuelle Modellierung erfolgt dann im eigenen Client Code, und zwar für jede Zielsprache (ObjectiveC, Java, Javascript,…) separat. Meist werden dazu Key-Value Paare benutzt, wie das folgende Beispiel für Java zeigt:

BaaSObject highScore = new BaaSObject("HighScore");
highScore.put("score", 2999);
highScore.put("name", "Jordan");
highScore.save();

Bei einem generierten SDK enthält das SDK bereits vorgefertigte Klassen für alle eigenen Datenmodelle mit entsprechenden Methoden zum Zugriff auf die Attribute. Im folgenden Beispiel wurde eine Klasse Highscore mit Attributen “score” und “name” im Backend angelegt. Das generierte Java-SDK enthält daraufhin eine entsprechende Klasse mit zugehörigen Methoden, die wie üblich verwendet werden können:

HighScore score = new HighScore();
score.setScore(2999);
score.setName("Jordan");
score.save();

So ähnlich die Codeschnipsel aussehen, so grundlegend verschieden sind jedoch die Konsequenzen, die sich aus beiden Varianten ergeben. Bei apiOmat verwenden wir generierte SDKs und wollen euch nun zeigen, warum wir denken, eure Arbeit damit erleichtern zu können:

Keine Tippfehler

Bei generischen SDKs liefert schon ein highScore.get("Name") aufgrund des groß geschriebenen “N” kein Ergebnis. Einzelne Tippfehler oder vergessenes Nachziehen von Änderungen führen hier zu schwer lokalisierbaren Fehlern. Natürlich ist es möglich Konstanten zu nutzen oder Wrapper-Klassen mit Gettern und Settern zu schreiben, aber auch dies funktioniert nur innerhalb einer Zielplattform; für eine Portierung nach ObjectiveC müsste die Highscore Klasse noch einmal komplett neu programmiert werden, die Anzahl möglicher Fehlerquellen verdoppelt sich.
Bei einem generierten SDK wird die initiale Modellierung und auch nachfolgende Veränderungen des Datenmodells jeweils nur an einer Stelle vorgenommen, nämlich im Backend. Auf der Clientseite muss der SDK Code an keiner Stelle mehr verändert werden. Bei Änderungen am Datenmodell lädt man einfach ein neues SDK herunter.

Schneller

Neben der Fehleranfälligkeit spielt natürlich auch der zeitliche Faktor eine Rolle; angenommen, eine App soll für Android, iOS und ein kleines Webfrontend mit PHP parallel entwickelt werden. Dann müssen die Modelle bei einem generischen SDK dreimal in verschiedenen Sprachen erstellt werden. Kommt später ein weiteres Feld zu der HighScore Klasse hinzu, muss dieses wiederum in drei Sprachen angepasst werden.
Bei einem generierten SDK finden Änderungen immer zentral im Backend statt, danach muss das SDK für die Sprachen heruntergeladen und eingebunden werden. Der Aufwand, vom Backend abgesehen, beschränkt sich somit meist auf einen Download mit Copy&Paste des Inhalts.

Komfortabler

Da der Inhalt des generierten SDKs in objektorientierter Form ausgeliefert wird (und auf Serverseite ebenso), bieten sich neben den zwei oben genannten noch einige weniger offensichtliche, wenn auch sehr hilfreiche Vorteile:
* Man “sieht” den Klassen sofort an, welche Attribute sie beinhalten. Bei Key-Value Paaren müsste man auf dem Backend nachsehen.
* Der Ansatz bietet – zumindest in den Zielsprachen, die dies selbst unterstützen – Typsicherheit. Es ist also nicht möglich, als “score” eine Zeichenkette mitzuschicken. Derartige Fehler fallen schon direkt in der Entwicklungsumgebung auf.
* Weiterhin bietet die Objektoriertierung natürlich die Möglichkeit zur Vererbung; im Backend kann eine Vererbungshierarchie modelliert werden, die sich auch im SDK wiederfindet. Bei komplexeren Datenmodellen erleichtert dies die Arbeit ungemein, denn hier würde sich der Aufwand bei Key-Value Paaren wiederum vervielfachen.

Wir hoffen, wir konnten euch von den Vorteilen der generierten Welt überzeugen und freuen uns auf eure Kommentare!

Google+LinkedInTwitterFacebook

Veröffentlicht am:
Nutzername / E-Mail
Passwort

Login
Hast du noch keinen Account?
Signup
Melde dich kostenlos und unverbindlich an.
Nutzername
E-Mail
Passwort
Passwort wiederholen

Signup
Hast du bereits einen Account?
Login