LibGDX in Android Studio

Wie oben erwähnt beschäftigt sich dieser Artikel ausschließlich mit LibGDX für Android. Der Erstellungsvorgang der Projektdateien zur Integration in Android Studio ist denkbar einfach. Von der Homepage erhält man eine .jar Datei – welches die ganze Arbeit bezüglich Ordnerstruktur erledigt.

Box2d ist die Physics Engine die von LibGDX mitgeliefert wird. Sollte man im Nachhinein noch weitere Extensionen hinzufügen, kann man das ganz einfach über das Gradle File in Android Studio erledigen. Später mehr dazu! Nachdem die wunderbare Ordnerstruktur im Ordner der Wahl erstellt wurde, kann man im Android Studio über File->Import Projects das Projekt importieren. Einfach in der Ordnerhierachie im Ordner libs build.gradle auswählen – fertig. Die App sollte bereits auf dem Smartphone laufen – sieht zwar (noch)  nicht sehr sexy aus aber ein rascher Anfang!

Game Aufbau – erste Schritte

Eins soll dem Java-Programmierer hier klar sein: der normale App-Aufbau mit Activities usw. findet mit LibGDX nicht statt. Hier wird das Game vielmehr in einzelne Screens aufgeteilt, die wiederum den Spieleinhalt je nach Framerate rendern. Aber eins nach dem anderen.

Vorgehensweisen variieren hier – genaue Vor- und Nachteile der einzelen Herangehensweisen sind mir nicht ganz klar geworden, ich denke es hängt hier einfach vom Programmierstil ab. Ich habe mich dafür Entschieden eine Art Main zu erstellen welches die diversen Screens beinhaltet und sich um den Screenwechsel kümmert. Die Screens wiederum kümmern sich um die Darstellung, Rendern und wenn nötig um die Spielelogik. Natürlich kann man das je nach Spielekomplexität anders schachteln – bei einigen wird vielleicht die Main-Klasse nicht nötig sein.

Ein grober Aufbau wäre:

Wichtig: Eure Main Klasse muss von der Klasse Game erben und erhält so die Funktion create – in der sich dann auch der Einstieg in euren Programmiercode befinden wird. Hier ist ein Beispiel für die Funktionen des Screen-Wechsels, dazu wird einfach die Methode setScreen der Game-Klasse verwendet. Zur statischen Klasse AssetLoader kommen wir später.

public class GameMain extends Game
{
    private StartScreen startScreen;
    private GameScreen gameScreen;
    private IntroductionScreen introductionScreen;

    @Override
    public void create() {
        AssetLoader.load(); //load all assets!!
        this.setStartScreen();
    }

    public void setStartScreen()
    {
        startScreen = new StartScreen(this);
        setScreen(startScreen);
    }

    public void setGameScreen()
    {
        gameScreen = new GameScreen(this);
        setScreen(gameScreen);
    }
}

Eure verschiedenen Screens – also zum Beispiel der Anfangs-Screen, der Extras-Screen und natürlich der InGame-Screens, müssen das Interface Screen implementieren – denn das liefert euch gleich die sechs heiligen Methoden des Game-Development mit LibGDX:

• show() – wird aufgerufen wenn dieser Screen durch setScreen aufgerufen wird – hier sollte der Grundaufbau der graphischen Elemente stattfinden
• render() – wird jedes Frame aufgerufen und rendert die Grafiken – es kann immer nur ein Screen gleichzeitig gerendert werden. In die ersten Zeilen der render() Methode gehören diese zwei kryptischen Zeilen (diese dienen zum löschen des Screens vor dem erneuten Zeichnen – und in diesem Fall würde der Hintergrund blau gemalt werden):

  Gdx.gl.glClearColor(34 / 255f, 187 / 255f, 255 / 255f, 1);

  Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

• pause() – wird aufgerufen, wenn die App in den Hintergrund gelegt wird (sollte man auch händisch aufrufen, wenn man das Spiel manuell pausiert)
• resume() – wird aufgerufen, wenn die App vom Hintergrund wieder in den Vordergrund gerufen wird (sollte man auch händisch aufrufen, wenn man das Spiel manuell fortsetzt)
• hide() – wird aufgerufen, wenn durch die setScreen Methode ein anderer Screen aufgerufen wird
• resize()
• dispose() – wird von selbst nicht aufgerufen – sollte aufgerufen werden wenn der Screen alle Elemente freigeben soll (Stages, Tables, Sprites)

Wie man sich denkt ist während eines laufenden Spiels das Herzstück des Programmiercodes die render() Methode der GameScreen Klasse (oder wie auch immer euer In-Game Screen heißen mag).

Sprites, Buttons, Skins, … – alles rund um ums Interface

Das Look’n’Feel ist bei einem Game natürlich das A und O. LibGDX liefert mit dem Nightlies build einige nützliche Tools rund ums Interface und Grafik erstellen. Beginnen wir mit einigen wichtigen Elementen.

Exkurs AssetLoader

Bevor wir mit dem Erstellen von Grafiken und Buttons weitermachen, kommen wir zu der mysteriösen Code-Zeile

AssetLoader.load();

in der oben gezeigten GameMain Klasse. Wie gewohnt sind beim Android-Development Assets alles “externe” was währen der Laufzeit der Applikation verwendet werden soll. Grafiken, text, xml, json, videos und quasi alles Multimedia-mäßige gehört in den asset-folder der Projektes. Der AssetLoader ist meine selbst erstellte statische Klasse, die am Anfang alle für das Spiel benötigten Assets in eine statische Variable lädt – damit man einfach von überall aus auf diesen asset zugreifen kann. Ein einfaches Beispiel wäre:

tree = new TextureRegion(graphic_atlas.findRegion("tree"));

Nun habe ich die Möglichkeit in jeder meiner Klassen mit AssetLoader.tree einen Baum zu zeichnen. Quasi alle Elemente, die wir nachher erstellen werden, werden mit dem AssetLoader geladen. Mehr dazu jedoch später.

