Sviluppare app in Material Design è ancora più facile grazie ai nuovi 'Components'

12 Maggio 2017 57

Google si impegna sempre molto per fornire agli sviluppatori gli strumenti più semplici possibile per realizzare applicazioni e siti Web seguendo le proprie linee guida di stile, comunemente note come Material Design. Nelle scorse ore ha debuttato una nuova sezione sul sito dedicato chiamata Material Design Components: si tratta di una libreria molto ampia di template e componenti di interfaccia precostruiti e sempre aggiornati.

Non solo Android: i template sono disponibili anche per iOS e per il Web. In tutto sono più di trenta, ripartiti in modo più o meno equo tra le tre piattaforme. Per ogni Component viene fornita una documentazione completa per implementarla nel proprio progetto e personalizzarla in base alle esigenze.

Per ulteriori informazioni, non vi resta che visitare la nuova sezione Material Design Components sul sito web ufficiale (la documentazione è tutta in inglese).

Bordi Edge e potenza ma con risparmio garantito? Samsung Galaxy S6 edge, compralo al miglior prezzo da Amazon a 378 euro.

57

Commenti

Regolamento Commentando dichiaro di aver letto il regolamento e di essere a conoscenza delle informazioni e norme che regolano le discussioni sul sito. Clicca per info.
Caricamento in corso. Per commentare attendere...
a'ndre 'ci

anche meno di due anni...

a'ndre 'ci

ma è gggoooglee... fanno tutto fico e bello..

mamma mia.. mai vista una SDK peggiore....

Luke_Friedman

Si, il modello di due anni e mezzo fa. Ti avrebbe dovuto pagare il negozio per toglierlo dal magazzino.

Ho comprato un galaxy tab e per mia madre a 120€. Nuovo di zecca e con Android 4.4

Luke_Friedman

Ti invito a trovarmi un cellulare nuovo da 100€ con Android 4.4, allora.

Matteo85_b

Non dico che il cliente ti viene incontro, però noi nel preventivo premettiamo la versione e se la vuole su una versione inferiore il costo cambia, nella maggior parte dei casi la differenza di prezzo ha portato al cambio del dispositivo. In alcuni casi abbiamo perso il cliente però è anche vero che è inutile prendere un lavoro se si è in perdita.
La frammentazione non è una scusante è una condizione che porta a sviluppare con determinati costi. Se poi qualcuno vende non tenendo conto di queste cose e tira il collo a te mi spiace ma non è colpa di Android.

stiga holmen

Si, dovresti estendere la ListView, farti un metodo tipo setData() in cui passi i nuovi dati da visualizzare. Ovviamente il setData() si occuperà di aggiornare l'adapter e richiamare il datasetChanged sulla lista . Insomma Android ti da le funzioni di basso livello, poi o le usi direttamente o tocca creare classi personali per velocizzare e semplificare le operazioni.
Forse windows parte già con classi più semplici e ti consente anche di accedere alle funzioni a basso livello quando serve.

Purtroppo non ho tempo per provare windows xD Sono già indietro con la formazione personale di Android ad ogni nuova uscita xD

Luca

Non è così semplice... Quando c'è un cliente di mezzo si combatte sempre per semplificare il lavoro allo sviluppatore, ma le esigenze del cliente devono essere rispettate e basta, non è che se glielo spieghi automaticamente ti verrà incontro... Il mio team si è ritrovato a scrivere codice apposito per far funzionare un'app su un telefono del cacchio solo perché chi l'ha commissionata aveva quel telefono del cacchio... E tu mi dirai "Possibile che chi vi ha commissionato quell'app non si fa un telefono più moderno?"... Troppi pensieri ci sono passati per la testa, troppe domande, discussioni e spiegazioni, ma non vinci! Nonostante il costo possa essere maggiore... Che poi anche questa cosa lascia il tempo che trova... Possono non farsi problemi sul prezzo, possono ingaggiare a tempo, possono aver determinato le specifiche prima del tuo arrivo... Se lo sviluppatore sta dentro un'azienda in cui è l'ultima ruota del carro, dopo una gerarchia di manager e tecnici che fanno certe scelte per certe motivazioni, tu, sviluppatore, fai quello che ti dicono e basta... E' scomodo? Trova il modo. Questa è la mia esperienza, se tu sei stato fortunato a trovare clienti diversi o lavori solo da freelance sono contento per te, ma non è sempre così che funziona... Di certo su iOS non si mettono a spiegare perché gli conviene alzare la versione minima... Apple li obbliga, o semplicemente non vale la pena perché la frammentazione lì praticamente non esiste, discorsi però non validi per android e che un dev non può rivendersi come scusante...

