In ultima saptamana am vrut sa fac o mica aplicatie pentru mobil (Android). Initial am vrut sa o fac folosind Titanium, platforma cu care m-am mai jucat si am fost placut impresionat.

Totusi dupa ce am descarcat compilatorul si am facut prima aplicatie am avut o surpriza, aplicatia “Hello world” avea aproximativ 5M. Cum s-a ajuns la marimea asta? Simplu, Titanium compileaza aplicatile in cod nativ dar nu exista o metoda clara prin care sa determine ce API-uri sunt folosite, asa ca va introduce minimul necesar pentru toate functionalitatile. Perspectiva de o aplicatie care trece de 5M nu m-a incantat asa ca am inceput sa caut alternative.

Mi-am instalat Phonegap, am vrut sa fac un joc si cu aceasta plaforma de mult timp, dar avand in vedere ca nu are o instalare la fel de eleganta ca Titanium nu m-a incantat. Am facut o aplicatie “Hello world” si surpriza… ~200k! O dimensiune rezonabila pentru mine.

Evident exista o explicatie, Phonegap ofera acces la multe facilitati cum ar fi: accelerometru, camera sau contacte, dar nimic pe partea de prezentare. Partea de prezentare este facuta exclusiv prin HTML, CSS si JavaScript.

Intreagul proiect Phonegap se bazeaza pe faptul ca platformele importante au nativ un “web view” care poate parsa o pagina web.

In plus, pentru ca proiectul nu este la fel de “elegat” ca Titanium poti adauga facilitati destul de usor. De exemplu pentru Android exista un numar decent de proiecte care adauga facilitati in plus pentru platforma. Modul de incarcare al lor nu e foarte dificil dar nici plug & play. Practic sunt module de Java pentru Android care au si un API care poate fi apelat din “web view”. Acesta poate sa fie un avantaj, pentru ca exista multa lume care scrie module suplimentare care nu trebuie sa fie neaparat in “core”.

Pentru aplicatii simple care fac listari sau afisaza informatii, platforma este o alternativa interesanta, mai ales ca exista o serie intreaga de framework-uri JavaScript si CSS pentru formatare, cum ar fi: jQTouch, jQuery Mobile sau XUI. Platforma este foarte buna pentru a impacheta aplicatii de acest fel. De exemplu daca ai o aplicatie HTML pentru mobil si vrei sa-i adaugi functionalitate nativa in plus si sa o distribui compilata, Phonegap face o treaba buna.

Pe de alta parte chiar daca poti accesa de exemplu butonul de meniu, nu poti construi un meniu nativ.

Concluzionand, este o platforma cu o abordare complet diferita fata de Titanium. Daca Titanium se bazeaza pe faptul ca aplicatia va ajunge cod nativ cu API-uri native, cu tot codul scris in JavaScript, iar web view este una din optiuni, abordarea PhoneGap este ca toata prezentarea sa fie exclusiv in web view folosind HTML(5) + CSS si doar cateva API-uri specifice dispozitivelor care nu pot fi accesate din browser si nu sunt legate de prezentare sa fie expuse, cum ar fi vibratia, butoanele, etc. Avand in vedere aceste lucruri nu cred ca se poate face o comparatie reala intre platforme, doar programatorul poate decide care este abordarea de care are nevoie.

JavaScript si PHP suporta atat functii lambda cat si closures. Dar termenii sunt putin intelesi in ambele libaje de programare si de multe ori sunt confundati.

Functii Lambda

Mai sunt numite si functii anonime. Acestea se refera la functii care pot fi apelate fara sa fie neaparat legate de un identificator. Unul din scopurile lor este de a fi pasate ca argumente. Numele de Lambda li se trage de la Alonzo Church, inventatorul lambda calculus in 1936. In lambda calculus toate functiile sunt anonime.

JavaScript

In JavaScript functiile lambda fac parte din setul de baza si reprezinta metoda preferata de creare a unei functii.

De exemplu:

1var add = function (a, b) {
2     return a + b;
3}
4alert(add(1, 2)); // 3

Functiile lambda sunt folosite aproape in orice context cand vine vorba de JavaScript, un exemplu este:

