Soluţii - PC Magazine Romania, Aprilie 2004

MIDP - programare pe înţelesul mobilelor

Mircea Scărlătescu

Aţi avut ocazia să citiţi în numerele trecute despre ce înseamnă programarea pentru telefoane mobile JavaEnabled. Desigur că cea mai bună metodă de învătare este experimentarea API-ului şi a uneltelor de dezvoltare. Aici însă vă oferim o serie de sfaturi din punctul de vedere al ergonomiei şi al eficienţei programelor pe care le veţi realiza.

Orice program (din orice domeniu, didactic, programare în timp real, grafică etc.) va fi întodeauna catalogat din punctul de vedere al vitezei de execuţie. Deşi, în cazul PC-urilor de azi, şi mai ales în domeniul serverelor, viteza nu mai este o problemă atât de stringentă (puţine programe utilizează serios un calculator în ziua de azi) pentru un device mobil, care foloseşte procesoare mult mai lente şi cu resurse mult limitate, viteza de execuţie redevine o problemă de actualitate.

Cum îmbunătăţim viteza de execuţie a unui program? Nu sunt puţini programatorii care sunt de acord că un program rulează de obicei 75% din perioada de viaţă într-o zonă de cod care este cam 10% din totalul programului. Aşadar, aceste zone trebuie identificate, şi e obligatoriu să găsim cei mai buni algoritmi pentru aceste zone de execuţie. Având în vedere faptul că un program în ziua de azi poate să însemne în mare parte apeluri către biblioteci deja făcute de alţii, modul de funcţionare al acestor biblioteci trebuie atent studiat. Dacă un apel către o funcţie de bibliotecă ce nu vă aparţine durează prea mult până se execută, atunci poate e un semn să folosiţi altă funcţie, altă bibliotecă sau să vă scrieţi chiar voi o bibliotecă, mai bună decât cea existentă. De asemenea, atunci când proiectaţi un soft pentru un telefon mobil, ţineţi cont de capacităţile şi specificaţiile acestuia. Viteza unui program pe două tipuri de telefoane diferite poate să varieze semnificativ. Totodată, încercaţi să fiţi cât mai la curent cu schimbările realizate de producătorii telefonului în arhitectura lui, influenţa acestor schimbări putând fi semnificativă.

Interfaţa grafică a unui program este deosebit de importantă pentru performanţele unui soft pentru J2ME. Şi la calculatoarele personale, grafica unui joc este cea care de cele mai multe ori vă va face să constataţi că sistemul dumneavoastră este rămas în urmă. Acelaşi lucru este valabil pentru un telefon. Grafica unui program nu trebuie să fie prea încărcată, nu trebuie să conţină elemente care să nu aibă o funcţionalitate directă (imagini fără rost, eventual şi de dimensiuni mari J). Problema devine ceva mai complicată atunci când discutăm de MIDlet-uri care sunt jocuri. Atunci valoarea programatorului iese cel mai bine în evidenţă. Evitaţi operaţiunile de "repaint" a ecranului când nu este cazul. Dacă se poate, redesenaţi doar porţiunea care de la un frame la altul se schimbă. Efectul viziual este acelaşi, în schimb procesorul este mai puţin utilizat, operaţia devenind mai rapidă.

Programamea multi-thread în cadrul unui program poate să aducă importante beneficii. Task-uri care se pot executa în paralel cu o operaţie de transmitere pe reţea via HTTP spre exemplu se pot implementa în thread-uri separate, şi astfel creşte mult eficienţa programului. Thread-urile se pot aştepta unele pe altele dacă este nevoie, dar cert este că eficienţa va creşte simţitor, mai ales la programele care lucrează cu reţeaua de comunicaţie. De asemenea, în aceeaşi sferă a comunicaţiei cu alte device-uri mobile, proiectaţi protocoalele de comunicaţie cât mai eficient, tinând seama că reţelele wireless de azi nu au viteza unei reţele Ethernet. Şi este neplăcut dacă un program afişează un icon de gen "Loading" sau "Uploading" mult prea des în execuţie. Desigur, aici modul de programare ţine mult de experienţă, şi de studiul comportării unui cod pe un device real, sau pe un emulator de calitate.

Reducerea dimensiunii arhivelor JAR este deosebit de importantă pentru un utilizator. Traficul generat pentru încărcarea pe telefon printr-o reţea a unui JAR de cele mai multe ori se plăteşte, şi nimeni nu vrea costuri mari pentru o factura, nu? :) Deci trebuie avut în vedere că o arhivă JAR va fi mai mare sau mai mică în funcţie de dimensiunea fişierelor pe care le conţine. Aşadar, în programarea J2ME e de multe ori mai bine să nu încărcaţi biblioteci mari, din care folosiţi metode prea puţine.

Demodata metodă "Ctrl-C -> Ctrl-V" pentru metode şi funcţii se poate dovedi foarte eficientă, din acest punct de vedere.

V-am prezentat 4 puncte de reper pentru eficientizarea programării pentru device-uri mobile. Desigur, există şi multe alte soluţii, dar la acestea vom mai avea timp să ne referim.

Mult succes!