Sviluppare apps per iPhone e iPad: differenze tra ambienti di sviluppo per Windows e Mac.

iOS Development from Iperfile.it

Il numero di applicazioni per smartphone è passato da circa 50.000 nel 2009 (anno di uscita dell'iphone 4) fino ad oltre 500.000 nel 2014 per un business di decine di miliardi di dollari. In un contesto del genere e, con un occhio rivolto al futuro, considerando anche il sempre crescente sviluppo della domotica, gli smartphones si configurano come i naturali successori di telecomandi e interruttori in una smart-casa. 
Saper programmare un'app per smartphones, pertanto, anche per un "elettronico", è una competenza spendibile nel presente e nel futuro. Objective C, Java, C++, C#, HTML, .NET eccetera. Come e cosa scegliere se si parte da zero? Cos'è un IDE cross-platform e quando conviene usarlo? Confrontiamo insieme le varie opportunità in quest'articolo.

Credits

Malgrado la sempre maggiore diffusione dell'elettronica Open Source, il passaggio che separa la prototipazione dall'industrializzazione è ben lungi dall'essere colmabile attraverso l'Open Source.

Molti protitipi realizzati da hobbysti e ingegneri, infatti, spesso si arenano, dal punto di vista commerciale, ancora prima di nascere per via di stringenti norme di sicurezza, certificazioni, oltre che per la difficoltà intrinseca di promuovere un prodotto elettronico.

Questa elevata barriera all'ingresso posta dal mercato dell'hardware risulta invece essere, almeno in parte, stata superata in quello del software, in particolare in quello delle app per smartphone. 

Entrarvi è, infatti, di una semplicità estrema e non servono particolari certificazioni, né si necessita di qualificarsi come una figura giuridica. 

Gli App Stores rappresentano dei microcosmi in cui le grandi aziende investono molto, generandone le infrastrutture, ovvero le App portanti tuttavia, essi dominati dai cosiddetti “Indie Developers”, ovvero gli sviluppatori indipendenti, veri e propri “Pirati” di una Silicon Valley virtuale, citando il film cult del 1999 di Martyn Burke.

Stando ai dati riportati dal noto circuito di banner pubblicitari per Smartphone Flurry, infatti, il numero di sviluppatori indipendenti, nel caso in analisi di Giochi, è in aumento e al 2012 si attestava intorno al 68%, un vero e proprio trionfo del libero mercato!

Dopo aver decantato il magico mondo degli App Stores e averli paragonati a un vero e proprio Klondike dove cercare fortuna con le proprie Apps senza bisogno di una solida infrastruttura societaria alle spalle, andiamo ad osservare nel dettaglio le barriere all’ingresso che un aspirante sviluppatore deve affrontare nel lungo percorso verso la commercializzazione del prodotto.

  • Il linguaggio di programmazione (quale e come scegliere);
  • Ambienti di sviluppo e strumenti (costi e opportunità);
  • Marketing dell'App.

In questo articolo verranno approfonditi soltanto i primi due punti in maniera congiunta.

Scegliere un linguaggio

Il linguaggio di programmazione non rappresenta una vera e propria barriera all’ingresso, ma è una scelta da tenere in considerazione per diverse ragioni e strettamente correlata all’IDE e, talvolta all’hardware necessario per lo sviluppo.

  • Per programmare applicazioni per iOS attraverso l’IDE ufficiale Xcode occorre conoscere il linguaggio Objective C che è un “super-set” del linguaggio C, ovvero totalmente retrocompatibile con esso, che aggiunge alcune funzioni che ne estendono l’utilizzo facendolo evolvere da linguaggio procedurale a un linguaggio ad oggetti;
  • Per programmare applicazioni per Android la maggior parte degli sviluppatori adotta l'IDE Eclipse, anche se molti stanno gradualmente migrando verso “Android Studio”. Il linguaggio nativo da conoscere è in questo caso Java (in alternativa C++), e, per essere in grado di manipolare le interfacce grafiche in maniera efficiente, un minimo di XML;
  • Infine, per programmare per Windows Phone, il cui mercato è in rapida crescita, nel linguaggio nativo occorre conoscere uno dei linguaggi “Microsoft .NET”, ovvero: C#, Visual Basic .NET, J# e Managed C++ per IDE Visual Studio.

Da questo cappello appare palese che, nell'ottica di realizzare una applicazione che includa la fascia di mercato più ampia possibile, occorrerebbe conoscere almeno un linguaggio di programmazione per Sistema Operativo.

Osservando il grafico sottostante e, ragionando puramente in termini di mercato, l'unico sistema operativo per cui sembrerebbe sensato iniziare a programmare parrebbe esssere Android che copre oltre l'80% del fabbisogno mondiale di Smartphone.

Fonte: Wikipedia

Tuttavia questi grafici celano un tranello: mostrano, infatti, il numero di unità di smartphone venduti  che adottano i diversi sistmi operativi. 

Ben altra cosa è il numero degli utenti che effettivamente utilizzano il device in questione, e quindi i potenziali clienti, cosa messa bene in evidenza dal grafico seguente stilato dalla nota agenzia di Rating Nielsen.

Dall'ultimo grafico appare ben evidente che la linea tra OS Android e iOS è sottile (circa 11%) e che Windows Phone è ancora ben lungi dal raggiungere una porzione interessante di mercato, anche se risulta sicuramente essere il sistema operativo che mostra il maggiore tasso di crescita in numero di utenti.

La segmentazione del mercato è stato un cappello necessario per introdurre gli IDE cross-platform e spiegarne limiti e vantaggi. 

Gli IDE cross-platform

Un IDE cross-platform è essenzialmente un ambiente di programmazione che consente di sviluppare Software per più piattaforme contemporaneamente (ad esempio iOS e Android) attraverso un unico linguaggio di programmazione di alto livello.

Questo approccio solitamente pone severi limiti in termini di funzionalità e interfaccia grafica e, nella maggior parte dei casi, porta alla creazione di app che, pur essendo efficaci (fanno ciò per cui sono preposte), non sono per niente efficienti e risultano anche scarsamente personalizzabili.  

Prima di scartare a priori questi IDE occorre però effettuare una opportuna distinzione, poichè, mentre alcuni di questi forniscono come output un file eseguibile pronto per essere pubblicato sullo store (.apk o .ipa) e quindi non ulteriormente modificabile dallo sviluppatore, altri ambienti generano come output linee di codice di linguaggio nativo (Java o objective C) e quindi possono risultare un importante strumento per costruire un'unica infrastruttura dell'applicazione.

Non bisogna, pertanto, scartare a priori i tool per sviluppare cross platform, ma è necessario considerarli da un punto di vista più ampio, con i loro pregi e difetti.

Pregi:

  • Riduzione dei tempi di sviluppo;
  • Semplicità di sviluppo;
  • Eccellente documentazione (è uno dei punti forza di questi ambienti).

Difetti:

  • Costi spesso elevati (gli IDE hanno un costo!);
  • Codice inefficiente (si traduce nel peggiore dei casi in una globale lentezza delle app);
  • Elevati tempi di Cross-Compilazione;
  • Non garantita retrocompatibilità per versioni future degli OS;
  • Snaturalizzazione delle Apps.

Il peggior difetto tra quelli elencati è certamente la snaturalizzazione delle app.

Sviluppando in un linguaggio diverso da quello nativo, che viene poi generato attraverso degli script,  l'applicazione viene privata della sua identità. La fantasia, l'arte, la filosofia e il design che ci sono alle sue spalle scompaiono per cedere il posto alla standardizzazione. 

Volendo effettuare una audace comparazione si potrebbe considerare l'app risultante da un codice realizzato tramite un IDE cross-platform come "un prodotto di una catena di montaggio industriale" e quella derivante dal linguaggio nativo come "un prodotto artigianale".

Chiaramente un prodotto artigianale può essere tanto migliore quanto maggiori sono le competenze e le esperienze dell'artigiano, mentre un prodotto industriale svolge sempre (o quasi) lo scopo per cui è stato creato.

In conclusione, lo sviluppatore non deve escludere a priori gli IDE cross-platform, specie quelli a basso costo, che rispondono molto bene a situazioni in cui l'urgenza e il low-budget sono le specifiche cui bisogna attenersi.

Il fatto che i costi degli IDE siano elevati non deve essere considerato necessariamente come un valido motivo per non usarli, in quanto, facendo questi risparmiare notevole tempo allo sviluppatore, fanno in modo che il suo lavoro, nel caso di applicazioni su commissione, abbia un costo drasticamente minore incrementando così la sua competitività sul mercato. 

Tra i principali IDE cross-platform iOS, Android citiamo :

  • Appcelerator ->Si scrive in JavaScript e si traduce in iOS, Android, Windows Phone (versione Titanium Open Source, versioni comprensive di cloud computing a pagamento);
  • PhoneGap -> Si scrive in JavaScript, HTML, CSS, si traduce in App iOS,Android,Symbian,Windows Phone, Blackberry, Bada (totalmente Open Source, nel 2011 è stato donato all'Apache Foundation);
  • MoSync -> Si scrive in C/C++, HTML 5, si traduce in App iOS,Android,Symbian,Windows Phone, Blackberry, Moblin,Java,Windows Mobile, MeeGo  (Open Source, ma se si vuole pubblicare una applicazione senza rilasciare pubblicamente il codice occorre prendere la versione Basic Pro a 199€ l'anno);
  • Xamarin -> Si scrive in C#, si traduce in App iOS,OSX,Android,Windows (versione Indie  a 299$ l'anno per sistema operativo e per sviluppatore. Versione Business a 999$ l'anno per sistema operativo e per sviluppatore).

Poichè quest'articolo è incentrato sullo sviluppo per iOS, di seguito ci si occuperà di descrivere e confrontare l'ambiente di sviluppo nativo XCode e un "simil cross-compiling IDE", ovvero DragonFireSDK. Il senso di questo confronto trova la sua ragion d'essere nel fatto che l'IDE XCode è sviluppato soltanto per ambiente Mac e, pertanto, volendo programmare apps per iOS su ambiente Windows senza dover necessariamente comprare un Mac, trascurando macchine virtuali o Hackintosh vari, DragonFireSDK è senz'altro una possibilità. 

Confronto tra DragonFireSDK ed XCode

DragonFireSDK è un particolare SDK che consente di sviluppare Apps per iOS su ambiente Windows configurandosi come un plug in di Visual Studio

Poichè l'unico tipo di apps che si possono programmare con DragonFireSDK sono per iOS non è corretto definirlo un SDK cross-platform, tuttavia, mi accingo a descrivere questo sia per i numerosi punti in comune con un IDE cross-platform sia perchè ho avuto modo di utilizzarlo in prima persona per circa un anno.

Costi

Tool Ambiente Costo IDE App OS Pubblicazione App Licenza per AppStore
Xcode Mac FREE iOS FREE 80€ per anno
DragonFireSDK Windows 150$ iOS 10$ 80€ per anno

L'acquisto di DragonFireSDK costa 99.95$ una tantum e consente di sviluppare apps solo per iPhone oppure solo per iPad. Volendo però sviluppare per entrambi i tipi di Device, il prezzo da pagare è di 150$ cui vanno sommati 10$ per ogni App o aggiornamento di App che si intende pubblicare su AppStore e 3$ per ogni Device da aggiungere ai propri "provisioned Devices" (ovvero Debug & Test Devices), costi che diventano considerevoli con il passare del tempo.

Infatti, pur essendo in generale gratuito effettuare queste due operazioni sugli IDE per Sviluppatori iOS, l'utente, che si presuppone non utilizzi XCode, non può effettuarle senza di XCode e pertanto lo staff DragonFireSDK offre un "ottimo" servizio sostitutivo a pagamento.

L'IDE XCode, al contrario, è gratuito ma, come specificato prima, soltanto per ambiente Mac e non prevede alcun costo extra.

Pubblicare una o più Apps sull'App Store per un anno implica il pagamento, a prescindere dall'ambiente di sviluppo, di una quota forfettaria di 80€ per anno. Quest'importo corrisponde all'acquisto di uno dei Developers Programs per iOS o OSX che possono essere acquistati sul sito degli sviluppatori apple.

Linguaggi

DragonFireSDK non richiede la conoscenza nè di JavaScript nè di HTML nè di C# ma del sempre antico e quantomai moderno linguaggio C

Il C, ben noto ai programmatori di microcontrollori, è un linguaggio procedurale, mentre l'Objective C, ovvero il linguaggio di programmazione nativo di XCode, come lo stesso nome suggerisce, è una versione orientata agli oggetti del linguaggio C

L'Objective C fu creato nella metà degli anni 80 da Brad Cox e Tom Love, i fondatori della Stepstone Corporation, acquisita poi da NeXT Computers nel 1995 (la società fondata da Steve Jobs nel 1985 dopo essere stato espluso dalla Apple e che poi rilevò la stessa Apple), è totalmente retro-compatibile il C puro e la sua mission si esplica nel tentativo di somigliare il più possibile al linguaggio inglese parlato.

L'SDK di DragonFireSDK consente di usare il linguaggio C (o anche di usare il C++) per richiamare dei metodi di Objective C. Infatti, attraveso l'API DragonFireSDK.h, è possibile utilizzare un'ottima parte di Framework, Librerie e Metodi dell'Objective C, risultando però totalmente trasparenti ad esso e continuando a conoscere semplicemente il C.

DragonFireSDK mette inoltre a disposizione, come XCode del resto, un simulatore di iPhone su cui debuggare il codice come se si stesse utilizzando un vero device. Questo Tool, tuttavia, non è sufficiente per testare adeguatamente una applicazione in quanto non è in grado di emulare alcune features come gli in-App Purchases, le Push Notifications, l'accelerometro, il giroscopio etc, e pertanto presuppone che lo sviluppatore sia comunque in possesso di un Device Apple.

Poichè la politica di Apple è molto stringente circa la qualità delle Apps sullo Store, al punto che vengono revisionate una per una testandone ogni singola funzione, acquistare un Device Obsoleto (non aggiornabile al sistema operativo corrente) per Debugging non è sicuramente un'opzione consigliabile, poichè un basta un piccolo Bug e l'App finisce con il non essere approvata.

Inoltre le Apps, stando a una direttiva Apple di Gennaio 2014 devono essere ottimizzate per iOS 7 e per lo schermo 4'' di iPhone 5, altrimenti non verranno pubblicate.

Tornando a DragonFireSDK, sebbene nella versione 2.0 dell'API siano state aggiunte funzionalità importanti come ad esempio la possibilità di integrare il motore grafico Open Source BOX 2D, il supporto per SQLite e la compatibilità con gli iPhone 5, DragonFireSDK resta uno strumento estremamente limitante perchè, per come è strutturato, rende impossibile l'aggiunta di una qualsiasi API esterna se non integrando tutte le funzioni in un unico foglio di codice C dove risiede la Main Function.

In poche parole, il codice diventa illeggibile e ogni API di terze parti, per poter essere integrata nel progetto, deve praticamente essere riscritta da capo. Non esiste un vero e proprio progetto, ma semplicemente due file .h e .c, che costituiscono lo spazio di lavoro del programmatore. Librerie terze, infatti, seppure accettate in fase di compilazione da Visual Studio, non sono supportate dall'SDK di DragonFire.

L'installazione dell'applicativo sul proprio dispositivo Apple può essere fatta abbastanza semplicemente via cavo e tramite iTunes, o addirittura in Cloud attraverso il sistema OTA (Over The Air). 

Hello World

L'IDE Xcode prevede un duplice modo per lavorare sulla User Interface, ovvero disegnando fisicamente i vari layer all'interno di ViewControllers (l'equivalente delle Activities per Android), oppure programmatically, cioè attraverso il codice. 

Poichè DragonFireSDK non offre la possibilità di gestire l'interfaccia grafica in maniera diretta andremo a confrontare soltanto il codice.

 

1) DragonFireSDK

    int font=FontAdd("Helvetica","Regular",14,0xFF0000);

    int text=TextAdd( 0, 100, "Hello World", font);

 

2) XCode

    CGRect frame = CGRectMake(0, 100, 320, 200);

    UILabel *helloLabel = [[UILabel alloc] initWithFrame:frame];

    helloLabel.text = @"Hello World"

    helloLabel.font = [UIFont fontWithName:@"Helvetica" size:14];

    helloLabel.textColor = [UIColor greenColor];

    [self.view addSubview:helloLabel];

 

Supponendo di aver configurato correttamente i due IDE, questi due codici, eseguono esattamente lo stesso compito, ovvero aggiungere un'etichetta con scritto "Hello World", disegnata a partire dai Pixel di coordinate (0,100) del device. 

Si possono osservare a questo punto le differenze tra i due linguaggi a prescindere dalla sintassi. 

 

1)

La cosa che immediatamente risalta dal codice è che un Font, aggiunto tramite il comando FontAdd, è un int e che la funzione FontAdd ha 4 argomenti, di cui 2 stringhe, un int e un HEX, analogamente TextAdd restituisce un numero intero e riceve come argomenti 3 int e una stringa.

Le funzioni di DragonFireSDK restituiscono sempre o quasi dei numeri interi il cui valore, ben lungi dal poter essere interpretabile, rappresenta solo e soltanto il riferimento all'oggetto in questione, in questo caso un Font e un'etichetta. Quindi guai a sovrascrivere le variabili font e text o non si potrebbe più accedere agli oggetti cui queste puntano!

Il codice esadecimale rappresenta il valore HEX del colore del testo secondo la nomenclatura standard dei colori per codice HTML.

Lo stile del Font sono definiti tramite i valori tra virgolette Helvetica e Regular mentre la dimensione tramite il parametro intero '14'.

In TextAdd, invece, i primi due parametri rappresentano i pixel di origine del testo sul display, il terzo il testo visto come stringa e il quarto il Font. 

 

2)

