Android, iPhone e Windows Phone: serve 1 mentore x capirne potenzialità e differenze

[Matrixbob]

http://it.wikipedia.org/wiki/Android
http://en.wikipedia.org/wiki/Android_(operating_system)
http://it.wikipedia.org/wiki/Iphone
http://en.wikipedia.org/wiki/Iphone
http://it.wikipedia.org/wiki/Windows_Phone_7
http://en.wikipedia.org/wiki/Windows_Phone_7

Come differenze, come uguaglianze, come killer application, come reali utilità, come esclusività e anche a livello programmabilità/sviluppo.

Chi vuole dire qualcosa?

[Matrixbob]

Io come pseudo-programmatore immagino che sia + facile, e quindi meglio, lavorare su Android e WP7 che sul C ad oggetti di iPhone.

[pabloski]

objective-c non è niente di strano e una volta capito come funziona lo troverai decisamente avanzato e piacevole da usare

android ha il vantaggio di usare java e quindi un linguaggio diffusissimo

windows ti dà la possibilità di usare i vari linguaggi di .net anche se la fusione con silverlight non è che mi piace tanto....è come se su pc fossi costretto ad usare flash per creare le tue interfacce

se poi parliamo di quale piattaforma è più valida in termini di diffusione e di money per il programmatore allora la scaletta è iOS, Android e Windows

tieni presente che android ha più share di ios ma il secondo ha utenti più spendaccioni, windows non ha nè l'uno nè gli altri

[Tommo]

Pensieri sparsi:

IOS ha un volume di acquisti di molte volte superiore ad Android;

IOS ha una pirateria molte volte inferiore ad Android;

Android costa meno e approvano un pò tutto

Android usa Java

IOS supporta in maniera completa lo sviluppo di applicazioni native, quindi in C++; e quindi spesso puoi ignorare completamente ObjC (i miei giochi sono tutti C++ puro).

Il supporto Android per le app native è piuttosto carente, o almeno lo è stato fino alla 2.3, quindi il supporto è scarso anche in termini di users.

Al contrario WP7 non supporta nulla che non sia MS, quindi qualunque cosa andrà sviluppata da 0 e rimarrà legata a WP7 per sempre.

Personalmente credo che IOS sia molto più maturo e semplice da sfruttare rispetto ad Android che è ancora troppo frammentato e lasciato a se stesso, specie per chi sviluppa applicazioni native.
WP7 è un ambiente davvero interessante ma non ho intenzione di sacrificarmi per arricchire il parco esclusive di MS.

[insane74]

giusto per aumentare la confusione:
http://monotouch.net/
http://monodroid.net/

e così si scrive in C# sulle 3 diverse piattaforme.

[Tommo]

Originariamente inviato da insane74

giusto per aumentare la confusione:
http://monotouch.net/
http://monodroid.net/

e così si scrive in C# sulle 3 diverse piattaforme.

Se uno invece che sviluppare mira a farsi del male, è perfetto

[insane74]

Originariamente inviato da Tommo

Se uno invece che sviluppare mira a farsi del male, è perfetto

uno che sviluppa è già uno che ama farsi del male!

[pabloski]

Originariamente inviato da insane74

giusto per aumentare la confusione:
http://monotouch.net/
http://monodroid.net/

e così si scrive in C# sulle 3 diverse piattaforme.

lasciando da parte android, ma usare monotouch su iOS è un suicidio...che succede se apple se ne esce con una nuova trovata anti-altri-ambienti-di-sviluppo?

poi l'overhead di simili soluzioni qual'è? su un pc può andar bene ma su un telefono non è che si finisce per avere un'applicazione che va a scatti?

[insane74]

Originariamente inviato da pabloski

l...

poi l'overhead di simili soluzioni qual'è? su un pc può andar bene ma su un telefono non è che si finisce per avere un'applicazione che va a scatti?

boh?
stando al sito ci sono un pò di app sviluppate con monotouch, pure giochi.
bisognerebbe chiedere ai possessori dell'iCoso e chiedere a loro.
io androido, quindi ancora non ho provato (monodroid è ancora in fase di sviluppo).

PS: con smartphone che quest'anno passeranno il ghz e avranno dei dualcore...

[pabloski]

Originariamente inviato da insane74

boh?
stando al sito ci sono un pò di app sviluppate con monotouch, pure giochi.
bisognerebbe chiedere ai possessori dell'iCoso e chiedere a loro.
io androido, quindi ancora non ho provato (monodroid è ancora in fase di sviluppo).

ma sono a pagamento???

PS: con smartphone che quest'anno passeranno il ghz e avranno dei dualcore...

