1.
Technologie
mobilne w
platformach
edukacyjnych
KOSMIKUS 1.5
STUDIUM PRZYPADKU
Michał Łukaszewski
Sławomir Rodak

2.
Część 1
BUSINNES CASE

3.
Cel biznesowy

"Mobile są modne" to nie wymaganie

"Mobile" to ogromne spektrum urządzeń, rozdzielczości, wydajności
sprzętowej

Mobile-first? Czy - również? Czy - przy okazji?

Android to koszmar, ale ma większość rynku ("i co pan nam
zrobisz?")

Wymagania funkcjonalne powinny być uściślone przed
rozpoczęciem produkcji tak bardzo jak to możliwe

Wybór technologii zbyt powiązany z wymaganiami

Zmiana wymagań może w najgorszym przypadku zakopać projekt może wymusić zmianę technologii i kosztowny refaktoring (w
zależności od momentu, w którym zmiana nastąpiła)

4.
Ogrom możliwości?

Trudno znaleźć jedną bibliotekę, która może wszystko

Więc balansujemy pomiędzy możliwościami, a oczekiwaniami

To że dany komponent coś może nie oznacza, że możemy go użyć (bo np.
wydajność)

Klęska urodzaju?

Dostępne silniki JS: CreateJS, PaperJS, KineticJS, Phaser, Cocos 2D, Jaws, Solpeo
Engine, ImpactJS, iio Engine, Farbric JS, PIXI

Biblioteki JS: jQuery, jQuery UI, Zepto, MooTools, Prototype, ExtJS, Dojo, YUI

Frameworki MVC/MVVC: Angular JS, BackBone, Knockout

Frameworki CSS: bootstrap, Foundation, Pure CSS, Cardinal CSS, Compass

Preprocesory: LESS, SASS

RWD: viewport, media-query

5.
Realne możliwości





Praktycznie rzecz biorąc da się zrobić niemalże wszystko: bajeranckie
stronki, prezentacje, singlepage, gry (!), animacje.
Ale bardzo rzadko za pomocą jednego komponentu
Mieszanie komponentów utrudnia rozwój i utrzymanie
- konieczne wdrożenie programisty w komponent aby wykorzystać go
optymalnie
- rosną koszty
- rośnie ryzyko błędów
- konieczne bardzo szerokie kompetencje albo szeroki zespół)
Ale stosowanie jednej wszystkomogącej biblioteki wszędzie jest bez
sensu
- zazwyczaj jest duża (jako plik)
- niekoniecznie najwydajniejsza
- strzelanie z armaty do komara
Na co Cię stać?

6.
Sky is the limit?

Nope - the enviroment

Wydajność niektórych bibliotek jest denna (ilość klatek/żądań na
sekundę vs. RAM + obciążenie CPU)

Same różnice pomiędzy PC dają w kość

Urządzenia mobilne to koszmar

Tablety z Biedronki

Zetaphony

7.
Przykład - przeglądarki desktop

Minimalne wersje przeglądarek

Chrome +23 (Blink: post-WebKit)

FF +20 (Gecko)

IE +10 z bólem, IE11 bardzo dobrze (IE9 do najprostszych stron, IE8
nie, nie, nie)

Opera 12 (Presto) - śmieć, ale już Opera +15 (WebKit) jest ok

Safari +6 (WebKit) - OK, ale tylko iOS; na Win jest max 5: nie OK.

Win XP to ciągle ok 30% rynku OS na dektopach - więc np. IE8 to
max. - i co z tym fantem zrobić?

8.
Urządzenia mobilne

iOS jako referencyjny (jak to powinno wyglądać i działać).

ale - opieranie się na iOS nie jest wystarczające, nawet jeśli ktoś lubi iOS
lub klient ma i musi u niego wyglądać .

W przypadku produktu uwzględniającego telefony na rynek PL musimy
brać pod uwagę WP (bo ma ok 30% rynku i rośnie).

W przypadku EU - różnie w zależności od kraju (np. Hiszpania ma duży
udział WP, inne kraje mają inny rozkład)

Android najważniejszy, bo ma największy udział globalny i to się w
najbliższym czasie nie zmieni.

