di  -  mercoledì 21 settembre 2011

L’avventura con Android inizia, seguendo pedissequamente le istruzioni presenti nel sito dedicato al progetto, con Java in primis (spesso già presente) e poi l’IDE che bisogna caricare e installare, o decomprimere da qualche parte, come nel caso di Eclipse, che non richiede quest’operazione a cui siamo normalmente abituati.

L’SDK si scarica molto velocemente, ma ciò che fa perdere parecchio tempo (anche una mattinata) è la fase di scaricamento e installazione delle varie versioni delle piattaforme (API Level) e componenti vari. Sarebbe stato meglio avere un pacchetto completo con tutti i componenti (magari una ISO), dando poi la possibilità di scegliere ciò che si vuole, anche in prospettiva di un’eventuale reinstallazione.

Installato tutto, incluso l’apposito plugin per l’IDE, purtroppo il primo impatto è stato negativo: non veniva visualizza l’apposita voce per creare un progetto Android, pur risultando tutto correttamente configurato.

Fortunatamente esisteva un plugin per NetBeans, il mio IDE preferito, per cui ho potuto proseguire senza difficoltà, anche se questa piattaforma non è quella ufficialmente supportata dalla casa madre.

Il plugin per NetBeans non è comodo e completo come quello di Eclipse, mancando soprattutto una finestra/pannello di anteprima dell’interfaccia grafica a cui si sta lavorando, ma la bontà di quest’ambiente di sviluppo mi ha permesso di andare avanti ugualmente.

Successivamente ho voluto provare l’ultima versione di Eclipse con la quale, inspiegabilmente, risultava tutto finalmente operativo (misteri dell’informatica):

Quindi ho potuto sperimentare con la finestra di anteprima, che per i layout più semplici consente di sistemare gli elementi grafici senza dover ricorrere all’emulatore oppure a un dispositivo per poter prendere visione della resa finale.

Purtroppo per layout più complicati si rivela del tutto inutile, presentando uno sconfortante pannello vuoto. Mi riferisco, in particolare, a situazioni come la progettazione degli elementi visualizzati da una ListView. L’introduzione di placeholder (“segnaposto”) sarebbe già un grosso passo avanti, poiché consentirebbe di dare almeno una forma agli “item”.

Anche la disposizione del pannello di impostazione delle proprietà di un widget sarebbe da ripensare, in quanto adesso risulta più veloce modificare a mano l’XML piuttosto che spostarsi col mouse a caccia dell’apposita voce. Debbo dire che da programmatore preferirei non staccare le mani dalla tastiera, per cui se l’editing dell’XML che definisce l’interfaccia fosse più avanzato si otterrebbe senz’altro un risultato più appagante.

La più grossa pecca della piattaforma di sviluppo è, però, rappresentata dall’emulatore, che è un autentico pachiderma: anche su macchine “pompate” (una con Intel Core i-5 2,67Ghz, 8GB DDR3, e Radeon 4550 dovrebbe esserlo) impiega diversi minuti prima di divenire operativo, presentando peraltro una reattività appena sufficiente allo scopo (sempre su PC ben carrozzati, s’intende).

Una volta avviato è bene non chiuderlo mai, proprio per evitare questi lunghissimi tempi morti che trasformerebbero lo sviluppo in un supplizio tecnologico. Il tool è, infatti, in grado di accettare nuove istanze delle nostre applicazioni in tempi molto più rapidi.

In ogni caso è caldamente consigliato l’uso di un dispositivo reale anche economico, da collegare tramite porta USB, per lavorare molto più velocemente. In mancanza di un PC dotato è praticamente indispensabile, ma è sempre bene testare l’applicazione con un telefonino, perché si potrebbero scoprire bug che con l’emulatore magari non si manifestavano (ciò vale per qualunque piattaforma mobile).

Dopo aver installato l’SDK, normalmente dovrebbe essere sufficiente collegare il telefonino per renderlo visibile al PC e, soprattutto, all’SDK per utilizzarlo al posto dell’emulatore. Sfortunatamente ciò non è sempre vero, a causa di un bug nel driver in dotazione all’SDK, e ovviamente non poteva che presentarmisi. La soluzione in questo caso è di patchare il file android_winusb.inf (che si trova in extras\google\usb_driver), e forzarne manualmente l’uso quando il s.o. richiede di ricercare o selezionare il driver da qualche fonte.

Sempre rimanendo sul tema emulatore, a volte s’impalla e non è possibile lanciare l’applicazione perché viene generato il seguente errore:

emulator: ERROR: the user data image is used by another emulator. aborting

La soluzione in questi casi è cancellare alcuni file di lock (che si trovano in una cartella utente), cancellare la virtual machine e ricrearne un’altra, uccidere il processo adb.exe (il server che gestisce la comunicazione con emulatore o dispositivo), o ancora chiudere e far ripartire l’IDE. Sono tutti consigli che si possono recuperare in giro, quando si è alla disperata ricerca di una soluzione a questo problema. Qualcosa prima o poi dovrebbe funzionare, anche nel caso in cui, inspiegabilmente, alcune volte il debugger perde la connessione con l’emulatore o il telefonino…

Per concludere, aggiungo che di recente ho effettuato un aggiornamento all’SDK, avendo rilevato la presenza di alcuni pacchetti aggiornati (erano presenti quelli della nuova API Level 13, ad esempio), e il risultato è stato il seguente:

Altre volte a caccia di bug si è presentato il seguente messaggio fra i log:

E/dalvikvm( 2480): Unable to open stack trace file ‘/data/anr/traces.txt': Permission denied

A parte il fatto che percorsi del genere mal si sposano con il s.o. utilizzato (e con le sue politiche di gestione dei dati privati e/o pubblici), trovo davvero deplorevole che a fine 2011 continuino a esserci problemi di permessi facendo uso di account limitati (che dovrebbero essere la norma da tempo, ormai), costringendo a ricorrere all’esecuzione come amministratore del gestore dell’SDK per portare a compimento l’operazione.

A completamento è apparso qualche altro problema e un piccolo difetto dovuto a una codifica dei caratteri non corretta (sic.):

Nonostante tutto, l’aggiornamento non è andato a buon fine:

Col risultato di essere stato costretto a cercare l’eseguibile dell’emulatore (si trova nella cartella tools dell’SDK), e lanciarlo da linea di comando specificando il nome del Virtual Device pur di vederlo finalmente all’opera…

Sono tante piccole cose, che però messe assieme danno fastidio e, cosa più grave, fanno perdere tempo a chi ne ha veramente poco a disposizione. Per un programmatore è importante affidarsi a strumenti comodi e solidi, che rendano veloce e produttivo lo sviluppo senza tanti mal di testa.

Non v’è dubbio che l’obiettivo finale sia mettere in mano all’utente finale un prodotto che soddisfi le sue esigenze, ma è altrettanto vero che chi deve realizzare quei prodotti dovrebbe essere in grado di farlo nel “migliore” dei modi. Pertanto mi auguro, da persona che deve lavorarci, che Google investa di più su questo fronte, su cui, a mio avviso, c’è ancora parecchio da fare.

