quale libro per imparare android? [Archivio]

View Full Version : quale libro per imparare android?

Ansem_93

17-08-2011, 13:50

e-commerce84

17-08-2011, 19:17

salve,io vorrei imparare a programmare per android,visto che su amazon c'è lo sconto del 40% su tutti i libri vorrei prendermi una guida.
Quale tra queste 3 mi consigliate?
Sviluppare applicazioni per Android (Guida completa) di Massimo Carli
Android. Guida per lo sviluppatore (Guida completa) di Massimo Carli
Sviluppare applicazioni per Android con HTML, CSS e JavaScript (Informatica) di Jonathan Stark e G. Branca

io ero più orientato sul primo,in quanto è il più recente (2011).

Per iniziare prendi Android. Guida per lo sviluppatore (Guida completa) di Massimo Carli...è ottimo, io lo stò usando e mi ci stò trovando benissimo...poi puoi proseguire con Sviluppare applicazioni per Android

Però una cosa...nota bene che DEVI già conoscere di tuo Java e la logica della programmazione ad oggettti...ho visto varie persone dire che il libro di Carli non è buono come si dice perchè "fornisce il codice senza spiegarlo" e poi si viene SEMPRE a scoprire che queste persone non conoscono Java...questo è un libro che tratta lo sviluppo con il framework di Android...è un libro sul framework e su una specifica tecnologia...non è un manuale di Java...se non hai basi di programmazione devi studiare prima Java e programmazione ad oggetti per fatti tuoi

Ansem_93

17-08-2011, 20:09

e-commerce84

18-08-2011, 00:26

attualmente sto già studiando java infatti.
Ho comunque delle ottime basi di programmazione in pascal.
L'unica cosa è che devo ancora capire come sfruttare al meglio gli oggetti,ma sul loro funzionamento e sulla loro logica so già qualcosa :)
grazie mille per l'aiuto comunque :)

Oddio...sei del 93...Pascal forse lo avrai fatto alle scuole superiori? già quì ti dico che al più avrai visto la punta dell'iceberg della programmazione...in più Pascal è un linguaggio vecchissimo che va bene più che altro per fare qualche esempio di informatica applicata alla matematica...di programmazione OO non ha assolutamente nulla...

Ti consiglio di studiarti per bene un minimo di Java e poi passare ad Android...quantomeno devi arrivare a manegiare con scioltezza i concetti di oggetti, ereditarietà (quindi classi astratte ed interfacce) e polimorfismo...

In finale...datti qualche mese per studiare bene le basi di Java prima di buttarti su Android...

LMCH

18-08-2011, 04:01

Ti consiglio di studiarti per bene un minimo di Java e poi passare ad Android...quantomeno devi arrivare a manegiare con scioltezza i concetti di oggetti, ereditarietà (quindi classi astratte ed interfacce) e polimorfismo...