Luca

Si, ma il notify di android è relativo ad un adapter e quindi ad una collection e basta... Prima però devi ovviamente prendere la listview e settare la sorgente dati sempre da code behind...
Dai va bene così, ognuno ha le sue implementazioni, ma devi conoscere .NET prima di poter fare un paragone come si deve... Io ho iniziato su android per lavoro, ora sto sulle UWP per lavoro e mi diverto a fare qualcosa per conto mio da pubblicare sullo store... Quando avrò terminato la UWP farò anche la parte android, ma non ti nego un po' di pesantezza tornare a certe gestioni... Si fa, ci si diverte, si migliora sempre, ma le differenze tra i due framework esistono... Per curiosità e diletto però ti consiglio di farla una semplice UWP, anche senza MVVM, per giocare un po' con lo XAML e scoprire cosa offre veramente :) Magari ti ci trovi bene, non ti peserà svilupparci sopra, acquisisci una nuova competenza e ti rivendi sul mercato più completo ;) Ciao!

Matteo85_b

Bhe dipende, se sono dipendente e sviluppo ovviamente faccio quello che mi dicono ma li dov'è il problema mi pagano per farlo... è cura di chi analizza il progetto di spiegare al cliente finale che se fa una versione compatibile con Android 2 o superiore ha un costo diverso da Android 5 o superiore. poi il cliente valuta. ma non è che uno si mette a caso a fare un app e poi scopre che esistono le versioni...

Non per questo devi insultare decine di milioni di persone. Non si parla del 20% di utenti Windows Mobile o iOS, ma di Android. Non é un numero irrilevante. E come già scritto da altri, il 20% era riferito alla versione 4.x, se si considerano tutti fino alla versione 4.4, siamo al 30%.

E non so quanti ne conosci tu, ma sono proprio i ragazzi giovani a prendersi il telefono da 100€ con Android 4.4, non tutti gli anziani per avere un display più grande per via dei numeri da premere.

Luca

Figurati nessun problema...
Comunque nessuno vuole puntare il dito contro google, a mio avviso è relativamente giovane sugli strumenti di sviluppo, è anche piuttosto normale che Microsoft con il suo .NET stia più avanti... Più che altro la frecciatina era verso chi ha scritto le parole da me citate... E' indubbio che c'è di peggio rispetto ad android studio e i suoi sdk, ma da qui a definire quegli strumenti il più semplici possibile ce ne passa ;)

stiga holmen

In merito al button per modificare il testo: mi pare la stessa cosa, o chiami una funzione o modifichi direttamente l'attributo. Mi pare un pò più pulito richiamare la funzione, poi de gustibus.

"Se vuoi rimuovere, aggiungere o modificare l'elemento di una lista, tu non la tocchi proprio la ListView, al più modifichi la sua sorgente dati come se fosse semplicemente un oggetto della business logic e la grafica reagirà di conseguenza." > su android aggiorni la sorgente dati e chiami il notifyDatasetChanged() e la lista grafica si aggiorna di conseguenza...

Su android il comportamento del pulsante è già pronto con le stateList e quindi specifichi lo stile in quegli stati, senza dover toccare altro. Se applichi un click al testo mi pare già sbagliato in partenza, a meno che non sia un link, ma in quel caso hai l'azione corrispondente anche pronta.

Insomma, dipende tutto da come strutturi l'applicazione rispettando il significato dei componenti. Ad esempio: potresti benissimo ficcare un'immagine in un button per renderla cliccabile, ma esiste già un altro componente pronto per questo a cui associare l'evento di click.