Nel codice Objective C, sorvolando sul metodo che alloca la memoria e inizializza l'oggetto helloLabel, si può notare che il posizionamento dell'etichetta necessita di due coordinate in più, ovvero la lunghezza e l'altezza, attraverso i quali si possono definire i bounds ovvero i confini dell'etichetta stessa.

La mancanza di questi parametri in DragonFireSDK rende l'allineamento rispetto ad un asse di simmetria del testo molto difficile, se non impossibile.

Infatti, mentre in XCode per fare questa cosa è sufficiente definire un confine grande quanto lo schermo del dispositivo in questione e quindi specificare come attributo del testo l'allineamento centrale

 

    CGSize size = [UIScreen mainScreen].bounds.size;
    helloLabel.frame = CGRectMake(0, 100, size.width, 100);
    helloLabel.textAlignment = NSTextAlignmentCenter;

 

In DragonFireSDK il programmatore dovrebbe calcolare, oppure creare una funzione che lo faccia, lo spazio in Pixel occupato dal testo dell'etichetta e quindi spostare l'origine dell'etichetta di conseguenza attraverso la funzione

 

    int TextSetxy(int tx, int x, int y);

 

Immaginando di avere un'app multilanguage e quindi dove il testo dell'etichetta non è noto a priori, ma dipende dalla lingua del dispositivo si possono capire molti dei limiti di quest'approccio.