speriamo che non si segua la filosofia pc, altrimenti dovremo usare 8 core solo per la gui

[insane74]

Originariamente inviato da pabloski

ma sono a pagamento???

i tool di sviluppo? purtroppo si.
mono rimane FOSS solo su pc, ma i tool di sviluppo per smartphone/tablet sono a pagamento.

Originariamente inviato da pabloski

speriamo che non si segua la filosofia pc, altrimenti dovremo usare 8 core solo per la gui

se non fosse così, non riuscirebbero a vendere il "ferro"!

[Tommo]

Originariamente inviato da pabloski

lasciando da parte android, ma usare monotouch su iOS è un suicidio...che succede se apple se ne esce con una nuova trovata anti-altri-ambienti-di-sviluppo?

poi l'overhead di simili soluzioni qual'è? su un pc può andar bene ma su un telefono non è che si finisce per avere un'applicazione che va a scatti?

A parte l'overhead, il problema di soluzioni simili è IOS e Android non sono i loro linguaggi...
è possibilissimo programmare in Java o ObjC su windows, ma IOS e Android (soprattutto IOS) offrono librerie native ai loro linguaggi che sono sconfinate, per esempio Cocoa.

Il cosiddetto look&feel di IOS è tutto costruito tramite l'interface builder di XCode + Cocoa; avere ObjC ma non avere questi due significa dover fare tutto daccapo comunque, e significa anche che Apple potrebbe bocciare l'applicazione perchè sarà brutta e troppo diversa dallo standard.

L'unica eccezione la fanno i giochi (per mia fortuna ) dato che lì basta acquisire lo schermo e disegnare quello che vuoi con OpenGL.

[cdimauro]

Originariamente inviato da insane74

giusto per aumentare la confusione:
http://monotouch.net/
http://monodroid.net/

e così si scrive in C# sulle 3 diverse piattaforme.