Bitmap Font

Um alle Schriftarten ohne Probleme anzeigen zu können werden Bitmap Fonts verwendet. Hierfür gibt es diverse Tools. Diese erstellen im Prinzip ein großes Bild aller zu verwendeten Zeichen und einem File, in dem steht bei welchen Koordinaten welches Zeichen zu finden ist. Im LibGDX Wiki werden einige Tools empfohlen – unter anderem Hiero oder GlyphDesigner. Ich habe mich für Hiero entschieden – verschiedene Möglichkeiten es zum Laufen zu bringen (sei es über die Konsole oder über Gradle) findet man hier.

Das Erstellen der Font ist denkbar einfach: die Zeichen, die benötigt werden auswählen, Größe einstellen, Farbe auswählen und eventuelle Effekte hinzufügen, speichern und fertig. Das .png File und das .fnt File müssen natürlich beide sicher in den asset Ordner der Projekts abgelegt werden – damit die Applikation auch darauf zugreifen kann.

Skins

Um unsere Bitmap Font nun in Labels und Buttons zu verwenden, erstellt man im besten Fall einen Skin für alle Styles, die man verwenden will. Ein Skin ist im Prinzip eine JSON-Datei in der alle Styles definiert werden. Als erstes erstellt man eine BitmapFont, hernach kann man Farben definieren, dann gewünschte Labels und Buttons:

{
 "com.badlogic.gdx.graphics.g2d.BitmapFont": {
    "cooperBlackSmall": { "file": "fonts/cooperBlack_small.fnt" },
 },
 "com.badlogic.gdx.graphics.Color": {
    "white": { "r": 1, "g": 1, "b": 1, "a": 1 },
    "black": { "r": 0, "g": 0, "b": 0, "a": 1 },
 },
 "com.badlogic.gdx.scenes.scene2d.ui.Label$LabelStyle": {
    "textWhiteSmall": { "font": cooperBlackSmall ,"fontColor": white },
 },
 "com.badlogic.gdx.scenes.scene2d.ui.TextButton$TextButtonStyle": {
    "menuButton": { "up": menu_button_blue_normal, "down": menu_button_blue_pressed, "font": cooperBlackSmall},
 },
}

Die JSON-Datei wird in den asset Ordner gespeichert. Wie wir zu den Grafiken für die Button-States kommen wird im nächsten Teil erklärt – also keine Sorge.

Buttons und Labels

Für einen Button fehlt uns noch etwas essentielles: die Grafiken. Für die simpelste Version wären dies zwei Grafiken: eine für den Button selbst und eine für den “down”- Modus – also wenn dieser geklickt oder getoucht wird. Damit sich die Buttons, dann auch optimal an den Text anpassen können, sollte man die Grafiken vorerst einmal 9patchen. Dies bedeutet, dass man die Bereiche definiert, welche im Button dehnbar sein sollten und auch die Bereiche in denen Inhalt stehen darf. Die Android-sdks kommen mit einem einfachen grafischen Tool dafür. Es befindet sich im sdk-Ordner/tools/draw9patch und sieht in etwa so aus:

Die schwarzen Linien an der oberen und der linken Seite definieren den Dehnbereich die Linien an der rechten und unteren Seite den Content-Bereich. Wenn man alles Speichert sollten die Grafiken die Endung 9.png haben. Der nächste Schritt wäre nun, beide Grafiken bzw. alle Interface Grafiken mit einem Texturepacker in ein großes .png zu packen (ähnlich wie bei der Bitmap-Font). Dies bietet performance- und speichertechnisch große Vorteile. Anstatt tausend Grafiken laden zu müssen, lädt die Applikation nur die gepackte Datei und erhält von einer externen Datei wieder die Positinen der einzelnen Grafiken im Bild. Auch einen TexturePacker findet man in der Nightlies-Distribution von LibGDX. Da bei mir die Graphishe Oberfläche allerdings nicht funktionier hat, habe ich das Ganze dann über die Konsole gemacht. Man könnte auch über Gradle die Tools zur IDE hinzufügen und von dort aus laufen lasse. Eine genaue Beschreibung wie ihr eure Grafiken mit dem TexturePacker packt findet ihr hier. Herauskommen sollte eine Text-Datei meist mit der Endung .pack oder .atlas und eine .png-Datei, die in etwa so aussehen könnte:

Ab damit in den asset-Folder! Weiter geht es mit dem Laden des TextureAtlas und des Skins im AssetLoader:

TextureAtlas buttons_atlas = new TextureAtlas("skins/buttons_stuff.pack");
Skin skin = new Skin(Gdx.files.internal("skins/skin.json"),buttons_atlas);

Da wir nun unsere Styles in einem Skin definiert haben, die Grafiken in mit einem Texturepacker gepackt, die passende Schrift als Bitmap-Font gespeichert und alles im AssetLoader geladen haben, können wir endlich loslegen. Ein Label wird zum Beispiel folgendermaßen instanziert:

private Label highscore_label = new Label("Highscore: 40",AssetLoader.skin,"textWhiteSmall");

Unser Highscore-Label wird als Klassenvariable instanziert, der erste Parameter ist der Text, der zweite greift auf unser JSON-Skin-File über den AssetLoader zu und der dritte Parameter zeigt auf den Namen des Styles den wir im Skin definiert haben. Ein Beispiel für einen Funktionierenden Button hätten wir hier:

private TextButton buttonPlay = new TextButton("Go!", AssetLoader.skin,"menuButton");

Damit der Button allerdings noch klickbar wird müssen wir zwei Dinge tun. Erstens: In dem Konstruktor des Screens müssen wir angeben, dass die Stage (Erklärung zu Stages findet ihr im nächsten Abschnitt) auf die der Button hinzugefügt wird, auf die Eingaben des Users reagieren soll.

Gdx.input.setInputProcessor(stageName);

Zweitens: einen ActionListener auf den Button hängen (meist in der show() Methode):