Continuando nella customizzazione dell'etichetta vado a trasformare lo sfondo di quest'ultima da bianco a verde pastello tramite Xcode.

 

   helloLabel.backgroundColor = [UIColor greenColor];

 

Questa operazione non può essere fatta tramite DragonFireSDK perchè non prevista dall'API e per emularla occorrerebbe creare una sorta di livello raster da anteporre al di sotto dell'etichetta del colore selezionato, consumando così in modo iniquo tempo e memoria (si può dire che sarebbe come utilizzare un cannone per aprire una porta di legno semichiusa).

Aggiungendo la libreria di sistema Quartzcore.h in XCode si possono ottenere customizzazioni ancora più spinte settando ad esempio le dimensioni, il colore e l'angolo di curvatura della cornice che racchiude l'etichetta, piuttosto che la trasparenza di quest'ultima. Tutte cose che in DragonFireSDK andrebbero fatte attraverso una immagine di sfondo opportunamente disegnata in PhotoShop.

 

    helloLabel.layer.cornerRadius = 50;

    helloLabel.layer.borderColor = [UIColor blackColor].CGColor;

    helloLabel.layer.borderWidth =5;

    helloLabel.layer.backgroundColor = [UIColor greenColor].CGColor;

    helloLabel.alpha = 1;