1window.onload = function (e) {
2     alert('Pagina s-a incarcat!');
3}

PHP

In PHP, functiile lambda au fost introduse de la versiune 4.0.1 folosind create_function. In versiunea 5.3+ a fost adaugata si sintaxa similara cu JavaScript, un mod mult mai lizibil si elegant de a definii o functie.

Asta inseamna ca in PHP exista doua moduri de a genera o functie lambda:

 1// PHP 4.0.1+
 2$add = create_function('$a, $b', 'return $a + $b;');
 3
 4// vs.
 5
 6// PHP 5.3+
 7$add = function ($a, $b) {
 8     return $a + $b;
 9};
10
11echo $add(1,2); // 3

Functiile lambda pot fi folosite ca parametru pentru alte functii, cum ar fi usort:

1$array = array(4, 3, 5, 1, 2);
2usort($array, function ($a, $b) {
3     if ($a == $b) {
4          return 0;
5     }
6     return ($a < $b) ? -1 : 1;
7});

Chiar mai mult, PHP 5.3+ permite apelarea unui obiect ca o functie anonima:

1class test {
2     function __invoke($a) {
3          echo $a;
4     }
5}
6$a = new test();
7$a('test'); // 'test'

Closures

Notiunea de closure este notiunea cu adevarat neinteleasa dintre cele doua. In general confuzia apare pentru ca implementarea de cloasure poate presupune si functii lambda. Un closure se refera la capacitatea unei functii/obiect de a accesa mediul in care aceasta a fost creat(a) chiar daca executia functiei parinte s-a terminat. Cu alte cuvinte functia/obiectul intors de un cloasure pastreaza mediul in care a fost definita.

In JavaScript notiunea de closure face parte din arsenalul de baza, pentru ca limbajul nu are la baza un model obiectual traditional ci unul bazat pe prototype si functii. Dar JavaScript mai are si cateva reminescente, cum ar fi faptul ca poti folosi “new” pentru a construi un obiect pe baza unei functii care joaca roul de clasa. In PHP este mai degraba o noua posibilitate de abordare a problemelor, PHP facand parte din familia de limbaje cu model obiectual traditional.

JavaScript
In JavaScript notiunea de closure este foarte folosita, iar popularitatea se datoreaza faptului ca JavaScript nu este un limbaj obiectual traditional, ci unul functional, bazat pe mostenire prototype.

In JavaScript nu exista notiunea de Public, Private si Protected, exista doar Public si Private iar obiectele pot mostenii unele de la altele, fara sa foloseasca clase.

O alta problema este mediul (scope), care in mod implicit este cel global. Prin closure aceste probleme pot fi rezolvate intr-un mod elegant:

 1var closure = function () {
 2     var sum = 0;
 3     return {
 4          add: function (nr) {
 5               sum += nr;
 6          },
 7          getSum: function () {
 8               return sum;
 9          }
10     }
11}();
12
13closure.add(1);
14closure.add(2);
15console.log(closure.getSum());

In exemplul de mai sus, sum este o proprietate privata iar aceasta teoretic, putea fi accesata si modificata doar din functia closure. Partea interesanta este ca parantezele de la finalul definitiei de functiei semnifica faptul ca aceasta functie se va si executa si deci va intoarce rezultatul care este un obiect. In acest moment functia initiala nu mai exista decat pentru a servi obiectul intors, incapsuland astfel variabila privata.

Desi functia si-a terminat executia, prin intermediu acestul closure obiectul returnat poate accesa variabilele definite in interiorul functiei, pentru ca este mediul in care a fost creeat.

Problema devine mai interesanta atunci cand o functie intoarce o alta functie:

 1var counter = function () {
 2    var counter = 0;
 3    console.log('in closure');
 4    return function () {
 5        console.log('in functia anonima');
 6        return ++counter;
 7    };
 8};
 9var counter1 = counter();
10
11console.log(counter1()); // 1
12
13var counter2 = counter();
14console.log(counter2()); // 1
15console.log(counter1()); // 2

Output-ul va fi:

