Adobe AIR for Android: istruzioni per l’uso

Mentre mi sto apprestando a ripubblicare la versione riveduta del mio giochino sul lotto e continuo alla lavorazione di un nuovo progetto, ho deciso di scrivere due righette sulla mia esperienza di sviluppatore AIR. Visto che la documentazione sull’argomento scarseggia, spero di contribuire nel mio piccolo ad ampliare le informazioni sull’argomento.
Da qualche annetto, pur continuando a portare avanti la mia solita attività di webmaster/designer e consulente, nei ritagli di tempo non ho mai smesso di giocare con AIR. Non trovando informazioni soddisfacenti su alcuni aspetti tecnici, ho creato su una sorta di mini laboratorio casalingo: ogni volta che un dispositivo android veniva sostituito da un nuovo modello, invece di regalarlo o venderlo, finiva nella mia lista di smartphone o tablet da testare. Attualmente ho cinque smartphone e due tablet sui quali provo i miei lavori (se tutto va male, posso sempre mettermi a fare il rivenditore di dispositivi usati). Nel corso degli ultimi due anni ho anche creato decine di mini app utili solo per effettuare dei test o creare soluzioni riusabili. Chiaramente, dopo l’ennesima applicazione che serve solo a provare questa o quella funzione, amici e parenti hanno minacciato di uccidermi a colpi di macete se non iniziavo a concretizzare. Per cui sono passato “spontaneamente” alla creazione delle prime app complete e spendibili sul wallet. Tornando al succo del discorso, nel corso di questi mesi ho imparato cosa può fare AIR, come farlo e soprattutto cosa quali errori evitare. Ecco la mia breve ricetta in sei punti.

• Non animare troppo. Adobe AIR è perfetto per applicazioni come Candy Crush Saga (che è stato appunto ideato con quella tecnologia), ma a prescindere dalla frequenza impostata o da quali classi usare per muovere oggetti, se si animano troppe cose assieme, la scheda grafica soffre arrivando a creare dei piccoli scatti. Non dico di creare giochini statici, ma bisogna usare con giudizio movimenti e dissolvenze. Non tutte assieme e mai una dietro l’altra.

• Preferire le bitmap. Se come me si è affezionati al tool classico, lasciare come impostazione predefinita la grafica vettoriale sarebbe comodo e immediato. Tuttavia, i processori più vecchi soffrono nel ridisegnare continuamente curve vettoriali. In questi casi conviene usare direttamente le bitmap o anche solo impostare la proprietà cacheAsBitmap su true.

• Non usare simboli nidificati attivabili dal tocco. Spesso, mi è capitato di riscontrare bug quando ho inserito elementi in altri elementi. Le regole dell’ereditarietà, i listener impostati come si deve e tutte le normali teorie vanno a farsi friggere. Purtroppo, si tratta di problemi che non sempre sono omogenei. Magari non succede niente se attivi il touchEvent con un Galaxy ma riscontri un tilt con un Nexus. Il malfunzionamento del tocco diventa imprevedibile. Meglio impostare come target dell’evento oggetti in primo piano o anche usare aree invisibili sempre in primo piano.

• Non usare gli eventi del mouse. Lavorando in AIR è possibile approfittare del fatto che durante la creazione del file apk, il motore traduce gli eventi del mouse in eventi del tocco. Per fare alcuni esempi, MOUSE_DOWN diventa TOUCH_BEGIN, MOUSE_UP diventa TOUCH_END e così via. Spulciando la rete è addirittura possibile trovare degli articoli in cui dei developer suggeriscono di usare gli eventi del mouse per risparmiare risorse. Bene (anzi male), in base alla mia esperienza ci possono essere malfunzionamenti analoghi a quelli descritti per gli oggetti nidificati. Quindi se si creano app, conviene sempre fare riferimento al touchEvent.

• Ricordarsi di disattivare gli eventi ricorsivi quando non servono. Sembra una sciocchezza ma in molti se ne dimenticano. Per muovere personaggi, far rimbalzare palline, sparare missili o anche semplicemente far scorrere menu sono necessari strumenti quali il timerEvent, l’entreFrame, o anche la funzione setInterval. Alcuni sviluppatori consigliano di disattivare anche i listener relativi al tocco quando non servono, ma personalmente (in base ai miei test) non ho riscontrato sostanziali differenze. Cosa che invece non avviene con gli eventi ricorsivi: in quel caso spegnerli con un semplice removeEventListner velocizza – anche se di poco – le prestazioni. 
• Infine, ma questo è un semplice consiglio frutto del buon senso. Quando si crea un’app, conviene sempre provarla su modelli di penultima o terzultima generazione. Se la proviamo solo sull’ultimissimo modello, con il processore migliore in circolazione e una buna ram, stiamo falsando il nostro test.

In conclusione Adobe AIR, nonostante le scelte scellerate dei vertici della casa madre, e pur non essendo allo stesso livello della applicazioni native pure, resta allo stato attuale uno strumento di tutto rispetto. Bisogna solo essere consapevoli dei limiti e saper valorizzare i punti di forza.