In conclusione in questo articolo è stato utilizzato DragonFireSDK per mettere in evidenza i limiti degli IDE cross-platform in generale e per mostrare al lettore che, se si dovesse, costretti con le spalle al muro, scegliere se imparare un linguaggio di programmazione nativo, oppure utilizzarne uno già noto, a lungo andare è senz'altro la prima opzione quella che paga. 

Ciò nonostante gli IDE cross-platform, se correttamente utilizzati rappresentano un validissimo strumento per la progettazione iniziale di un app multi-piattaforma in cui definire, per esempio, i modelli delle varie classi e l'infrastruttura grafica iniziale da customizzare poi nei linguaggi nativi, per offrire all'utente il piacere di utilizzare un applicazione che metta ben in risalto il Concept del sistema operativo del suo Smartphone.

STAMPA     Tags:, , , , ,

8 Comments

  1. Antonio.Braile 13 settembre 2014
  2. Luigi.D'Acunto 13 settembre 2014
  3. Luigi.D'Acunto 21 maggio 2014
  4. gfranco78 22 maggio 2014
  5. Luigi.D'Acunto 22 maggio 2014
  6. Marco.Riva 1 25 aprile 2014
  7. Piero Boccadoro Piero Boccadoro 11 aprile 2014
  8. gfranco78 12 aprile 2014

Leave a Reply