di  -  mercoledì 7 settembre 2011

E’ l’obiettivo che si pone Google riguardo alla sua piattaforma mobile, per bocca di quello che possiamo definire a buon titolo il padre di Android: Andy Rubin, che lavora al progetto da quando è nato (circa 8 anni fa, nel 2003).

Per arrivarci la casa di Mountain View ha deciso di centralizzare e tenere saldamente in mano le redini dello sviluppo e deciderne la direzione, com’è stato puntualizzato nello stesso intervento.

Open source (o quasi, come sottolineato tempo fa), quindi, ma senza “bazar” : è l’approccio della “cattedrale” (anche se non molto diffuso in quest’ambito), che personalmente condivido poiché permette, sulla carta, di meglio incanalare le risorse ed evitare eccessive frammentazioni (possibili sempre e comunque, a causa di eventuali fork).

Tutto molto bello, quindi, ma le parole di Rubin non possono che provocare sensazioni strane, qualcosa di unico; un misto di fastidio e ilarità allo stesso tempo, con l’idea martellante che il personaggio in questione stia sicuramente scherzando, che la sua non possa che essere ironia o sarcasmo ben celati, sapientemente miscelati in un discorso di pura promozione del prodotto.

Già, perché tutto si può attribuire ad Android, tranne le qualità sopra citate. Lo sa bene chi ha avuto modo di lavorarci, magari professionalmente (quindi non fermandosi al classico hello world et similia).

La stabilità è stata una chimera fin dall’inizio, con un SDK rilasciato velocemente, ma le cui applicazioni sviluppate smanettandoci (per provare il nuovo sistema) tendevano a non funzionare già con la successiva versione.

In ogni caso il wizard di creazione del progetto è l’immagine della situazione di Android dal punto di vista dello sviluppatore, e non necessita di molte parole:

ben 12 versioni (13, con l’ultimo SDK per Honeycomb 3.2), più altre “varianti”… in soli 8 anni. Da guinness dei primati.

Senza parlare poi delle molteplici configurazioni hardware con cui bisogna avere a che fare. E pensare che c’è gente che ha l’ardire di affermare che il mercato Android non sia frammentato…

Ma non c’è niente di meglio di un eloquentissimo esempio del concetto che hanno di stabilità in casa Android:

FILL_PARENT (renamed MATCH_PARENT in API Level 8 and higher), which means that the view wants to be as big as its parent (minus padding)

Dopo diversi anni e ben 7 versioni qualcuno s’è svegliato e ha deciso di cambiare nome, dall’API level 8, a una delle costanti in assoluto più utilizzate nella definizione dell’aspetto (i famigerati layout) dei componenti dell’interfaccia grafica. Per aggiungere la beffa al danno, il termine risulta persino meno autoesplicativo rispetto al precedente.

“Ottimizzazione” e “bontà” meritano di essere trattate assieme (è proprio Android che ce ne dà la possibilità!), partendo dalla citazione di quella che possiamo considerare la pietra angolare di tutta la piattaforma di sviluppo: la classe View.

Com’è possibile vedere dalla paginetta a essa dedicata, discende direttamente da Object (astrazione? specializzazione? Concetti alieni agli ingegneri di Android) e si fa carico di tantissime responsabilità. Un chiaro esempio di God class, insomma; ovviamente da NON imitare assolutamente.

Un altro spunto sull’argomento lo dà la classe TextView, che dal nome dovrebbe permettere di visualizzare del testo. In effetti è proprio quello che fa, ma spulciando la documentazione salta fuori una caratteristica molto interessante:

Displays text to the user and optionally allows them to edit it. A TextView is a complete text editor, however the basic class is configured to not allow editing; see EditText for a subclass that configures the text view for editing.

Quindi TextView racchiude un intero editor di testo, che non è immediatamente abilitato, mentre la classe EditText si occupa semplicemente di quest’aspetto, come ci conferma dall’apposita paginetta:

EditText is a thin veneer over TextView that configures itself to be editable.

Chi ha sviluppato delle applicazioni dotate di interfaccia grafica, siano esse desktop o mobile, sa che quella di visualizzare delle scritte è di gran lunga l’esigenza più comune. Magari con colori e/o font diversi, più o meno grandi, allineate a destra, sinistra o centro, ma rimangono pur sempre delle scritte immobili, appiccicate sullo schermo.

Su Android, invece, qualunque scritta che dev’essere semplicemente visualizzata… si trascina dietro un intero editor! Il classico cannone usato per sparare a una mosca…

Un’altra operazione molto diffusa è visualizzare dei bottoni, ossia delle aree generalmente rettangolari che mostrano scritte e/o immagini che richiamano alla mente un’azione da svolgere a seguito del tradizionale click sull’oggetto in questione. La classe Button, che si occupa di tutto ciò, ha, però, un sorprendente genitore: TextView.

L’associazione logica sembrerebbe corretta: TextView visualizza un testo, per cui se diventa anche cliccabile abbiamo, di fatto, creato un link (ipertesto), e quindi effettuato la classica quadratura del cerchio.

Sarebbe tutto molto bello se non fosse che i bottoni non devono visualizzare soltanto testo, ma magari delle immagini, con un layout anche più complesso (immagine dentro e testo al centro; oppure immagine a sinistra e testo a destra; o ancora layout che prevedono diversi elementi che concorrono al risultato finale).

Ma a parte questa motivazione, che già di per sé sarebbe sufficiente a comprendere l’errore progettuale, c’è da considerare il fatto che la stessa classe View è un elemento cliccabile, poiché anche questa è una fra le sue tante responsabilità. In pratica View e qualunque suo discendente è, di base, cliccabile alla stregua di un bottone, a prescindere dalla sua effettiva specializzazione (che ne modellerà il comportamento atteso).

Pertanto sarebbe stato sufficiente derivare Button direttamente (sic!) da View per realizzare questo tipo di oggetti, anziché portarsi appresso un editor completo: quando mai un bottone ha pure l’esigenza di editare il testo eventualmente presente al suo interno? Agli sviluppatori di Android l’arduo (perché tale è) compito di convincere della “bontà” e “ottimizzazione” di queste scelte…

Per finire (ma ce ne sarebbero tante cose da dire) riguardo a quest’ultimo argomento, ruotare il display comporta la distruzione e successiva ricreazione dell’activity corrente (per i non addetti ai lavori, si tratta di un’applicazione o parte di essa che interagisce in un preciso momento con l’utente)!

E’ facile immaginare il costo di quest’operazione per un’applicazione che fa uso di layout complessi, magari con dati che sono stati precedentemente scaricati da un server remoto (scenario tutt’altro che insolito, in un mondo sempre più online / cloud).

Sarebbe stato troppo complicato invalidare il display, ed eseguire il ricalcolo (grafico) di tutti gli elementi tenendo conto delle mutate dimensioni dell’area visibile? I programmatori esperti non lasciano nemmeno il beneficio del dubbio…

Mentre per il discorso “bontà” delle API si può tranquillamente chiudere con un’altra chicca:

public int getDisplayId ()
Since: API Level 1

Returns the index of this display. This is currently undefined; do not use.

Otto anni e tredici versioni delle API non sono stati sufficienti per definire una buona volta quest’API pubblica…

Per cui mi scuserà il sig. Rubin ma, alla luce di tutto ciò (e di molto altro), le sue affermazioni potrebbero trovare applicazione soltanto in un universo che funzionasse con logica negata. Decenni di ingegneria del software, programmazione a oggetti, ma anche semplice buon senso, impediscono fortemente di condividerle a chi ha un minimo di infarinatura ed esperienza sugli argomenti…

