so oft man möchte? Aber wie würde man diese Funktionalität in seine eigene App implementieren? In diesem Artikel zeige ich auf, wie ich dieses Problem bei Pixelboy gelöst habe.

  1. Die effektivste aller Varianten ist natürlich es ganz wegzulassen. In diesem Fall würde die App überhaupt keine zusätzliche Ressourcen verbrauchen.

    Implementiere nie ein Feature nur um des Features-Willen! Prüfe es vorher auf seine Existenzberechtigung. Das KISS- und Eisenhower Prinzip helfen mir bei solchen Entscheidungen.

  2. Alle anderen Möglichkeiten münden darin, dass man den App Status speichert und bei Bedarf wiederherstellt.

Pixelboy ist im Inneren relativ simpel aufgebaut: Es gibt nur drei Variablen, die alle wichtigen Informationen beinhalten.

  1. Frames = {} ist eine Liste mit Pfaden, zu Bildern aus der Animation. Die eigentlichen Bilder liegen im Ordner Documents - ergo werden diese auch nicht direkt in der Varibale gepuffert.
  2. CurrentFrame = 0 ist die id des aktuellen Bildes aus Frames. Frames[CurrentFrame] gibt also den Pfad des aktuellen Bildes aus Documents zurück.
  3. Versions = {} ist der Speicherort für die einzelnen Status.

Wenn in Pixelboy ein neues Frame erzeugt wird, legt das System automatisch ein leeres Bild in Documents ab. Der Pfad dazu wird in der Varibale Frames, mit einer entsprechenden id gespeichert. - Diese id wird fortan CurrentFrame zugewiesen.

Verändert man ein Frame malerisch, wird erneut ein Bild erzeugt, dessen Pfad unter Frames[CurrentFrame] entsprechend abgeändert wird. - Beim Löschen wird logischerweise ein Bild aus Frames und Documents getilgt.

Jegliche Änderungen an einem Frame (erstellen, verändern, löschen) speichern den aktuellen Status in der Variable Versions.

Die Variable Frames verkörpert also den jeweils aktuellen Status meiner App, nach jeder Operation! Und eben diesen Status speichere ich in Versions ab.

In Codea gibt es die Möglichkeit Bilder direkt in Varibalen zu puffern: local imageInMemory = image(width, height). Warum lagere ich also die Bilder in Documents aus? Die bewusste Entscheidung nur Zeichenketten in den Variablen zu speichern, statt die Bilder, wie eben erwähnt, ist den technischen Grenzen des iPad geschuldet. Ein Beispiel dafür ist, dass der Lua RAM Speicher auf ~4MB begrenzt ist! Würde ich Bilder (Frames) in 1024x768px puffern, wäre dieses Limit wohl schnell erreicht. - Hiermit, kann ich beinahe unendlich viele Frames anlegen ohne auch nur annährend an die physischen Grenzen zu stoßen. Nunja, eine Restriktion hätte man noch: die Speicherkapazität des iPad. Aber selbst das kleinste Model mit 16GB sollte das zur Genüge abdecken.

Mit der Zeit wächst die Länge der Versions Liste und damit auch der Ressourcen-Verbrauch. Ebenso nimmt auch die Speicherbelastung durch die abgelegten Bilder in Documents zu. Um dem entgegen zu wirken, gibt es einige sinnvolle Konzepte:

Bild zu (1.)

  1. Angenommen ich erstelle ein neues Projekt und male drei Striche auf das aktuelle Bild. Somit habe ich drei verschieden #Versions (Status) erzeugt. Nun drücke ich 3x Widerrufen und male anschließend erneut ein Strich auf das Bild. Letztlich hätte ich vier Versions von denen ich eigentlich nur eines behalten müsste! Warum? Weil ich wieder von vorn zu zeichnen beginne und somit keine Aktionen zum Wiederholen haben kann! siehe Bild zu (1.)
  2. Für den (unwahrscheinlichen) Fall dass unseren Variablen doch das 4MB Limit des RAM Speichers erreichen, checken wir kontinuierlich, vor jedem Versions (Status) Backup, den aktuellen Speicherverbrauch und entfernen successive älteste Einträge aus Versions und damit auch abgelaufene Bilder aus Documents.
  3. Zu Beginn eines jeden neuen Projektes entfernen wir alle Dateien der vorhergehenden Sitzung aus Documents.

Um das Ganze abzurunden gibt es anschließend noch einige Code-Auszüge aus Pixelboy den kompletten Sourcecode von Pixelboy.