1in closure
2in functia anonima
31
4in closure
5in functia anonima
61
7in functia anonima
82

Ce se intampla de fapt este ca prima functie se executa si intoarce o functie anonima care inca mai poate accesa mediul in care a fost creata. Dupa parerea mea de aici vine confuzia dintre closures si lambda functions, pentru ca o functie intoarce o alta functie.

Diferenta dintre exemple este ca in primul exemplu functia initiala de closure se executa imediat, iar in al doilea exemplu se poate vedea ca atunci cand counter se executa intoarce un rezultat, care este de fapt o definitie de functie, care la randul lui poate fi executata. Evident si acest exemplu poate fi adaptat sa se comporte precum cel precedent folosind paranteze la final.

PHP

Cum spuneam si mai sus, in PHP notiunea de closure nu este la fel de importanta ca in JavaScript.

Daca functiile lambda sunt disponibile in limbaj incepand cu versiunea 4, closure au aparut de abea dupa PHP 5.3+

Datorita mediului (scope) de executie care este de tip block in PHP se realizeaza o incapsulare mai buna dar si mai putin flexibila fata de JavaScript. Practic in PHP trebuie specificat cu ajutorul instructiunii use ce anume va putea accesa functia anonima din closure-ul care si-a terminat executia.

 1function closure () {
 2     $c = 0;
 3     return function ($a) use (&$c) {
 4          $c += $a;
 5          echo $a . ', ' . $c . PHP_EOL;
 6     };
 7}
 8
 9$closure = closure();
10
11$closure(1);
12$closure(2);

Spre deosebire de JavaScript in PHP nu se pot realiza closure care sa intoarca un obiect, sau mai bine zis obiectul nu poate fi legat de mediul in care a fost creat, decat sa zicem, daca nu se trimit parametrii la constructor prin referinta, metoda nu foarte eleganta care nu vad in ce scenariu ar avea neaparata nevoie de closure.

Ca o paralela la exemplele  de la JavaScript, in loc de parantezele “()” de la finalul functiei, in PHP pentru a executa functia imediat dupa definire se pot folosii call_user_func() sau call_user_func_array():

 1$closure = call_user_func(function () {
 2    $c = 0;
 3    return function ($a) use (&$c) {
 4        $c += $a;
 5        echo $a . ', ' . $c . PHP_EOL;
 6
 7    };
 8});
 9
10$closure(1);
11$closure(2);

Cum eu sunt un mare fan al lui Douglas Crockford, inventatorul JSON, cu cateva saptamani in urma am descoperit o noua serie de prezentari. Prezentarile au avut loc in 2010 si se gasesc in pagina dedicata pe blog-ul YUI: http://yuiblog.com/crockford/.

De ce sunt fan Crockford? Au fost 3 lucruri care m-au surprins inca de la prima prezentare care am vazut-o cu el:

• a sustinut cu inversunare ca JavaScript are si parti bune, dar acestea nu sunt intelese,
• a spus ca JavaScript este un limbaj functional si trebuie luat ca atare pentru a descoperii frumusetea lui,
• a fost unul dintre foarte putinii care a scos o carte adevarata de programare despre JavaScript si nu doar o colectie de efecte speciale cum au facut majoritatea pana la el.

Seria de prezentari “Crockford on JavaScript” de la Yahoo!, nu este tocmai noua dar totusi foarte de actualitate.

Ce este diferit fata de celelalte prezentari sustinute, este ca nu sunt focalizata pe sintaxa, limbaj si evident “good parts”, ci mai degraba pe intreaga imagine de ansamblu, toata povestea limbajului, inclusiv istoria limbajelor care au avut o influenta.

Prezentarile sunt destul de lungi, peste o ora fiecare, dar foarte interesante dupa parerea mea, mai ales daca esti fan al istoriei calculatoarelor.

Partea a treia poate fi un pic mai dificila pentru ca sunt niste notiuni care pot parea destul de bizare. Dar o data ce te familiarizezi cu ele, multe lucruri incep sa fie mai clare.

In week-end navigam intrebandu-ma de ce nu exista inca 3d pe net realizat in JavaScript. O intrebare ridicola intr-o dupamiaza torida.

