Link alla notizia: http://www.hwupgrade.it/news/programmi/app-mobile-i-prossimi-anni-tra-passaparola-e-html5_50491.html

Sempre di più le app mobile, ma sempre meno saranno quelle realmente remunerative. Inoltre nei prossimi anni i browser mobile saranno sempre più utilizzati come piattaforme di distribuzione digitale

Click sul link per visualizzare la notizia.

Al momento le app HTML5 sono le peggiori e scegliere l'accoppiata HTML5+JS per realizzare una propria app è tirarsi la zappa sui piedi dato che lo sviluppo è più lento e ricco di problematiche.

Invece credo diventerà molto più importante il C#, attualmente utilizzabile su iOS, Android e ovviamente Windows e che permette la realizzazione di applicazioni native multipiattaforma scrivendo gran parte del codice una volta sola.

Senza considerare lo spostamento delle app verso sistemi più potenti come i PC e allo stesso tempo l'aumento delle capacità dei dispositivi ultramobile.

Il tempo dei browser è finito, era l'epoca fino a 2 anni fa circa quando realtà come Zynga facevano soldi a palate con browser game. Ora invece sono quasi fallite e tutti preferiscono l'app, sia per le prestazioni sia per la comodità di fruizione. E non credo che trasferire le app in un browser nascosto possa migliorare la situazione.

Riguardo al fatturato generato dalle app, è ovvio sia un mercato destinato alla saturazione e alla sopravvivenza di pochi big. Il mondo dei telefoni è oggi simile al mondo dei PC all'epoca della silicon valley di Jobs e Gates, anche un ragazzetto in un garage può diventare milionario anche un dev singolo può guadagnare dei soldi facendo app. Ma in futuro sarà come i programmi per PC, sono talmente tanti e complessi che solo quelli delle grosse SW riescono ad andare avanti

nella mia società usiamo un approccio ibrido con parti native (objective c, java...) e HTML+JS per la presentazione dei dati
riusciamo a riciclare gran parte del codice tra le varie versioni e manteniamo alcuni dei vantaggi (specialmente le prestazioni) derivate dall'utilizzo di funzionalità native
ci sono progetti interessanti come xamarin per essere multipiattaforma con il minimo sforzo ma preferiamo il nostro approccio con tanto HTML, perché realizzare una WebApp che emuli le nostre app native diventa quasi immediato

per quanto riguarda il fatturato noto che già ora il mercato si sta saturando ed è difficile entrarci con una nuova idea
rendono di più le app B2B o quelle enterprise per le quali sei pagato dal cliente per una soluzione custom, ovviamente non è un mondo alla portata del piccolo sviluppatore

Al momento le app HTML5 sono le peggiori e scegliere l'accoppiata HTML5+JS per realizzare una propria app è tirarsi la zappa sui piedi dato che lo sviluppo è più lento e ricco di problematiche.

Invece credo diventerà molto più importante il C#, attualmente utilizzabile su iOS, Android e ovviamente Windows e che permette la realizzazione di applicazioni native multipiattaforma scrivendo gran parte del codice una volta sola.

Senza considerare lo spostamento delle app verso sistemi più potenti come i PC e allo stesso tempo l'aumento delle capacità dei dispositivi ultramobile.

Il tempo dei browser è finito, era l'epoca fino a 2 anni fa circa quando realtà come Zynga facevano soldi a palate con browser game. Ora invece sono quasi fallite e tutti preferiscono l'app, sia per le prestazioni sia per la comodità di fruizione. E non credo che trasferire le app in un browser nascosto possa migliorare la situazione.

Riguardo al fatturato generato dalle app, è ovvio sia un mercato destinato alla saturazione e alla sopravvivenza di pochi big. Il mondo dei telefoni è oggi simile al mondo dei PC all'epoca della silicon valley di Jobs e Gates, anche un ragazzetto in un garage può diventare milionario anche un dev singolo può guadagnare dei soldi facendo app. Ma in futuro sarà come i programmi per PC, sono talmente tanti e complessi che solo quelli delle grosse SW riescono ad andare avanti