71 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
    massimo
     scrive: 

    Possibile che anche Google sia un allevamento di programmatroti??? Ne ho visti tanti in realtà piccole e medie, ma speravo che da quelle parti bazzicasse gente più in gamba. Incredibile… hanno fatto perfino peggio delle API di Windows.
    La cosa spiega bene l’esistenza di N-mila versioni di Android: il tempo di fare le cose bene non c’è mai, ma il tempo di rifarle da capo c’è sempre. :-(

  • # 2
    Matteo
     scrive: 

    Purtroppo non sono un programmatore e il tuo discorso l’ ho compreso ma non capito a fondo…
    Tuttavia l’ idea di Android mi piace e spero che nelle prossime versioni riescano a sistemare gli evidenti problemi di cui soffre…
    Nel frattempo grazie di avermi mostrato in maniera chiara e precisa alcuni dei problemi di cui soffre… Continua così!!

  • # 3
    Marco
     scrive: 

    “il tempo di fare le cose bene non c’è mai, ma il tempo di rifarle da capo c’è sempre”

    E la cosa più triste è che, nonostante tutto, questo modello si sia rivelato vincente sul fronte commerciale a discapito di soluzioni tecnicamente ben più valide…

  • # 4
    Antonio Barba
     scrive: 

    solo un commento: lol! :-D

  • # 5
    Cla
     scrive: 

    Non è una novità che le soluzioni tecnicamente migliori non abbiano molto successo e viceversa.
    Hanno scelto il timing giusto per entrare in un mercato che da li a poco sarebbe esploso ed effettivamente hanno fatto una gran cosa.

    Io credo che molti di questi problemi siano frutto della fretta di uscire per colmare un buco nel mercato e allo stesso tempo recuperare terreno su Apple (che anche lei ha i suoi bei problemi) il più velocemente possibile.

    Per me appena la situazione si stabilizzerà e i tempi di rilascio si dilateranno vedremo piano piano le cose sistemarsi. Già dalle prime informazioni su Ice Cream sembra che abbiano lavorato molto in tal senso.

  • # 6
    Giovanni
     scrive: 

    Ci sono tante cose da aggiungere. L’articolo è completo, ma il mondo reale è imperfetto. Se da una parte anche io sono allibito al vedermi distruggere le Activity quando si ruota lo schermo, oppure bug come questo http://code.google.com/p/android/issues/detail?id=2626 mai risolti, in giro non c’è molto di totalmente “perfetto” (provate a scrivere qualcosa di decente in vbscript o jscript, l’unico linguaggio scripting preinstallato su tutti i pc windows su cui potete contare! frammentazione zero, ma a che costo ?).
    Insomma, schifezze ce ne sono tante. Android non è perfetto, ma si piazza bene in alto nella classifica della perfezione. E sicuramente è meglio di symbian, quasi impossibile da programmare e molto più frammentato. Non ditemi che symbian è morto perché nokia ad oggi (settmbre 2011) continua a presentare modelli con symbian e la gente li compra pure.
    E di fatto, le API di Android, seppure imperfette, hanno permesso comunque il fiorire di tantissime app che sotto symbian non erano mai fiorite prima.
    Quindi concludo che, nonostante tutti i suoi difetti, inclusi quelli non elencati nell’articolo, evviva android ! :)

  • # 7
    Carmelo
     scrive: 

    Parlo da informatico che ha scritto amatorialmente qualche applicazione android: non capisco tutta questa ilarità che ti causa la dichiariazione di questo super riccone: potresti citare un progetto di dimensioni simili in cui vi si trovino in pieno le qualità citate?
    Eloquente il fatto che la tua arringa iniziale critichi il fatto che uno sviluppatore possa scegliere se compilare una applicazione per un cellulare molto vecchio (sorvoliamo sul fatto che per avere tutte le opzioni che mostri nella creazione di un nuovo progetto devi averle abilitate esplicitamente una per una nella fase di installazione… ). Per te “chiarezza” vuol dire avere una sola release di sdk in 8 anni o avere la possibilità di utilizzare esclusivamente l’ultimo uscito?

    Concludo con una curiosità: la classe view da quale classe dovrebbe discendere se non dalla object??

  • # 8
    Pierpaolo
     scrive: 

    E’ più semplice e produttivo programmare per Windows Phone 7 che non per Android.

    Oddio l’ho detto.

  • # 9
    Andrea Del Bene
     scrive: 

    Sottoscrivo pienamente l’analisi di Cesare, peraltro espressa in una forma divertente ed “umanizzata”.
    Premesso che non sono affatto un fan di Android e che mi sono limitato solo all’esempio Hello World, nel framework sono state fatte delle scelte oggetivamente cretine e frettolose.

    Il fatto è che purtroppo basta proprio guardare un semplice HelloWorld per rendersi conto della confusione e della fretta che albergava nelle menti dei progettisti di Google.
    Possibile che una classe importante presente in ogni progetto me la chiami ‘R’ e basta??!!!
    Possibile che i programmatori di Google, che pure hanno un’ottima fama, non diano dei nomi significativi a classi e campi??
    Oltre tutto è una classe statica e non posso usarla attraverso una variabile con un nome decente.
    Che cosa dovrei capire io guardando la reference che si trova qua: http://developer.android.com/reference/classes.html#letter_R ?

    @Carmelo
    Ci sono tanti progetti, non solo Java ovviamente, di complessità notevolissima ma molto più stabili a livello di API di Android, ad esempio Spring, le cui API sono praticamente invariate dalla versione 2.0 (anno 2006)

  • # 10
    Tommaso
     scrive: 

    “E’ più semplice e produttivo programmare per Windows Phone 7 che non per Android.

    Oddio l’ho detto.”

    D’altra parte Android è quello messo peggio nel mercato portatile, ed è messo peggio anche di diversa roba desktop (.NET è un’ambiente che non uso ma ammiro, OSX è sempre stato stabile e coerente) e IOS è un esempio eccellente di come si fa un sistema operativo, dai pallini della GUI fino alla gestione dei thread.

    Sarà che google campa con la roba gratis invece che la roba fatta bene?

    Oddio l’ho detto :P

    @autore: bel rant :P

  • # 11
    Luca Azzone
     scrive: 

    A confronto con lo sviluppo per iOS che si può dire? Qualcuno che ha sviluppato per entrambi può fare un confronto?

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

    Al momento mi manca iOS (ho studiato già qualcosa, comunque) per poter fare un confronto concreto con tutte le piattaforme mobile più quotate. Ci vorrà qualche mese: giusto il tempo che mi venga commissionata un’applicazione per questo s.o., costringendomi a sbatterci la testa.

    Preciso che il progetto Android è stato sviluppato da un’azienda, che dopo un paio d’anni è stata acquisita da Google. Quest’ultima s’è, quindi, ritrovata un progetto già in corso d’opera, sebbene siano passati ormai 6 anni da quando è nelle sue mani (IMHO il tempo per dargli una sistema direi che si sarebbe stato).

    @Cla: non mi sembra che, dal punto di vista tecnico, ci saranno eclatanti novità con le nuove versioni. Il framework, insomma, è quello, e ormai viene esteso alla bisogna, ma non riscritto.

    @Giovanni: non bisogna confondere l’aspetto commerciale (successo di mercato) da quello prettamente tecnico. L’articolo è incentrato su quest’ultimo, e permettimi: Android è ben in basso nella classifica della “perfezione” (qualunque cosa tu voglia intendere con ciò).

    @Carmelo: alcune risposte le hai già avute. Un esempio di ciò che chiedi lo trovi già lontano nel tempo: http://en.wikipedia.org/wiki/Turbo_Vision Non bisogna, insomma, scomodare progetti nuovi, tanto meno le GUI, per trovare un framework OOP scritto bene da punto di vista ingegneristico.

    Riguardo all’ultima questione, View non dovrebbe nemmeno esistere, per lo meno col carico di responsabilità che ha.
    Tanto per fare un esempio, immagino una classe “AbstractGraphicControl”, che discende da Object, e che serve a renderizzare elementi grafici. Una classe AbstractUserControl, che discende da GraphicControl, che aggiunge le responsabilità di gestire gli input provenienti dagli utenti.
    Si potrebbe, a questo punto, far discendere TextView da AbstractGraphicControl, ma anche roba come LineView, RectangleView, ecc..
    Creare un’AbstractButton (da AbstractUserControl) per tutti gli oggetti che sono “cliccabili” (Button, Check, Radio, Toggle, ecc.), AbstractEdit (sempre da AbstractUserControl) per tutti gli oggetti “editabili”, ecc.
    E’ soltanto un esempio, ma dovrebbe rendere bene il concetto.

    @Andrea Del Bene: non posso che concordare.

  • # 13
    Antonio Barba
     scrive: 

    @Cesare: visto che “essere cliccabile” non è un modo di esistere, ma una proprietà opzionale, questa dovrebbe essere implementata come interfaccia astratta. Quindi direi qualcosa come ILookMaClickable :-D

    Quindi se vuoi poter cliccare su un Frame fai una bella class MioFrame extends Frame implements ILookMaClickable

    La classe Button non dovrebbe nemmeno esistere, perchè non esiste “un solo modo di essere Bottone”, ma potenzialmente qualsiasi oggetto grafico potrebbe ricevere (e reagire a) l’evento OnClick.
    Se vuoi implementare un paio di comportamenti standard, come lo “stato cliccato”, puoi tranquillamente aggiungere un’altra interfaccia ILookPaHavestate, che implementa funzioni come “setCurrentState”. Uno “State” a sua volta può essere una collection di coppie “proprietà”,”valore”, che servirebbero per (eventualmente) cambiare colore/forma/dimensioni/ecc… dell’eventuale oggetto.

    Quindi avrei (pseudo-Java)

    State cliccato = { “cliccato”, “color”, “rosaShocking” };
    State noncliccato = { “noncliccato”, “color”, “bluCobalto” };

    class MioBottone implements Frame extends ILookPaHavestate, ILookMaClickable
    {
    public MioBottone() { addState(cliccato); addState(noncliccato); }

    // ILookPaHavestate
    @Override
    protected void addState(State s) { mPropertiesDictionary.add(s.mName, s.mPropertyName, s.mPropertyValue); }

    // ecc…

    // ILookMaClickable
    protected void onClickEvent(ClickEvent e) {
    if (e.mType == CLICK_START) setState(“cliccato”);
    else setState(“noncliccato”);
    }

    // ecc…
    }

    In questo modo puoi trasformare in “Bottone” tutto quello che vuoi, in particolare puoi creare un bottone contenete un layout complesso…

    Comunque, questo sistema è usato da molti toolkits, non me lo sono inventato adesso su due piedi, ed essendo totalmente customizzabile si presta benissimo ad una generazione automatica del codice (o addirittura al caricamento di layout a runtime tramite reflection).

  • # 14
    TheMac
     scrive: 

    Io programmo (poco e malissimo) per iOS. E Ho anche una certa esperienza che va da Cobol a Abap/4 passando per Java e .Net.
    iOS SDK e’, attualmente, parecchio indietro rispetto alle WinApi (per rimanere sulle basi), cosi’ come Xcode e’ anni indietro rispetto ai vari Visual o anche Eclipse .
    Questo per rispondere a chi chiedeva notizie su iOS che, comunque ha l’enorme pregio di lavorare su un “parco macchine” che e’ enorme ma non differenziato come quello di Android : in pratica hai Iphone3g, Iphone3gs e iPhone4 e poi iPad1/2. Stop. Fantastico.
    In ogni caso anche su iOS quasi tutto discende da una unica classe, NSObject :)
    Per cio’ che riguarda Android alla fine anche google ha dovuto fare un suo super-fork, dividendo gingerbread (Smartphone) da Honeycomb (Tablet). Male, ora voglio vedere i futuri dispositivi 4,2″ o 5″ cosa monteranno.
    E, in ogni caso, per cio’ che riguarda le versioni di api che si susseguono io sono sempre dell’idea che basti lasciare tutto il vecchio invariato (java e il deprecaggio selvaggio insegnano). Per tutte le nuove funzionalita’, quando possibile, si aggiungono NUOVI metodi alle vecchie classi (anche qui java ha fatto scuola).
    E’ brutto, ma funziona, sempre ;)

    TheMac

  • # 15
    zephyr83
     scrive: 

    Come al solito ho riconosciuto l’articolo di Cesare dal titolo :D
    Per il resto niente da dire, nn ne capisco niente di tutto ciò ma ho sempre sostenuto che android ha avuto successo grazie al nome di google! C’erano già da prima soluzioni più valide che nn hanno avuto successo! Android di pecche ne ha tante e questa nn è certo da poco, ma nel complesso ha permesso a molti di trarre vantaggi (sia utenti che sviluppatori). Speriamo solo migliori in futuro visto che la concorrenza nn sta a guardare!
    Invece nn capisco cosa c’è da stupirsi in certe sparate di Andy Rubin…..per caso la concorrenza si comporta diversamente? :D

  • # 16
    Elena
     scrive: 

    Ciao, sono una sviluppatrice Android da 2 anni e non sono d’accordo con la tua critica. Entrando nel merito:

    CAMBIO NOME COSTANTE
    Tra FILL_PARENT e MATCH_PARENT cambia poco, visto che si tratta di un intero (-1)…. non credo che cambiarne il nome mini alla stabilità del framework nel suo insieme…

    CLASSE VIEW
    Secondo me non hai spiegato bene le tue ragioni. Trovo abbastanza naturale che discenda da Object… non vedo motivo di avere altre astrazioni nel mezzo. Non mi sembra una god class quanto piuttosto una buona astrazione del concetto di view, che in una interfaccia ovviamente ha molte responsabilità, e che secondo me sono riusciti a rendere versatile e ben costruita.

    TEXT VIEW
    Non è che solamente perchè l’oggetto ha molte funzionalità, istanziarlo significa occupare + memoria o cosa…. immagino che la scelta dei sviluppatori sia stata questa: visto che di fatto è vero che sono la stessa cosa, però concettualmente vengono usati in modo diverso nella UI (hanno proprio un ruolo diverso) assegnamogli 2 classi al posto del classico flagghetto boolean “editable”.

    BUTTON
    Secondo me l’unica vera pecca che riguarda i Button non l’hai detta, cioè il fatto che ImageButton non sia un Button, per cui spesso quando si cambia idea e si sostituisce uno con l’altro si incorre in una noiosa ClassCastException.

    ORIENTATION
    Con un flag nella activity è possibile specificare se si vuole distruggere l’activity alla rotazione oppure usare il metodo onConfigurationChanged

    Secondo me questi 8 anni sono stati sufficienti a creare un framework di sviluppo grafico tra i + usabili e versatili al mondo.
    Dalla mia esperienza, che ormai si può dire abbastanza completa, le pecche sono:
    - gli ImageButton che non ereditano da Button.
    - il background di un componente viene considerato alla stregua del contenuto nel calcolo delle dimensioni
    - i content provider: sono limitanti e potevano essere fatti meglio.
    - il fatto che il touch down su un componente si mangi tutti gli eventi successivi, per cui solo lui riceve l’evento di touch move e touch up.

    E qualche altra cosa, tipo le animazioni un po’ trascurate.

    Ma i vantaggi sono geniali e infiniti secondo me.
    - La classe R per accedere alle risorse in modo statico
    - le 9 patch
    - la grafica da xml con preview da eclipse
    - il log
    - il sistema dei layout per avere interfacce adattabili a diversi schermi
    - i service e i thread
    - il plugin x eclipse nel suo insieme
    - lo hierarchy viewer

    E per finire quello che amo di + è che, secondo me, hanno messo la semplicità davanti agli occhi dell’utente meno esperto e la potenza per chi vuole approfondire un po’.

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

    @Antonio: a prescindere dal fatto che tu voglia utilizzare una classe astratta o un’interfaccia, il punto è che devi mettere a disposizione del programmatore una classe Button, senza egli sia costretto ogni volta a implementare l’interfaccia o la classe astratta. Diciamo che da un framework mi aspetto che ci sia.

    A parte questo, è vero che definendo un’interfaccia come ILookMaClickable puoi rendere cliccabile qualunque classe. Rimane, comunque, una tua scelta se farlo o meno, a seconda delle tue esigenze. View, invece, si fa già carico di questa responsabilità, e la “trasmette” a tutti i suoi eredi, che la utilizzino o meno.

    La gestione degli stati ormai è un must per qualunque toolkit/framework, come giustamente riporti. Comunque dovresti dare un’occhiata a quello che offre la concorrenza… O:-)

    @TheMac: è normale che, per un linguaggio a oggetti, qualunque classe derivi dalla classe “madre”, qualunque essa sia (NSObject per Objective-C; Object per Java, C#, Python; object per Delphi; ecc.).

    Quello che volevo dire è che quando si progetta una gerarchia di classi, s’individuano insiemi di responsabilità che “confluiscono” poi una determinata classe. E così via, man mano si forma la gerarchia, come nell’esempio che ho fatto nel commento #12.

    Non si parte da una classe enorme, come View, che racchiude in sé già in partenza tante responsabilità.

    @zephyr83: qualunque oste ti dirà che il suo vino è buono. E’ dopo averlo assaggiato poi scoprirai la verità. ;)

    @Elena: vado per punti, ma mi permetto di farti notare che l’articolo è incentrato su quei tre concetti esposti, e non è una recensione di Android per gli sviluppatori.

    CAMBIO NOME COSTANTE
    Tra FILL_PARENT e MATCH_PARENT cambia poco, visto che si tratta di un intero (-1)…. non credo che cambiarne il nome mini alla stabilità del framework nel suo insieme…

    Non cambia nulla, ma ricorda che è il concetto di stabilità a essere in discussione. Quella costante è rimasta in piedi per 7 versioni e con l’8a hanno deciso di chiamarla MATCH_PARENT. Quale “stabilità” ti può garantire una scelta del genere?

    CLASSE VIEW
    Secondo me non hai spiegato bene le tue ragioni. Trovo abbastanza naturale che discenda da Object… non vedo motivo di avere altre astrazioni nel mezzo. Non mi sembra una god class quanto piuttosto una buona astrazione del concetto di view, che in una interfaccia ovviamente ha molte responsabilità, e che secondo me sono riusciti a rendere versatile e ben costruita.

    L’ho spiegato alla fine del commento #12. E’ una questione di astrazione e modellazione della gerarchia di oggetti.

    TEXT VIEW
    Non è che solamente perchè l’oggetto ha molte funzionalità, istanziarlo significa occupare + memoria o cosa…. immagino che la scelta dei sviluppatori sia stata questa: visto che di fatto è vero che sono la stessa cosa, però concettualmente vengono usati in modo diverso nella UI (hanno proprio un ruolo diverso) assegnamogli 2 classi al posto del classico flagghetto boolean “editable”.

    Come spiegato nell’articolo, se devo stampare a video una semplice scritta, non ho certo bisogno di portarmi dietro un intero editor. Un’etichetta e un editor sono due oggetti con responsabilità molto diverse, e tali dovrebbero essere le classi.

    A parte questo, per implementare le funzionalità di editing TextView farà sicuramente ricorso a diverse variabili d’istanza (che occupano memoria), e richiamerà diversi metodi per l’inizializzione e/o durante il normale funzionamento (che consumano per lo meno cicli di clock) anche quando non serve nessuna funzionalità di editing.

    E’ una questione di ottimizzazione e buon design, come già detto.

    BUTTON
    Secondo me l’unica vera pecca che riguarda i Button non l’hai detta, cioè il fatto che ImageButton non sia un Button, per cui spesso quando si cambia idea e si sostituisce uno con l’altro si incorre in una noiosa ClassCastException.

    Non è per questo motivo che ho citato Button, ma per una questione di design e ottimizzazione, come per il caso della TextView.

    Oltre al fatto, sempre come già detto, View implementa le funzionalità tipiche di un oggetto cliccabile. Quindi View sarebbe stata sicuramente una classe migliore da cui partire per implementare Button.

    ORIENTATION
    Con un flag nella activity è possibile specificare se si vuole distruggere l’activity alla rotazione oppure usare il metodo onConfigurationChanged

    Vero, ma devi sempre gestire tu manualmente il cambio di layout. Il sistema non si occupa di invalidare tutto e ricostruire il display.

    Sul resto ci sarebbe da discutere, ma lo scopo dell’articolo, come già detto, è diverso da quello che hai inteso.

    Comunque penso che sperimentare con quanto offerto dalla concorrenza potrebbe giovarti. Un sano confronto è utile per capire se, ad esempio, è vero o no che Android offre uno dei framework più versatili al mondo. Secondo me avresti delle sorprese non da poco. O:-)

    P.S. Bello l’avatar. Miyazaki rulez. 8)

  • # 18
    Alex del viero
     scrive: 

    Quello che manca veramente e’ un sistema di aggiornamento automatico all ultima versione per tutti i dispositivi.
    Ovviamente con la possibilita di scalare asseconda delle prestazioni del dispositivo.
    Ok ci son tante cosine che non vanno pero’ se fosse aggiornabile si potrebbero cancellare pian piano le magagne.
    Linux, che io uso e apprezzo, non sono sicuro che sia il massimo per creare una piattaforma per il mobile.
    Un microkernel stile qnx o beos(haiku) lo vedrei meglio (per dirne 2 a caso).

  • # 19
    Antonio Barba
     scrive: 

    Linux non c’entra niente. Per come è progettato Android, basta impiantare la Dalvik sopra un kernel qualsiasi e in ciò hanno fatto una scelta molto saggia.

    Linux ha ovviamente tutta una serie di difetti, ma qui si mostravano i difetti che stanno sulle API pubbliche, quelle esposte al programmatore e quindi tutto ciò che gira “sopra” la Dalvik VM.

  • # 20
    Zerho
     scrive: 

    Amen fratello Cesare!

  • # 21
    Fabio
     scrive: 

    Sono uno sviluppatore a cui è stata commissionata un applicazione android. Ho avuto l’impressione che lo sviluppo sia inutilmente complicato, ma prima di leggere questo articolo ero convinto che la colpa fosse solo mia. Mi fu più facile sviluppare su Java MIDP e persino su Pocket PC..

  • # 22
    Dario Solera
     scrive: 

    La mia opinione è che Google non è abituata a rilasciare API/SDK così estesi e complessi. Il loro modello interno è estremamente snello e su ogni progetto non mettono mai più di tot persone (è come se ogni progetto fosse una sorta di startup – e questo ha dei pregi e dei difetti).

    Il punto è che Google di solito rilascia tante piccole nuove versioni molto frequentemente, prendendosi la libertà di fare tutte le modifiche che ritiene necessarie. Questo in un SDK così esteso e così diffuso non funziona, come giustamente evidenziato nell’articolo.

    Per fare un contro-esempio, .NET è molto più stabile per quanto riguarda le API e non succede praticamente mai che le cose vengano cambiate/rinominate/eliminate di punto in bianco. Al più le marcano come obsolete ma per N versioni continuano a essere supportate. D’altronde MS basa il suo successo sugli sviluppatori e, forse, ha capito come si fanno gli SDK.

  • # 23
    MaxArt
     scrive: 

    Sto affrontando il mondo della programmazione Android da poco, e devo ammettere che anche a me il framework è parso un po’ confusionario ed anti-intuitivo per un programmatore di esperienza, ma… Mi sono accorto che semplicemente stavo fondando le mie critiche in base alle mie esperienze di programmatore desktop, e questo approccio, con Android, è *sbagliato*. E a me pare che Cesare stia percorrendo la stessa strada.

    Alcune scelte sono state fatte esplicitamente tenendo a mente il tipo di dispositivi su cui dovrà girare l’applicazioni, quindi giungendo a compromessi strutturali.

    Certe critiche sono anche piuttosto gratuite, come quella sulla View, che di fatto È tipo l’AbstractGraphicObject, anche se non è una classe astratta. In pratica nessuno istanzia le View, o anche le ViewGroup, ma le sue classi discendenti.

    La questione di MATCH_PARENT e FILL_PARENT è trascurabile, direi, visto che FILL_PARENT non è stata mai dismessa come costante e si può usare ancora anche nei layout XML, per cui MATCH_PARENT è solo un sinonimo che può usare chiunque voglia creare progetti per Froyo e successivi. E secondo me ha un nome più significativo perché se qualcuno mi dice “fill parent” mi aspetto che si estenda sino a ricoprire interamente le dimensioni del nodo genitore. Cesare non è d’accordo ma la mia, al pari della sua, è un’interpretazione personale e come tale va considerata. La stabilità, qui, non c’entra proprio nulla.

    Sul fatto del TextView è vero che ci sono delle variabili d’ambiente che occupano memoria (meno sicuro sui cicli di clock usati nel costruttore, oltre ad un minimo trascurabile: bisognerebbe vedere il sorgente), ma è anche vero che così facendo si lascia la possibilità allo sviluppatore di creare delle implementazioni di testo che permettano l’editazione ma che NON si comportino come EditView, e secondo me non è cosa da poco.
    Di contro, ma forse mi è sfuggito, non mi pare che qualcuno si sia mai lamentato delle scarse performance delle TextView: magari perché non si usano mai in contesti dove le performance sono fondamentali?

    Se vogliamo mettere immagini in un pulsante, ci sono già gli strumenti disponibili in maniera semplice:
    http://www.anddev.it/index.php?topic=151.0
    Per il resto ci si può sempre sbizzarrire a creare proprie implementazioni di bottoni.

    Per il cambio di orientamento, sicuramente desterà sgomento il fatto che l’Activity venga distrutta e reinizializzata, soprattutto se si considera che è il comportamento di default ma, oltre alle note di Elena, questo è un processo che viene effettuato anche per altre modifiche importanti, come un cambio di lingua, per cui la ripartenza dell’applicazione risulta ovvia. Ciò è legato al modo in cui vengono concepite le risorse in Android, categorizzate per una serie di parametri tra cui, appunto, orientazione e lingua.
    Inefficiente? Forse. Ma si può circonvenire (la reimpostazione di un layout è roba di una riga di codice), e non è che l’applicazione riparta proprio da zero ogni volta: i campi mantengono in automatico i loro contenuti e noi possiamo salvarci i nostri bravi Bundle di informazioni prima della distruzione dell’attività.

    La classe R si chiama così per brevità, dato che viene presumibilmente usata spesso.

    Insomma, ci sono tanti aspetti dello sviluppo di Android che lasciano effettivamente perplessi, e anche in questo caso i punti possono rimanere perché non voglio assolutamente elevare le mie risposte a qualcosa più di ipotesi, ma quello che farebbe veramente piacere è che fosse proprio qualcuno in forza al progetto Android a rispondere. Sarebbe molto interessante se venisse fatta proprio un’intervista in merito a questo.
    Appunti Digitali è una testata giornalistica che si presta molto, perché non farci un pensierino?

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

    @MaxArt: rispondo sempre per punti.

    Sto affrontando il mondo della programmazione Android da poco, e devo ammettere che anche a me il framework è parso un po’ confusionario ed anti-intuitivo per un programmatore di esperienza, ma… Mi sono accorto che semplicemente stavo fondando le mie critiche in base alle mie esperienze di programmatore desktop, e questo approccio, con Android, è *sbagliato*. E a me pare che Cesare stia percorrendo la stessa strada.

    Nei commenti avevo scritto che attualmente sviluppo per Windows Phone 7 e Android, e prossimamente per iOS (ho già studiato qualcosa, ma non m’è ancora arrivata una richiesta di sviluppo di un’applicazione completa per approfondire questa piattaforma).

    Alcune scelte sono state fatte esplicitamente tenendo a mente il tipo di dispositivi su cui dovrà girare l’applicazioni, quindi giungendo a compromessi strutturali.

    Lo stesso discorso dovrebbe valere per gli altri player, che però non soffrono di questi compromessi, e offrono framework ben progettati, con diverse classi (ma anche interfacce) che modellano l’intero ecosistema.

    Certe critiche sono anche piuttosto gratuite, come quella sulla View, che di fatto È tipo l’AbstractGraphicObject, anche se non è una classe astratta. In pratica nessuno istanzia le View, o anche le ViewGroup, ma le sue classi discendenti.

    Non è così. Vedi commento #12. Attualmente View è quasi assimilabile a una classe (concreta) Button.

    La questione di MATCH_PARENT e FILL_PARENT è trascurabile, direi, visto che FILL_PARENT non è stata mai dismessa come costante e si può usare ancora anche nei layout XML, per cui MATCH_PARENT è solo un sinonimo che può usare chiunque voglia creare progetti per Froyo e successivi. E secondo me ha un nome più significativo perché se qualcuno mi dice “fill parent” mi aspetto che si estenda sino a ricoprire interamente le dimensioni del nodo genitore. Cesare non è d’accordo ma la mia, al pari della sua, è un’interpretazione personale e come tale va considerata.

    Senza dubbio.

    La stabilità, qui, non c’entra proprio nulla.

    Ne hanno avuto di tempo per pensarci. Comunque concordo che sia una sciocchezza, specialmente rispetto alle 13 versioni di API.

    Sul fatto del TextView è vero che ci sono delle variabili d’ambiente che occupano memoria (meno sicuro sui cicli di clock usati nel costruttore, oltre ad un minimo trascurabile: bisognerebbe vedere il sorgente),

    Certamente, ma un editor è decisamente più complesso di un banale controllo “label”, per cui anche senza codice davanti penso di non sbagliare se affermo che consumo di memoria e carico sul processore saranno più consistenti (sempre rispetto a un controllo label implementato discendendo direttamente da View, e che realizza solo quello).

    ma è anche vero che così facendo si lascia la possibilità allo sviluppatore di creare delle implementazioni di testo che permettano l’editazione ma che NON si comportino come EditView, e secondo me non è cosa da poco.

    AbstractEditView.

    Di contro, ma forse mi è sfuggito, non mi pare che qualcuno si sia mai lamentato delle scarse performance delle TextView: magari perché non si usano mai in contesti dove le performance sono fondamentali?

    Dipende dall’applicazione. Forse a te non è capitato di realizzarne con layout molto complessi, con numerose TextView presenti anche all’interno di altri controlli (ad esempio ListView con pannelli informativi per ogni item).

    Se vogliamo mettere immagini in un pulsante, ci sono già gli strumenti disponibili in maniera semplice:
    http://www.anddev.it/index.php?topic=151.0
    Per il resto ci si può sempre sbizzarrire a creare proprie implementazioni di bottoni.

    Non lo metto in dubbio. Comunque altre piattaforme offrono meccanismi di gran lunga più flessibili, che riducono nettamente la necessità di scrivere altre classi / componenti.

    Per il cambio di orientamento, sicuramente desterà sgomento il fatto che l’Activity venga distrutta e reinizializzata, soprattutto se si considera che è il comportamento di default ma, oltre alle note di Elena, questo è un processo che viene effettuato anche per altre modifiche importanti, come un cambio di lingua, per cui la ripartenza dell’applicazione risulta ovvia. Ciò è legato al modo in cui vengono concepite le risorse in Android, categorizzate per una serie di parametri tra cui, appunto, orientazione e lingua.

    Ho riportato la rotazione del display perché è un’operazione di gran lunga più comune rispetto al cambio di lingua (quante volte lo farà un utente, con le applicazioni per giunta aperte?).

    Inefficiente? Forse. Ma si può circonvenire (la reimpostazione di un layout è roba di una riga di codice), e non è che l’applicazione riparta proprio da zero ogni volta: i campi mantengono in automatico i loro contenuti e noi possiamo salvarci i nostri bravi Bundle di informazioni prima della distruzione dell’attività.

    Certamente, la scappatoia c’è. Non comodissima, ma c’è.

    La classe R si chiama così per brevità, dato che viene presumibilmente usata spesso.

    Togli pure il presumibilmente: inflating e la ricerca di view per ID di risorsa sono il pane quotidiano per lo sviluppatore Android, e ti complicano non poco la vita.

    Senza voler scatenare polemiche su confronti (che al momento non voglio fare), ti riporto a titolo puramente dimostrativo un esempietto di come normalmente si fa la stessa cosa da “altre parti”:

    MediaPlayer.Play();

    Dove MediaPlayer è il nome assegnato all’istanza del componente (MediaElement, nello specifico) che è stato definito nel file (XML) che descrive il layout della pagina in cui dev’essere visualizzato.

    Come vedi, si referenzia immediatamente, citandolo soltanto per nome.

    Ripeto: è soltanto un esempio (perché ci sarebbe altro da dire), che serve soltanto come “reality check” per uno sviluppatore che lavora soltanto su Android e che combatte tutti i giorni con quanto scritto sopra, così può vedere come si fa, invece, su altre piattaforme.

    Per essere chiari: è una breve parentesi che si apre e si chiude qui, per pura conoscenza. L’articolo parla d’altro, e vorrei che si continuasse sull’argomento. ;)

    Insomma, ci sono tanti aspetti dello sviluppo di Android che lasciano effettivamente perplessi, e anche in questo caso i punti possono rimanere perché non voglio assolutamente elevare le mie risposte a qualcosa più di ipotesi, ma quello che farebbe veramente piacere è che fosse proprio qualcuno in forza al progetto Android a rispondere. Sarebbe molto interessante se venisse fatta proprio un’intervista in merito a questo.

    Certamente.

    Appunti Digitali è una testata giornalistica che si presta molto, perché non farci un pensierino?

    Passo la palla al Mega Direttore Arcangelo. ;)

  • # 25
    zephyr83
     scrive: 

    Sono sempre stato un sostenitore dell’ottimizzazione e del lavoro fatto al meglio :D I punti elencati da Cesare mi paiono condivisibili, magari all’atto pratico alcune cose incidono poco però se si può farle meglio perché nn migliorarle? Effettivamente fa strano anche a me leggere alcune cose ma da utilizzatore di android nn mi stupiscono! Riguardo alla rotazione del display in passato era la principale causa di crash di alcuni programmi :D Nn so se dipende da quello scritto ma capitava troppo spesso per i miei gusti.
    Ma quanto scritto si riflette su un sistema instabile? a me android pare tutto meno che instabile e al massimo crasha qualche applicazione (cosa che però succede di rado). A titolo di confronto leggo spesso sui forum molto bene di windows phone come sistema ma non delle relative applicazioni realizzate da terzi che nn risultano esser sullo stesso livello del sistema operativo. E questo nonostante un SDK fatta meglio di quella di Android!

  • # 26
    Alessio Di Domizio
     scrive: 

    Appunti Digitali è una testata giornalistica che si presta molto, perché non farci un pensierino?

    Passo la palla al Mega Direttore Arcangelo. ;)

    Il mega direttore arcangelo è occupato con Bonolis a fare il caffè, provo a rispondere io.

    Non sono sicurissimo che Google ci darà ascolto ma possiamo provarci. Collegatevi qui col vs account google: https://docs.google.com/document/d/1D3FUybXsr2ZbPcM5TSwLj580URnYIMwiXv_Uwbja07M/edit?hl=it

    Quindi inserite le vostre domande. Selezioneremo quelle più rilevanti e le proporremo al contatto che (spero) riusciremo a rintracciare in Google.

  • # 27
    Drizzt
     scrive: 

    “La classe R si chiama così per brevità, dato che viene presumibilmente usata spesso.”

    Direi che una frase del genere permette di distinguere immediatamente un programmatore da uno che per sbaglio e’ inciampato su una tastiera.

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

    Per favore, non facciamo deragliare quest’articolo nell’n-esimo flame.

    @zephyr83: la “stabilità” di cui s’è parlato era quella delle API, e ben 13 versioni (addirittura due API level diverse per la stessa major version) penso siano piuttosto eloquenti in merito.

    @Alessio: per me rimangono in piedi i tre punti che ho scritto nell’articolo. ;)

  • # 29
    Alex del viero
     scrive: 

    @Cesare
    “Quindi TextView racchiude un intero editor di testo, che non è immediatamente abilitato, mentre la classe EditText si occupa semplicemente di quest’aspetto, come ci conferma dall’apposita…”

    Ma siamo sicuri che in compilazione si porti dietro l’editor? mi sembra strano , penso che la classe dipenda da come viene chiamata (polimorfismo?).

    @Antonio Barba

    Linux ha diversi problemucci sui cellulari.
    - e’ troppo lento a partire! (sui modelli base riavviare android e’ peggio del riavvio di windows xp dopo 2 anni)
    - il sistema dei driver richiede la ricompilazione ad ogni
    aggiornamento di kernel (il maggior problema per i cuochi di rom)
    - La gestione multimediale e’ complessa. I programmatori di android hanno avuto molti grattacapi a creare il layer grafico e han fatto un mezzo porcaio ovviamente.

    Anche se mi piace abbastanza java dal punto di vista creativo (cioe’ dal lato programmazione) non lo trovo il massimo per l ottimizzazione anche con dalvik.

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

    Tutto il codice del framework di Android è già compilato, e TextView ingloba tutto l’occorrente per implementare un editor.

    Il polimorfismo viene usato, e difatti TextView si differenza da View ridefinendo alcuni metodi virtuali per modellare il nuovo comportamento.

  • # 31
    Gianrico
     scrive: 

    Io sapevo che Android usa un approccio incrementale nella API e che le applicazioni vecchie sono compatibili con le nuove versioni una volta definito minSdk nel manifest (al di la della genialata del FILL_PARENT, MACH_PARENT).

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

    Sulla carta è così. Ma nessuno utilizza l’API Level 1 per realizzare applicazioni compatibili con tutti i dispositivi. :P

  • # 33
    zephyr83
     scrive: 

    @Alex del viero

    Non è linux che ha quegli inconvenienti, è Android, è ben diverso :)
    _Nn ricordi quanto erano lenti ai tempi anche symbian e windows mobile ad avviarsi (soprattutto il primo)?
    _Quello dei driver è appunto un problema per i “cuochi” ma nn mi pare in ogni caso un “problema”.
    _Colpa solo di android :) su maemo ad esempio tutti sti problemi nn ci sn stati!

  • # 34
    Alanford
     scrive: 

    Bellissimo articolo come sempre!!

    Non essendo un programmatore mi è venuto questo dubbio.

    Android girando su una VM CON JIT sarà comunque sempre più lento (o più pesante)a parità di hardware di qualsiasi altro Os.

    oppure ho scritto una castroneria e non centra niente

    Se fosse riscritto da zero senza VM non sarebbe più efficente?

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

    Dipende da come sviluppi le applicazioni.

    In teoria potresti utilizzare l’NDK per realizzarle interamente in C/C++ (ma anche altri linguaggi, come FreePascal, ad esempio), a parte una microscopica parte di interfacciamento alla VM necessaria per passare il controllo al codice nativo (tramite le JNI).

    Quindi avresti prestazioni mediamente migliori (anche se una JVM moderna, come quella di Java 7, è equiparabile al C), ma tempi di sviluppo decisamente più lunghi (soprattutto perché avresti a che fare coi tipici bug di linguaggi non-managed, che possono essere veramente molto rognosi). Oltre ai bug dell’NDK e la scarsa documentazione. :D

    Per cui è MOLTO meglio evitare.

    Chiuso OT. :P

  • # 36
    Alanford
     scrive: 

    :) cristallino
    Mi sa mi sa che devo leggermi qualche libricino come finisco la casa :)

  • # 37
    alex del viero
     scrive: 

    @zephyr83

    un problema dei cuochi e’ un problema degli utenti!
    non comprerei mai un cellulare che non e’ supportato da community.
    Le case madri dimenticano i ” vecchi ” modelli dopo pochi mesi e
    ti ritrovi dopo un anno con un cell 2o3 versioni piu’ vecchio
    dell attuale.
    Forse anche le case produttrici farebbero qualche upgrade in più
    se non gli costasse molto tempo cucinare le rom aggiornate.

  • # 38
    alex del viero
     scrive: 

    @Alanford

    diciamo che:
    Vero che cmq c’e’ una maggiore occupazione di risorse.
    vero anche che parte delle operazioni di flusso son più lente

    però l ottimizzazione del runbyte e’ veramente notevole e
    la maggior parte delle operazioni onerose chiamano librerie
    native ultraottimizzate.

    x semplicità si potrebbe pensare a java come a una lista di cose
    da fare che poi vengono fatte esternamente. (ora qualche filosofo della programmazione mi ucciderà lo so…)

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

    Tutti i linguaggi fanno ricorso a librerie, scritte magari in un linguaggio diverso. Non c’è nessuna filosofia in ciò, ma una sana pragmaticità.

    Riguardo ai telefoni con versioni diverse purtroppo la situazione è quella che hai descritto, ed è il motivo per cui il mercato Android è così frammentato. Giusto per essere chiari, io NON posso sviluppare l’API Level 13, che è l’ultima in assoluto, ma nemmeno con la 10.

    Questo se tengo al mercato (e da professionista NON posso non considerarlo); se, invece, sviluppo per gioco, allora il problema non esiste e posso perdere tutto il tempo che voglio sulla versione che mi aggrada.

  • # 40
    zephyr83
     scrive: 

    @alex del viero

    Ok, anche io nn voglio un telefono non supportato dalla comunità ma sto discorso nn vale solo per android! era così anche prima ai tempi di windows mobile! il mio vecchio htc s310 l’ho aggiornato a WM 6.1 grazie a quelli di xda nn ad HTC. Anche a quei tempi c’erano per lo più problemi con i driver per aggiornare i telefoni! Quindi nn è tanto questione di linux o non linux.

    @Cesare Di Mauro

    Che intendi quando dici che nn puoi sviluppare l’API Level 13? Intendevi CON l’API level 13? è un discorso relativo al numero di terminali da supportare? da che API Level partiresti? Chiedo per curiosità!

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

    Sì, è un discorso di supporto. Se scrivessi applicazioni settando API Level 13, raggiungerei un piccolissimo parco macchine. Per questo parto dalla 7, ma non posso, ad esempio, passare alla 8, perché taglierei una bella fetta di mercato.

    Purtroppo su Android non puoi aggiornare (è a totale discrezione dei produttori) né c’è un’azienda dietro che si occupa di aggiornare TUTTI i terminali. E questo compito non possiamo lasciarlo ai singoli utenti, perché non sono certo tutti smanettoni.

    E’ vero che non c’entra il s.o., e che una situazione simile c’era anche in passato (ma non ricordo che fosse così frammentato il mercato di Windows Mobile / PocketPC), ma al momento con Android la situazione è quella, e ricalca molto i tempi del J2ME (sic!).

  • # 42
    zephyr83
     scrive: 

    Continuo a sostenere che ai tempo di J2ME la situazione era molto ma molto peggiore! :D

    Riguardo a windows mobile il mercato era sicuramente frammentato, oltre ai vari modelli con processori e schermi differenti c’erano anche due categorie distinte, quella dei touch e quella dei non touch. In questo senso una situazione peggiore rispetto android! Però per quanto riguarda la compatibilità con le applicazioni non ci sono mai stati grossi problemi! alcuni programmi che avevo per windows mobile 2003 giravano a distanza di anni anche su windows mobile 6.1….però c’erano sempre ben due categorie di prodotti differenti con quella non touch sempre un po’ bistratta da sviluppatori e produttori!

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

    Esatto: le API di Windows Mobile erano molto stabili. E due categorie di prodotti da considerare non sono tanti.

    E’ vero che la situazione di J2ME era ben peggiore. Senza dubbio.

    Comunque siamo finiti nuovamente OT. :-/

  • # 44
    zephyr83
     scrive: 

    Si come sistema operativo a windows mobile nn ho mai avuto tanto da rimproverargli! era la gestione dell’aspetto telefonico che per me lasciava molto a desiderare. E sicuramente la compatibilità delle applicazioni è sempre stato un punto favorevole di windows (in generale). Però il problema non è tanto far funzionare le vecchie applicazioni sulle nuove versioni del sistema operativo (anche se su android mi sa che ci sn problemi anche in questo caso), ma il contrario! Ovviamente se il produttore non aggiorna il sistema operativo ti attacchi! sto problema c’è cn Android e c’era prima cn windows mobile! Anche se, ad esser sincero, sn decisamente di più i modelli aggiornati con android (anche se cn ritardo) che quelli in passato cn windows mobile (ne venivano aggiornati davvero pochi ma per essere era l’unico che permetteva una cosa del genere ed erano altri tempi)!

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

    L’aggiornamento non era un problema per Windows Mobile, proprio perché le API erano stabili.

    Al più era l’esperienza utente che era diversa con le nuove versioni, ma le applicazioni giravano praticamente su tutti i modelli.

    Su Android non è così, sia perché la politica degli aggiornamenti è a dir poco pessima, sia perché le API non sono stabili, per l’appunto.

    Comunque finiamo sempre OT. Lasciamo perdere i confronti con le altre piattaforme, più o meno nuove, e concentriamoci sul tema dell’articolo. :P

  • # 46
    zephyr83
     scrive: 

    ah bhe lo so che nn era un problema per windows mobile l’aggiornamento, lo era per i produttori :D

  • # 47
    Carmelo
     scrive: 

    Beh Cesare, il confronto con altre piattaforme mi sembra dovuto dato che “stabile” cambia da contesto a contesto. Tu stesso hai portato l’esempio di Spring come riferimento per la stabilità. Sorvolando sul fatto che ci sono state 6 diverse release dal 2010 a oggi (stracciando i numeri dell’sdk di android), avendoci lavorato posso dirti che il cambiamento radicale del sistema di pacchettizzazione delle librerie mi ha creato qualche problema quando ho aggiornato versione. Ma non me ne sono lamentato. Gli aggiornamenti sono inevitabili e non da punire (e da non confondere con instabilità se si aggiunge un alias ad un valore).
    In ogni caso i dati parlano chiaro:
    http://developer.android.com/resources/dashboard/platform-versions.html
    Usa la versione 8 se vuoi avere la quasi totalità di compatibilità, o la settima se vuoi escludere meno del 3%. Le versioni successive magari introducono miglioramenti per i multicore, ma attualmente non mi sembrano così diffusi da giustificare il passo, anche se google giustamente da la possibilità a chi voglia farlo.
    Questo ovviamente è solo il mio parere, e lo esprimo per il dialogo costruttivo che ha instaurato Cesare.

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

    Non sono stato io a citare Spring. :P

    Comunque di quest’argomento ne parlerò meglio nel prossimo articolo, se hai la pazienza da aspettare un paio di giorni. ;)

  • # 49
    LMCH
     scrive: 

    Google potrebbe risolvere il problema alla radice supportando ufficialmente Qt.
    Già adesso c’è un porting in corso (Necessitas) con tanto di installer automatico delle dll necessarie alle varie applicazioni
    solo che è un casino metter su tutto l’ambiente di sviluppo per Android+Qt.

    Se programmate già in C++, con Qt si raggiunge letteralmente il nirvana, se invece NON programmate in C++ perchè “troppo complicato” ecc. ecc. dovreste provare ad usarlo con Qt, è tutta un altra storia rispetto all’uso di altri framework più diffusi ma molto più ostici.

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

    Il C++ personalmente lo evito come la peste. Non mi piace proprio come linguaggio: troppo criptico, la sintassi mi è del tutto indigesta, e poi è un linguaggio enorme che richiede parecchio tempo per essere assimilato adeguatamente con tutto quello che offre.

    Le Qt non mi piacciono molto, ma se dovessi usarle preferirei il binding per Python, PyQt, perché rende la vita più facile anche rispetto al C++; adesso c’è pure un altro binding che si chiama PySide, e sembra rendere ancora più facile la vita a chi ci lavora.

    P.S. Se le Qt sono il nirvana, per altri framework servirebbe coniare un nuovo termine. :D

  • # 51
    Antonio Barba
     scrive: 

    le Qt sono il nirvana relativamente a ciò che offre il mercato in termini di framework C++ multipiattaforma :-)
    Se restringiamo il campo al solo Windows c’è di meglio, ma Android non è Windows :D

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

    http://android.xamarin.com/ O:-)

  • # 53
    Antonio Barba
     scrive: 

    Mono non supporta WPF ]:-)

  • # 54
    Antonio Barba
     scrive: 

    con quel framework usi .Net come linguaggio, ma avrai sempre quella schifezza di TextView pachidermica che avresti in Java, per dire… :-)

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

    Purtroppo lo so, ma in programma c’è un porting di Moonlight per Monodroid, che lo farebbe assomigliare molto a Windows Phone 7.

    Nel frattempo lavorare con C# e il resto di .NET non sarebbe affatto male. :P

  • # 56
    zephyr83
     scrive: 

    quest’ultimo discorso sembra molto interessante :) ho visto che Necessitas “sfrutta” l’ndk di android quindi si possono realizzare applicazioni che accedono direttamente all’hardware (utile soprattutto per programmi multimediali) ma poi aumenta la “frammentazione” e bisogna realizzare la stessa applicazione per più piattaforme hardware! la trovo un’ottima alternativa all’ndk “tradizionale”.
    Con monodroid invece questo inconveniente nn dovrebbe esserci ma a sto punto rispetto all’SDK in java di droid cosa cambia? che si usa c# al posto di java? ma le applicazioni girerebbero su un’altra virtual machine o sempre su quella principale?

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

    Per portare le Qt su Android si deve passare necessariamente dall’NDK, per cui non me ne stupisco.

    Riguardo a Monodroid, il vantaggio è di poter usare C# come linguaggio (molto più comodo di Java), le librerie di .NET (qui il vantaggio è minore: Java è ben messo), e soprattutto riciclare codice comune ad altre piattaforme.
    Ma la cosa più significativa sarebbe il porting di Moonlight, che permetterebbe di realizzare le interfacce usando Silverlight e sfruttando strumenti come Expression Blend (la versione per Windows Phone 7 è gratuita).

    Riguardo a Mono/Droid, non conosco i dettagli dell’implementazione, per cui non so se gira su Dalvik oppure sfrutta l’NDK.

  • # 58
    xan
     scrive: 

    ma chi l’ha scritto questo agglomerato di baggianate?
    1 – tutti gli sdk sono compatibili in avanti. se scrivo un app per android 1.1 sicuramente sarà funzionante su android honeycomb 3.2. il problema è che la mia app non userà mai le funzionalità aggiuntive di android 3.2 pero funzionerà senza problemi

    2 – “FILL_PARENT” vs “MATCH_PARENT”: è vero che hanno aggiunto la seconda come sostituta della prima senza un apparente motivo, la cosa che non si capisce dall’articolo è che un programmatore puo sbattersene e continuare ad usare la prima senza problemi, quindi di fatto da una possibilità in piu (inutile) ma non causa nessun problema.

    3 – la parte sulle view non le commento perche sarebbe un discorso troppo complesso

    4 – getDisplayId le api dicono di non usarla? ma perche cè ancora, facile per garantire il funzionamento delle applicazioni vecchie, un app pensata per android 1.1 che usa getDisplayId su android 3.2 continuerà a funzionare

    perche parlare a vanvera?

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

    Appunto: riflettere e comprendere l’articolo prima di scrivere sarebbe stato meglio…

    1) Ovvio, ma il problema è un altro. L’hai letto l’articolo?

    2) Ovvio anche questo, ma dopo 7 versioni?

    3) Commenta pure (ma prima leggi bene l’articolo).

    4) Secondo te quell’API è stata usata da qualcuno? Hai visto cos’ha riportato l’articolo? Come avresti potuta usarla a quelle condizioni?

    A questo punto forse non ti farebbe male dare un’occhiata anche ai commenti…

  • # 60
    xan
     scrive: 

    1- l’articolo mostra vari problemi, il primo non è un problema anzi è un sintomo di una piattaforma molto seguita

    2- ok, è strano e non ne capisco il motivo, ma quale è il problema? da sdk 8 in poi puoi usare indifferentemente fill o match, e quindi?

    3- la parte delle view non posso commentarla qui perche andrebbe fatto un controllo approfondito. apparentemente il tuo ragionamento non è sbagliato ma secondo me un motivo ci deve essere stato.

    4- ok, cè un metodo che non va usato. ok è poco pulito pero non comporta nulla in stabilità

    5- io programmo api 8 e becco 85% dei device. se proprio voglio prenderli tutti uso api 7 che ne prendo tipo 97%

    6- il problema che i produttori non aggiornano è serio e reale. anche perche bloccano tutto, e su questo sono molto incazzato

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

    1) E molto frammentata, come dimostrato.
    2) Per fortuna che lo dici pure tu che è “strano”. Un po’ di sana progettazione non avrebbe guastato.
    3) Approfondisci pure, non c’è problema: sono qui che aspetto.
    4) Non è quello il problema. Da ciò che hai scritto finora continui a non comprendere il fine dell’articolo (vedi sopra punto 2).
    5) Appunto. Prova a usare l’API Level 10 o, peggio, la 13, e vedi un po’ quanti terminali riesci a raggiungere.
    6) Concordo, ma l’avevo già scritto.

    Comunque cerca di rileggere l’articolo e rifletterci sopra, magari dando un’occhiata ai commenti. Vedrai che ti sarà tutto più chiaro.

  • # 62
    xan
     scrive: 

    ho letto tutto, compresi commenti, e continuo a non essere d’accordo.

    1 – le api che hanno uno share sufficiente per prenderle in considerazione sono: la 7, 8, 10. 3 versioni non mi sembrano eccessive. le altre sono soltanto degli errori statistici. come se non esistessero proprio.

    2 – una cosa strana non significa che sia sbagliata. semplicemente che non ne capisco il motivo. spero ce l’abbia, in ogni caso io posso usare l’una o l’altra costante e non cambia nulla.

    3 – visto che java è tutto per riferimenti cè la possibilità che questo non porti un appesantimento al tutto, inoltre magari in questo modo la dalvik deve istanziare una sola classe invece di 10. ripeto ipotizzo ma chi fa una recenzione deve prendere in considerazione queste possibilità, cosa che te non hai fatto.

    4 – il metodo in questione non possono torglierlo per questioni di compatiblità. non è un errore è una cosa voluta. hanno sbagliato all’inizio a metterlo ma ora se lo tolgono rischiano di rendere inusabili delle vecchie app.

    5 – che uso a fare l’api 13 se è usata solo dallo 0.5% dello share? per quanto mi riguarda è come se non esiste

    6 – intendevo che quello del mancato aggiornamento è l’unico vero problema di android.

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

    1) Non siamo arrivati alla versione 13 a caso, ma dopo un percorso durato un po’ di anni. Immagina chi ha seguito e lavorato con Android cos’ha dovuto fare col passare del tempo. Inoltre se ci sono diverse API level ancora “attive” (che non puoi escludere), è dovuto all’eccessiva fretta di rilasciarne sempre nuove, che ha portato alla situazione attuale.

    2) Appunto: non ne capisci il motivo. Tanto basta.

    3) Non si istanziano n classi se una classe deriva da n-1 classi: l’istanza è sempre una soltanto, come pure una è la Virtual Method Table associata a quella precisa classe. Inoltre la mia non è una recensione (sigh).

    4) Bene, almeno questo finalmente t’è chiaro.

    5) No comment. E per fortuna che hai detto di aver letto articolo e commenti.

    6) Hai detto niente: è concausa della frammentazione di Android. Ed è motivo per cui hai scritto il punto 5).

  • # 64
    xan
     scrive: 

    1 – no, è dovuto al fotto che i produttori dopo aver ricevuto i soldi dai clienti li abbandonano al loro destino. per ipotesi basterebbe che tutti comprassero solo nexus e il problema sarebbe risolto

    2 – che io (e te) non ne capisco il motivo non mi pare sufficiente per dire che la cosa sia sbagliata, comunque ripeto, non comporta nulla.

    in sostanza sono tutti non problemi: al massimo piccole accortezze che potevano essere sistemate ma che comunque non comportano nulla, avere 2 costanti che fanno la stessa cosa o un metodo inutile o altro non comportano nulla

    i problemi del mondo android sono 2:
    1 la mancanza o l’estremo ritardo degli aggiornamenti
    2 l’inesistenza della garanzia di fatto

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

    Allora non lo vuoi proprio capire che la tesi è quella che la progettazione e gestione della piattaforma Android lascia a desiderare, e ti fornito un bel po’ di elementi a riguardo.

    Poi puoi continuare a pensarla come vuoi. Tanto gli errori continueranno a pagarli i programmatori, non i geni che hanno portato a tutto ciò…

  • # 66
    xan
     scrive: 

    …pagarli i programmatori….
    cosa devono pagare?
    pagano il fatto di dover scegliere tra n api?
    pagano il fatto di avere 2 costanti per la stessa cosa?
    pagano il fatto di avere un metodo inutilizzato e inutile?
    pagano il fatto che una view contiene un editor?

    cosa pagano i programmatori? io ancora non l’ho capito

    detto questo posso essere d’accordo che ci siano piccole accortezze che potevano essere sistemate ma è robbetta

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

    De gustibus. L’articolo è chiaro e altri hanno capito. A questo punto, anche dopo tutto questo ping-pong di commenti, il problema non è certo mio…

  • # 68
    xan
     scrive: 

    il mondo è bello perché è vario…

    comunque l’sdk android è gratuito e multipiattaforma, paghi sono 25 dollari per attivare il market

    l’sdk ios costa 99 dollari l’anno (credo) e devi comprarti un mac perche cè solo per osx

    win phone non so

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

    E nemmeno interessa, visto che il tema dell’articolo è un altro…

  • # 70
    SiRioKD
     scrive: 

    @xan

    Xan, non contraddire l’autore del post, altrimenti ti risponde all’infinito pur di avere ragione. Non perdere il tuo tempo.

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

    Ti sarà sfuggito che avevo già lasciato perdere la discussione, poiché non andava avanti.

    A parte questo, se una persona fa un’affermazione e ho elementi per contestarla, lo faccio.

    Che poi a te non piaccia per antipatia, fanatismo, attaccamento al prodotto acquistato, o altro, è un problema tuo.

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.