buttonPlay.addListener(new ClickListener(){
                @Override
                public void clicked(InputEvent event,float x, float y) {
                    //HIER DEIN CODE WENN AUF DEN BUTTON GEKLICKT WURDE
               }
        });

Anordnen der Elemente

Die Andordnung der Elemente erfolgt durch Stages und Tables. Die Elemente werden in einem Table angeordnet – dieser übernimmt dann die Ausrichtung am Screen des Smartphones. Das Table wird wiederum zur Stage hinzugefügt. Der Aufbau und die Anordnung erfolgt meist in der show() Methode des jeweiligen Screens. In der render() Methode wird das Ganze dann noch in jedem Frame gerendert bzw. gezeichnet. Will ich jetzt zum Beispiel ein Label und einen Button untereinander in der Mitte des Screens anordnen, könnte das so aussehen:

startTable.add(highscore_label).padBottom(30).row();
startTable.add(buttonPlay).width(500).padBottom(30).row();
startTable.setFillParent(true);
startStage.addActor(startTable);

Es gibt diverse Funktionen für die Ausrichtung und Anordnung der Elemente. row() schließt eine Zeile ab. Weiteres zum Table findet man hier. Der obere Code-Auszug würde in der show() Methode stehen. Damit man den Aufbau auch dann zur Laufzeit bewundern kann müsste man noch in die render() Methode folgendes schreiben:

startStage.act();
startStage.draw();

Animations

Da wir nun wissen, wie man statische Elemente zeichnet, kommen wir zum spannenden Teil – die Animationen. Einface Animationen – zb eine konitnuierliche Fortbewegung entlang der x-Achse erfolgt in der render() Methode indem man zu dem jeweiligen Element einfach immer einen bestimmten Wert zur x-Position dazuaddiert. Allerding sollten dynamische Elemente nicht mit einem Table positioniert werden sondern über einen sogenannten Spritebatch immer neu gezeichnet werden. Auch dies erfolgt natürlich jedes Frame und steht deshalb in der render() Methode des jeweiligen Screens. Hier ein einfaches Beispiel:

batch = new SpriteBatch(); //instanzierungen erfolgen natürlich im Konstruktor
tree = new Sprite(new TextureRegion(AssetLoader.tree));
tree.setPosition(400,400);

batch.setProjectionMatrix(camera.combined); //ab hier alles in der render() Methode
batch.begin();
tree.setPosition(tree.getX()+5,tree.getY());
tree.draw(batch);
batch.end();

Die ersten drei Zeilen dienen der Definition des SpriteBatches und einem Sprite. Der Sprite zeigt eine TextureRegion aus einem TextureAtlas an. Dies bedeutet einfach er zeigt auf eine spezielle Grafik in einem gepackten .png. Praktischerweise können wir alle unsere einzelnen Grafiken (besonders wenn man sie öfter als einmal verwendet) vorher im AssetLoader laden:

TextureAtlas graphic_atlas = new TextureAtlas("skins/gameGraphics.pack");
tree = new TextureRegion(graphic_atlas.findRegion("tree"));

Zuerst wir die gesamte .atlas oder .pack Datei geladen und nachher mit der Funktion .findRegion kann die gewünschte Region bzw. das gewünschte Einzelbild gefunden werden. Der Name in der Klammer bezieht sie auf den Dateinamen der Grafik bevor sie gepackt wurde.

Bevor gezeichnet wird muss der Batch auf die Kamera ausgerichtet werden. In LibGDX benötigt jedes Spiel eine Kamera – sie zeigt auf einen speziellen Teil der gesamten Spielewelt – eben das was man am Smartphone dann auch sieht. Mehr zu Kameras findet ihr hier. Danach wird mit begin() der Anfang der Zeichensequenz eröffnet. Der Baum wird um jeweils 5 Einheiten auf der x-Achse verschoben und dann gezeichnet. Nicht auf das Beenden der Sequenz mit .end() vergessen!

Sprite Animations

Da aber nicht immer eine einfache Verschiebung eines Elemente für realistische Ergebnisse sorgt ist es auch wichtig, die Elemente selbst animieren zu können. Soll eine Figur laufen können ist natürlich der erste Schritt alle benötigten Grafiken einer Gehbewegung zu malen und diese zu packen. Im primitivsten Fall wären dies zwei Grafiken:

Diese zwei Grafiken müssen auch im AssetLoader wieder als TextureRegion definiert werden. Nun zur eigentlichen Animation. Man benötigt ein TextureRegion Array in dem alle States der Animation gespeichert werden. In diesem Fall hätte das Array eine Länge von 2. Hernach muss die Animation definiert werden – als Parameter werden die gewünschte Framerate (also Schnelligkeit) und das Array übergeben.

walkFrames = new TextureRegion[2];
walkFrames[0] = AssetLoader.pug_walking1;
walkFrames[1] = AssetLoader.pug_walking2;
walkAnimation = new Animation(0.25f,walkFrames);

In der render() Methode des jeweiligen Screens kann dann gezeichnet werden, den Keyframe der angezeigt werden soll errechnet sich LibGDX aus der vergangenen Laufzeit des Spiels:

batch.start();
batch.draw(walkAnimation.getKeyFrame(Gdx.graphics.getDeltaTime(),true),posX,posY);
batch.end();

Andere interessante Features – weiterführende Links

Mir ist klar, dass dieser Artikel nur der allererste kleinste Schritt in Richtung Game-Development ist. Es geht vorwiegend um die Interfacegestaltung und das Verständnis des Grundgerüsts von LibGDX. Deshalb liste ich hier noch einige Tipps und Tricks und Tutorials die mir sehr weitergeholfen haben:

Sollte man auch Schriften, Buttons, einfache Sprites mit Tween-Animations versehen wollen, stößt man nur mit LibGDX leider an Grenzen. Dafür empfehle ich die Klasse Tween Universal, welche einfach über Gradle zu LibGDX hinzuzufügen ist und auf JEDE! Klasse anwendbar ist. Eine Beschreibung für die Integration in euer LibGDX Projekt findet ihr hier und ein Tutorial für die Anwendung mit LibGDX Objekten hier.