scusa ma in teoria le app per iOs non sono in objective-c, quelle per android in java e quelle per win mobile in c#?

scusa ma in teoria le app per iOs non sono in objective-c, quelle per android in java e quelle per win mobile in c#?

http://xamarin.com/

in ogni caso per lavorare con iOS ti serve un Mac perché il pacchetto da rilasciare o da testare sui dispositivi lo generi solo in OS X, però puoi fare gran parte del lavoro in C# e riciclare le varie classi

La società di analisi di mercato Gartner sostiene che entro il 2018 meno dello 0,01% di tutte le app mobile consumer saranno considerate un successo economico dai loro sviluppatori, questo perché il pubblico sta sempre più affidandosi ad un meccanismo di "passaparola" (tramite i pareri degli amici, con i motori di raccomandazione, sui social networking) per scoprire le applicazioni mobile invece che tramite la tradizionale consultazione del catalogo delle app disponibili sui vari marketplace digitali.

non ho proprio capito come questi due eventi siano il primo la conseguenza del secondo.
cioè: solo lo 0.01% delle app sarà considerato un successo economico da chi le ha fatte perché la gente si affiderà di più al passaparola ???

scusa ma in teoria le app per iOs non sono in objective-c, quelle per android in java e quelle per win mobile in c#?

Come dice recoil :)

Fondamentalmente puoi far tutto con Visual Studio + Xamarin + C# e fare del codice che gira su tutto :) Su iOS C# è anche supportato "ufficialmente", indipendentemente da Xamarin e Visual Studio, che sono comunque la soluzione migliore. Poi una volta che hai la tua PCL con il cuore dell'app lasci alle parti platform dependent la gestione dello storage, della gestione API e dell'interazione con l'UI e l'IO. Anche se fondamentalmente sono più lavoro di dependency injection che gestione vera e propria. Ovviamente solo se fai un buon lavoro nella PCL :D Solo l'ultimo tassello della UI ti tocca gestirlo diversamente e non puoi riciclare nulla, ma è forse una buona cosa, così si evita di usare la stessa UI su piattaforme che necessitano di UI differenti. Troppo spesso vedo app fatte per iOS girare su Android e WP o fatte per Android e girare su WP e iOS. Sono slegate dal sistema di destinazione e sono proprio un bruto vedere oltre che spesso inadatte (ad es WP ha il tasto back, iOS ha il pusante back lato UI che si trova in alto)


non ho proprio capito come questi due eventi siano il primo la conseguenza del secondo.
cioè: solo lo 0.01% delle app sarà considerato un successo economico da chi le ha fatte perché la gente si affiderà di più al passaparola ???

Si, ho notato anche io, è un passaggio che non ha senso, forse perché la gente si affiderà di più al passaparola :asd:

visto che sto studiando objective-c vi faccio questa domanda: c'è molta differenza tra c# e objective-c?

visto che sto studiando objective-c vi faccio questa domanda: c'è molta differenza tra c# e objective-c?

per esperienza quando lavori in questo ambito il problema non è tanto la differenza di linguaggio ma la piattaforma su cui lavori
C# non è difficile da imparare, non lo uso da anni ma a suo tempo l'ho trovato abbastanza intuitivo

visto che sto studiando objective-c vi faccio questa domanda: c'è molta differenza tra c# e objective-c?

Moltissima

Giusto qualche confronto sulla sintassi:

http://www.texnomic.com/blog/?p=692

Fondamentalmente, per fare le stesse cose, con O-C ci metti almeno il doppio del tempo che con C#, a questo tempo in più devi aggiungerci lo svantaggio nel non poter usare Visual Studio, il miglior IDE in circolazione. E credimi, quando il lavoro diventa tanto e i progetti complessi, Visual Studio ti aiuta più di un collega che programmi al posto tuo :D

