quale libro per imparare android?

[Ansem_93]

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).

[e-commerce84]

Originariamente inviato da Ansem_93

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]

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

[e-commerce84]

Originariamente inviato da Ansem_93

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]

Originariamente inviato da e-commerce84

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 (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 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_...ter_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]

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

[WarDuck]

Originariamente inviato da LMCH

Ed i design patterns (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 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_...ter_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]

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 .-.

[LMCH]

Originariamente inviato da WarDuck

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]

Originariamente inviato da Ansem_93

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]

Originariamente inviato da Ansem_93

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]

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

[cdimauro]

Originariamente inviato da e-commerce84

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]

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]

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

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 e TextBox, 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, che a sua volta lo eredita da ButtonBase.
Come pure CheckBox, che aggiunge pure l'evento Checked in quanto ulteriore specializzazione di Button (in realtà deriva da ToggleButton, 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]

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

Hai citato Microsoft, e ti riporto le due paginette relative a TextBlock e TextBox, 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...

Originariamente inviato da cdimauro

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]

Originariamente inviato da pabloski

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.

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.

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, che specializza Object, introduce soltanto il minimo indispensabile per gestire il concetto di proprietà "dipendenti".
UIElement 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, 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.

[pabloski]

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]

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

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

[pabloski]

Originariamente inviato da cdimauro

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

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

Originariamente inviato da cdimauro

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/referen...view/View.html nella sezione "Implement a custom view"