Wer Lust hat einen Shooter oder ein Jump’n’Run zu programmieren sollte auf die Physics Engine Box2D nicht verzichten. Ein super Tutorial zum Einstieg damit findet ihr hier.

Was wäre ein Android-Game ohne gute und effiziente Gestenerkennung. Die Doku dafür ist zwar super, doch wer kein großer Mathematiker ist kann sich beim Ausrechnen der swipe-Gesten schnell verlieren. Hier ist ein großartiger Post darüber wie man schnell erkennen kann ob eine Swipegeste nach oben, unten links oder rechts ausgeführt wurde und bietet eine tolle Grundlage dafür noch komplexere Gestenerkennung umzusetzen.

Eine tolle Seite für allerhand gute Tutorials bezüglich LibGDX:  http://libdgxtutorials.blogspot.co.at/

Auch eine sehr tiefgehende Tutorialreihe (inklusive TileMaps mit Level-Editor!) mit ausführlichen Erklärungen: http://www.gamefromscratch.com/page/LibGDX-Tutorial-series.aspx

The post Erste Schritte mit LibGDX – Android appeared first on Mobile USTP MKL.

Hier ein paar Aussagen über Internet-Nutzung:

• Im Durchschnitt verbringt ein Erwachsener 5 Stunden pro Tag im
  Internet
• Angestellte senden und empfangen in etwa 40 E-Mails am Tag und
  20 Benachrichtigungen
• Leute besuchen etwa 10 Websites pro Tag
• Ein Smartphone-Nutzer nimmt sein Smartphone etwa 1.500 Mal in
  der Woche in die Hand

Ladezeiten um die 10 Sekunden sind, vor allem in mobilen Netzwerken, zur Normalität geworden. Der Grund liegt teilweise in der Komplexität der Websites aber auch darin, dass Websites oft nicht so ausgeliefert werden, wie es für Browser gut wäre. In diesem Blog-Post wurden etwa 30 Artikel aus unterschiedlichsten Gebieten der Performance-Optimierung zusammengefasst. Dennoch ist dies nur ein sehr kleiner Teil aller möglichen Optimierungslösungen. Mit Hilfe dieses Blog Posts ist es jedoch möglich sich einen Überblick über die Funktionsweise von Browsern, mögliche Optimierungsbereiche und nützliche Tools zu verschaffen.

Funktionsweise der Browser

Zu verstehen wie Browser funktionieren kann helfen Websites performanter zu entwickeln.
HTTP Request

Die Grundlage von allem, was im Web passiert, ist der Austausch von Daten zwischen einem Client (Browser) und einem Server. Sobald der
User Enter drückt wird ein Initialer Request zum DNS geschickt, der die URL in die IP-Adresse des Servers übersetzt.

Zumindest ist das die vereinfachte Vorgehensweise für Geräte, die mit einem LAN oder WLAN verbunden sind. Mobile Geräte müssen einen Extra-Schritt machen, denn der Browser sendet den Request zunächst noch an einen Sende-Mast in der Nähe. Aus diesem Grund kann das Aufbauen einer Verbindung auf mobilen Geräten bis zu zwei Sekunden länger dauern.

Ruft der Browser eine HTML-Datei auf, bekommt er sie Stück für Stück vom Server zugeschickt und parst sie prozedural. Dabei achtet er auf Verweise zu anderen Dateien im HTML-Dokument, die ebenfalls geladen werden müssen. Die HTML Datei wird dabei in einen strukturierten Baum konvertiert, bekannt als DOM (Document Object Model). Wenn der DOM erstellt wurde, kann dieser danach mit JavaScript manipuliert werden. CSS gibt den Elementen ihr Aussehen. Das Parsen von HTML ist sehr kompliziert und füllt ganze Bücher. Leider gibt es auch Unterschiede von Browser zu Browser. Wichtig zu wissen ist aber folgendes:

• CSS funktioniert am besten, wenn es geladen wird BEVOR das
• HTML Dokument im Browser sichtbar ist.
  JavaScript hingegen wird oft erst dann angewendet NACHDEM
  Elemente geladen wurden.

Dies führt uns zum nächsten Thema:

Rendering und Blocking
Ein HTML, das sehr schnell geladen werden kann ist eines, welches auf keine externen Dateien verweist. Doch sind solche HTML-Dateien in der heutigen Zeit eher untypisch. Eine typische HTML-Datei verweist auf eine Vielzahl von Dateien wie CSS, JavaScript oder Bilder. Standardmäßig warten Browser mit dem Rendern von Inhalten bis CSS und JavaScript geladen wurden. Dieses Verhalten ist als Blocking bekannt.

Performance Budget

Ein gutes Performance Budget bringt User Experience und Browser Experience in Einklang. Zu einer guten User Experience gehören Milestone Timing und der Speed Index. Das Smashing Magazine empfiehlt für den WebPageTest einen Speed Index von 1000. Außerdem sollen alle HTML, CSS und JavaScript Dateien mit 14KB geladen werden können. Der Speed Index ist die durchschnittliche Dauer, bis sichtbare Teile einer Website geladen werden konnten. Sie wird in Millisekunden angegeben und ist abhängig von der Größe des Viewports. Diese Art Performance ist natürlich sehr sinnvoll. „Above the fold“-Inhalte sollen rasch geladen werden. Dazu gehört beispielsweise nicht der Footer einer Website, denn dieser ist typischerweise beim Laden einer Webpage zuerst einmal außerhalb des sichtbaren Bereichs Meist legt man sich Meilensteine, die eingehalten werden sollen. Beispielsweise dass die gesamte Website in 5 Sekunden geladen werden soll und dabei das Budget von z.B. max. 10 Bilder und 2 Webfonts oder 2 Bilder und 10 Webfonts eingehalten werden soll. Doch wie genau kommt man zu so einem Meilenstein? Zunächst wird eine Performancenalyse der eigenen Webpage. Danach sieht man sich die Konkurrenz-Websites an. Eine
Statistik besagt, dass Leute etwas als schneller oder langsamer wahrnehmen können, wenn etwa ein 20% Unterschied besteht. So sucht man sich am Besten die
schnellste Konkurrenz-Website und versucht diese bezüglich Ladezeit um 20% zu unterbieten.