Con VS + C# posso tirarti su un'app in pochissimo tempo, con O-C considera di doverci mettere dalle 2 alle 3 volte tanto.

Questo perché O-C non è affatto un linguaggio moderno e quindi manca di molti strumenti che ti permettono di lavorare con un più alto livello di astrazione rispetto a C#.

LINQ su tutti, strumento che permette di effettuare query su collezioni di oggetti, come fosse un database. Non solo, accoppiato alla ObservableCollection (un tipo di lista ""avanzato"") ti permette di fare cose pazzesche.

Ad esempio, hai una lista di libri caricata da un database (di tipo LINQ to SQL), vuoi derivare da quella lista una lista di libri che siano della categoria gialli, per visualizzarli all'utente.

ObservableCollection<Libro> TuttiILibri() = DataBase.LoadLibri();
ObservableCollection LibriGialli<Libro> = new ObservableCollection(from libro in TuttiILibri where libro.Categoria == "giallo" select libro);

Fatto in 2 righe! :O Ora in LibriGialli ho solo i libri della categoria "gialli". Ma qui viene la parte bella, ipotizziamo che LibriGialli sia collegato (data binding) ad un controllo UI che li visualizza a schermo, e che all'utente sia fornito un comando per cancellare o modificare un qualsiasi parametro dell'oggetto libro (che sia titolo autore categoria o altro non importa).

Quando l'utente preme il comando, il libro che si trova in LibriGialli viene modificato. Questo fa si che AUTOMATICAMENTE, senza che tu debba programmare una sola riga di codice, la modifica va a cascata su LibriGialli, poi su TuttiILibri (dato che LibriGialli deriva da TuttiILibri) fino ad arrivare a modificare il database! Allo stesso tempo una modifica fatta al database si riflette in senso inverso a tutti i livelli superiori, visualizzando all'utente la modifica, sempre senza scrivere una sola riga.

In circa 5-10 righe di codice tu puoi scrivere l'esempio che ti ho descritto qui sopra, compreso il comando di modifica e la visualizzazione dei dati all'utente (considerando di avere il DB già scritto), con O-C non basterebbe lo spazio in questo post.

Per lo sviluppo di app o di software non di basso livello, C# è (quasi) sempre la scelta migliore.

Questo non vuol dire, ovviamente, che O-C non serva a nulla. Infatti ti permette di gestire la memoria o di effettuare operazioni a basso livello che C# non ti permette di fare. Dipende tutto da quello che devi fare tu ;)

Moltissima

Giusto qualche confronto sulla sintassi:

http://www.texnomic.com/blog/?p=692

Fondamentalmente, per fare le stesse cose, con O-C ci metti almeno il doppio del tempo che con C#, a questo tempo in più devi aggiungerci lo svantaggio nel non poter usare Visual Studio, il miglior IDE in circolazione. E credimi, quando il lavoro diventa tanto e i progetti complessi, Visual Studio ti aiuta più di un collega che programmi al posto tuo :D

Con VS + C# posso tirarti su un'app in pochissimo tempo, con O-C considera di doverci mettere dalle 2 alle 3 volte tanto.

Questo perché O-C non è affatto un linguaggio moderno e quindi manca di molti strumenti che ti permettono di lavorare con un più alto livello di astrazione rispetto a C#.

LINQ su tutti, strumento che permette di effettuare query su collezioni di oggetti, come fosse un database. Non solo, accoppiato alla ObservableCollection (un tipo di lista ""avanzato"") ti permette di fare cose pazzesche.

Ad esempio, hai una lista di libri caricata da un database (di tipo LINQ to SQL), vuoi derivare da quella lista una lista di libri che siano della categoria gialli, per visualizzarli all'utente.

ObservableCollection<Libro> TuttiILibri() = DataBase.LoadLibri();
ObservableCollection LibriGialli<Libro> = new ObservableCollection(from libro in TuttiILibri where libro.Categoria == "giallo" select libro);