Speriamo esca presto MonoDroid, perché effettivamente si prendono 3 piccioni con una fava (WP7 sfrutta già C# e .NET).

E poi Objective-C fa vomitare come linguaggio.

Originariamente inviato da pabloski

lasciando da parte android, ma usare monotouch su iOS è un suicidio...che succede se apple se ne esce con una nuova trovata anti-altri-ambienti-di-sviluppo?

Sarebbe la volta buona che la mandano a cacare.

Comunque dopo la figuraccia che ha fatto non credo che abbia intenzione si attirarsi nuovamente le ire degli sviluppatori.

Anche perché Android avanza come un rullo compressore, ed è meglio mantenere il vantaggio del parco applicazioni, in qualunque modo vengano sviluppate.

poi l'overhead di simili soluzioni qual'è? su un pc può andar bene ma su un telefono non è che si finisce per avere un'applicazione che va a scatti?

MonoTouch (e MonoDroid per Android) compila in codice nativo. Inoltre fa uso di un garbage collector efficiente che aiuta sia nello sviluppo del codice che nella gestione delle risorse allocate.

Comunque potresti fare una prova. Realizza una classe in Objective-C e la stessa in C#/MonoTouch, scrivi un test che richiama un bel po' di volte un metodo, e poi vedi un po' quanto c'impiega l'uno e l'altro.

Objective-C, per come funziona, a naso dovrebbe essere più lento.

Originariamente inviato da Tommo

A parte l'overhead, il problema di soluzioni simili è IOS e Android non sono i loro linguaggi...
è possibilissimo programmare in Java o ObjC su windows, ma IOS e Android (soprattutto IOS) offrono librerie native ai loro linguaggi che sono sconfinate, per esempio Cocoa.

Da MonoTouch puoi accedere a tutto Cocoa, e in più a buona parte di .NET. Hai il meglio dei due mondi.

Lo stesso vale per MonoDroid.

Il cosiddetto look&feel di IOS è tutto costruito tramite l'interface builder di XCode + Cocoa; avere ObjC ma non avere questi due significa dover fare tutto daccapo comunque,

Con MonoTouch utilizzi Interface Builder per disegnare la GUI della tua applicazione, per poi eseguire il binding del codice C#. Con MonoDevelop è come se lavorassi con XCode: né più né meno.

e significa anche che Apple potrebbe bocciare l'applicazione perchè sarà brutta e troppo diversa dallo standard.

Vedi sopra. E poi figurati: Apple le boccia per i motivi più disparati.

L'unica eccezione la fanno i giochi (per mia fortuna ) dato che lì basta acquisire lo schermo e disegnare quello che vuoi con OpenGL.

Se dovessi sviluppare soltanto giochi e avere come target tutte e tre le piattaforme (e magari anche altre), preferirei utilizzare Unity3D.

[insane74]

Originariamente inviato da cdimauro

Speriamo esca presto MonoDroid, perché effettivamente si prendono 3 piccioni con una fava (WP7 sfrutta già C# e .NET).

E poi Objective-C fa vomitare come linguaggio.

Sarebbe la volta buona che la mandano a cacare.

Comunque dopo la figuraccia che ha fatto non credo che abbia intenzione si attirarsi nuovamente le ire degli sviluppatori.

Anche perché Android avanza come un rullo compressore, ed è meglio mantenere il vantaggio del parco applicazioni, in qualunque modo vengano sviluppate.

MonoTouch (e MonoDroid per Android) compila in codice nativo. Inoltre fa uso di un garbage collector efficiente che aiuta sia nello sviluppo del codice che nella gestione delle risorse allocate.

Comunque potresti fare una prova. Realizza una classe in Objective-C e la stessa in C#/MonoTouch, scrivi un test che richiama un bel po' di volte un metodo, e poi vedi un po' quanto c'impiega l'uno e l'altro.

Objective-C, per come funziona, a naso dovrebbe essere più lento.

Da MonoTouch puoi accedere a tutto Cocoa, e in più a buona parte di .NET. Hai il meglio dei due mondi.

Lo stesso vale per MonoDroid.

Con MonoTouch utilizzi Interface Builder per disegnare la GUI della tua applicazione, per poi eseguire il binding del codice C#. Con MonoDevelop è come se lavorassi con XCode: né più né meno.

Vedi sopra. E poi figurati: Apple le boccia per i motivi più disparati.

Se dovessi sviluppare soltanto giochi e avere come target tutte e tre le piattaforme (e magari anche altre), preferirei utilizzare Unity3D.

quotone su tutta la linea.
inoltre Unity3D è basato su mono...

[Giullo]

Originariamente inviato da cdimauro

E poi Objective-C fa vomitare come linguaggio.

bhè con java è decisamente in buona compagnia allora mentre ritengo c# un gradino sopra

Originariamente inviato da cdimauro

MonoTouch (e MonoDroid per Android) compila in codice nativo. Inoltre fa uso di un garbage collector efficiente che aiuta sia nello sviluppo del codice che nella gestione delle risorse allocate.

Comunque potresti fare una prova. Realizza una classe in Objective-C e la stessa in C#/MonoTouch, scrivi un test che richiama un bel po' di volte un metodo, e poi vedi un po' quanto c'impiega l'uno e l'altro.

il fatto di compilare nativo non è garanzia di velocità: la prova che tu dici l'ho fatta con l'exporter ios per flash di adobe ... una semplice tableview con una ventina di elementi .. .la differenza era imbarazzante: lo scrolling della tabella andava ad un decimo del framerate

vero che il meccanismo di dispatching dinamico di obj-c è sicuramente più lento di una dispatch table statica (ala c++), ma è altrettanto vero che con 4 righe di codice si può eliminare per ogni chiamata (laddove serva veramente, per esperienza personale questo caso si è verificato solo una volta , durante l'import di centinaia di migliaia di righe da un csv)

[cdimauro]

Originariamente inviato da Giullo

bhè con java è decisamente in buona compagnia allora mentre ritengo c# un gradino sopra

Penso che, al solito, si tratti di una questione di gusti.

Per quanto mi riguarda, mi stanno sullo stomaco i linguaggi C-like. Fra questi penso che Objective-C sia quello riuscito peggio.

Francamente, se proprio Apple doveva cambiare linguaggio abbandonando l'ObjectPascal (sigh!) con cui iniziò coi Mac, avrei preferito che avesse sposato SmallTalk anziché "trapiantarlo" malamente nel C.

SmallTalk lo trovo di gran lunga più elegante e "coerente" con la filosofia con cui Alan Key lo ideò.

Detto ciò, visto che dovrò iniziare a sviluppare applicazioni mobile, ed iPhone ovviamente è tenuto in grande considerazione, spero di poter fare a meno di Objective-C e lavorare con C#/MonoTouch: per lo meno la pillola sarà meno dolorosa da ingoiare.

Poi, per quanto detto, C#/.NET sarebbe decisamente più conveniente visto che permetterebbe di riciclare buona parte del codice per tutte e tre le piattaforme di riferimento.

il fatto di compilare nativo non è garanzia di velocità: la prova che tu dici l'ho fatta con l'exporter ios per flash di adobe ... una semplice tableview con una ventina di elementi .. .la differenza era imbarazzante: lo scrolling della tabella andava ad un decimo del framerate

Grazie per la conferma.

vero che il meccanismo di dispatching dinamico di obj-c è sicuramente più lento di una dispatch table statica (ala c++), ma è altrettanto vero che con 4 righe di codice si può eliminare per ogni chiamata (laddove serva veramente, per esperienza personale questo caso si è verificato solo una volta , durante l'import di centinaia di migliaia di righe da un csv)

Ma il dispatching ai metodi di una classe non avviene sempre dinamicamente, anche nel caso in cui dichiari una variabile col tipo della classe anziché con id?

Per lo meno, ricordo di aver letto questo nella documentazione di Apple sul linguaggio.

[Giullo]

Originariamente inviato da cdimauro

Detto ciò, visto che dovrò iniziare a sviluppare applicazioni mobile, ed iPhone ovviamente è tenuto in grande considerazione, spero di poter fare a meno di Objective-C e lavorare con C#/MonoTouch: per lo meno la pillola sarà meno dolorosa da ingoiare.

se l'obiettivo è riutilizzare il codice condivido al 100% la tua scelta

Originariamente inviato da cdimauro

Ma il dispatching ai metodi di una classe non avviene sempre dinamicamente, anche nel caso in cui dichiari una variabile col tipo della classe anziché con id?

il tipo con cui viene dichiarata una variabile è ortogonale rispetto al metodo con cui reperisci il valore. forse fai riferimento alle properties? cmq il dispatch si può evitare ottenendo un puntatore alla funzione che implementa il metodo, e poi si può richiamare direttamente quello senza passare per il meccanismo dinamico. certo così si vanifica il motivo della sua esistenza, ma in alcuni casi particolari il boost prestazionale può essere rilevante (tipicamente quando ci sono migliaia o decine di migliaia di chiamate a metodi, magari nel ciclo di un loop)

[e-commerce84]

Io ho sviluppato un progetto in Android per l'uni tempo fà.

Nell'azienda in cui sono attualmente stagista programmano sia su Android che su IOS e sostengono che anche se ora come ora IOS ha un po' più di mercato per quanto riguarda applicazioni per grandi enti a breve dovrebbe sbloccarsi anche il mercato Android visto che come crescita stà crescendo di più rispetto ad Apple

Per quanto riguarda i pro di Android secondo me sono:

1) Non sei vincolato ad usare un computer Apple o ad installarti una copia piratata di McOs du un PC in modo a dir poco bislacco (ed illegale)

2) Di fatto con Android programmi in Java che è un linguaggio molto conosciuto ed usato...quindi facilità di trovare qualcuno che ti sappia aiutare.

3) Ci sono ari forum italiani dove puoi trovare aiuto durante lo sviluppo: anddev in particoalre ma anche androidiani ed altri...

4) Si trova decisamente più documentazione e tutorial per Android