ale - Android nie może być punktem odniesienia, bo segmentacja jest
ogromna. Działanie i wygląd w zależności od wersji mogą być bardzo
różne - duże koszty. Ale uwzględniać i testować trzeba - potrzeba też
szerokiej palety urządzeń. Nexusy jako punkt odniesienia dla Androida .

9.
Segmentacja wersji Androida
Stan na 2.12.2013, dane za: developer.android.com

10.
Wzrost WP

WP jako nr 2 wśród telefonów
Indie, Meksyk, Włochy, Chile, Tajlandia, Wietnam, Malezja, Polska, R
PA, Ukraina, Węgry, Finlandia, Czechy, Grecja

WP przewyższył sprzedaż iPhone
Chile, Kolumbia, Czechy, Egipt, Egipt, Finlandia, Grecja, Węgry, Indi
e, Włochy, Kenia, Kuwejt, Malezja, Meksyk, Nigeria, Pakistan, Peru, P
olska, Arabia Saudyjska, RPA, Tajlandia, Ukraina, Zjednoczone
Emiraty Arabskie, Wietnam
Dane na 4Q2014 za Microsoft i adduplex
ALE

głównie modele budżetowe (Lumia 520, 620, 625)

11.
Backend

Backend ma poślednie znaczenie, o ile są kompetencje w firmie

PHP 5.4 i następne dobrze nadaje się do współpracy z GUI mocno
opartym o JS

node.js - jeden język programowania po stronie FE i BE, ale ciągle
dość świeże rozwiązanie (też ma swoje limity).

Bazy danych bez znaczenia.

12.
Kosmikus 1.5 - technologie

HTML5

Bootstrap 2 (wersja 3 - wydana w trakcie trwania developingu)

jQuery

Create JS (pozwolił na łatwe przejście programistom ActionScript)

SVG Animations (bezkosztowo, dzięki Google Swiffy; przykład)

RWD w oparciu o viewport (całość) i media-queries (częściowo, per typ widoku)

Korzyści
- Wygląda ładnie
- Minimalna ilość technologii, wygodna separacja kompetencji

Wady
- Niektóre ekrany ciężkie: najcięższy ok 3MB + XHR = ~6MB do ściągnięcia - Canvas by Create JS +
ponad 300 elementów do wyboru przez użytkownika.
- FF vs niektóre animacje na Canvasach ledwo dyszy (inne przeglądarki lepiej, IE11
najwydajniejszy)
- Ułomne technologie (np. wprowadzenie dźwięku do animacji)
- Błędy i ograniczenia bibliotek: wprowadzaliśmy autorskie zmiany, które trafiły do oficjalnego
wydania z opóźnieniem w stosunku do planu wydawniczego mijając się z naszym .
- brak kompatybilności wstecz (bootstrap 3 vs boostrap 2)

13.
Podsumowanie

Inwestowanie w nowe technologie czy stosowanie rozpoznanych
rozwiązań?

Kryteria wyboru nowej technologii
- "próg wejścia"
- reużywalność w ramach organizacji
- "próg wyjścia"
- zaangażowanie zespołu
- popularność
- wsparcie producenta

Zakres nowych technologii w projekcie

PoC

Kto nie ryzykuje ten nie ma

Cel biznesowy jest zbieżny z celami technologicznymi

14.
Część 2
TECHNOLOGY CASE

15.
Silniki JS

Warstwa kompetencji

Możliwe zastosowania

16.
Silniki JS

CreateJS
Dema
http://www.createjs.com/#!/TweenJS/demos/twee
nCircles
http://www.createjs.com/#!/EaselJS/demos/sprite
sheet
http://www.createjs.com/#!/EaselJS/demos/game
http://www.createjs.com/#!/EaselJS/demos/cache
http://www.createjs.com/#!/TweenJS/demos/twee
nCircles
http://www.createjs.com/#!/SoundJS/demos/soun
dGrid
http://www.createjs.com/#!/SoundJS/demos/explo
sion
http://www.createjs.com/#!/SoundJS/demos/visua
lizer

Wszystkie potrzebne komponenty
(bitmapy,sprites,animacje,dźwięk)

Integracja z Flash

Źródła na GitHub

Niski próg wejścia

Wersja 0.51 (0.4 przy starcie prac)

Wolne działanie

Brak komponentów do formularzy nie najlepsza integracja z
elementami DOM

17.
Silniki JS