Ed i design patterns (http://it.wikipedia.org/wiki/Design_pattern) (schemi di progettazione).
Sono essenzialmente "schemi base" per la strutturazione di software in moduli ed oggetti e specialmente per la programmazione ad oggetti aiutano molto i principianti a partire con la mentalita giusta.

Poi ci sarebbero pure gli anti-pattern (http://it.wikipedia.org/wiki/Anti-pattern) :fagiano: ovvero gli "schemi da evitare" che di solito prendono forma quando si parte male nello sviluppo oppure per varie ragioni si fanno molte modifiche progressive ed aggiornamenti ad un software senza considerare che effetto hanno sulla "struttura del sistema complessivo".

Le pagine in inglese relative ai design pattern ed anti-pattern contengono descrizioni più estese e ulteriori link:
http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
http://en.wikipedia.org/wiki/Anti-pattern

E' da notare che alcuni anti-pattern sono a livello di organizzazione e progetto (quindi in essi c'entra il fattore umano più che il software).

Ansem_93

18-08-2011, 07:52

WarDuck

18-08-2011, 08:21

Ed i design patterns (http://it.wikipedia.org/wiki/Design_pattern) (schemi di progettazione).
Sono essenzialmente "schemi base" per la strutturazione di software in moduli ed oggetti e specialmente per la programmazione ad oggetti aiutano molto i principianti a partire con la mentalita giusta.

Poi ci sarebbero pure gli anti-pattern (http://it.wikipedia.org/wiki/Anti-pattern) :fagiano: ovvero gli "schemi da evitare" che di solito prendono forma quando si parte male nello sviluppo oppure per varie ragioni si fanno molte modifiche progressive ed aggiornamenti ad un software senza considerare che effetto hanno sulla "struttura del sistema complessivo".

Le pagine in inglese relative ai design pattern ed anti-pattern contengono descrizioni più estese e ulteriori link:
http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
http://en.wikipedia.org/wiki/Anti-pattern

E' da notare che alcuni anti-pattern sono a livello di organizzazione e progetto (quindi in essi c'entra il fattore umano più che il software).

Per quella che è la mia esperienza non credo che imparare da subito i design pattern sia l'approccio migliore per iniziare, anzi, credo sia l'ultima cosa da imparare una volta afferrati per bene i vari concetti OO (anche facendo degli errori).

Spesso parlare di design pattern ad una persona che non ha mai visto cosa sono, confonde molto di più le idee.

Inoltre secondo me sono profittevoli solo se hai progetti medio-grandi, per piccoli progetti è solo una perdita di tempo.

Ansem_93

18-08-2011, 08:28

LMCH

19-08-2011, 00:31

Inoltre secondo me sono profittevoli solo se hai progetti medio-grandi, per piccoli progetti è solo una perdita di tempo.

Sono utili anche per roba piccola, proprio perchè aiutano a strutturare meglio il software (e questo si traduce in tempo risparmiato nel debug, ecc. ecc.).

In fin dei conti, cose come i pattern command, model-view-controller, abstract factory, ecc. li si incontra anche facendo cose banali e molti imparano lentamente "per esempio" (esempi di codice nei libri i negli help file) vari casi di utilizzo quando potrebbero farlo più velocemente studiando direttamente i design pattern nella loro forma "generica" (più facile da riapplicare in altre situazioni diverse da quelle degli esempi).

e-commerce84

19-08-2011, 07:16

si,so benissimo che tra pascal e java si sono molte differenza,ma almeno i concetti di base della programmazione (while,if,ecc) sono praticamente identici :)
Comunque secondo voi è molto difficile programmare per android? io inizialmente volevo fare un giochino estremamente semplice giusto per capirne il funzionamento

Programmare in Android secondo me è molto comodo per via del framework che reputo pensato molto bene però...vorrei farti notare che i concetti base della programmazione come le parole chiavi while, if, etc sono tipo lo 0,000000000000001% dei prerequisiti che devi conoscere...

Ripeto...devi avere padronanza con i concetti base di programmazione ad oggetti: ereditarietà (classi astratte ed interfacce), polimorfismo, sapere almeno a grandi linee cos'è un framework e conoscenza di qualche pattern (anche se quelli puoi impararteli direttamente lavorandoci siù e leggendo il libro di Carli)

Ti ripeto...impara prima le basi di Java e la programmazione OO (ti ci vorrà qualche mese, prenditi un manuale di Java prima) e poi passa ad Android...fare giochini non è banale...devi usare strumenti grafici e probabilmente qualche altro framework integrativo per gestirne la grafica...se non sei più che ferrato non ne esci vivo

e-commerce84

19-08-2011, 07:26

io attualmente per il mio primo progetto ho intenzione di fare una cosa mooooolto semplice eh XD
di oggetti ce ne dorebbero essere solo due,una matrice e l'oggetto che poi starà in ogni casella della matrice :)
l'unica cosa è che devo ancora studiare il funzionamento delle matrici,per l'oggetto bene o male so già come farlo,visto che fortunatamente a scuola abbiamo un eccellente prof che ci ha fatto anche programmazione ad oggetti,oltre che a quella imperativa di pascal .-.

ok con quello che vedi a scuola arriverai allo 0,00005% di quello che devi sapere della programmazione OO...te lo dico perchè al terzo anno della facoltà di Informatica mi sono ritrovato allo stage che ne sapevo circa lo 0,1% di ciò che mi serviva...dopo 6 mesi di stage diciamo che mi sento di essere arrivato si e no al 5% di ciò che dovrei sapere per lavorare seriamente...

Fidati...studiati bene Java per almeno 3 mesi...

E come ti ha detto qualcuno ti toccherà vedere anche determinati pattern (ma vediteli dopo esserti ferrato molto bene in Java)...sicuramente avrai a che fare con l'Observer che di fatto implementa la gestione delle interazioni utente-dispositivo, l'Adapter che è usato massicciamente nel framework di Android, il Composite che ti tornerà utile anche nel concetti di layout, l'Iterator che ti servirà per iterare in maniera intelligente su collezioni di oggetti e qualche pattern creazionale ti torna spesso utile...

Ti ripeto...non buttarti così sprovvisto di nozioni in qualcosa di questo tipo...il tuo progetto per quanto semplice necessità di conoscenze base del framework di Android e senza conoscere bene queste cose invece di aiutarti (perchè il framework ti aiuta e ti guida nello sviluppo) ti incasinerà tantissimo la vita, anche nel caso che riuscissi a fare qualcosa non capiresti bene cosa stai facendo...

Ciao
Andrea

Ansem_93

19-08-2011, 13:04

grazie mille per i consigli :) allora al più presto prenderò il libro di carli,e nel frattempo finirò di studiarmi java :)