50 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Unrealizer
     scrive: 

    Insomma, è una tragedia lavorare con Android a quanto pare :D

  • # 2
    Antonio Barba (TheKaneB)
     scrive: 

    Tutto molto scomodo e farragginoso, ma ho lavorato con devkit peggiori (ad esempio devkit Symbian pre-Qt, tutti i devkit Nintendo, tutti i devkit per console Sony), quindi ormai non ci faccio più caso :-D

    Ti sei lasciato viziare un po’ troppo con i tools di Microsoft!

  • # 3
    Griso
     scrive: 

    Concordo con Antonio Barba, una volta lavorato con i devkit Nintendo e Sony tutto il resto è oro colato.
    Ottimo l’XNA di Microsoft, attacchi l’Xbox e stai apposto.

  • # 4
    zephyr83
     scrive: 

    Ste cose sn sempre molto sconfortanti e mi sembrano anche evitabili! a volte ci si perde in un bicchier d’acqua! io per curiosità in passato ho provato app inventor, molto divertente per giocherellare :) li avevano (metto al passato visto che il progetto è stato “chiuso” ufficialmente) fatto un lavoro migliore a quanto pare, si è installato tutto subito senza problemi con tanto di emulatore che sul mio pc (pentium e2160 overcloccato a 3 ghz, 6 gb di RAM, nvidia 9500gt) non girava male e nn ho avuto neanche problemi a far riconoscere il mio magic, sia su windows che su kubuntu!
    Per curiosità l’altro giorno ho installato Necessitas e anche li ha fatto tutto da solo, ho solo dovuto installare alcuni pacchetti necessari (relativi a java più che altro).
    Invece cn l’sdk ufficiale nn ci ho capito molto neanche io e ho sempre lasciato stare…..troppo sbattimento per accontentare solo una mia personale curiosità :)

  • # 5
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Antonio & Griso: penso che sia proprio quello il problema. Sono troppo ben abituato. :P

  • # 6
    imayoda
     scrive: 

    eeeeek! windows? :D

  • # 7
    Griso
     scrive: 

    @Cesare

    Sarebbe interessante anche un articolo come il tuo riguardo lo startup di un programmatore con l’ambiente iOS per vedere come se la cava Apple nel supporto agli sviluppatori.

  • # 8
    Cesare Di Mauro (Autore del post)
     scrive: 

    Prima devo iniziare a svilupparci e annotarmi un po’ di roba, come ho fatto con WP7 e Android. :P

  • # 9
    MauSeventyOne
     scrive: 

    eh si siamo troppo viziati, ma daltronde l’IDE di Visual Studio non ha eguali per me.

    L’unica cosa che trovo parecchio odiosa, sviluppando con Android, è la quasi impossibilità di debuggare il codice nativo (usando l’NDK e gcc/CygWin).

    :(

  • # 10
    Cesare Di Mauro (Autore del post)
     scrive: 

    L’unica è cercare di realizzare delle test suite per il codice che si può testare agevolmente, incrociando le dita per tutto il resto.

  • # 11
    Antonio Barba (TheKaneB)
     scrive: 

    non serve arrivare al codice nativo per iniziare le bestemmie… provate a sviluppare banalmente un Service, ad esempio un wallpaper di quelli animati, oppure un servizio che accetta dei broadcast Intent in background per offrire delle notifiche (una cosa proprio banale, tanto per fare una prova). Stiamo parlando sempre di codice Java / Dalvik, ok?

    Ecco, provate a debuggarlo :D

  • # 12
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non ci sono ancora arrivato (non mi sono serviti). E a questo punto spero di non arrivarci. :D

  • # 13
    Antonio Barba (TheKaneB)
     scrive: 

    buahhahaha!! Ti eri illuso di aver già trovato chissà che difetti eh? Ho visto cose, che voi umani…

    Poi magari dai anche un’occhiata ai Renderscript di Honeycomb, e alla loro non debuggabilità (per restare in tema).

  • # 14
    Cesare Di Mauro (Autore del post)
     scrive: 

    No, non mi ero illuso. In nemmeno un mese ho trovato una carrettata di roba che non va / piace, per cui immagino che la situazione non sarà certo migliore man mano che dovrò utilizzare altre cose nuove. -_-

    Difficilmente metterò le mani su Honeycomb, perché è ancora poco diffuso. Ma intanto mi segno i Renderscript. :P

  • # 15
    Antonio Barba (TheKaneB)
     scrive: 

    Figurati, anch’io ci lavoro da pochi mesi. Praticamente da Maggio di quest’anno e mi sono fatto un’idea identica alla tua.

    Andando un pelino OT (poco poco, lo prometto), non ho ancora sviluppato su Windows Phone 7, che sospetto sia quello con l’SDK migliore, però ho lavorato con l’SDK di iPhoneOS (poi diventato iOS) e anche li ci sono tanti difetti.

    Ma, ironia della sorte, se dovessi assegnare un premio al migliore ed al peggiore SDK per smartphone da me usato (escludendo quindi le piattaforme che non conosco), darei entrambi i premi a Nokia, uno per il vecchio orrendo kit Symbian e uno per il nuovo ottimo kit Qt (che sostituisce quasi tutto quello che si può fare con il vecchio kit).

    Peccato che il progetto stia morendo, perchè hanno raggiunto un’ottimo livello di produttività grazie a Qt, ma è ormai troppo tardi.

  • # 16
    zephyr83
     scrive: 

    @Antonio Barba

    Ti è capitato di provare Necessitas? in pratica usi qtcreator ma sviluppi per android. Si installa tutto in maniera semplice! Però nn ha capito se rimangono sempre i soliti problemi di debug dell’NDK di android

  • # 17
    Cesare Di Mauro (Autore del post)
     scrive: 

    Per fortuna sono rimasto fuori dallo sviluppo per Symbian. :P

    Comunque Antonio, prima o poi dagliela un’occhiata a Windows Phone 7. 8-)

  • # 18
    Antonio Barba
     scrive: 

    @zephyr83: non l’ho mai provato, me lo segno :-)
    @Cesare: certamente :-) Le piattaforme Microsoft sono quelle che conosco meno, ho tanto da imparare :-)

  • # 19
    demetrius
     scrive: 

    è da un anno e mezzo che programmo con Android, e tutti questi problemi non li ho mai avuti… mi sembri l’uomo più sfigato sulla faccia delle terra ;)

    Ho provato diverse versioni di eclipse, tutto fermentante funzionante, sin dalle prime versioni del sdk.
    Mai avuti problemi di connessione dei telefoni (provato con diversi modelli).
    L’unica cosa che ho riscontrato, è il debugger che ogni tanto perdeva la connessione, ma il problema non mi si presenta più da diverso tempo (quindi presumo sia stato risolto con gli aggiornamenti)

    L’emulatore non è una scheggia, ma è abbastanza normale: non è una versione ridotta come in altri sdk, ma viene emulato un dispositivo reale in tutto e per tutto, con tutto quello che ne consegue sulla pesantezza, ma col vantaggio che una volta testato il programma sull’emulatore sei sicuro che funzioni allo stesso modo anche su un telefono reale che abbia la stessa configurazione e versione software.
    Comunque è veramente esagerato (per non dire falso) dire che “impiega diversi minuti prima di divenire operativo” (a meno che non ti riferisca all’emulazione di un tablet da 10″ con Andorid 3)… ed io lavoro ancora con un athlon x2.

    Poi, alcune cose che dici non possibili quando si lavora col layout grafico in realtà sono possibili ( ci sono i placehold personalizzabili nelle listview, così come sono state inserire alcune scorciatoie per cambiare velocemente le proprietà più usate)… forse stai lavorando su versioni vecchie di sdk e plugin eclipse (e sarebbe il caso di aggiornarle prima di scrivere un articolo del genere)

  • # 20
    zephyr83
     scrive: 

    @Antonio Barba

    Se vuoi dare una rapidissima occhiata guarda qui
    http://labs.qt.nokia.com/2011/02/28/necessitas/
    ad installarla su kubuntu ho fatto prestissimo! comprende anche già l’emulatore! nn è un fulmine ma nn ci mette neanche tantissimo ad avviarsi. non ho provato con il mio magic ancora (ma credo eviterò).
    Sicuramente se Nokia avesse scelto Android al posto di WP poteva occuparsi lei di una cosa del genere! non avrebbe perso i propri strumenti di sviluppo! Ma va bhe, ormai è andata così, si vede che il miliardino di microsoft ha fatto troppo gola :D

  • # 21
    Dany
     scrive: 

    @demetrius: ma come, programmi per Android da un anno e mezzo e te ne vieni fuori che “se testi con l’emulatore sei sicuro che funziona sui device”. Ma stai scherzando? Forse per applicazioni basilari, se utilizzi opengl es o qualsiasi altra cosa leggermente avanzata escono fuori bug addirittura device specific, come sull’overlay delle mappe in qualche motorola e acer. Trovi decine di bug del genere spulciando la bug list su google code.

  • # 22
    Cesare Di Mauro (Autore del post)
     scrive: 

    @demetrius: rispondo per punti.

    è da un anno e mezzo che programmo con Android, e tutti questi problemi non li ho mai avuti… mi sembri l’uomo più sfigato sulla faccia delle terra ;)

    Ho provato diverse versioni di eclipse, tutto fermentante funzionante, sin dalle prime versioni del sdk.

    Che sia sfortunato è cosa nota. Per fortuna (una volta tanto) ho testimoni e, soprattutto, ho conservato alcuni log e screenshot, che ho poi mostrato.

    Mai avuti problemi di connessione dei telefoni (provato con diversi modelli).

    Se cerchi in giro, vedrai che altri hanno avuto problemi, e la soluzione è quella che ho riportato io.

    Personalmente m’è successo con un HTC (uno dei primi con la 320×480): non è stato visto da Windows 7 Business x64. Dopo l’hack a quel file tutto a posto, invece.

    L’unica cosa che ho riscontrato, è il debugger che ogni tanto perdeva la connessione, ma il problema non mi si presenta più da diverso tempo (quindi presumo sia stato risolto con gli aggiornamenti)

    A me è capitato fino a due mesi fa, con la penultima versione dell’SDK.

    L’emulatore non è una scheggia, ma è abbastanza normale: non è una versione ridotta come in altri sdk, ma viene emulato un dispositivo reale in tutto e per tutto, con tutto quello che ne consegue sulla pesantezza, ma col vantaggio che una volta testato il programma sull’emulatore sei sicuro che funzioni allo stesso modo anche su un telefono reale che abbia la stessa configurazione e versione software.

    Purtroppo c’è una forte customizzazione dei dispositivi, per cui ciò che dici non è vero. Alcune cose le scopri sul dispositivo reale. Vedi anche il messaggio precedente.

    Comunque anche l’emulatore di iOS simula l’intero dispositivo, e non soffre degli stessi problemi prestazionali (pur emulando anche hardware di un certo spessore).

    A parte questo, emulare tutto si potrebbe anche evitare, per lo meno per le applicazioni (la maggioranza) che fanno uso di dalvik. Purtroppo c’è l’NDK di mezzo che rompe le uova nel paniere…

    La verità è che con QEmu si sono ritrovati praticamente tutto già pronto, per cui hanno investito il minimo indispensabile per quello che gli serviva, non pensando a migliorare la situazione…

    Comunque è veramente esagerato (per non dire falso) dire che “impiega diversi minuti prima di divenire operativo” (a meno che non ti riferisca all’emulazione di un tablet da 10? con Andorid 3)… ed io lavoro ancora con un athlon x2.

    E’ vero che dipende dal tipo di dispositivo emulato. Riporto alcuni test fatti sulla macchina di cui sopra:

    API Level 7 -> 45 secondi
    API Level 12 -> 3:07

    Secondo più, secondo meno. Che non sono pochi per l’hardware su cui girano, se permetti.

    Poi, alcune cose che dici non possibili quando si lavora col layout grafico in realtà sono possibili ( ci sono i placehold personalizzabili nelle listview, così come sono state inserire alcune scorciatoie per cambiare velocemente le proprietà più usate)…

    Non mi pare di aver visto placeholder anche sull’ultima versione dell’SDK e del plugin.

    Giusto per evitare incomprensioni, intendo roba come questa:
    http://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.fallbackvalue(v=vs.95).aspx
    http://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.targetnullvalue(v=vs.95).aspx

    O, per situazioni più complesse, qualcosa come questo:

    http://blogs.msdn.com/b/wpfsldesigner/archive/2010/06/30/sample-data-in-the-wpf-and-silverlight-designer.aspx

    Il tutto ovviamente rimanendo a design-time (senza mai lanciare l’applicazione).

    forse stai lavorando su versioni vecchie di sdk e plugin eclipse (e sarebbe il caso di aggiornarle prima di scrivere un articolo del genere)

    Ho lavorato fino a 2 mesi fa col penultimo SDK, e ho eseguito l’aggiornamento all’ultimo giusto una ventina di giorni fa, come puoi vedere dalla parte finale dell’articolo.

    @zephyr83: Non è certo con un miliardo di euro che Nokia si sarebbe potuta risollevare…

  • # 23
    zephyr83
     scrive: 

    @Cesare Di Mauro

    Ah no di certo no ma sicuramente ha contribuito tantissimo! Così come i vari tagli in ricerca e sviluppo e di personale che questa scelta ha comportato!
    Anziché affidarsi sulle proprie forze hanno preferito affidarsi a qualcun altro!

  • # 24
    Cesare Di Mauro (Autore del post)
     scrive: 

    Ma tu hai idea di quanto fattura Nokia? Secondo te 1 miliardo avrebbe fatto realmente una grossa differenza, specialmente con tutti i soldi che sta perdendo negli ultimi tempi?

    La differenza è aver tagliato la divisone ricerca & sviluppo (software di sistema) della piattaforma, che consente enormi risparmi da qui a diversi anni.

    Tanto c’è già Microsoft che spende l’ira di dio in questo settore.

    Chiuso OT.

  • # 25
    zephyr83
     scrive: 

    certo ma l’aiuto economico è stato decisamente importante! Elop diceva che bisognava fare in fretta, che nn c’era più tempo da perdere, hanno cancellato altri progetti (vedi meego) perché se no nn sarebbero arrivati in tempo sul mercato e invece sn più “indietro” di prima! Le azioni nokia sn crollate ed è uscita anche dall’indice Euro Stoxx 50. Senza un accordo come quello di microsoft cn tanto di soldini promessi sarebbe stato un disastro! di certo nokia nn si sarebbe fatta “convincere” tanto facilmente se fra le altre cose nn ci fosse stato anche questo famoso miliardino!

    Fine OT

  • # 26
    Delphi
     scrive: 

    A me aveva abituato bene Borland. :P
    Comunque è vero: MS ha sempre puntato molto sul “coccolare” i programmatori… anche se lavoravo molto più in fretta e meglio con Delphi, che con Visual Basic o qualche C/C++

  • # 27
    Antonio Barba (TheKaneB)
     scrive: 

    piccola precisazione:

    @Cesare

    Comunque anche l’emulatore di iOS simula l’intero dispositivo, e non soffre degli stessi problemi prestazionali (pur emulando anche hardware di un certo spessore).

    Non è corretto. Il simulatore iOS esegue codice nativo x86. Puoi verificare quanto ho detto semplicemente leggendo i parametri di compilazione che sono differenti per le piattaforme: Simulator x86, Device ARMv6, Device ARMv7 (iphone4 e ipad1/2)

    Anche in fase di debug ciò è visibile, semplicemente interrompendo il task (con un banale breakpoint) e selezionando la modalità di visualizzazione “mixed codice + assembly”. In fase di simulazione si avrà del codice x86.

    Per il resto, concordo con tutto quello che hai scritto :)

  • # 28
    zephyr83
     scrive: 

    Bhe con Delphi hai una breccia anche nel cuore di Cesare :D

  • # 29
    michelangelog
     scrive: 

    L’emulatore ios al confronto non emula un benemerito K.
    Quando da xcode compili per emulatore fai una compilazione con target i386, quindi l’emulatore emula solo le api e solo una parte minima del sistema; non l’hardware reale. (ci sono diverse differenze tra l’emulatore e un device ios vero, si notano spesso sviluppando su opengl, fai due benchmark su emulatore su ad esempio un macbook air, un imac e un iphone reale e vedrai differenze spaventose,)
    L’emulatore android grazie a qemu emula completamente un altra architettura, quindi specie se cerchi di emulare un tablet o delle api recenti 2.3.3 (ad esempio), emuli un architettura esosa e ben diversa dal x86 e quindi l’emulatore, … pesa.
    Con android un apk compilatore per emulatore e caricato sul device, gira, su xcode devi fare un build per device con target arm6 o arm7; le uniche app che fa girare l’emulatore sono target i386.

  • # 30
    michelangelog
     scrive: 

    Quindi riassumo:
    “An application running natively on an iOS device is an ARM program. However, an application running in the iOS Simulator is an ordinary 32-bit (i386 architecture) Mac OS X program. In other words, the Simulator doesn’t simulate an iOS device down to the hardware level. It provides a faithful copy of the iOS environment, reimplemented to run natively on the Mac.”
    in pratica l’ios emulator è un “simulatore” l’emulatore di android emula davvero una piattaforma arm a tutti i livelli.
    (per dire non si può fare un paragone tra la velocità delle due piattaforme)
    (non sono ne pro android ne pro ios ma secondo me era una specificazione dovuta)

  • # 31
    zephyr83
     scrive: 

    ops….ovviamente intendevo scrivere “apri una breccia” nel mio precedente commento :P

  • # 32
    demetrius
     scrive: 

    @dani: se usi opengl è praticamente impossibile sfruttare l’emulatore, è da pazzi anche solo provarci ;)
    (c’è praticamente una “doppia emulazione”, prima vengono convertite in istruzioni arm e poi ancora in x86).
    Se mi parli di versioni customizzate dal produttore allora non stiamo parlando della stessa versione software, quindi non centra con quello che ho scritto; e proprio perché sono problemi
    specifici, provarlo su un dispositivo reale non ti serve a niente se non è quello che crea problemi, e quindi alla fine non risolvi niente.

    @cdm: non sto mettendo in dubbio che hai avuto quei problemi, è solo che è bene precisare che io non ho avuto tutti i problemi descritti, e come me molti altri.

    [quote]Purtroppo c’è una forte customizzazione dei dispositivi, per cui ciò che dici non è vero. Alcune cose le scopri sul dispositivo reale. Vedi anche il messaggio precedente.[/quote]
    Ma non avrai mai la possibilità di provare il codice tutti i dispositivi possibili, quindi in sostanza non cambia niente, il problema rimane lo stesso, con o senza emulatore.

    [quote]Comunque anche l’emulatore di iOS simula l’intero dispositivo, e non soffre degli stessi problemi prestazionali (pur emulando anche hardware di un certo spessore).

    A parte questo, emulare tutto si potrebbe anche evitare, per lo meno per le applicazioni (la maggioranza) che fanno uso di dalvik. Purtroppo c’è l’NDK di mezzo che rompe le uova nel paniere…

    La verità è che con QEmu si sono ritrovati praticamente tutto già pronto, per cui hanno investito il minimo indispensabile per quello che gli serviva, non pensando a migliorare la situazione…
    [/quote]
    l’emulatore di iOS, non è emulatore ;)
    gira tutto su x86, come ha ben spiegato michelangelog.

    vuoi utilizzare velocemente android sul pc? Installa la versione x86 di Android su VirtualBox, e poi connetti il debbuger a quella.

    Comunque al google I/O (2011) hanno mostrato una versione sperimentale dell’emulatore che stanno sviluppando
    che supera i problemi di prestazioni di QEMU con il rendering software.
    Ti invito a dare un’occhiata a questo video (si inizia a parlare dell’emulatore intorno al minuto 40):
    http://www.youtube.com/watch?v=Oq05KqjXTvs&feature=player_embedded#!

    [quote]E’ vero che dipende dal tipo di dispositivo emulato.
    Riporto alcuni test fatti sulla macchina di cui sopra:

    API Level 7 -> 45 secondi
    API Level 12 -> 3:07

    Secondo più, secondo meno. Che non sono pochi per l’hardware su cui girano, se permetti.[/quote]
    i test li hai fatti con l’animazione di boot disattivata?
    inoltre avviando l’emulatore dall’eseguibile del sdk invece che da dentro eclipse, l’emulatore si avvia un pò più velocemente.

    comunque 3 minuti non mi sembrano così tanti da rientrare nella definizione di “diversi minuti” ;)

    Infine puoi usare gli snapshot che ti avviano istantaneamente l’immagine, ed in 2 secondi è perfettamente attiva e funzionante (occupi spazio su disco, ma non credo sia così rilevante)

    [quote]Non mi pare di aver visto placeholder anche sull’ultima versione dell’SDK e del plugin.

    Giusto per evitare incomprensioni, intendo roba come questa:
    http://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.fallbackvalue(v=vs.95).aspx
    http://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.targetnullvalue(v=vs.95).aspx

    O, per situazioni più complesse, qualcosa come questo:

    http://blogs.msdn.com/b/wpfsldesigner/archive/2010/06/30/sample-data-in-the-wpf-and-silverlight-designer.aspx

    Il tutto ovviamente rimanendo a design-time (senza mai lanciare l’applicazione).
    [/quote]
    utilizzando ListView, dei segnaposti che ti danno un anteprima del tuo layout reale e dando “una forma agli item” ci sono, non si può ancora personalizzare il contenuto della lista, anche se ci stanno lavorando.
    Se ti crei una custom view puoi anche inserire i dati in design-time, c’è un esempio nel video di sopra con il calendario.

  • # 33
    badboyme
     scrive: 

    Salve ragazzi!
    Sono uno studente di Informatica e sto lavorando alla tesi di laurea.
    Ho trovato molto interessante l’articolo.
    Anche se ancora non ho iniziato, dovrei scrivere un’applicazione..credo per smartphone Android (aspetto conferma dal mio Prof).
    Io ho esperienza di programmazione JAVA, è conosco sufficientemente l’IDE NETBEANS. Da quello che ho letto nell’articolo, anche se esiste un plug-in (l’SDK ANDROID) per Eclipse, è possibile installarlo in NETBEANS: questo è positivo!
    Il fatto è che non ho mai programmato su smartphone. Solo JAVA, C, Visual Basic.

    ORa, vorrei sapere da dove partire…
    A proposito: il mio prof mi ha chiesto se avessi uno smartphone android…io credevo di poter usare un emulatore…ma avendo letto l’articolo…credo sia meglio che me ne compri uno, giusto?

    Poi un’altra cosa…Dovrei cercare informazioni sulla programmazione lato server, per creare un’applicazione web-oriented che si possa interfacciare con dispositivi smartphone.
    Cosa dovrei cercare esattametne? Il mio prof ha parlato genericamente di linguaggio C++ e C# (linguaggi che non conosco affatto).

    Vi prego, potreste aiutarmi ???
    Grazie per la pazienza.

    PS: se possibile, vorrei un contatto email con qualcuno di voi programmatori, così da poter avere una comunicazione più diretta.

  • # 34
    cristian
     scrive: 

    La piattaforma migliore per programmare in Android è indubbiamente Linux.
    Posso confermare solo la lentezza dell’emulatore.

  • # 35
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Delphi & zephyr83: un nome, un garanzia. :)

    @Antonio & michelangelog: grazie per la precisazione. Come ho già scritto, su iOS non ho ancora iniziato a lavorarci, per cui non ho esperienza in materia (al momento ho studiato Objective-C) e l’emulatore l’ho soltanto visto all’opera (non conosco i dettagli sul suo funzionamento, come avete riportato).

    @demetrius: rispondo sempre per punti.

    se usi opengl è praticamente impossibile sfruttare l’emulatore, è da pazzi anche solo provarci ;)

    Non vedo perché: potrebbe benissimo essere accelerato in hardware, sfruttando il s.o. ospite similmente a quanto fanno virtualizzatori come VMWare e VirtualBox.

    (c’è praticamente una “doppia emulazione”, prima vengono convertite in istruzioni arm e poi ancora in x86).

    Questo vale per la CPU. Vedi sopra.

    Se mi parli di versioni customizzate dal produttore allora non stiamo parlando della stessa versione software, quindi non centra con quello che ho scritto; e proprio perché sono problemi specifici, provarlo su un dispositivo reale non ti serve a niente se non è quello che crea problemi, e quindi alla fine non risolvi niente.

    Conosci produttori che non abbiano personalizzato Android per le loro esigenze? Mi pare che la strada seguita generalmente sia questa, per cui un emulatore serve per lo sviluppo di massima dell’applicazione. Poi serve il testing su quante più configurazione e dispositivi possibile, per essere un po’ più tranquilli.

    non sto mettendo in dubbio che hai avuto quei problemi, è solo che è bene precisare che io non ho avuto tutti i problemi descritti, e come me molti altri.

    Ciò non toglie che li abbia avuti, come tanti altri, ed è quello che ho scritto.

    Ma non avrai mai la possibilità di provare il codice tutti i dispositivi possibili, quindi in sostanza non cambia niente, il problema rimane lo stesso, con o senza emulatore.

    Mi fa piacere che tu abbia ritrattato del tutto quanto avevi scritto prima. Che poi sia impossibile provare il software su qualunque dispositivo l’avevo già scritto.

    l’emulatore di iOS, non è emulatore ;)
    gira tutto su x86, come ha ben spiegato michelangelog.

    In realtà stiamo facendo un uso improprio dei termini. Formalmente sono tutti emulatori. I simulatori devono soddisfare a ben altri, decisamente più pesanti e rigorosi, requisiti. Ma non è questa la sede per parlarne.

    vuoi utilizzare velocemente android sul pc? Installa la versione x86 di Android su VirtualBox, e poi connetti il debbuger a quella.

    La strada migliore sarebbe metterla a disposizione senza far ricorso a VirtualBox, esattamente come fa la concorrenza da un bel pezzo. Ma servono investimenti.

    Comunque al google I/O (2011) hanno mostrato una versione sperimentale dell’emulatore che stanno sviluppando
    che supera i problemi di prestazioni di QEMU con il rendering software.
    Ti invito a dare un’occhiata a questo video (si inizia a parlare dell’emulatore intorno al minuto 40):
    http://www.youtube.com/watch?v=Oq05KqjXTvs&feature=player_embedded#!

    Al momento non ho tempo. Vediamo se nel fine settimana posso dargli un’occhiata. Fermo restando che, come avevo detto anche prima, servirebbe una soluzione radicale e allineata ai competitor.

    i test li hai fatti con l’animazione di boot disattivata?

    Ho lasciato tutto com’è.

    inoltre avviando l’emulatore dall’eseguibile del sdk invece che da dentro eclipse, l’emulatore si avvia un pò più velocemente.

    E’ quel che faccio sempre. Di recente sono costretto a farlo partire da linea di comando.

    comunque 3 minuti non mi sembrano così tanti da rientrare nella definizione di “diversi minuti” ;)

    Considerata la macchina che ho a disposizione, direi che sono fin troppi. :P

    Comunque sì, per la mia macchina magari sono un po’ esagerati. Non biasimo chi è costretto a usare sistemi più vecchi / meno prestanti.

    Infine puoi usare gli snapshot che ti avviano istantaneamente l’immagine, ed in 2 secondi è perfettamente attiva e funzionante (occupi spazio su disco, ma non credo sia così rilevante)

    La prima cosa che ho imparato è lanciare l’emulatore, lasciandolo sempre attivo. Poi sul mio PC uso sempre l’ibernazione, per cui mi ritrovo sempre con l’ambiente di lavoro per come l’ho lasciato.

    Per cui l’esigenza degli snapshot l’ho sentita soltanto quando ho avuto i problemi di cui ho parlato nell’articolo, ma finora non v’ho fatto ricorso. Forse se tornerò a svilupparci più attivamente li prenderò in considerazione.

    utilizzando ListView, dei segnaposti che ti danno un anteprima del tuo layout reale e dando “una forma agli item” ci sono

    Dove?

    non si può ancora personalizzare il contenuto della lista, anche se ci stanno lavorando.

    E’ da 8 anni che lavorano ad Android…

    Se ti crei una custom view puoi anche inserire i dati in design-time, c’è un esempio nel video di sopra con il calendario.

    Se permetti, questo non c’entra nulla con quanto ho riportato prima in merito.

    Non è una “feature” della piattaforma, ma una pezza a cui deve lavorare lo sviluppatore. Tra l’altro si tratta di una soluzione applicabile praticamente a qualunque framework/libreria.

    Ben altra cosa è quanto esposto nei link che ho fornito: un meccanismo standard, a disposizione fin da subito per qualunque componente già esistente o nuovo, che lo sviluppatore deve utilizzare (con un po’ di lavoro per lo scenario più complesso, ma qui è necessario perché bisogna pur sempre “costruire” la fonte di dati che verrà poi passata al componente a design-time).

    @badboyme: mi spiace, ma questo spazio non è utilizzabile per quanto chiedi. T’invito a esporre il tuo problema nella sezione Programmazione del forum del sito madre (Hardware Upgrade), sicuramente più indicato. Grazie.

  • # 36
    demetrius
     scrive: 

    Non vedo perché: potrebbe benissimo essere accelerato in hardware, sfruttando il s.o. ospite similmente a quanto fanno virtualizzatori come VMWare e VirtualBox.

    Appunto potrebbe, ma al momento non lo fa, quindi purtroppo non è possibile utilizzare produttivamente l’emulatore per testare un app che sfrutta opengl.

    Conosci produttori che non abbiano personalizzato Android per le loro esigenze? Mi pare che la strada seguita generalmente sia questa, per cui un emulatore serve per lo sviluppo di massima dell’applicazione. Poi serve il testing su quante più configurazione e dispositivi possibile, per essere un po’ più tranquilli.

    Mi fa piacere che tu abbia ritrattato del tutto quanto avevi scritto prima. Che poi sia impossibile provare il software su qualunque dispositivo l’avevo già scritto.

    Ritrattato? o_0

    Testare con l’emulatore è praticamente equivalente (prestazioni a parte) a testare un telefono con Android AOSP; è quello che ho scritto io, né più, né meno.

    Ci sono comunque personalizzazioni e personalizzazioni, ad esempio un semplice launcher personalizzato non comporta il minimo problema ad un app normale.

    Quello che volevo evidenziare con i precedenti interventi è che sviluppare su emulatore o su un solo device fisico non cambia sostanzialmente niente dal punto di vista della compatibilità.

    Ciò non toglie che li abbia avuti, come tanti altri, ed è quello che ho scritto.

    Hai scritto la tua esperienza ed io ho scritto la mia, non mi pare niente di strano. Non capisco la necessità di controbattere.

    Per quanto riguarda il discorso sulla velocità di avvio, disattivando l’animazione di boot riduci di un bel pò i tempi di avvio.
    E comunque con l’introduzione degli snapshot il tempo di avvio non è più un problema.
    Sono cose che avresti potuto (secondo me dovuto) citare nell’articolo.

    Per quanto riguarda le listview, se hai l’ultima versione dell’ADT è strano che tu non l’abbia visto, non si deve fare nessuna azione particolare.
    Appena metti una listview nel layout ti dovrebbe appare una lista col layout predefinito. Cliccando col tasto destro, su “preview list content” si può cambiare il layout degli elementi tra i vari tipi predefiniti o caricare il tuo.

    Se permetti, questo non c’entra nulla con quanto ho riportato prima in merito.

    Non è una “feature” della piattaforma, ma una pezza a cui deve lavorare lo sviluppatore. Tra l’altro si tratta di una soluzione applicabile praticamente a qualunque framework/libreria.

    non è una cosa così scontata, e fino a qualche mese fa non era possibile farla… ma forse non hai capito bene cosa intendevo, dai un’occhiata all’esempio del calendario nel video che ti dicevo.

    Ben altra cosa è quanto esposto nei link che ho fornito: un meccanismo standard, a disposizione fin da subito per qualunque componente già esistente o nuovo, che lo sviluppatore deve utilizzare (con un po’ di lavoro per lo scenario più complesso, ma qui è necessario perché bisogna pur sempre “costruire” la fonte di dati che verrà poi passata al componente a design-time).

    Su questo non c’è dubbio, l’ho scritto prima, non si può ancora.

    A parte questo, vorrei farti una domanda sul tuo approccio in generale… preferisci “perdere tempo” (si fa per dire) a creare la struttura per avere a design time la preview con dati,
    oppure avere una “bozza” a design time e verificare in pochi secondi il risultato reale sul telefono o emulatore?
    Secondo me sono pochissimi i casi in cui una cosa del genere ha una vera utilità, che ne pensi?

  • # 37
    floriano
     scrive: 

    se vuoi programmare su windows Vista e windows 7 lascia perdere proprio la directory “C:\Program Files” visto che dà problemi con un bel pò di programmi.

    sembrerà poco elegante però invece di installare in

    C:\Program Files\Android

    metti tutto in

    C:\Android

    almeno in questo modo si evitano i problemi sui diritti…

  • # 38
    Cesare Di Mauro (Autore del post)
     scrive: 

    Alcune applicazioni (penso, al solito, a Python :D) te lo propongono già all’installazione: avrebbe dovuto farlo anche l’SDK, visti i grossolani problemi di cui soffre in merito. ;)

    Detto ciò, a parte casi particolari, siamo passati da Vista a 7, tra poco arriva 8, ed è inaccettabile questa situazione.

    Ovviamente a saperlo prima avrei fatto così… :P

    @demetrius:

    Appunto potrebbe, ma al momento non lo fa, quindi purtroppo non è possibile utilizzare produttivamente l’emulatore per testare un app che sfrutta opengl.

    Ed è un grosso limite, visto che i giochi sono importanti e non si realizzano con le View.

    Ritrattato? o_0

    Testare con l’emulatore è praticamente equivalente (prestazioni a parte) a testare un telefono con Android AOSP; è quello che ho scritto io, né più, né meno.

    Ci sono comunque personalizzazioni e personalizzazioni, ad esempio un semplice launcher personalizzato non comporta il minimo problema ad un app normale.

    Quello che volevo evidenziare con i precedenti interventi è che sviluppare su emulatore o su un solo device fisico non cambia sostanzialmente niente dal punto di vista della compatibilità.

    Tu hai scritto prima questo:

    “una volta testato il programma sull’emulatore sei sicuro che funzioni allo stesso modo anche su un telefono reale che abbia la stessa configurazione e versione software”

    e dopo hai cambiato discorso scrivendo questo:

    “Se mi parli di versioni customizzate dal produttore allora non stiamo parlando della stessa versione software, quindi non centra con quello che ho scritto”

    Perché hai introdotto il concetto di “versione customizzata”. Cosa che è praticamente la norma su Android, a parità di API Level che rappresenta il “collante” o, meglio, l’elemento fondante di tutta la piattaforma.

    Posta in altri termini, la questione è molto semplice: un dispositivo che implementa una determinata API Level, effettuando poi delle personalizzazioni, si può ancora considerare Android?

    Se sì, affiorano i problemi di cui abbiamo parlato finora, e coi quali uno sviluppatore deve confrontarsi e sbatterci la testa.

    Se no, stiamo parlando del sesso degli angeli, e Android come piattaforma si ridurrebbe ai soli emulatori. Ergo: inappetibile per i programmatori che hanno bisogno di stabilità e solidità.

    Perché non è normale che la stessa applicazione funzioni perfettamente con l’emulatore e con uno scrauso (ormai; ma quando è stato comprato era un ottimo prodotto) HTC, mentre sul Galaxy fiammante non va (e bisogna introdurre una pezza al codice, o trovare una soluzione alternativa che funzioni sempre). E no, non stiamo parlando di OpenGL.

    Hai scritto la tua esperienza ed io ho scritto la mia, non mi pare niente di strano. Non capisco la necessità di controbattere.

    Nemmeno io, perché è scontato che ad altri non saranno capitati gli stessi problemi.

    Per quanto riguarda il discorso sulla velocità di avvio, disattivando l’animazione di boot riduci di un bel pò i tempi di avvio.

    Dal manager, che hai consigliato anche prima, non si può. Devi farlo… da riga di comando. Quindi andare a recuperare l’eseguibile dell’emulatore, dare un’occhiata alle varie opzioni, e poi procedere a impostare la riga di comando di conseguenza.

    Se ti sembra una cosa normale a 2011 inoltrato, quando c’è a disposizione una GUI per gestire le macchine virtuali e addirittura un plug-in per sviluppare l’UI di un’applicazione…

    E comunque con l’introduzione degli snapshot il tempo di avvio non è più un problema.
    Sono cose che avresti potuto (secondo me dovuto) citare nell’articolo.

    Come già detto, ho riportato la mia esperienza, quindi senza uso degli snapshot. L’emulatore rimane appena sufficientemente reattivo, anche togliendo di mezzo lo startup.

    Per quanto riguarda le listview, se hai l’ultima versione dell’ADT è strano che tu non l’abbia visto, non si deve fare nessuna azione particolare.
    Appena metti una listview nel layout ti dovrebbe appare una lista col layout predefinito. Cliccando col tasto destro, su “preview list content” si può cambiare il layout degli elementi tra i vari tipi predefiniti o caricare il tuo.

    Con l’ultima versione installata potrò provarlo, anche se nutro qualche dubbio che possa rendere in qualche modo la custom view complessa che ho realizzato per gli item delle ListView, a maggior ragione se un item include un’altra ListView al suo interno.

    Comunque ho trovato qualche informazione in giro e siamo di fronte all’n-esima pezza aggiunta a un caso particolare di un problema molto più generale.

    Trovo scandaloso che abbiano utilizzato i COMMENTI all’interno dell’XML per memorizzare queste informazioni addizionali: basta effettuare qualche cambiamento con la GUI e si perde tutto! E, come detto, vale solo per le ListView.

    non è una cosa così scontata, e fino a qualche mese fa non era possibile farla… ma forse non hai capito bene cosa intendevo, dai un’occhiata all’esempio del calendario nel video che ti dicevo.

    Ho capito, ho capito. Più che altro sperimenterò appena tornerò a metter le mani su Android.

    A parte questo, vorrei farti una domanda sul tuo approccio in generale… preferisci “perdere tempo” (si fa per dire) a creare la struttura per avere a design time la preview con dati,
    oppure avere una “bozza” a design time e verificare in pochi secondi il risultato reale sul telefono o emulatore?
    Secondo me sono pochissimi i casi in cui una cosa del genere ha una vera utilità, che ne pensi?

    Io lavoro la stragrande maggioranza del tempo a design-time su altre piattaforme (Windows Phone 7, al momento) ed è la via che preferisco. Anche perché non puoi verificare in pochi secondi il risultato finale, su un’applicazione complessa che magari prevede diverse “pagine”/activity con le quali interagire prima di arrivare a quella schermata desiderata.

    Fermo restando che i placeholder per tutti i controlli ti fanno in ogni caso perdere pochissimo tempo, perché è sufficiente… piazzare il valore (sull’XML o dal pannello, è ugualmente veloce; nel primo caso l’editor con autocompletamento, nel secondo basta cliccare sulla voce) e il risultato l’hai immediatamente davanti a te. Su layout più complessi devi comunque perderci tempo, ma una volta definita la struttura che genererà a design time i tuoi dati, anche qui puoi cambiare velocemente quello che vuoi e toccare con mano i risultati immediatamente.

    Su Android, purtroppo, devi lanciare in continuazione per vedere se è tutto come ti aspetti. Parlo di layout non banali, ovviamente, non del classico esperimento tanto per provare a fare qualcosa su questa piattaforma.

  • # 39
    michelangelog
     scrive: 

    Non puoi fare quello che fa virtualbox perchè qua stai parlando di accellerare un’architettura diversa da quella dell’host.
    Con le estensioni per la virtualizzazione l’emulatore è solo quasi un supervisore, e mentre vengono rimappate le istruzioni a livello ring-0 tutte le altre sono passate direttamente al processore.
    Un processore x86 non può eseguire istruzioni arm, quindi una virtualizzazione hardware non si può mai avere.
    Al massimo puoi avere un compilatore jit che traduce l’istruzione arm in una o più equivalenti istruzioni x86 e poi passare queste al processore, credo che a un qemu-jit stiano lavorando.
    Avresti comunque un downgrade di performance (mi pare che sui jit empiricamente abbiano misurato un 20-40% di latenza, dovuta al fatto che comunque non c’è caching delle istruzioni successive e alla lentezza del jit di per se.)
    Quindi si può virtualizzare un architettura uguale-simile tra host e gust, un’architettura differente si può solo emulatore con tutti i rallentamenti del caso.
    Secondo me un modo per accellerare lo sviluppo sarebbè avere vari target di emulazione, da quello più veloce, un bell’anroid x86 veramente virtualizzato e vari target arm6-arm7 più simili all’hardware reale ma molto più lenti e pesanti… ti fai quasi tutto lo sviluppo su android x86 e poi nella fase di testing passi dal virtualizzatore x86 all’emulatore arm.
    Credo che comunque a google siano a conoscenza della situazione e prima o poi un rimedio simile arriverà.

  • # 40
    Cesare Di Mauro (Autore del post)
     scrive: 

    Veramente quando ho citato VMWare e VirtualBox non mi riferivo alla CPU, ma esclusivamente al resto dell’hardware. Nello specifico, si parlava di OpenGL.

    Per il resto ovviamente concordo, e avevo già scritto che sarebbe stato meglio sviluppare una versione di Android x86, da NON far girare su qualche virtualizzatore, ma come applicazione; come, quindi, avviene sulla concorrenza. ;)

  • # 41
    Z80Fan
     scrive: 

    @Cesare
    Un progetto del genere c’è già, si chiama IcedRobot, però non so a che punto è.

  • # 42
    demetrius
     scrive: 

    Tu hai scritto prima questo:

    “una volta testato il programma sull’emulatore sei sicuro che funzioni allo stesso modo anche su un telefono reale che abbia la stessa configurazione e versione software”

    e dopo hai cambiato discorso scrivendo questo:

    “Se mi parli di versioni customizzate dal produttore allora non stiamo parlando della stessa versione software, quindi non centra con quello che ho scritto”

    Perché hai introdotto il concetto di “versione customizzata”. Cosa che è praticamente la norma su Android, a parità di API Level che rappresenta il “collante” o, meglio, l’elemento fondante di tutta la piattaforma.

    Posta in altri termini, la questione è molto semplice: un dispositivo che implementa una determinata API Level, effettuando poi delle personalizzazioni, si può ancora considerare Android?

    Se sì, affiorano i problemi di cui abbiamo parlato finora, e coi quali uno sviluppatore deve confrontarsi e sbatterci la testa.

    Se no, stiamo parlando del sesso degli angeli, e Android come piattaforma si ridurrebbe ai soli emulatori. Ergo: inappetibile per i programmatori che hanno bisogno di stabilità e solidità.

    Perché non è normale che la stessa applicazione funzioni perfettamente con l’emulatore e con uno scrauso (ormai; ma quando è stato comprato era un ottimo prodotto) HTC, mentre sul Galaxy fiammante non va (e bisogna introdurre una pezza al codice, o trovare una soluzione alternativa che funzioni sempre). E no, non stiamo parlando di OpenGL.

    Non ho cambiato alcun discorso, una versione customizzata in profondità dal produttore (non ovviamente un semplice launcher cambiato, o qualche app preinstallata) non è la stessa versione dell’AOSP, mi sembra una cosa chiara e scontata… non ho scritto (o voluto intendere) che versione software = API Level.
    Mi sembra di aver chiarito abbastanza il concetto, e che quello che volevo dire sia abbastanza chiaro, altrimenti pazienza, non ha senso continuare a ripeterlo.

    Essendo open-source, ogni produttore può quasi tutto quello che gli pare, anche fare cambiamenti a livello di API senza rilasciare informazioni, e nessuno puoi impedirglielo. Non puoi farci niente, è così, prendere o lasciare.
    E’ il produttore che deve capire che, facendo modifiche a livello profondo, crea solo problemi ai suoi clienti, e che eventualmente sarebbe meglio a collaborare con google per includere le sue modifiche nell’AOSP (anche se capisco che possa voler non condividere alcune cose con altri produttori).

    Dal manager, che hai consigliato anche prima, non si può. Devi farlo… da riga di comando. Quindi andare a recuperare l’eseguibile dell’emulatore, dare un’occhiata alle varie opzioni, e poi procedere a impostare la riga di comando di conseguenza.

    Se ti sembra una cosa normale a 2011 inoltrato, quando c’è a disposizione una GUI per gestire le macchine virtuali e addirittura un plug-in per sviluppare l’UI di un’applicazione…

    c’è l’opzione in eclipse sotto “run configuration”, non c’è bisogno di usare la riga di comando.

    Come già detto, ho riportato la mia esperienza, quindi senza uso degli snapshot. L’emulatore rimane appena sufficientemente reattivo, anche togliendo di mezzo lo startup.

    ok, ma uno dei problemi di cui ti lamentavi erano i tempi di avvio, cosa risolvibile con gli snapshot.

    Con l’ultima versione installata potrò provarlo, anche se nutro qualche dubbio che possa rendere in qualche modo la custom view complessa che ho realizzato per gli item delle ListView, a maggior ragione se un item include un’altra ListView al suo interno.

    non ho idea se funzioni con una ListView dentro un’altra, ma ho provato con layout anche abbastanza complessi e fa il suo lavoro.

    Comunque ho trovato qualche informazione in giro e siamo di fronte all’n-esima pezza aggiunta a un caso particolare di un problema molto più generale.

    Trovo scandaloso che abbiano utilizzato i COMMENTI all’interno dell’XML per memorizzare queste informazioni addizionali: basta effettuare qualche cambiamento con la GUI e si perde tutto! E, come detto, vale solo per le ListView.

    devi trovare sempre il pelo nell’uovo ;)

    cmq non è vero che perdi tutto ad ogni cambiamento fatto nella GUI.

    Io lavoro la stragrande maggioranza del tempo a design-time su altre piattaforme (Windows Phone 7, al momento) ed è la via che preferisco. Anche perché non puoi verificare in pochi secondi il risultato finale, su un’applicazione complessa che magari prevede diverse “pagine”/activity con le quali interagire prima di arrivare a quella schermata desiderata.

    Fermo restando che i placeholder per tutti i controlli ti fanno in ogni caso perdere pochissimo tempo, perché è sufficiente… piazzare il valore (sull’XML o dal pannello, è ugualmente veloce; nel primo caso l’editor con autocompletamento, nel secondo basta cliccare sulla voce) e il risultato l’hai immediatamente davanti a te. Su layout più complessi devi comunque perderci tempo, ma una volta definita la struttura che genererà a design time i tuoi dati, anche qui puoi cambiare velocemente quello che vuoi e toccare con mano i risultati immediatamente.

    Su Android, purtroppo, devi lanciare in continuazione per vedere se è tutto come ti aspetti. Parlo di layout non banali, ovviamente, non del classico esperimento tanto per provare a fare qualcosa su questa piattaforma.

    volendo, puoi testare direttamente l’activity che ti interessa.

    Il mio pensiero è che un’anteprima di massima (secondo me sufficiente a sviluppare efficacemente) ce l’hai già con l’implementazione attuale, bisogna vedere di volta in volta
    se è il caso perdere tempo ad impostare la struttura per avere un’anteprima anche sui dati… ma queste sono valutazioni personali.

    Cmq…
    http://code.google.com/p/android/issues/entry?template=Tools%20feature%20request

    magari puoi avere utili suggerimenti per rendere la vita più facile ;)

  • # 43
    Cesare Di Mauro (Autore del post)
     scrive: 

    @demetrius:

    Non ho cambiato alcun discorso, una versione customizzata in profondità dal produttore (non ovviamente un semplice launcher cambiato, o qualche app preinstallata) non è la stessa versione dell’AOSP, mi sembra una cosa chiara e scontata… non ho scritto (o voluto intendere) che versione software = API Level.
    Mi sembra di aver chiarito abbastanza il concetto, e che quello che volevo dire sia abbastanza chiaro, altrimenti pazienza, non ha senso continuare a ripeterlo.

    Essendo open-source, ogni produttore può quasi tutto quello che gli pare, anche fare cambiamenti a livello di API senza rilasciare informazioni, e nessuno puoi impedirglielo. Non puoi farci niente, è così, prendere o lasciare.
    E’ il produttore che deve capire che, facendo modifiche a livello profondo, crea solo problemi ai suoi clienti, e che eventualmente sarebbe meglio a collaborare con google per includere le sue modifiche nell’AOSP (anche se capisco che possa voler non condividere alcune cose con altri produttori).

    Francamente mi pare difficile credere che i produttori arrivino a cambiare persino le API, ma è una possibilità che non si può certo escludere del tutto.

    Ma che sia questo o meno il motivo, poco importa: gli sviluppatori devono comunque farsi carico di questa situazione instabile. Mentre sulla concorrenza ciò non avviene.

    c’è l’opzione in eclipse sotto “run configuration”, non c’è bisogno di usare la riga di comando.

    L’ho vista adesso, e ovviamente non l’avevo mai usata. Ho sempre eseguito Run (o premuto F5), ma per lo più lanciando la macchina virtuale direttamente dal manager dell’SDK.

    ok, ma uno dei problemi di cui ti lamentavi erano i tempi di avvio, cosa risolvibile con gli snapshot.

    I tempi di avvio rimangono elevati. Gli snapshot nascono per risolvere un altro tipo di problematica, e contingentemente accorciano anche il tempo impiegato dall’emulatore a rendersi disponibile. Ma prima (cioè in assenza di snapshot) devi comunque sorbirti tutto il periodo di inattività.

    non ho idea se funzioni con una ListView dentro un’altra, ma ho provato con layout anche abbastanza complessi e fa il suo lavoro.

    Come avevo intuito, non funziona. D’altra parte era prevedibile, per com’è stata implementata questa pezza.

    devi trovare sempre il pelo nell’uovo ;)

    Non mi pare. E’ decisamente grave affidarsi ai commenti presenti nell’XML per memorizzare queste informazioni, poiché si tratta di informazioni aleatorie che possono essere rimosse da un parser, appunto.

    XML nasce per trasportare informazione, e questa si trova nei tag e nei loro attributi. NON nei commenti.

    cmq non è vero che perdi tutto ad ogni cambiamento fatto nella GUI.

    Non ho detto questo, infatti. Ho detto che basta qualche cambiamento per rimuovere quest’informazione. Come un semplice spostamento della ListView, ad esempio.

    volendo, puoi testare direttamente l’activity che ti interessa.

    Solo se si tratta di un “modulo a se stante”, e comunque ti devi preoccupare di lanciare quell’activity e non quella principale.

    Se, come avviene per lo più nel mio caso, l’activity dipende dalle informazioni raccolte da altre activity, devi procedere necessariamente col normale workflow.

    Il mio pensiero è che un’anteprima di massima (secondo me sufficiente a sviluppare efficacemente) ce l’hai già con l’implementazione attuale, bisogna vedere di volta in volta

    Ce l’hai solo per le ListView (con tutti i limiti di cui sopra), e non per gli altri controlli se questi visualizzano informazioni prelevate a runtime.

    Come dicevo prima, si tratta di una pezza a un caso particolare per una problematica molto più generale…

    se è il caso perdere tempo ad impostare la struttura per avere un’anteprima anche sui dati… ma queste sono valutazioni personali.

    Indubbiamente, ma principalmente dipende dal tipo di applicazione che stai sviluppando.

    Cmq…
    http://code.google.com/p/android/issues/entry?template=Tools%20feature%20request

    magari puoi avere utili suggerimenti per rendere la vita più facile ;)

    In 8 anni che lo sviluppano, mi aspetto che tutto quello di cui abbiamo discusso sia stato già segnalato. :P

    Comunque non ho tempo per fare da beta tester a Google: vengo pagato per fare altro. ;)

  • # 44
    Davide Rao
     scrive: 

    Io uso l’emulatore sotto piattaforma linux e hardware parecchio meno pompato (laptop da 300 euro della emachines) e per me non ci vogliono diversi minuti per arrivare all’operativita’ e le performance sono comunque simili a quelle che ottengo con emulazione QEMU per ARM Versatile. (Tra l’altro sospetto fortemente che sotto linux l’android-sdk-linux_x86 usi un qemu travestito per creare i virtual device)

  • # 45
    Fede
     scrive: 

    Qualcuno ha esperienza con MONODROID?
    Sto valutando l`idea di prenderlo per portare su Android delle applicazioni scritte per .NET in csharp

    http://monodroid.org/

  • # 46
    Cesare Di Mauro (Autore del post)
     scrive: 

    L’ultima volta che ho provato (su Windows) a realizzare il classico “Hello, World!” non mi ha nemmeno creato correttamente il progetto (il wizard ha generato un’eccezione).

    Spero che maturi velocemente, perché sarebbe molto comodo lavorare con C# e le librerie .NET.

  • # 47
    Fede
     scrive: 

    Io l’ho usato di recente, e rispetto alla tua esperienza posso dirti che il classico “hello world” sono riuscito a farlo, e che anzi, sono riuscito a portare un’applicazione completa (tranne la parte grafica) senza nessun problema particolare.

  • # 48
    Cesare Di Mauro (Autore del post)
     scrive: 

    Eureka! S’ha da riprovare, allora. Grazie. :)

  • # 49
    pascal
     scrive: 

    In poche parole non esiste un IDE per android? Bisogna soccombere ad usare codice emulato con kernel linux? Pensano veramente che programmatori che non hanno 1 minuto di tempo da perdere vadano ad imparare un nuovo sistema da zero? Se lo sono mai chiesto se ne avranno la voglia? Visto che il problema ad usare codice nativo c++ sono le API, togliendo l’NDK ovviamente, perche’ non hanno pensato di riscrivere le API native per i vari processori usati piuttosto di creare il dalvik?

  • # 50
    Cesare Di Mauro (Autore del post)
     scrive: 

    Esiste un IDE per Android: è Eclipse con apposito plugin sviluppato da Google.
    Sì, purtroppo si deve emulare un’intera macchina Linux per avviare il simulatore.
    Sì, generalmente i programmatori devono imparare nuovi sistemi da zero o quasi. Purtroppo.
    Dalvik serve per non dover ricorrere al C++ per scrivere applicazioni; è già difficile con Dalvik/Java, per cui figuriamoci col C++…

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.