Luke_Friedman

Capisco, eccome se capisco. Però la colpa non è di Google, che forse è una delle aziende che rilascia più materiale per lo sviluppatore. Questo intendevo, rileggendo il messaggio mi sono trovato più rude di quanto volessi :)

Luke_Friedman

Quel 20% di persone con un cellulare fino a 4.4 nel 99,9% dei casi non hanno mai scaricato una app che non sia Facebook e la loro età media non è sicuramente inferiore ai 40. Solitamente sono quelle a cui una software house punta di più, vero? Complimenti per sapere la differenza tra template e libreria ma sulla pratica stiamo messi veramente a poco.

Luke_Friedman

Apri le "librerie" che ti ha lasciato Google e vienimi a dire se sono più l'una o più l'altra.

Luca

In android non è un vero e proprio MVVM, ma è il pattern volendo a cui si avvicina di più, sicuramente più dell'MVC... C'è il file di interfaccia grafica, il file dietro che lo gestisce ed eventuale le varie entities scorporate... Ma questo equivale ad usare il code behind su Windows... Si può fare, ma un progetto strutturato bene riesce a separare completamente la View, dal ViewModel, e dai Models...
Su android se vuoi modificare il testo di una TextView, da codice scrivi nomeDellaView.SetText("qualcosa"), su Windows, da code behind puoi fare la stessa cosa NomeDelControllo.Text = "qualcosa", oppure andare nello XAML e dire a quel TextBlock che il suo campo testo è collegato ad un certo attributo del relativo ViewModel... e per cambiare quel testo? Basta semplicemente modificare l'attributo al ViewModel, senza toccare l'elemento testuale che lo renderizza, il quale saprà in automatico che il testo che sta mostrando viene modificato... Idem per una collection... Se vuoi rimuovere, aggiungere o modificare l'elemento di una lista, tu non la tocchi proprio la ListView, al più modifichi la sua sorgente dati come se fosse semplicemente un oggetto della business logic e la grafica reagirà di conseguenza... Se ti interessa approfondire puoi cercare l'interfaccia INotifyPropertyChanged, comunemente implementata in un ViewModel...
Su android sta cosa non si fa, e nel momento in cui lavori in team più strutturati torna comodo perché può esserci quello che si occupa della parte grafica e quello che si occupa della business logic... Possono lavorare parallelamente senza calpestarsi i piedi poiché c'è un disaccoppiamento delle parti...
Per quel che riguarda il pulsante provo a farti una domanda, su android preferiresti poter fare un pulsante come vuoi, o rendere clickabile qualsiasi cosa? Ovviamente tenendo presente ad esempio che quando fai click su un pulsante, vedi che il pulsante viene premuto, se fai click su un testo, non vedi che il testo viene premuto, a prescindere da ciò che scatena il click o tocco...

stiga holmen

Per non avere frammentazione hai diverse opzioni:
- tagli il supporto alle vecchie SDK
- non aggiorni mai le SDK
- obblighi tutti ad aggiornare o a comprare un nuovo cellulare.

Pensa che stronz* quelli di Android, hanno creato le supportLibrary risolvendo il problema...tranne API specifiche per HW nuovo, la compatibilità delle nuove strutture funziona anche sulle vecchie versioni...Ed hanno evitato i contro delle opzioni sopra..

stiga holmen

A dire il vero i componenti nuovi su JB li vedi esattamente come in NN se usi gli stili adeguati.....

poi mi spieghi come si fa a pensare un componente adesso che vada bene tra 2 anni? Impossibile, in genere appunto si lavora con librerie di supporto o aggiornando a mano il vecchio codice..

stiga holmen

Se ho ben capito, MS ti consente di inserire dentro un Button un layout complesso? E quindi ad andare a prendere eventi più specifici?

ma allora che senso ha? Non è lo stesso in Android dove puoi specificare un layout complesso, associargli tutti gli eventi che vuoi, sia all'elemento dentro al layout che al parent dell'elemento?