cdimauro

20-08-2011, 09:56

Programmare in Android secondo me è molto comodo per via del framework che reputo pensato molto bene però...
Spero che tu stia scherzando. Il framework è fatto coi piedi, da gente che non sa cosa sia il concetto di astrazione e definizione di gerarchie di classi.

I miei colleghi si mettono a ridere quando chiamo "puttana" la classe View, per tutta la roba (e responsabilità) che le hanno infilato dentro. Ma dico io, possibile che debba rispondere all'evento click anche una banale TextView? Dovrebbe essere prerogativa della classe ButtonView & derivate!

Un'altra cazzata galattica che dimostra l'assoluta incapacità di realizzare una gerarchia di oggetti come informatica (di base) comanda, è rappresentata dalla ListView. Quei geni (con una singola i) hanno pensato bene d'infilare internamente una ScrollView, per gestire lo scorrimento degli item. Risultato: provate a far scrollare una ListView i cui item siano a loro volta delle ListView...
ListView e ScrollView dovrebbero essere oggetti con specifiche responsabilità. Dovrebbe essere poi il programmatore a combinarli (composizione; do you known composition?) per ottenere ciò che vuole. Altrimenti si corre il rischio di doversi riscrivere nuovamente ListView partendo da CustomListView per farla funzionare come si deve.

Mi fermo qui che è meglio (anche perché ho poco tempo a disposizione, e dannarmi ancora per Android non ne vale la pena).

pabloski

21-08-2011, 19:06

La TextView deve necessariamente rispondere all'evento click per com'è fatto. E' di fatto un editor ed è pure possibile ficcarci dentro dei link.

Del resto si può sempre settare la proprietà clickable in modo da non farla rispondere ai click del mouse.

In ogni caso c'è la necessità proprio per i compiti per cui la TextView è pensata.

Voglio dire, pure la TextBox di .net supporta gli eventi del mouse, non vedo cosa c'è di scandaloso.

Stesso discorso per la View che, alla fin fine, supporta tutti le proprietà tipiche di una view. Abbiamo varie proprietà grafiche ( tipo effetti di fading, parametri per il touch, ecc... ), proprietà delle scrollbars, animazioni, suoni legati agli eventi. In sostanza si tratta di elementi comuni a tutte le classi derivate dalla View. Almeno a me hanno insegnato che quando ci sono molti elementi comuni a più classi è opportuno metterli nelle classi madre.