Intrebarea mea a plecat de la ideea ca prima etapa in evolutia 3d a fost facuta in 2d, practic reprezentarea obiectelor 3d folosind mijloacele 2d existente.

Evident am ajuns usor la primul meu rezultat: un shooter 3d direct in browser folosind JavaScript realizat de Ben Joffe!

Este cel putin impresionant!

In afara de acest raspuns imediat am mai gasit cateva variante de jocuri 3d realizate in JavaScript care nu se foloseasc de facilitati cum ar fi canvas, dar acele rezultate nu sunt foarte impresionante dintr-un motiv simplu: viteza!

Pana la HTML5 viteza de afisare in browser era o problema foarte mare. Este bine cunoscut ca una dintre cele mai incete componente dintr-un browser este DOM, in special in Internet Explorer. Cand vine vorba totusi de canvas se poate vedea o diferenta imensa in bine, multitudinea obiectelor de pe scena nu mai sunt coordonate prin DOM ci pur si simplu afisate intr-un element cu adevarat grafic.

In timp ce deschideam calculatorul azi ma intrebam, oare de ce nu se poate realiza un joc care sa fie macar ca Duke Nukem 3D? Evident, probabil browserul nu o sa devina prea curand o platforma concurenta cu XBOX pentru jocuri dar este normal… Nici nu-mi dau seama cum am ajuns acolo, dar parca ceva din universul meu m-a inpins spre ceva cu adevarat impresionant:

Quake 2 direct in browser, folosind JavaScript!

Initial m-am gandit ca au trisat, au folost WebGL, nu doar popularul canvas 2d. Dar rezultatul este cu adevarat impresionant, iar acest standard probabil va fi disponibil ca specificatie in HTML5, adica se va regasi pe cel putin o parte din browsere.

Chiar daca au folosit GWT, codul final rezultat este JavaScript, deci asa ceva se poate realiza folosind doar JavaScript!

De unde a plecat toata ideea de 3d in browser? Am citit acum aproape 2 ani despre niste eforturi in acest sens, iar acestea se bazau pe VRML. Dar VRML exista ca standard din 1994 si nimic impresionant nu am vazut pana acum. Am chiar si o carte de VRML care se umple de praf in biblioteca. Marele defect este ca nu exista browsere care sa ofere suport nativ.

Noua perspectiva este cu totul inovativa, pentru ca este o punte intre browser si hardware 3d. Deci probabil ca daca vom avea 3d in browser intr-o buna zi, asa va fi realizat!

Lucram eu zilele trecute la un nou joculet in JavaScript pentru sectiunea de jocuri. Ca marea majoritate a programatorilor (cum arata statisticile) si eu folosesc FireFox pentru dezvoltare. Dar cum jocul a ajuns in faza de testare am zis ca e timpul sa vad daca inca mai functioneaza corect in Internet Explorer.

Sa testez in Internet Explorer este o adevarata placere mereu, practic primesti o eroare iar apoi speri ca ai gasit sursa.

Evident a aparut o eroare, una plina de semnificatie ca de obicei:

Unknown runtime error??? WTF??? Daca el nu stie la ce are eroare, eu cum ar trebui sa stiu?

Bucata de cod care genera eroare era:

1canvas.innerHTML = '';

Unde canvas era un o variabila care stoca un document.getElementById(‘canvas’), iar id-ul canvas era de la:

1<table border="0" cellspacing="0" cellpadding="0">
2<tbody id="canvas"></tbody>
3</table>

Pare gresit? ei bine nu este pentru ca in acel moment am inceput sa ma uit la alte jocuri care fac cu succes acelasi lucru, chiar si in IE.

Am incercat si in IE 6, evident aceeasi eroare.

Se pare ca eroarea apare la blocuri cum ar fi table, tbody, p si altele.

Ca sa rezolv totusi problema am folosit in loc de un tbody un div in care adaug elementele iar problema a disparut ca prin minune.

Ce este interesant este ca problema asta nu apare tot timpul pentru un anumit tip de tag!

Multumesc Microsoft pentru mesajele de eroare care sunt atat de pline de logica!