Obsługa wektorów i bitmap

Matematyczno - wektorowy
Dema

Źródła na GitHub
http://paperjs.org/examples/nyanrainbow/
http://paperjs.org/examples/meta-balls/

Brak obsługi dźwięków

Paper JS
http://paperjs.org/showcase/

18.
Silniki JS

Kinetic JS

Szeroki wachlarz funkcji
(obrazy,sprites,animacje,eventy,
warstwy, filtry,selektory)

Źródła na GitHub

Spójny

Brak obsługi dźwięku

Wbrew obietnicom - nie jest szybki

19.
Silniki JS

Silnik do tworzenia gier

Zawiera wszystko co trzeba (nawet
dźwięk)
http://grimpanda.com/games/sandb
ox/connectme-sfx/

Renderowanie na CANVAS i
WebGL (Pixi.js)
http://www.bbc.co.uk/cbeebies/pet
er-rabbit/games/peter-rabbit-hideand-seek/

Źródła na GitHub

TypeScript

Kompletny silnik do wytwarzania
gier

322kB - po kompresji

Phaser
Dema
http://gametest.mobi/phaser/exampl
es/_site/view_full.html?d=filters&f=fire.j
s&t=fire

20.
Silniki JS
Cocos 2D
Dema
http://www.cocos2dx.org/games/all?p=15

Kompletny silnik do tworzenia gier


Źródła na GitHub

Wysoki koszt wejścia

21.
Silniki JS

Produkt polski

Zwarta dokumentacja
Dema

Silnik gier 2D/3D
http://ck.solpeo.com/

Nie wiadomo w jakim stadium
rozwoju jest produkt

Solpeo Engine

22.
Silniki JS

Kompletny framework do gier

Edytor poziomów, fizyka, dźwięki
Dema

Dokumentacja
http://phoboslab.org/#games

Dojrzały projekt
http://impactjs.com/games

Płatny (99$)

Impact JS

23.
Silniki JS

Silnik graficzny

Bardzo szybki
Dema

CANVAS + WebGL
http://www.pixijs.com/examples/

Dokumentacja
http://www.goodboydigital.com/pixij
s/bunnymark/

Źródła na Github

Silnik graficzny

PIXI
https://github.com/GoodBoyDigital/p
ixi.js/

24.
Biblioteki JS

Warstwa kompetencji

Możliwe zastosowania

25.
Biblioteki JS

jQuery

Doskonała obsługa zdarzeń

Świetna obsługa DOM

Doskonała obsługa komunikacji
asynchronicznej via Ajax

Powolny (req per sec)

Różna jakość pluginów

26.
Biblioteki JS

jQuery UI

Ogromne możliwości

Ogromna baza pluginów

Możliwość customizacji FW

Bardzo ciężki

Customizacja utrudnia kontrolę
możliwości

Pluginy różnej jakości

27.
Biblioteki JS

Zepto

Leciutki (~9kB skompresowany)

Kompatybilny z jQuery

Zaprojektowany jako alternatywa
dla jQuery dla mobilek

Pełne wsparcie tylko dla
najnowszych przeglądarek

Relatywnie niewielki zakres
możliwości

Brak wsparcia dla IE < 10

28.
Biblioteki JS

Dojo

Bardzo rozbudowane środowisko
(Dojo Toolkit, od prostych
pluginów po kompletne widgety Dijit, Dojox)

Możliwość dobierania
komponentów wg
potrzeb, rozszerzeających
możliwości core

Używany w dużych projektach
komercyjnych

Alternatywny do jQuery
wszystkomogący FW

Bardzo złożone środowisko, tylko
do dużych, złożonych projektów

29.
Kontrolery widoku

Angular JS

Implementuje MVC tam gdzie
dotychczas go nie było

MVVM (Model-View-ViewModel)

Upraszcza część back-endową

Obecnie wspierana i firmowana
przez Google

Wysoki próg wejścia

30.
Kontrolery widoku

Backbone

Knockout

31.
Frameworki CSS

Warstwa kompetencji

Możliwe zastosowania

32.
Frameworki CSS

Bootstrap

Oparty o grid - duża wygoda

Relatywnie łatwo skalowalny

Dostarcza pełny LESS

Opiera się o grid - ograniczenia

Wymusza LESS