cdimauro

22-08-2011, 06:18

Col tuo ragionamento esisterebbe soltanto la classe "essere vivente". :D

Ed è, purtroppo, quello che ha fatto il team che ha realizzato Android: View deriva direttamente da Object, e ha una caterva di "figli" di primo letto.

Nello specifico, visto che li hai citati, TextView servirebbe per visualizzare testo, ma consente anche di editarlo, se abilitato a farlo. EditText discende da TextView... semplicemente per permettere questa caratteristica! Potevano farne a meno, a questo punto (principio DRY).

Adesso mi devi spiegare per quale motivo devo avere un oggetto che si porta dietro un enorme carico di responsabilità dovuto al fatto che integra quelle di un editor, quando normalmente lo uso soltanto per visualizzare del testo, e faccio ricorso a EditText quando ho realmente l'esigenza di editarlo, quel benedetto testo.

In un framework a oggetti per realizzare GUI normalmente i componenti hanno poche e ben definite responsabilità. Classi come "Label", ma potremmo citare anche Shape, sono fra le più elementari proprio per questo motivo, e non necessitano di intercettare un evento click (al contrario di Button & derivati).

Man mano che le responsabilità aumentano e s'individuano nuovi insiemi di problematiche e relative responsabilità, e si realizzano delle classi che le modellano. E così via, generando una gerarchia ben definita.