Magari non ho compreso bene. Comunque mi pare normale distinguere per bene gli elementi e gli eventi associati, altrimenti si finisce ad associare eventi "strani" agli oggetti che non avrebbero competenza.

Mi informo meglio, perchè magari non ho capito cosa offre di più MS, visto che lo MVVM lo si può avere anche in Android (es. medium. com /upday-devs/android-architecture-patterns-part-3-model-view-viewmodel-e7eeee76b73b )

Adriano

Tra chi le lascia incomplete e mette altre carte in tavola di volta in volta e chei le azzera ogni 2 anni... Insomma, non vedo chi sia meglio. O ovviamente android è ormai troppo diffuso e gli sviluppatori devono preferirlo. A parti invertite sarebbe stato lo stesso

Luca

Ma quella pagina non serve a niente...
La sintassi è la stessa, lo XAML di fatto è un XML, ma come lo si usa è differente... Solo la struttura delle DependencyProperty e il Data Binding rendono lo sviluppo su Windows qualcosa di impareggiabile rispetto alla programmazione su Android, l'applicazione di un pattern a tutto tondo come l'MVVM e la costruzione proprio degli oggetti...
Provo a farti un esempio davvero banale su questo ultimo punto...
Spesso e volentieri su android non ci si sbatte troppo a creare pulsanti con layout complessi, se proprio si vuole cliccare un layout complesso non si fa altro che settare un ClickListener al layout stesso scatenando l'azione che si vuole? Funziona? Ovviamente si, ma si andranno a perdere tutti quegli effetti che il sistema da in automatico ad una View come il Button, ovvero la pressione, l'holding, il click, effetti puramente grafici che lo rendono decisamente più carino di uno spazio cliccabile senza alcun feedback... Volendo fare la stessa cosa su Windows lo puoi fare, c'è l'evento Tapped che puoi applicare a qualsiasi controllo... Funziona? Si, ma farebbe schifo come su android... Fortunatamente la struttura degli oggetti nello XAML ti permette di modificare COME VUOI il Content di (in questo caso) un Button, dandoti la possibilità di metterci dentro quello che ti pare, ad esempio quel layout complesso... Ecco che quel layout complesso sta dentro un bottone e visivamente si mostra per quello che è, un elemento cliccabile, non andando a ricorrere all'evento Tapped, ma al vero e proprio Click... Tutto si può toccare, ma l'oggetto clickabile è un pulsante, e questo vale su Windows, su Android e su iOS... Su Windows però puoi usarlo sempre e comunque (come andrebbe fatto), su android si limita a contenere cose semplici... Poi se ti diverti con gli stili e i VisualState capirai che la flessibilità che ti offre uno XAML è troppo al di sopra...
Chiaro, Microsoft si è dovuta attrezzare poiché il suo sistema gira su una varietà di dimensioni che android nemmeno conosce, ma se un'app android girasse in una finestra ridimensionabile come una UWP su un pc, portandola da un fullscreen ad un layout stretto e verticale come da smartphone, come si comporterebbe?
Comunque quello che secondo me fa veramente la differenza, ma troppa differenza, è il Data Binding, che ti permette di applicare l'MVVM pattern a regola d'arte...

Però é come ha scritto Luca. O perdi in funzionalità o in qualità.
Appunto perché scrivi in JEE le app non dovrebbero dipendere tanto dall'OS ma dalla versione della VM no?
Finché il 20% usa Android 4.4, non puoi dire "tralascio loro".
E' un po' come scrivere una app per Windows XP perché non tutti possiedono ancora Windows 10. Chi ha le risorse crea una app per Android 1.6 a 5.0 e ne crea una bella per Android 6-7. Ma io ancora devo poter dare la mia app a chi possiede Android 4.4.

Secondo me dovrebbero trovare un sistema per poter aggiornare la versione minima indipendentemente dalla versione Android che possiedi... Anzi forse sarebbe meglio se tirassero una buona riga e cominciassero da capo con le cose fatte in ordine.

Mi ricordo ancora come con Android 1.6 dicevano che non sarebbe mai stato frammentato come Symbian. Tempo 1 anno e aveva più frammentazioni di Symbian in 10 anni :P A Google gli va bene per una sola cosa: quando un'app non va, di solito si da la colpa al produttore di telefoni, mai all'OS. Non so come ci siano riusciti, ma questo li ha salvati.