Brak kompatybilności wstecz
pomiędzy wersjami 2 a 3

33.
Frameworki CSS

Foundation

Mobile First (od v.4)

Więcej wbudowanych
komponentów

Technologicznie, krok do przodu

Real fluid layout

SASS - więcej możliwości

Znacznie mniej popularny niż
Bootstrap

SASS - ciężka składnia

34.
Frameworki CSS

Pure CSS

Małe rozmiary

Skin Builder

Brak źródeł: LESS,SASS

Stosunkowo mała popularność

35.
Frameworki CSS

Semantic

Idea semantycznego kodu

Ładny na starcie (w
przeciwieństwie do Foundation)

LESS

Semantyczność - poprzez nazwy
klas :)

Popularność

36.
Preprocesory

Warstwa kompetencji

Możliwe zastosowania

37.
Preprocesory

LESS

Bardzo łatwa składnia

Niezła dokumentacja

Bardzo duże możliwości

Bardzo popularny, vide źródła
bootstrap

Łatwo spuchnąć wynikowy CSS

Przy dużych, zaawansowanych
zestawach trudno zachować
kontrolę nad tym co gdzie jest

Przy zaawansowanych układach
bywa mało czytelny

38.
Preprocesory

SASS

Główne zalety i wady jak w LESS

Trudniejsza składnia, oferująca
jednak więcej możliwości

Mniej popularny

39.
Preprocesory

Coffee Script

Ułatwia pisanie
zaawansowanych, wieloplikowych
rozwiązań JS

Specyficzna składnia, teoretycznie
dążąc do ECMA, w praktyce
własny narzut

Niepomijalny koszt wejścia

40.
RWD

Warstwa kompentencji

Możliwe zastosowania

41.
RWD

viewport

Podstawowy mechanizm
skalowania

Nie wymaga fw css

Dobra dokumentacja

IE wie lepiej

42.
RWD

media queries

Ogromne możliwości
manipulowania renderowaniem
elementów oraz układem per
rozdzielczość

Łatwo zabagnić CSS

W praktyce: konieczność
stosowania preprocesorów CSS

43.
SEO/SEF

Ajax vs SEO

FW2 vs SEF

Canvas vs SEF

HTML5

location vs replace

44.
Urządzenia mobilne

iOS i Windows na tabletach są spoko: konkretne
rozdzielczości, konkretne przeglądarki, łatwo ogarnąć.

iOS na telefonach i WP wcale nie muszą renderować strony tak
samo jak przeglądarki na tabletach (dotyczy też Win RT vs WP)

Android to koszmar: nasz mega kwiatek - różnice w działanie JS na
tej samej przeglądarce pomiędzy 4.0.3 a 4.0.4

Nexusy jako podstawa testów dla Androida albo śmierć przez
walenie głową o klawiaturę .

45.
Backend






Backend nie ma krytycznego znaczenia
Jeśli jest kasa i kompetencje można eksperymentować
PHP min. w wersji 5.4, wyższe lepsze (wbudowany OpCache, listy
asocjacyjne ) - np. możliwość posługiwania się listami = mniej konwersji
w komunikacji z GUI opartym na JS (spójny wygląd kodu po stronie BE i
wynikowej - ułatwione debugowanie)
Bazy danych bez znaczenia, ale jeśli aplikacja (i budżet) pozwala
można np. rozważyć noSQL posługujący się składnią JSON - ponownie
jedna składnia itp.
Można rozważyć node.js - jeden język po stronie BE i FE, ale kwestie
wydajnościowe, load balancing: nie wierzyć w foldery
reklamowe, kopać mocno pod kątem problemów i wąskich
gardeł, które będą zbliżone do tych jakie będziemy mieli w aplikacji.
W praktyce - nie szalej.

46.
Wybór technologii

Inwestowanie w nowe technologie czy stosowanie rozpoznanych
rozwiązań?

Kryteria wyboru nowej technologii
- "próg wejścia"
- reużywalność w ramach organizacji
- "próg wyjścia"
- zaangażowanie zespołu
- popularność
- wsparcie producenta

Zakres nowych technologii w projekcie

PoC

47.
Kosmikus 1.5

Bootstrap 2
- wystarczający zakres funkcjonalności
- brak możliwości migracji do Bootstrap 3