Hai citato Microsoft, e ti riporto le due paginette relative a TextBlock (http://msdn.microsoft.com/it-it/library/system.windows.controls.textblock(v=vs.95).aspx) e TextBox (http://msdn.microsoft.com/it-it/library/system.windows.controls.textbox(v=vs.95).aspx), che sono i corrispettivi di TextView ed EditText. Dai un'occhiata alla gerarchia da cui derivano, e controlla di quali responsabilità si fanno carico le varie classi definite a partire da Object.
Per rispondere alla tua osservazione su TextBlock, è chiaro che mette a disposizione metodi e proprietà per agire sugli eventi di tastiera e mouse, ma perché vengono ereditati (è scritto accanto a ogni membro della classe) dalle classi da cui deriva (altrimenti come fai a realizzare un editor, se non vengono a essi propagati?).
Non espone però un evento come Click, come fa Button (http://msdn.microsoft.com/it-it/library/system.windows.controls.button(v=vs.95).aspx), che a sua volta lo eredita da ButtonBase (http://msdn.microsoft.com/it-it/library/system.windows.controls.primitives.buttonbase(v=vs.95).aspx).
Come pure CheckBox (http://msdn.microsoft.com/it-it/library/system.windows.controls.checkbox_members(v=vs.95).aspx), che aggiunge pure l'evento Checked in quanto ulteriore specializzazione di Button (in realtà deriva da ToggleButton (http://msdn.microsoft.com/it-it/library/system.windows.controls.primitives.togglebutton(v=vs.95).aspx), che identifica questa classe/insieme di componenti). Ecc. ecc. ecc.

Ma non serve andare a casa del "nemico" (che tra l'altro non ho mai citato, perché il contesto è generico: stiamo parlando di modellazione degli elementi di una UI): perfino Delphi 1.0, con la sua fantastica VCL, che nacque nel lontano '95, presenta una gerarchia ben definita di classi con precise responsabilità. E sono sicuro che se andassi a riprendere TurboVision, il framework realizzato da Borland per realizzare UI testuali per il Turbo Pascal 6, l'approccio utilizzato sarebbe quello.

pabloski

22-08-2011, 11:10

Nello specifico, visto che li hai citati, TextView servirebbe per visualizzare testo, ma consente anche di editarlo, se abilitato a farlo. EditText discende da TextView... semplicemente per permettere questa caratteristica! Potevano farne a meno, a questo punto (principio DRY).

Adesso mi devi spiegare per quale motivo devo avere un oggetto che si porta dietro un enorme carico di responsabilità dovuto al fatto che integra quelle di un editor, quando normalmente lo uso soltanto per visualizzare del testo, e faccio ricorso a EditText quando ho realmente l'esigenza di editarlo, quel benedetto testo.

il problema è quindi l'esistenza di EditText che non ha praticamente senso visto che è solo una TextView con l'editing abilitato

potevano creare una TextView senza editing o semplicemente tenere solo TextView

il problema è che semmai c'è una classe di troppo

In un framework a oggetti per realizzare GUI normalmente i componenti hanno poche e ben definite responsabilità. Classi come "Label", ma potremmo citare anche Shape, sono fra le più elementari proprio per questo motivo, e non necessitano di intercettare un evento click (al contrario di Button & derivati).

però questo significa che non c'è modo di cliccare su una label per ottenere un qualcosa un qualche effetto

non è detto che una label dev'essere per forza statica...è un pò come quando cominciarono a cominciare gli hyperlink nelle gui e i testi statici diventerano testi cliccabili tramite cui raggiungere un url

Man mano che le responsabilità aumentano e s'individuano nuovi insiemi di problematiche e relative responsabilità, e si realizzano delle classi che le modellano. E così via, generando una gerarchia ben definita.

Hai citato Microsoft, e ti riporto le due paginette relative a TextBlock (http://msdn.microsoft.com/it-it/library/system.windows.controls.textblock(v=vs.95).aspx) e TextBox (http://msdn.microsoft.com/it-it/library/system.windows.controls.textbox(v=vs.95).aspx), che sono i corrispettivi di TextView ed EditText. Dai un'occhiata alla gerarchia da cui derivano, e controlla di quali responsabilità si fanno carico le varie classi definite a partire da Object.

in pratica le funzionalità di View vengono spezzettate in Control, Visual, ecc...

Per rispondere alla tua osservazione su TextBlock, è chiaro che mette a disposizione metodi e proprietà per agire sugli eventi di tastiera e mouse, ma perché vengono ereditati (è scritto accanto a ogni membro della classe) dalle classi da cui deriva (altrimenti come fai a realizzare un editor, se non vengono a essi propagati?).

ovviamente ma pure textview eredita da view quelle proprietà

l'unica differenza che vedo è che View si sobbarca il lavoro che in .net è svolto da 4-5 classi diversi

turbo vision invece era fatto proprio nel modo che dici....TView per esempio ha solo proprietà tipo:

- cursore
- dimensione della view
- stato
- owner

e qualche altra...non c'era ombra di proprietà tipo colori, font, ecc...

cdimauro

22-08-2011, 13:03

il problema è quindi l'esistenza di EditText che non ha praticamente senso visto che è solo una TextView con l'editing abilitato

potevano creare una TextView senza editing o semplicemente tenere solo TextView

il problema è che semmai c'è una classe di troppo
In questo caso specifico sì, ma in generale il problema è che a View sono state date tantissime responsabilità, come dicevo prima.
però questo significa che non c'è modo di cliccare su una label per ottenere un qualcosa un qualche effetto

non è detto che una label dev'essere per forza statica...è un pò come quando cominciarono a cominciare gli hyperlink nelle gui e i testi statici diventerano testi cliccabili tramite cui raggiungere un url
Per questo sono nati i controlli HyperLink, che derivano... da Button(Base), in quanto devo gestire il concetto di "click" (del mouse o del touch screen).

I controlli testuali rimangono tali, e non hanno bisogno di essere clickabili. Altrimenti sarebbero dei Button (o derivati), appunto.

In Android una View è cliccabile, a prescindere dal modo in cui verrà specializzata. Tant'è che c'è pure un Button...
in pratica le funzionalità di View vengono spezzettate in Control, Visual, ecc...
Non è uno spezzatino. :D

Si tratta di demandare a delle classi alcune specifiche funzionalità. Ci sono poi dei controlli che possono estendere da uno dei "genitori" (non necessariamente da FrameworkElement, tanto per dire), a seconda delle proprie responsabilità. Non sono, insomma, costretti a farsi di carico di qualunque cosa.
ovviamente ma pure textview eredita da view quelle proprietà

l'unica differenza che vedo è che View si sobbarca il lavoro che in .net è svolto da 4-5 classi diversi
Ed è una differenza non da poco, quando parliamo della modellazione dell'ambiente che c'interessa. :p

Giusto per fare un esempio in linea con quanto già detto, un bottone è clickabile perché fa parte della "famiglia" dei bottoni. Non perché fa parte delle View o di FrameworkElement. ;)
turbo vision invece era fatto proprio nel modo che dici....TView per esempio ha solo proprietà tipo:

- cursore
- dimensione della view
- stato
- owner

e qualche altra...non c'era ombra di proprietà tipo colori, font, ecc...
Appunto. Se vai a vederti la gerarchia di classi di WPF/Silverlight, vedrai che non tutti i controlli hanno queste proprietà, perché ciò dipende strettamente dal tipo di controllo.

Non solo: UIElement non ha nemmeno il concetto di Width e Height, che ritrovi soltanto in FrameworkElement.

I controlli vengono specializzati a seconda del concetto che devono modellare.

DependencyObject (http://msdn.microsoft.com/it-it/library/system.windows.dependencyobject_members(v=vs.95).aspx), che specializza Object, introduce soltanto il minimo indispensabile per gestire il concetto di proprietà "dipendenti".
UIElement (http://msdn.microsoft.com/it-it/library/system.windows.uielement(v=vs.95).aspx) specializza quest'ultimo introducendo il concetto di elemento dell'interfaccia utente, e quindi della gestione degli eventi, la visibilità, e la "misurazione" dell'area (da occupare).
FrameworkElement (http://msdn.microsoft.com/it-it/library/system.windows.frameworkelement(v=vs.95).aspx), infine, introduce il concetto di layout (e quindi di dimensione dell'oggetto; infatti è qui che vengono introdotte le proprietà Width, Height, e annesse).

Ma non c'è traccia di colore, font, e nemmeno di eventi come Click. Nulla di tutto ciò, perché queste sono responsabilità che non competono a FrameworkElement, ma eventualmente alle sue specializzazioni. :read:

pabloski

22-08-2011, 14:17

Sicuramente si poteva articolare di più la gerarchia delle classi. A me pare che abbiano voluto creare un albero di classi quanto più semplice possibile.

Alla fine un mucchio di widget sono diretti discendenti di View. In sostanza c'è View e un figlio che implementa qualcosa. Hanno preso tutti i figli, hanno raggruppato i metodi comuni e li hanno messi nella View.

Certo un metodo non elegantissimo ma molto veloce nell'implementazione.

Lato sviluppatore non è che ti cambia chissà quanto la vita, anzi è più lineare e facile da capire.

cdimauro

22-08-2011, 14:22

Mi stai dicendo che possiamo andare a buttare a mare il concetto di astrazione e specializzazione delle classi? :p

Rispondi a questa domanda: "una View è un bottone, o un bottone è una View"? Da lì si capisce tutto. ;)

pabloski

22-08-2011, 14:48

Mi stai dicendo che possiamo andare a buttare a mare il concetto di astrazione e specializzazione delle classi? :p

no, ovviamente si poteva fare meglio ma non nello stesso tempo

da come hanno implementato le classi si capisce che si puntava a fare la cosa più semplice possibile

non è sbagliato a priori se la priorità è lanciare il prodotto nel minor tempo possibile

Rispondi a questa domanda: "una View è un bottone, o un bottone è una View"? Da lì si capisce tutto. ;)

certo ma se vai a guardare le funzionalità della classe View sono le tipiche funzionalità di un widget di qualsiasi tipo

che poi possiamo dire che TextView non dev'essere cliccabile o che EditText dev'essere l'unica ad essere editabile, ecc...

il vantaggio della loro scelta si può vedere qui http://developer.android.com/reference/android/view/View.html nella sezione "Implement a custom view"

cdimauro

22-08-2011, 15:01

no, ovviamente si poteva fare meglio ma non nello stesso tempo

da come hanno implementato le classi si capisce che si puntava a fare la cosa più semplice possibile

non è sbagliato a priori se la priorità è lanciare il prodotto nel minor tempo possibile
Qualunque azienda ha fretta di rilasciare i propri prodotti nel più breve tempo possibile.

Ciò non giustifica le scelte effettuate per le motivazioni di cui sopra. Anche una piccola software house è capace di organizzare bene il proprio lavoro, posto che abbia personale tecnico con adeguate capacità.

Inoltre, se parliamo proprio di tempo, Android è un prodotto che ha avuto una gestazione estremamente lunga.
certo ma se vai a guardare le funzionalità della classe View sono le tipiche funzionalità di un widget di qualsiasi tipo
Mi pare di no, proprio per quanto detto finora anche da te (ricordi Turbo Vision?).
il vantaggio della loro scelta si può vedere qui http://developer.android.com/reference/android/view/View.html nella sezione "Implement a custom view"
Buona parte riguarda la gestione di eventi e layout, comune a tanti UI framework. Nulla di nuovo, insomma.

Se poi ti riferisci all'override di onDraw, beh, anche questo è normale amministrazione: puoi chiamarlo onDraw come pure onPaint, ma è il concetto cui tipicamente si disegna un widget.

In ogni caso, nulla a che vedere col sovraccarico di responsabilità di cui si è parlato finora, che denota un framework scritto decisamente male.

pabloski

22-08-2011, 15:28

Difficile dire perchè abbiano seguito quella strada. La semplicità nel creare dei widget partendo di una megaclasse View è evidente. Magari era quello l'obiettivo.

La presenza di EditText tende ad escludere questa possibilità ma potrebbe anch'essa essere dovuta alla volontà di rendere semplice l'uso del framework.

Penso che non sapremo mai la verità. Mi viene difficile pensare all'incompetenza, alla fin fine è un'azienda che non è diventata certamente famosa per la sua incompetenza.

cdimauro

22-08-2011, 15:37

nucarote

22-08-2011, 15:57

Non parlavo di Google, ma dell'azienda che ha realizzato Android, ed è stata poi acquisita dalla prima.

E' chiaro che con un progetto in stato già molto avanzato Google non ha potuto fare molto, a meno di spendere altro tempo in un'enorme rifattorizzazione. E siccome Google aveva fretta...

Ricordo ancora il processore SOAP preso di peso da JavaME e le varie RC della 1.0 con cui "sviluppavo" nell'ormai lontano 2008. :D :D
Comunque concordo in pieno le critiche di cdimauro, senza contare che trovo un pò anacronistico il fatto che il programmatore debba provvedere a fare il binding a manina dei widget.

cdimauro

23-08-2011, 05:30

Parli dell'inflate dall'XML, del findViewByID, dell'uso di listener & compagnia, o della montagna di codice da scrivere per impostare un po' tutto? O di tutto assieme? :D

nucarote

27-08-2011, 11:59

Parli dell'inflate dall'XML, del findViewByID, dell'uso di listener & compagnia, o della montagna di codice da scrivere per impostare un po' tutto? O di tutto assieme? :D

In particolare dell'inflate dall'XML e del findViewByID, roba che IMHO manco il peggior programmatore phptroto concepirebbe mai. :D

Antares88

29-08-2011, 00:13

non conosco abbastanza a fondo Android e ho nozioni elementari sui principi di RDD, tuttavia mi permetto di dire un paio di cose:

1) da niubbo che giudica avendo fatto solo un esame di APS, la classe View mi pare un caso di blob (o god object): ha un sacco di responsabilità e si occupa di troppe cose, voglio dire, dov'è finito il concetto di coesione?

2) è uno scoglio per chi impara, specialmente se non avvezzo ad avere a che fare con un livello di generalizzazione/astrazione/polimorfismo così spinto. Una classe così grande che fa un miliardo e mezzo di cose può essere sfuggente per chi si approccia.

LMCH

29-08-2011, 08:43

la classe View mi pare un caso di blob (o god object): ha un sacco di responsabilità e si occupa di troppe cose, voglio dire, dov'è finito il concetto di coesione?

A pensar male la cosa più probabile è che (almeno inizialmente) abbiano cercato di incapsulare in View tutte le funzioni implementate nativamente che potrebbero tornar utili ad un widget.
Non è il massimo come implementazione, ma in quel modo c'era un unico punto in cui i widget si interfacciavano con le funzioni più a basso livello "al di fuori di Dalvik".

pabloski

29-08-2011, 10:48

cdimauro

31-08-2011, 20:19

L'ultima chicca di oggi (http://developer.android.com/reference/android/view/Display.html#getDisplayId()):
public int getDisplayId ()
Since: API Level 1

Returns the index of this display. This is currently undefined; do not use.
Ottimo esempio di definizione di un'API. :D

E chissà quando si decideranno a implementarla. :stordita:

Tommo

31-08-2011, 20:43

beh in ogni caso ci tocca conviverci

android è il Dio del mondo mobile e chi vuole lavorare in questo mondo deve fare i conti con android

sia chiaro che deve fare pure i conti con ios se vuole guadagnare sul serio

l'unico grande problema di tutti questi sistemi mobile è che ti costringono ad usare, chi più chi meno, il loro framework, senza darti la possibilità di usare qualcos'altro liberamente e senza doverti interfacciare con loro

sui pc si ha il vantaggio che l'unica api richiesta è quella del kernel, il resto puoi bypassarlo, con i sistemi mobile no

La tua visione del mondo mobile è quantomeno peculiare :asd:

Dire che chi vuole lavorare nel mobile DEVE imparare Android mentre IOS è un'opzione è veramente stare fuori dal mondo.
E' probabile che nei prossimi 5 anni la situazione si capovolgerà; ma ad oggi anche come posti di lavoro offerti, Android è prossimo allo zero, IOS ha un boom enorme.
E' probabile che il mercato IOS sia il più facile e il più redditizio per chi cerca lavoro senza esperienze, ad oggi, un pò come il web design nei primi anni 2000.

Per cui, pls stop being a fanboy.

pabloski

01-09-2011, 11:26

La tua visione del mondo mobile è quantomeno peculiare :asd:

Dire che chi vuole lavorare nel mobile DEVE imparare Android mentre IOS è un'opzione è veramente stare fuori dal mondo.
E' probabile che nei prossimi 5 anni la situazione si capovolgerà; ma ad oggi anche come posti di lavoro offerti, Android è prossimo allo zero, IOS ha un boom enorme.
E' probabile che il mercato IOS sia il più facile e il più redditizio per chi cerca lavoro senza esperienze, ad oggi, un pò come il web design nei primi anni 2000.

Per cui, pls stop being a fanboy.

e quand'è che avrei detto che ios è un'opzione? ho semplicemente fatto notare che, ad oggi, android è il più diffuso in assoluto

e così come all'epoca del windows monopolista dovevi arrangiarti pure se il compilatore c++ era pieno di bug, così oggi devi arraggiarti pure se l'api di android è scritta coi piedi

capisco che a molti il fatto che google domini il mercato mobile fa molto male....in questo caso se cerchi un fanboy guardati allo specchio

Tommo

01-09-2011, 12:02

Si caro ragazzo, ma non domina affatto in termini di lavoro che smuove, dato che il parco applicazioni per Android è deserto.
Anche nokia dominava il mercato, ma non mi risulta che realizzare applicazioni per nokia fosse un lavoro così in voga.
Google domina il mercato mobile ALL'ESTERO (in italia è ancora ridicola la percentuale di android), ma lo domina solo come numeri puri, e questo conviene solo a Google e ai costruttori, solo indirettamente a noi sviluppatori.

PS: se fosse conveniente non esiterei a sviluppare per Android, il mio motore lo supporterebbe... ma fai conto che non mi conviene nemmeno perdere tempo a ricompilare il gioco.
La situazione sta cambiando, ma molto lentamente...