Poi certo anche IOS ha i suoi vantaggi

Ti posso segnalare questo link relativo al corso universitario che seguii:
http://www.informatica.uniroma2.it/f0?fid=f0&id=LIS

Eventualmente scaricati lo le varie dispense relative allo sviluppo in Android, sono fatte molto bene e come punto di partenza eventualmente sono più che valide !!!

Ciao

[cdimauro]

Originariamente inviato da Giullo

se l'obiettivo è riutilizzare il codice condivido al 100% la tua scelta

Sì, è quello principale.

Personalmente avrei scelto MonoTouch pur di non lavorare in Objective-C , ma c'è da dire che altri colleghi che sviluppano su iPhone/iPad sono attratti da questo strumento perché ritengono che C# sia più comodo e produttivo, potendo contare anche sul framework .NET.

il tipo con cui viene dichiarata una variabile è ortogonale rispetto al metodo con cui reperisci il valore. forse fai riferimento alle properties?

No, mi riferivo al fatto che, dichiarando il tipo corretto di una variabile, il compilatore genera codice più ottimizzato e fa dei controlli già a runtime. Ma non è il caso del dispatching dei metodi, che rimane sempre dinamico.

cmq il dispatch si può evitare ottenendo un puntatore alla funzione che implementa il metodo, e poi si può richiamare direttamente quello senza passare per il meccanismo dinamico. certo così si vanifica il motivo della sua esistenza, ma in alcuni casi particolari il boost prestazionale può essere rilevante (tipicamente quando ci sono migliaia o decine di migliaia di chiamate a metodi, magari nel ciclo di un loop)

Ah ok, non ricordavo di questa possibilità, e hai ragione. Grazie!

[Tommo]

Originariamente inviato da e-commerce84

4) Si trova decisamente più documentazione e tutorial per Android

Android è uno scempio, in "coder friendliness", partendo dalla documentazione finendo sul rispetto degli standard.
Mai mi sarei aspettato di trovare "più documentazione" e "Android" così vicini in una frase