Create JS
- bardzo łatwe wejście dla programistów Action Script
- braki lub niedoskonałości w zaskakujących miejscach
- nonszalanckie podejście do planu wydawniczego
- animacje w zależności od przeglądarki mogą ubić procesor
- konieczność stosowania XHR dla mediów

SVG animations - animacja sobie, dźwięk sobie.

jQuery
- bardzo wygodny do podstawowej manipulacji DOM
- dobrze współpracujący z CSS
- eventy - najmocniejsza strona
- bardzo wygodna obsługa ajax'a, ale trzeba uważać, żeby pisać zgodnie z bieżącymi zaleceniami obsługę zdarzeń powrotnych
- niektóre pluginy (np. Validator) mają słabą wydajność, ale za to działają np. z nietypowymi mailami

LESS
- ogromna wygoda w zarządzaniu CSS'ami (których jest sporo)
- trzeba mieć dużą samokontrolę bo łatwo niechcący mocno spuchnąć wynikowy CSS (zwłaszcza przy wejściu w media query)
- minimalizacja wynikowego CSS by default (konsole dev w przeglądarkach są do sprawdzania i testowania, efekty nanoszone są do LESS, CSS nikt nie rusza)

RWD
- viewport jako podstawa - obejście problemu ze skalowaniem Canvasów
- media queries - oszczędnie, dla konkretnych elementów gdzie warto było zmienić ich wzajemny układ.

48.
Kosmikus 1.5

Komunikacja backend - frontend

Ustandaryzowane obiekty JS wstrzykiwane w kod strony

Specjalizacja obiektów JS podawanych scenie
- obiekt użytkownika
- dane "konfiguracyjne"
- dane aplikacyjne (np. język)
- dane sceny (np. media)
- dane o callbackach per akcja na scenie

ajax do walidatorów formularzy rejestracyjnych/profilowych i na niektórych stronach
wewnętrznych (tam gdzie to ułatwiało i/lub przyspieszało działanie strony)

dla FW2 konieczność własnego layout.php
- oryginalny ma przestarzały układ (CSS, JS, osobny <script> dla każdego addScriptCode;
wszystko w head)
- powinno być: CSS w head, JS-libs oraz JS-code przed </body> (w tej kolejnosci)

Ścisła (samo)kontrola - JS-code zawsze via addScriptCode, nigdy przez tpl; efektem jest
możliwość kontrolowania kolejności kodu na wynikowej stronie, uruchamianie silnika JS once-perview.

Oznacza to generowanie JS przez PHP - specjalizowane moduły i komponenty do (de)kompozycji
jako dobra praktyka.

49.
Kosmikus 1.5

Programowa blokada przeglądarek w zbyt niskich wersjach (oparta
o browsecap)

Programowa blokada urządzeń o zbyt niskiej rozdzielczości (min
1024px szerokości, badane przez JS) - bye, bye tablety z Biedronki.

Zasłanianie contentu (Empiria) w orientacji portrait (problemy ze
skalowaniem)

Widoki administratorów, sprzedawców, rodziców czy nauczycieli
mają RWD w wersji minimum - opierają się na minimalnej szerokości i
viewport: niższe koszty, łatwiejsze projekt i realizacja.

50.
Jakość kodu FE

Javascript nie jest już dodatkiem do zabezpieczenia formularzy tylko
pełnoprawnym językiem

Dotyczą go wszystkie zasady dobrego programowania jakie znamy
z innych języków

Wzorce i antywzorce

CleanCode, SOLID itp, itd

Podział funkcjonalny - warstwy, komponenty, biblioteki

Zależności: DI, promises, overload i override

BDD i testy automatyczne

Jeden duży plik vs szereg mniejszych (require.js)

51.
Wnioski

Technologie mobilne wymuszają nieustanne i sprawne poszerzanie swoich kompetencji

Zawsze będą specjaliści w danym obszarze, ale trzeba rozumieć oczekiwania BE vs FE aby
optymalnie dobierać rozwiązania i je implementować

Biznes nie ma szans tego ogarnąć (mają swoje obszary, ten jest nasz)

Rola technicznych w procesie kształtowania wymagań może być krytyczna

Rolą technicznych nie jest rzucanie kłód pod nogi (" sięnieda") tylko kompilowanie dużych
obrazków i szukanie rozwiązań, którymi da się je narysować. Lub nie. I co wtedy?