Antsm90

Ma infatti non si sviluppa MAI sull'ultima versione, soprattutto con Android (ad esempio adesso è il momento di sviluppare per Android 5.0), ma io son programmatore JEE, per cui ormai la dò per scontata come cosa :)

Luca

Certo che è un workaround! Altrimenti perché non è ancora un comportamento predefinito? Perché quando lavorano su un componente non lo predispongono anche per la retrocompatibilità ma lo separano tra support ed SDK? Prova ad usare una RecyclerView con le CardView con le support su JB... Lo puoi fare, ma le vedrai differenti da come si vedrebbero su una versione da Lollipop in su... Se android fosse veramente modulare come sistema, google riuscirebbe ad aggiornarlo a prescindere dal produttore che ha potere solo sulla sua personalizzazione, così come ha fatto con quei componenti scorporati dall'OS in se e aggiornabili tramite play store...
Inoltre vai a vedere quante know issues relative alle support libraries sono state create anni fa e stanno ancora lì... Si sbatteranno pure a fare questa cosa, ma da farla, a farla a regola d'arte ce ne passa e i side effects esistono, non è trasparente l'utilizzo di quelle librerie... Le uso pure io, sia chiaro, ma non mi dispiacerebbe poterne fare a meno...

Antsm90

Ah vero che ora c'è Swift, ai tempi usai Objective-c, e quello davvero ti fa chiedere se ti sei risvegliato negli anni 90 (magari :p )

fillobotto

Versione minima 4.1 e si include il 90% dello share. Con la support library l'unico punto che può creare criticità in un'applicazione media sono i permessi.

icos

Bisogna sempre capire quel 20% come usa il dispositivo e se la tua app/servizio e' potenzialmente utile anche per loro. Se sviluppi un client di messaggistica allora cerchi di ampliare il piu' possibile, se stai sviluppando un videogioco magari concentri gli sforzi altrove perche' ci sono buone probabilita' che quel 20% siano dispositivi piuttosto datati e non useranno comunque la tua app.

Vedrai che tra 1-3 anni anche Google lo capirà e presenterà una cosa simile a Xamarin, ovvero una Libreria che automatizza l'uso delle "support library" che a loro volta automatizzano l'uso delle librerie di Android.
Come se le app non fossero già lente di suo grazie a Java!

stiga holmen

Sono andato a vedere gli XAML di MS...non mi sembrano tanto diversi rispetto all'XML che usi per le interfacce di Android a prima vista. Mi potresti dire i grossi vantaggi si XAML rispetto ad XML di Android? GRAZIE.

msdn. microsoft. com /it-it/library/ms752059(v=vs.110).aspx

stiga holmen

Cioè sbattersi e creare una libreria per supportare indifferentemente dalla versione del sistema operativo, quasi tutte le ultime novità in fatto di stile e funzionalità ti pare un workaround?

Io lo vedo come supporto continuo , indipendente dall'aggiornamento dell'OS che molti produttori si dimenticano di fare ai propri dispositivi....

Sono contento a vedere chi come me capisce che Android é nato frammentato e di anno in anno é diventato più caotico :)
Vuol dire che la vedi come me :)

stiga holmen

Conosci la SupportLibrary? LOL

Luca

E' vero, esistono le support apposta, è il workaround per eccellenza da parte di google! E scusa se lo dico, ma che palle!

Luca

Se ti dicono di fare una cosa, tu fai quella cosa... Non è che prendi e decidi di alzare la versione minima così... Lo fai su un progetto tuo e se non ti va di perderci troppo tempo dietro, perché se poi è nel tuo interesse aumentare l'utenza, sceglieresti anche tu di non farlo, soprattutto quando quel 20% sono milioni di possibili utilizzatori della tua app/servizio...

SteDS

