Punti di contatto tra universi paralleli

Progettando una app multipiattaforma iOS/Android/WP8, si vuole trasformare un costo teorico 100×3 di tre progetti indipendenti (per produzione e distribuzione) in un ottimistico 150 dei quasi-tre-progetti-in-uno. Come?
Ovvero: quanto si può risparmiare sviluppando un’applicazione multipiattaforma? Dipende, ovviamente. Ma dipende da che cosa? Quantificare quante ore-uomo è possibile preservare è strettamente connesso a quanto spazio di manovra abbiamo.
La catena di montaggio di ogni progetto infatti, a prescindere dalla metodologia scelta per l’implementazione delle logiche funzionali, è condizionata a monte dalle specifiche di sviluppo del sistema operativo e a valle dalle metodologie e dagli strumenti per il deploy e la distribuzione sul mercato dedicato.
Ritrovandoci quindi vincolati sul che cosa fare, non ci rimane altra possibilità che giocarcela sul come farlo, ovvero come collegare al meglio il punto A col punto B per ogni contesto di produzione. In questo ambito app native, HTML5, 3D (OpenGL/DirectX) sono macrocategorie al cui interno possiamo cercare, per ciascuna, una strategia ottimale.

App native

In questo insieme troviamo le applicazioni progettate per restituire il look & feel del sistema operativo sottostante. Sono in genere le più veloci da costruire in quanto supportate sia dagli strumenti di sviluppo per il design WYSIWYG (What You See Is What You Get) delle interfacce, sia dalla documentazione ufficiale, sia dalla pluralità di moduli preesistenti e riutilizzabili per mezzo delle API (Application Programming Interface) e librerie contenute nell’SDK (Software Development Kit) liberamente scaricabile dal sito del produttore.
Tutto questo materiale che ci viene concesso non è una pura forma di cortesia produttore-sviluppatore, bensì una spietata corsa in cui i concorrenti cercano in ogni modo di accaparrarsi la fiducia di chi si sporca le mani, promettendo loro un lavoro più facile e veloce per un risultato più potente ed economico, senza far mancare poi il classico te lo vendiamo noi! Cosa vuoi di più?

Lo sviluppo nativo multipiattaforma è pertanto delegato al massimo comune divisore fra tutti i metodi con cui possiamo programmare i dispositivi, ed al momento consiste in moduli C/C++ e relativa sovrastruttura per chiamare le API ufficiali/componenti native. In commercio esistono soluzioni dedicate che offrono la possibilità di scrivere ed utilizzare con un singolo linguaggio le diverse API native a seconda delle esigenze e possibilità.

HTML5

Sono le soluzioni che fanno leva sulla capacità del browser e relativo interprete o motore JavaScript installato nei dispositivi. Il concetto di base è relativamente semplice: si tratta di pagine web che però non lo vogliono sembrare e quindi si spacciano per applicazioni.
L’utente non riesce (anzi direi che non può) distinguere una pagina web da un’applicazione, se questa è stata progettata per nascondere tutte le imperfezioni conseguenti alla scelta di questo compromesso. Trovano qui ruolo interi framework atti a fornire allo sviluppatore soluzioni per raggiungere nel più breve tempo possibile questi risultati.

Anche in questo caso, per usare le funzioni di sistema (come accendere il led del flash o salvare un file in memoria) è necessario utilizzare una sovrastruttura di codice capace di accedere alle API ufficiali. Accedere alle funzioni di sistema partendo da una pagina web è possibile nel momento in cui si ha il controllo del browser ovvero del contenitore/vista che sta renderizzando la nostra pagina-applicazione HTML5.

3D

Infine trattiamo delle applicazioni che fanno un uso attivo della pipeline di rendering configurata nei processori grafici dei dispositivi. Si tratta di prodotti dove possiamo apprezzare le animazioni avanzate o con centinaia di oggetti in scena, o più generalmente una grafica più accattivante del solito (potrei dire giochi, ma sarei riduttivo).
Queste applicazioni devono fare un uso più accorto di tutto il comparto RAM+CPU+GPU e pertanto risultano essere generalmente più complesse e costose da sviluppare. Il punto di contatto in questo caso non è (fortunatamente) da ricercare mettendo insieme le API dei produttori, bensì nella specifica grafica alla quale essi hanno aderito e quindi esposto le funzioni documentate. Non abbiamo molte possibilità: le principali sono OpenGL e DirectX, ma solo la prima è compatibile su tutte le piattaforme.

I framework che si occupano di dialogare per mezzo di linguaggi di alto livello con le funzioni descritte in questa specifica prendono il nome di motori grafici o graphic engine. I game engine sono motori grafici allargati, ed anche in questo caso esiste la sovrastruttura dedita alla semplificazione dell’interazione con le funzioni delle API ufficiali.
Sarebbe davvero insperato conoscere la lista delle API necessarie per ciascuna piattaforma in sede decisionale, durante lo startup di una nuova applicazione. In tal caso, infatti, le scelte inerenti al come realizzare la versione per ogni piattaforma diverrebbero non dico ovvie, ma sicuramente più comode.