Fatto in 2 righe! :O Ora in LibriGialli ho solo i libri della categoria "gialli". Ma qui viene la parte bella, ipotizziamo che LibriGialli sia collegato (data binding) ad un controllo UI che li visualizza a schermo, e che all'utente sia fornito un comando per cancellare o modificare un qualsiasi parametro dell'oggetto libro (che sia titolo autore categoria o altro non importa).

Quando l'utente preme il comando, il libro che si trova in LibriGialli viene modificato. Questo fa si che AUTOMATICAMENTE, senza che tu debba programmare una sola riga di codice, la modifica va a cascata su LibriGialli, poi su TuttiILibri (dato che LibriGialli deriva da TuttiILibri) fino ad arrivare a modificare il database! Allo stesso tempo una modifica fatta al database si riflette in senso inverso a tutti i livelli superiori, visualizzando all'utente la modifica, sempre senza scrivere una sola riga.

In circa 5-10 righe di codice tu puoi scrivere l'esempio che ti ho descritto qui sopra, compreso il comando di modifica e la visualizzazione dei dati all'utente (considerando di avere il DB già scritto), con O-C non basterebbe lo spazio in questo post.

Per lo sviluppo di app o di software non di basso livello, C# è (quasi) sempre la scelta migliore.

Questo non vuol dire, ovviamente, che O-C non serva a nulla. Infatti ti permette di gestire la memoria o di effettuare operazioni a basso livello che C# non ti permette di fare. Dipende tutto da quello che devi fare tu ;)

ma con xamarin che converte da c# a objective - c e java, per i limiti che elencavi te qui sopra di c#, non si possono fare app troppo avanzate che richiedono troppe risorse, oppure si?

ma con xamarin che converte da c# a objective - c e java, per i limiti che elencavi te qui sopra di c#, non si possono fare app troppo avanzate che richiedono troppe risorse, oppure si?

Attenzione, non converte in O-C o Java, crea direttamente le librerie compilate in maniera che siano utilizzabili su iOS e Android ;) O anche l'app intera comprensiva di UI, accesso alle API ecc...

Riguardo alle risorse, con C# puoi scrivere anche un sistema operativo o una mega applicazione server che gira su cluster da 10000 macchine, non hai limiti insomma :D

Quello che non puoi fare è accedere direttamente agli spazi di memoria, agli indirizzi, gestire il garbage collector ecc... o meglio, si possono fare ma non sempre e con maggiori limiti. Ma questo perché fondamentalmente C# è un linguaggio che come Java gira in VM e non direttamente sul sistema ospite, come fa O-C. Se tu usassi Assembly avresti accesso ad un livello ancora più basso di O-C, ma non per questo in Assembly riusciresti a realizzare applicazioni più grosse e che richiedono più risorse... potresti ottimizzare meglio il codice (in maniera quasi maniacale), ma il 99,99999999% dei casi è una cosa inutile, visto che sono problemi che si pongono esclusivamente su applicazioni molto particolari e certamente non nelle app dei cellulari

ma con xamarin che converte da c# a objective - c e java, per i limiti che elencavi te qui sopra di c#, non si possono fare app troppo avanzate che richiedono troppe risorse, oppure si?

xamarin non fa questo come è stato spiegato bene da bimarco, ci sono tool che convertono objective c in java ecc. ma mi convincono poco
se serve codice portabile ovunque meglio fare una libreria che vada sui vari sistemi in modo che una singola modifica e rigenerazione della libreria sistema lo stesso bug su n sistemi

xamarin non fa questo come è stato spiegato bene da bimarco, ci sono tool che convertono objective c in java ecc. ma mi convincono poco
se serve codice portabile ovunque meglio fare una libreria che vada sui vari sistemi in modo che una singola modifica e rigenerazione della libreria sistema lo stesso bug su n sistemi

Quoto! :) E' appunto la "grandiosità" di Xamarin :D