Ma anche no, esistono apposta le support library. Si riescono a implementare le linee guida più recenti preservando quasi tutta l'utenza (almeno da Android 4.0 in su). Io questo problema di scegliere fra qualità o utenza non lo vedo, unico appunto, le librerie a volte sono un po' caotiche e bisogna studiarle per bene quando vengono aggiornate, ma con un po' di sbattimento si riesce tranquillamente a utilizzarle e ottenere il risultato voluto.

Matteo85_b

Se valuto che il bacino di quel 20% non giustifica il costo di realizzazione dell' app per quel 20% certo che lo elimino. se stiamo a telefoni Microsof tra dispoditivi non aggiornati e hardware bassissimi è paragonabile. Apple tra versioni di ios e risoluzioni non è da meno ultimamente.

Luca

Bèh, guarda Microsoft e le sue UWP allora... Probabilmente sono l'esempio più lampante per quel che riguarda la flessibilità e android (con i suoi innumerevoli SDK) non è proprio paragonabile...
Appunto parlando di grafica e layout, se confrontiamo un XML di android con uno XAML di Windows, android rimane così arcaico che risulta difficile pensare come ancora, dopo anni, stiano a quel punto, soprattutto dopo aver conosciuto gli XAML...

Luca

Io non trovo difficile lavorare :)
Semplicemente lo faccio con una mano legata dietro la schiena ed ad un certo punto ci si ritrova sempre davanti alla scelta "tagliar fuori utenza o tagliar fuori qualità".

Luca

Fessi noi poveri sviluppatori che tempo fa combattevamo per tagliare fuori android 2.3 con il 9% di share... E tu taglieresti fuori il 20%?
Un dev non lavora solo e soltanto per se stesso, magari lavora per un cliente che ha richieste specifiche ed in quel caso quello che faresti tu (o io), non conta niente! Quella che potrebbe salvarti un po' al più è google, ma se ne sbatte altamente, a differenza di Apple e Microsoft che si ritrovano un panorama con una frammentazione minima e permettono agli sviluppatori di supportare al più le ultime 3 versioni, non le ultime 9...

Leox91

"Google si impegna sempre molto per fornire agli sviluppatori gli strumenti più semplici possibile" non ho letto il resto dell'articolo e mi son fermato qua.

E' chiaro che chi ha scritto l'articolo non sa un ca22o del panorama SDK che Google mette a disposizione, perché, a parte TensorFlow, il resto è "UNA CAG4ATA PAZZESCA" cit.

Samsung vende ancora oggi il suo Tablet 10" con Android 4.4 e lo comprano in tantissimi (me compreso) visto che il prezzo é di 120-140€.

Matteo85_b

e quanti di quel 20% installerebbero l' app?
probabilmente sono smatphone usati come feature phone

Grazie :D La mia percentuale in effetti riguardava Android 4.x.
Direi che non é irrilevante quel 30%!

Word_Life

Fai anche 30%

stewie321

Swift non mi sembra esattamente un linguaggio "vecchia scuola"... sulla flessibilità e i certificati è normale che sia così visto che è un sistema volutamente blindato.

Già solo il fatto che confondi i termini "librerie" con "template", mostra quanto ne capisci tu invece.

E' quello che fa Google appunto.

Ma perché ora é meglio? Google presenta nuovi tools, cerchi di usarli e poi li lascia in beta e pieni di bugs (sì, gli sviluppatori devono scervellarsi per capire come implementare workarounds) perché poi pensano alla versione 7.0. Cominci ad usare la versione 7.0 per i futuri telefoni e stessa storia... Google ti lascia con delle SDK buggate perché tanto poi ci sarà la versione 8.0.
Però vorresti che tutti possano usare la tua app, non solo chi compra i telefoni da 800€.

Non programmi Apps vero? Te lo dice Google sul portale quando scrivi una app: circa il 20% dei telefoni possiedono una versione inferiore a 5.0.

Recensione BlackBerry KeyOne: produttività, sicurezza e tastiera fisica

Recensione Zenfone AR: Tango phone e top di gamma da 899€

Recensione Motorola Moto Z2 Play, sottile, ottima autonomia e MOTO MODS

Guida acquisto: I migliori smartwatch con Android Wear | Luglio 2017