Diese Ladezeiten, können je nach verfügbarem Netzwerk (WLAN, 3G, Edge) in Kilobyte umgerechnet werden. 1.194 Sekunden sind bei 3G Verbindung 114 KB. Dieser Wert kann auf die verschiedenen Dateien, die geladen werden sollen aufgeteilt werden.

CSS

• Nicht benötigte Klassen und IDs entfernen
• Selektoren verkürzen und Specificity reduzieren
• eigene Print Style-Sheets vermeiden oder im Haupt-Stylesheet
  inkludieren, damit das Rendering nicht blockiert wird

Bilder

• PNGs verkleinern
  Der Vorteil von PNG gegenüber JPEG ist klarerweise die Möglichkeit von Transparenz. Doch die Kompression bei JPEGs ist um einiges besser. Mit einem SVG ist es möglich die Vorteile von beiden Bildformaten zu kombinieren. Dazu wird ein Bild als JPEG gespeichert und so weit komprimiert, wie man möchte. Dazu speichert man ein PNG, das als Maske dient. Es enthält nur weiß und schwarz und hat daher eine sehr geringe Dateigröße. Diese
  beiden Bilder werden in einem SVG so kombiniert, dass sie wiederum ein PNG ergeben.
  Hierfür gibt es verschiedene Tools:
  – MozJPEG (https://github.com/mozilla/mozjpeg)
  Artikel darüber: http://calendar.perfplanet.com/2014/mozjpe-3-0/
  – tinypng (https://tinypng.com/)
  – JPEGmini (http://www.jpegmini.com/)
  – ImageAlpha (http://pngmini.com/)
• SVGs verwenden
  SVG sind sehr beliebt seit Responsive Webdesign, doch wie bei jedem anderen Dateiformat, gibt es auch hier Möglichkeiten zu optimieren.
  • Gzip Komprimierung aktivieren
    SVGs sind textbasiert und eignen sich daher hervorragend für eine verlustfreie Komprimierung. Damit können um die 80% Dateigröße eingespart werden.
  • Mehrere Requests bei der Verwendung des <object>-Tags vermeiden
    Der <object>-Tag ist eine sehr beliebte Methode um SVGs einzubinden, weil er viele Vorteile bietet. Unter anderem ermöglicht er das Einbinden eines Fallbacks für Browser, die SVGs nicht unterstützen. 
    Doch hier wird von Browsern, die SVGs unterstützen sowohl das SVG als auch die Bitmap-Datei geladen. Dies kann jedoch wie folgt umgangen werden:
  • SVGs nicht als Data URIs einbetten
  • SVGs nicht mit base64 inlinen, sondern mit charset=utf-8
  • SVG Sprites verwenden
    Sprites sind schon seit Jahren bekannt und werden gerne für PNG Icons verwendet. Anstatt 50 Icons mit 50 einzelnen HTTP Requests zu laden wird nur ein PNG geladen. Die selbe Technik kann auch für SVGs verwendet werden.
  • Pfade so einfach wie möglich halten
  • Schlagschatten, Glühen und Blur vermeiden
  • SVGs nach Export nochmal optimieren
    Beispielsweise möglich mit diesem Online-Editor: http://petercollingridge.appspot.com/svg-editor

Fonts

Fonts können eine hohe Belastung für Websites darstellen. Verwendet man beispielsweise Roboto, so hat eine Datei etwa 140 KB. Doch Roboto hat nicht nur einen Schriftschnitt sondern 12. Addiert sind das etwa 1,7 MB allein nur für das Laden der Schriften. Hier gibt es natürlich auch einige Optimierungsansätze:

• Anzahl an Fonts klein halten
• subsetting
  Hier können Zeichen, die nicht benötigt werden, aus dem Font entfernt werden. Etwas vorsichtig sollte man dabei jedoch sein, weil es nicht sehr schön aussieht, wenn ein Zeichen angezeigt werden muss, das nicht mehr vorhanden ist. Möchte man auf keine Zeichen verzichten, ist es möglich verschiedene Fonts für unterschiedliche Zeichensätze anzulegen. Unicode-Range „U+0-A0“ deckt normale Zeichen, Ziffern und Satzzeichen während weitere Zeichen wie beispielsweise é nur in der erweiterten Version zu finden ist. Die Browserunterstützung dafür ist allerdings sehr gering. Nur Chrome und Opera unterstützen dies derzeit. Ein Tool, mit dem subsetting sehr einfach möglich ist, ist der Webfont-Generator von fontsquirrel: http://www.fontsquirrel.com/tools/webfont-generator
• WOFF2
• Fonts asynchron laden
  Das Laden der Fonts dauert mitunter recht lange und genau so lange muss der User dann auch warten, bis der Text angezeigt wird, wie diese Grafik zeigt. Um dieses Problem zu umgehen hat die Filament Group einen ganz eigenen Weg gewählt. Zunächst muss es einen nativen-Font-Fallback geben, der angezeigt werden kann, während die andere Schrift geladen wird. font-family: Open-Sans, sans-serif; Dann wird JavaScript benutzt, um herauszufinden, welches Font-Format (WOFF2, WOFF, TTF, …) gebraucht wird um diese hernach asynchron zu laden. Dazu ist es notwendig Fonts zu Data URIs zu encoden. Also Open-Sans-Regular.tff, Open-Sans-Regular.woff, Open-Sans-Regular.woff2 werden encoded und das Ergebnis wird in drei
  verschiedene Stylesheets kopiert, welche dann asychron geladen werden können.
  Für das encoden von Fonts gibt es verschiedene Möglichkeiten: SASS (http://compassstyle.org/reference/compass/helpers/inline-data/#inline-fontfiles), PHP (http://css-tricks.com/snippets/php/create-datauris/), Online-Generator (http://dopiaza.org/tools/datauri/index.php)
  Das Ergebnis sieht dann so aus:
  Durch das asynchrone Laden hat der User von Beginn an lesbaren Text, auch wenn dieser zunächst nicht die richtige Schriftart hat.
• Fonts im LocalStorage speichern
  So werden sie nur ein mal geladen und werden dann für alle
  weiteren Besuche im Speicher behalten.

Tools

• perf-tooling.today
  http://perf-tooling.today/
  Eine Sammlung von Resourcen, die helfen sollen den Workflow zu verbessern und damit schnellere und bessere Websites zu
  erstellen.
• WebPageTest
  http://www.webpagetest.org/
  Testet detailliert die Performance einer Website
• PERFROCKS
  http://www.perf.rocks/
  Eine Sammlung von Resourcen, die es ermöglichen sollen schnelle Websites zu erstellen.
• Google Page Speed Insights
  https://developers.google.com/speed/pagespeed/insights/
  Testet detailliert die Performance einer Website, jedoch mit einer anderen Herangehensweise als WebpageTest
• BrowserDiet
  http://browserdiet.com/en/
  Blog über Performance

Quellen
Allgemein:

• http://www.smashingmagazine.com/2014/09/08/improvingsmashing-magazine-performance-case-study/
• http://alistapart.com/article/planning-for-performance
• http://uxmas.com/2014/were-living-in-the-fast-web

Performance Budget:

• https://sites.google.com/a/webpagetest.org/docs/usingwebpagetest/metrics/speed-index
• http://chimera.labs.oreilly.com/books/1230000000545/ch10.html#SPEED_PERFORMANCE_HUMAN_PERCEPTION
• http://timkadlec.com/2013/01/setting-a-performance-budget/
• http://danielmall.com/articles/how-to-make-a-performancebudget/

CSS:

• https://www.nccgroup.com/en/blog/2014/10/does-a-print-css-fileslow-your-site-down/

Bilder:

• http://peterhrynkow.com/how-to-compress-a-png-like-a-jpeg/
• http://calendar.perfplanet.com/2014/tips-for-optimising-svgdelivery-for-the-web/

Fonts:

• http://jakearchibald.com/2014/minimising-font-downloads/
• http://www.filamentgroup.com/lab/font-loading.html
• http://bdadam.com/blog/better-webfont-loading-with-localstorageand-woff2.html

The post Performance im Web appeared first on Mobile USTP MKL.

Plakate

Die A3 Plakate wurden in Photoshop erstellt. Die Bilder im Hintergrund selbst mit Bleistift gezeichnet, eingescannt und in Photoshop coloriert. Der QR-Code darauf führt zu einer für mobile Geräte optimierten Website mit den Rezepten.

Rezepte

Insgesamt gibt es 31 verschiedene Rezepte, die täglich wechseln. Die Rezepte sind hauptsächlich aus eigner Küche und teilweise von Rezepten von Freunden und Bekannten zusammengetragen worden.

Umsetzung

Die Rezepte ändern sich täglich, sind alle Rezepte bereits durchgelaufen, wird wieder von vorne begonnen. Man hat die Möglichkeit zu bereist gescannten Rezepten zurückzukehren und sich jedes Rezept mailen zu lassen. Kategorien für die Rezepte beinhalten ganze Mahlzeiten, was für Zwischendurch, Partysnacks, Tassenkuchen, usw.

Dazu wurden die Rezepte in eine kleine MySQL Datenbank eingetragen. Bei dem ersten Aufruf der Seite an diesem Tag wird das nächste Rezept in der Reihe mit dem aktuellen Datum aktiv gesetzt. Aufgerufene Rezepte werden im LocalStorage gespeichert und als vierter Menüpunkt angezeigt. Die bereits besuchten Rezepte kann man per Link aufrufen. Dazu wird ein GET-PArameter übergeben. Der übergebene GET-Parameter wird mit den Daten im LocalStorage verglichen um einen Aufruf eines Rezeptes, welches noch nicht freigeschalten wurde, zu verhindern.

Aufhängen der Plakate

Die Plakate wurden in der FH St. Pölten, der FH Campus Wien und in der Universität für Bodenkultur Wien aufgehängt. Dieser Punkt hat sich als äußert kompliziert gestaltet, da die  Zuständigen entweder sehr lange nicht geantwortet haben, oder diverse Bedenken gegenüber eines QR-Codes hatten im Bezug auf Datenschutz und Anderem. Nachdem das Konzept und die funktionsweise der QR-Codes genau erklärt wurden, war es kein Problem mehr die Plakate aufzuhängen. Lediglich die Wirtschaftsuniversität Wien hat kein Einverständnis gegeben.

Auswertung

Die Aufrufe der Seite werden per Google Analytics gezählt. Die Seite wurde allerdings nur von 13 Leuten besucht, davon 8 wiederkehrende Besucher.

The post Initialprojekt: Rezepte für Studenten appeared first on Mobile USTP MKL.

SVG steht für Scalable Vector Graphics. Es ermöglich also das auflösungsunabhängige Darstellen von Grafiken. Es nützt XML um Pfade, Formen, Schriften und Farben zu definieren. So haben wir uns das auch für unser Logo von Mobile-O-Poly gewünscht.

Das Logo besteht links aus Pfaden und Formen und rechts davon ein Schriftzug in Open Sans extrabold. Schnell war das SVG Image eingebunden, in Chrome geöffnet. Hat perfekt funktioniert.

Dann habe ich das ganze in anderen Browsern getestet und musste feststellen, dass der Font nicht dargestellt wird.

Ein kurzer Blick auf CanIUse hat mir dann bestätigt, dass Firefox und Internet Explorer Fonts in SVGs nicht unterstützen.

Bis diese Browser die Funktion einbauen, ist es notwendig den Text in Pfade umzuwandeln, dann funktioniert das in allen Browsern.

The post Fonts in SVGs appeared first on Mobile USTP MKL.

The reason why

Entwickler sind heutzutage mit einer Fülle von Displaygrößen und Auflösungen konfrontiert. Daher rührt das Bedürfnis nach flexiblen Bildern, ohne aber die Ladezeiten zu beeinträchtigen. Da wir bei Mobile-O-Poly einen hohen Wert auf Performance legen, wollen wir dies auch bei unseren Bildern berücksichtigen und haben daher nach einer für uns passenden Lösung gesucht.

Ask-A-Cop Methode

Steve Ballmer, CEO von Microsoft, sagte kürzlich:

“If you ask someone if they’re a cop, they have to tell you,” said Ballmer during a press conference announcing the new responsive image spec, “the same thing should apply to site images. Ask the site what size it wants, and it has to tell you.”

Dieser Ansatz funktioniert wie folgt. Der User öffnet eine Website. Diese fragt ihn, ob er die Website mit einem mobile Gerät oder Desktop aufruft. Je nach Anwort, wird das richtige Bild geliefert.

Demo
Github

Diese client-seitige Methode nutzt switch-Statements und jQuery. Dass der User, beim Aufrufen einer Website angeben muss, mit was für einem Gerät er surft, wirkt allerdings etwas befremdlich.

ReSRC.it

„Responsive images on demand, directly form the cloud“

Dieser Service verspricht eine einfache Methode für Responsive Images und arbeitet dabei mit JavaScript. Dabei werden die Source-Adressen der Grafiken mit Prefixen versehen und mit Data-Attributes, die Bilder gekennzeichnet.

ReSRC.it

Doch dieser Service ist nur die ersten 30 Tage gratis.

http://www.resrc.it/

srcset-Attribut Methode

Das srcset-Attribut erlaubt es Entwicklern, eine Liste von Quellen für ein img-Element basierend auf der Pixel-Dichte eines Display zu spezifizieren.

<img src="low-res.jpg" srcset="high-res.jpg 2x">

Das Bild „low-res.jpg“ wird an niedrig auflösenden Displays geliefert und von Browsern geladen, die das srcset-Attribut nicht untersützten. „high-res.jpg“ wird geladen, wenn der Browser das srcset-Attribut unterstützt und ein hochauflösendes Display vorhanden ist.

So können User, die keine hochauflösenden Displays besitzen, Bandbreite sparen und bekommen ein eigenes Bild geliefert.

Leider wird das Attribut bislang nur von Webkit-Browsern unterstützt.

<picture>-Element Methode

Es ist bekannt, dass der <video>-Tag mehrere Videos referenzieren kann. Außerdem ist es möglich, einen Fallback zu definieren. In Kombination mit Media-Queries kann auch definiert werden, welches Video für welche Displaygröße verwendet wird.

<video>
    <source src="high-res.webm" media="min-width:800px" />
    <source src="low-res.webm" />
    <img src="poster.jpg" />
</video>

Doch gibt es das auch für Bilder?

<picture>
   <source src="high-res.jpg" media="min-width: 800px" />
   <source src="mobile.jpg" />
   <!-- Fallback content: -->
   <img src="mobile.jpg" />
</picture>

Es gibt eine Gruppe von Leuten, die derzeit an einem solchen Standard arbeitet. Doch man ist noch weit davon entfernt, das durchzusetzen.

Picturefill

Picturefill.js ist für uns die beste Lösung, denn sie ahmt das <picture>-Element nach.

<span data-picturedata-alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia"]]>
    <span data-src="small.jpg"></span>
    <span data-src="medium.jpg"     data-media="(min-width: 400px)"></span>
    <span data-src="large.jpg"      data-media="(min-width: 800px)"></span>
    <span data-src="extralarge.jpg" data-media="(min-width: 1000px)"></span>

    <!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. -->
    <noscript>
        <imgsrc="small.jpg"alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia"]]>
    </noscript>
</span>

The post Responsive Images appeared first on Mobile USTP MKL.

Auf dem Markt gibt es verschiedene fertige Systeme, doch für Mobile-o-Poly haben wir uns für das Susy Grid entschieden.  Susy ist ein sehr mächtiges responsive Grid für Compass mit dem komplexe Layouts erstellt werden können.

Susy ist schon allein deswegen perfekt für unser Projekt geeignet, da wir mit Sass und Compass arbeiten. Doch die Handhabung von Susy ist einfach nur ein Traum und erspart sehr viel Arbeit.

Installation

Installiert Susy, wie üblich, über den Terminal mit folgendem Befehl:

gem install susy

Erstellung eines Projekts

Danach kann mit folgendem Befehl ein neues Compass Projekt erstellt werden, welches das Susy Grid beinhaltet:

compass create <PROJEKTNAME> -r susy -u susy

Hat man schon ein existierendes Compass Projekt, kann man Susy integrieren, in dem man die Konfigurations-Datei config.rb um folgende Zeile erweitert:

require „susy“

Einstellungen

In dem neu erstellten Projekt befindet sich jetzt eine Datei _grid.scss, in der alle Einstellungen mittels Variablen vorgenommen werden können. Dies betrifft beispielsweise die Anzahl der Spalten, deren Breite, die Abstände zwischen den einzelnen Spalten und die Außenränder des gesamten Grids.

Im gesamten Projekt von Mobile-o-Poly arbeiten wir mit relativen Einheiten. Da Susy jedoch em-Werte verlangt, müssen diese Einheiten konvertiert werden.

Mit Susy ist es auch möglich, für jeden Breakpoint eine andere Anzahl von Spalten zu verwenden.

Im nächsten Schritt muss das Grid jetzt auf ein HTML Element angewendet werden. In unserem Fall ist das einfach ein div-Container mit der Klasse page. Gerade zu Beginn des Entwicklungsprozesses ist es hilfreich zu wissen, in welchem Breakpoint man gerade arbeitet. Es hilft auch sehr, wenn die Spalten sichtbar sind. Dies kann man mit den beiden unteren Zeilen erreichen.

Jetzt muss man nur noch für jeden Breakpoint die Spaltenanzahl angeben sowie die einzelnen Debug-Messages, und das System ist fertig aufgesetzt.

Das Ergebnis

Das Grid-System kann gerne unter folgender URL getestet werden: http://mop.fhstp.ac.at/Patterns/grid/html/

Arbeiten mit Susy

Im folgenden Screenshot werden die wichtigsten Befehle gezeigt. Mit span-columns wird angegeben, wie viele Spalten ein Element einnehmen sollen. Im kleinsten Breakpoint soll das Element also eine Spalte von insgesamt zwei Spalten einnehmen. Die Elemente floaten dann links. Jedes zweite Elemente, soll aber rechts floaten. Dies erreicht man mit omega.

Im nächsten Breakpoint sollen die Elemente dann zwei von vier Spalten einnehmen. Jedes zweite Elemente floatet wieder rechts. Diese Einstellung wird noch vom vorigen Breakpoint übernommen.

Im nächsten Breakpoint sollen die Elemente zwei von sechs Spalten einnehmen. Insgesamt sollen so also drei Elemente Platz haben. Daher muss jedes zweite Element wieder links floaten, aber jedes dritte rechts.

Die wichtigsten Begriffe werden in der Dokumentation von Susy sehr gut erklärt. Auf manche Sachen muss man allerdings erst kommen. Sobald man Susy einmal verstanden hat, wird man es gegen kein anderes Grid System mehr tauschen wollen.

The post Responsive Grids mit Susy appeared first on Mobile USTP MKL.

„We’re not designing pages, we’re designing systems of components.“ – Stephen Hay

Das Handwerk des Web Design ist einem ständigen Wandel unterlegen und es zeigt sich, dass ein Bedarf an umsichtigen Design Systemen, anstatt einfacher Sammlungen von Webseiten besteht.

In der Vergangenheit wurde schon einiges am Design Prozess geändert und viele Artikel über die Entwicklung von Design Systemen geschrieben. Der Fokus hierbei liegt auf der Entwicklung einer Grundlage für Farben, Typographie, Grids und Texturen. Das Problem daran ist, dass diese Komponenten subjektiv sind.

Auf der Suche nach Inspiration ist Brad Frost auf die Chemie gestoßen. Die kleinsten Elemente, die Grundlage für alles Leben sind, sind Atome. Diese Atome bilden zusammen Moleküle, die wiederum komplexe Organismen erschaffen. Das ist die Grundlage für Atomic Design.

Atomic Design bedeutet das methodische entwickeln eines Design Systems in 5 Leveln:

Atome
In der Chemie sind Atome die kleinsten Bestandteile. Sie können nicht verkleinert werden, ohne ihre Bedeutung zu verlieren. Übertragen auf Interfaces sind Atome Basis-Elemente wie Labels, Inputs, Buttons. Dazu gehören aber auch abstrakte Elemente wie Farben, Fonts und Animationen. Atome sind meist abstrakt und alleine nicht sinnvoll einsetzbar.

Moleküle
Aus chemischer Sicht sind Moleküle Verbände aus einzelnen Atomen welche durch den Zusammenschluss auch neue Eigenschaften haben. In Bezug auf Interfaces sind Moleküle einzelne Elemente, die gemeinsam eine Gruppe bilden und auch als solche funktionieren. Beispielweise bilden ein Label, ein Eingabefeld und ein Button eine Suche. Aus Atomen Moleküle zu formen ermutigt zu einer “do one thing and do it well”-Mentalität. Interface Patterns werden ein Mal perfekt entwickelt und können dann immer wieder verwendet werden.

Organismen
Organismen sind eine Gruppe von Molekülen und unter Umständen auch Atomen und bilden einen eindeutigen Bereich eines Interfaces. Organismen können sowohl aus gleichen als auch unterschiedlichen Molekülen bestehen. Ein Beispiel für einen Organismus aus unterschiedlichen Molekülen ist ein Header, welcher aus einem Logo, einer Navigation und einer Suche besteht. Eine Liste von Produkten angeordnet in einem Grid ist aber ebenfalls ein gutes Beispiel für einen Organismus. Dadurch entstehen eigenständige, portable und wiederverwendbare Komponenten.

Templates
Templates bestehen hauptsächlich aus Organismen und bilden so ganze Seiten. In diesem Level sieht man, wie die Organismen in Layouts angeordnet werden. Sie liefern den Kontext für die sonst so abstrakten Atome und Moleküle. In diesem Level kann auch der Kunde eingebunden werden. Üblicherweise wird hier auch mit dem Erstellen von HTML Wireframes begonnen.

Seiten
Seiten sind Instanzen von Templates. Platzhalter für Bilder, Texte, oder Ähnlichem werden durch echte Inhalte ersetzt. Seiten haben den höchsten Genauigkeitslevel. In diesem Schritt wird vor allem die Effektivität des Design Systems getestet, da alles im Kontext betrachtet werden kann. Passt etwas nicht, können Moleküle und Organismen angepasst werden.

Auf der beyondtellerand 2013 hat Brad Frost auch das Pattern Lab vorgestellt, welches dafür entwickelt wurde solche Design Systeme zu entwickeln.

Als Basis für die weitere Entwicklung der Patterns für Mobile-o-Poly wurde anhand der Screendesigns und der ersten Version des Spiels alle Komponenten in die drei Level Atome, Moleküle und Organismen eingeteilt.

Auf diesem Screen sind folgende Atome sichtbar:

• Icon
• Heading 1
• Paragraph
• Label
• Input Field
• Button

Daraus ergeben sich folgende Moleküle:

• Drop-Down Navigation
• Form

Dies wiederum ergibt einen speziellen Organismus:

• Title Bar

Alles zusammen bildet ein Template:

• Standard Template

The post Atomic Design für Mobile-o-Poly appeared first on Mobile USTP MKL.