Wieder einmal Samstag, wieder einmal Zeit für einen neuen Eintrag im White Pony DevBlog. Hoffentlich habt ihr alle euren langen, schwarzen Ledermantel und eure coole Sonnenbrille dabei, denn heute geht es weiter auf unserem Weg durch die Matrix. Und für alle, die neu dazu gekommen sind, haben wir hier noch einmal eine kleine Erinnerungshilfe.

 

Letztes Mal beim White Pony DevBlog

Letzte Woche waren wir bereits auf einem Spaziergang durch den Code mit unserem Programmier-Gott in Ausbildung, Chris, unterwegs. Dabei haben wir die RESTful API kennengelernt, die für unsere App Eosis: Raiders of Dawn die Datenübertragung im Griff hat.

Die REST API kümmert sich also darum, dass keine Attribute, Items, Routeninformationen oder Speicherstände verloren gehen, und synchronisiert diese mit dem Server. Dazu schickt die REST API regelmäßige Requests an den Server und sorgt für einen reibungslosen Ablauf. Wie genau das aussieht, haben wir letzte Woche schon gesehen. Heute beschäftigt sich Chris daher ein wenig mit dem Management und der Erweiterung der Routeninformationen durch die EosisAPI.

 

Die EosisAPI – Eine Klasse für sich

Erinnert ihr euch noch an die Klasse mit dem Namen EosisAPI? Sehr gut! Einigen von euch ist sicher aufgefallen, dass diese Klasse als partial bezeichnet wurde und ihr habt euch bestimmt gefragt, warum das so ist. Die Antwort ist so einfach wie genial: Die EosisAPI besteht aus mehreren Dateien! Der Code, den ihr letzte Woche gesehen habt, liegt bei uns in der Datei namens Base.cs. Daneben haben wir aber zum Beispiel noch Routes.cs. Dieser Teil der API ist für alles zuständig, was sich um Routen dreht. Im Code sieht das folgendermaßen aus:

public partial class EosisAPI
{
     public static void GetRoutes(Action<List<Route>> done)
     {
          var request = new RestRequest(Method.GET);
          request.Resource = "routes";
          Instance.Execute<List<Route>>(request, response =>
          {
               done(response.Data.Payload);
          });
     }
}

Hier sehen wir auch, wie der RestRequest erstellt wird. Dieser definiert einfach nur die Methode (in diesem Fall GET) und die Ressource (hier routes). Dann wird Instance.Execute mit dem Typ List<Route> aufgerufen (falls ihr euch fragt, woher Instance kommt, solltet ihr euch das hier unbedingt einmal durchlesen). Das bedeutet, dass wir eine GET-Anfrage an unsere API an den Endpunkt /routes stellen und die Nutzdaten in ein Objekt vom Typ List<Route> gepackt werden.

 

Make the magic happen

Sobald die EosisAPI ihre Magie gewirkt hat, rufen wir die Action done auf. Genau wie vorhin teilen wir so dem Code, der diese Funktion aufgerufen hat, mit, dass wir fertig sind und er nun anderweitig weitermachen kann. Wie man diese Funktion nun verwenden kann, seht ihr in diesem Beispiel: einem Auszug aus dem Code für das Routen-Menü in Eosis: Raiders of Dawn.

public void RefreshRoutes()
{
     if (refreshing) return;
     ClearRouteList();
     if (!hasRefreshedManually)
          ToggleSpinnerLayout(false);
     refreshing = true;
     EosisAPI.GetRoutes((routes) =>
     {
          routes.ForEach(AddRouteToList);
          ToggleSpinnerLayout(true);
          refreshing = false;
          scrollRect.movementType = ScrollRect.MovementType.Elastic;
     });
}

Und so kann man die EosisAPI wunderbar erweitern, ohne dass eine Datei unendlich lang wird und man den Überblick verliert. Fast wie eine sich selbst bewässernde Pflanze aus kleinen Datenpaketen.

 

No-Go Nr. 3: Grenzenloses Vertrauen in die Technik

Aber ganz so perfekt, wie das klingt, ist es natürlich nicht. Auch unsere EosisAPI-Pflanze braucht noch ein bisschen menschliche Pflege. Denn auch unsere Datenübertragung ist nicht unfehlbar. Und von den vielen Programmier-Halbgöttern da draußen gibt es genügend, die sich bestimmt beim Lesen schon überlegt haben, wie leicht es wäre, unseren Server reinzulegen. Immerhin ist es sehr einfach, dem Server „falsche“ Daten zu schicken und sich somit zusätzliche Items oder Level zu ergaunern.

Damit das nicht passiert, braucht es eben doch immer die doppelte Kontrolle durch den Menschen (oder, in unserem Fall, Programmier-Gott in Ausbildung). Denn gerade bei sensiblen Daten wie Ingame-Währung oder Levels ist es wichtig zu überprüfen, ob die Daten stimmen, die der Server erhalten hat. Wenn ihr daher für euer eigenes Projekt ein ähnliches Feature habt, bei dem eine regelmäßige Datenübertragung stattfindet, dann merkt euch einfach folgenden Grundsatz, mit dem ihr euch vor falschem Dateninput schützen könnt: Traut niemals Daten, die euer Server geschickt bekommt und überprüft diese immer serverseitig. #indiedev #programming #nogo003

 

Die rote oder die blaue Pille?

Wenn ihr nach dieser Faktenflut noch immer nicht genug habt, dann haben wir jetzt eine gute Nachricht für euch: Nächste Woche geht unser Ausflug in die Matrix in die nächste Runde. Wir schlucken mutig die rote Pille und erkunden gemeinsam mit Paul das Kampfsystem bei Eosis: Raiders of Dawn.

Falls ihr aber jetzt nur noch Bahnhof versteht, dann lehnt euch einfach zurück und vertieft euch doch ganz entspannt mit einer blauen Pille in der Welt der Illusionen. Stöbert weiter durch unseren Blog und kuschelt euch dabei gemütlich in euren Lesesessel.

Oh, und keine Panik: Sobald wir wieder aus den Untiefen der Matrix auftauchen, erfahrt ihr das natürlich sofort – folgt uns dazu einfach auf Facebook und Twitter. Egal, für welche Pille ihr euch nun entscheidet, wir wünschen euch noch ein schönes Wochenende und freuen uns darauf, wenn ihr auch nächste Woche wieder dabei seid!

Sollen wir dich auf dem Laufenden halten?


Keine Sorge, wir schreiben keinen täglichen, wöchentlichen oder monatlichen Newsletter. Aber wir geben dir gerne per E-Mail Bescheid, sobald bei uns oder unserer App EOSIS etwas Großartiges passiert, wenn du uns deine Mailadresse mitteilst.