Nie straszymy problemami, tylko szacujemy roboczogodziny

Biznes musi ufać technicznym, techniczni muszą być godni zaufania

Może być tak, że nawet coś trudnego, ale możliwego do zrealizowania będzie ok mimo sporych
kosztów: techniczni nie kształtują wartości biznesowej, choć mogą ją podpowiedzieć

Techniczni pilnują też grafików, którzy w trakcie kreacji mogą pominąć aspekt RWD - zawsze jest
złoty środek, o ile sygnalizuje się potencjalny problem odpowiednio wcześnie.

Pisz od razu optymalnie; kasy na optymalizację nigdy nie ma, gdy nie ma wartości dodanej dla
biznesu.

52.
Literatura i zasoby
Silniki JS







CreateJS
http://www.createjs.com
PaperJS
http://paperjs.org/
KineticJS
http://kineticjs.com/
Phaser
http://phaser.io/
Cocos 2D
http://cocos2djs.org/
Jaws
http://jawsjs.com/
Solpeo Engine
http://www.solpeo.com/

53.
Literatura i zasoby
Silniki JS

Impact JS
http://impactjs.com/

iio Engine
http://iioengine.com/

Fabric JS
http://fabricjs.com/

PIXI
http://www.pixijs.com/
http://www.goodboydigital.com/pixijs/storm/
http://www.goodboydigital.com/pixijs/examples/11/
http://www.goodboydigital.com/pixijs/examples/12-3/
http://www.goodboydigital.com/to-dom-or-not-to-dom/

54.
Literatura i zasoby
Zestawienia

http://ntt.cc/2011/01/31/66-open-source-javascript-game-enginefor-serious-developers.html

http://www.backslash.gr/content/blog/webdevelopment/7-10javascript-canvas-frameworks

55.
Literatura i zasoby
Biblioteki

jQuery - (http://jquery.com/)

YUI - (http://yuilibrary.com/)

Dojo - (http://dojotoolkit.org/)

ExtJS - (http://www.sencha.com/products/extjs/)

Prototype - (http://prototypejs.org/)

MooTools - (http://mootools.net/)

Zepto - (http://zeptojs.com/)

jQueryUI - (http://jqueryui.com/)

56.
Literatura i zasoby
Frameworki MVC

AngularJS - (http://angularjs.org/)

Knockout - (http://knockoutjs.com/)

Backbone - (http://backbonejs.org/)

57.
Literatura i zasoby
Zestawienia

http://jonathanmh.com/best-javascript-mvc-frameworks-2013-2014/

http://www.infoworld.com/d/application-development/the-10hottest-javascript-framework-projects-228335

http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks

58.
Literatura i zasoby
Frameworki CSS

Bootstrap - (http://getbootstrap.com/)
http://acc15.kosmikus.pl/
http://questrunner.ydp.eu/
http://nedu.ydp.pl/
http://getbootstrap.com/getting-started/#examples

Foundation - (http://foundation.zurb.com/)

Pure CSS - (http://purecss.io/)

Cardinal CSS -(http://cardinalcss.com/)

Compas - (http://compass-style.org/)

59.
Literatura i zasoby
Preprocesory CSS

LESS - (http://lesscss.org/)
https://svn.intranet.ydp/ydp/projects/kosmikus/branches/1.5.x/less/k
osmikus
http://lesscss.org/#-variables
http://lesscss.org/#-mixins
http://lesscss.org/#reference

SASS - (http://sass-lang.com/)

60.
Literatura i zasoby
Zestawienie

http://www.sitepoint.com/top-10-front-end-developmentframeworks/

http://www.sitepoint.com/top-10-front-end-developmentframeworks-part-2/

61.
Literatura i zasoby
Przeglądarki vs technologie
mobilne

http://caniuse.com/

http://html5test.com/

62.
Literatura i zasoby
RWD - kontrola nad ekranem

https://developer.mozilla.org/enUS/docs/Mozilla/Mobile/Viewport_meta_tag

http://css-tricks.com/snippets/css/retina-display-media-query/

http://msdn.microsoft.com/enus/library/windows/apps/hh453816.aspx

http://blog.kamilbrenk.pl/meta-tag-viewport-kiedy-i-jak-uzywac/