"La creazione di una versione Chrome OS della nostra app ha richiesto pochissimo sforzo. In 10 minuti abbiamo ottimizzato alcuni valori e ora i nostri utenti hanno accesso all’app su un'intera nuova classe di dispositivi. Si tratta di un'importante novità per i clienti aziendali che desiderano accedere all'app dai dispositivi desktop".
— Matthew Smith, CTO, AppTree Software
Firebase è stato lanciato oltre sei anni e mezzo fa come database, ma da allora si è espanso fino a divenire una piattaforma di diciotto (18!!) prodotti. Quest'anno abbiamo annunciato una gamma di nuove funzionalità che ti aiutano a creare app migliori e a sviluppare ulteriormente la tua attività. Abbiamo inoltre infuso Firebase con una maggiore potenza di machine learning in modo da rendere le app più intelligenti e più collaudate, e in modo che Firebase possa soddisfare meglio le esigenze degli sviluppatori delle grandi imprese complesse.
Poiché la fine dell'anno è il momento ideale per compilare liste top-ten, volevamo concludere l'anno con la "Top Ten List of Firebase launches". Ma poi ci siamo resi conto che avevamo più di dieci prodotti di cui volevamo parlare, e non ci andava di favorirne solo alcuni. Ecco quindi la nostra lista 2018 dei "Tredici lanci Firebase senza uno specifico ordine perché sono tutti fantastici a modo loro". Buona lettura!
In occasione di Google I/O, abbiamo lanciato una delle funzionalità più interessanti del 2018: ML Kit for Firebase, uno SDK di machine learning per Android e iOS. ML Kit ti consente di aggiungere la potenza del machine learning alle tue app senza dover avere una laurea in reti neurali. Fornisce una serie di soluzioni pronte all'uso per eseguire attività come riconoscere il testo nelle immagini, etichettare oggetti nelle foto e rilevare volti. Consentirà inoltre di usare modelli personalizzati a chi ama creare i propri (in questo momento le reti neurali artigianali sono molto in voga tra i data scientist hipster).
Le notifiche sono un ottimo modo per far ritornare gli utenti latenti alla tua app, ma come comunichiamo con quelli che invece utilizzano attivamente l'app? Nel 2018 abbiamo lanciato Firebase In-App Messaging per aiutarti a inviare messaggi mirati e contestuali agli utenti che adoperano regolarmente l'app. I messaggi in-app sono un ottimo modo per incoraggiare l'esplorazione e il rilevamento delle app, e guidare gli utenti verso la scoperta di nuove funzionalità nel prodotto o verso un importante evento di conversione.
Noi di Firebase siamo grandi fan della creazione di script che ci semplifichino la vita, sia che tratti di automatizzare le attività comuni o eseguire una logica personalizzata. In questa ottica abbiamo lanciato tre nuove API REST che puoi adoperare per automatizzarti la vita (almeno dalla prospettiva di Firebase). L'API Firebase Management è ottima per automatizzare attività come la creazione di nuovi progetti, l'API Remote Config REST può essere utile per personalizzare il modo in cui aggiorni i valori di Remote Config e l'API Firebase Hosting può essere usata per caricare automaticamente determinati file sul tuo sito.
Recentemente StackBlitz e Glitch hanno utilizzato l'API Management per creare integrazioni che consentono di implementare progetti direttamente su Firebase Hosting. Avvia un progetto, scrivi il codice, fai clic su qualche pulsante et voilà! Il tuo progetto Firebase è implementato sul Web!
Ottenere delle buone prestazioni è uno dei fattori chiave per la creazione di ottime esperienze per l'utente. Firebase Performance Monitoring raccoglie automaticamente le metriche delle prestazioni dove più contano: nel mondo reale.
Quest'anno il monitoraggio delle prestazioni è passato dalla versione beta alla disponibilità generale. Lungo il percorso abbiamo aggiunto nel dashboard alcune nuove funzionalità utili come il feed dei problemi per evidenziare gli importanti problemi di prestazioni riscontrati dagli utenti. Abbiamo anche aggiunto il supporto della visualizzazione di sessione per la classe di rete e le tracce, che consente di analizzare più nel dettaglio la singola sessione di una traccia, in modo da poter visualizzare gli attributi e gli eventi che hanno causato uno specifico problema di prestazioni.
Abbiamo anche rilasciato Firebase Predictions ed è ora disponibile per il pubblico. Predictions adopera il machine learning per segmentare in modo intelligente gli utenti in base alla previsione del loro comportamento. Lungo il percorso abbiamo aggiunto indicatori d'integrità e criteri di valutazione a ogni previsione, in modo da poter comprendere meglio quanto sia affidabile una previsione, così come i dati utilizzati per realizzarla. Abbiamo anche integrato Predictions con BigQuery per ottenere un maggiore controllo sui dati.
Iniziare a utilizzare Predictions è facile come premere un pulsante nella console. Prevediamo che ti piacerà da morire (scusa la battuta)!
Ormai non ci ferma più nessuno! Anche Cloud Functions è passato alla disponibilità generale, insieme alla sua nuova versione di SDK. Il nuovo SDK aggiunge funzioni "callable" che rendono molto più semplice chiamare le funzioni del server dal client, soprattutto se la funzione richiede l'autenticazione.
Cloud Functions ha anche rilasciato la nuova libreria firebase-functions-test per semplificare le funzioni di testing delle unità. Questa libreria si occupa delle configurazioni e disinstallazioni necessarie, consentendo una facile simulazione dei dati di test. Quindi, oltre ai semplici test standalone, è ora possibile scrivere test che interagiscono con un progetto di sviluppo Firebase e osservare il successo delle action come le scritture del database.
firebase-functions-test
Nel 2018 Firebase Test Lab è diventato multipiattaforma grazie all'aggiunta del supporto per iOS. Ora puoi scrivere ed eseguire test su dispositivi iOS reali in esecuzione nei nostri data center. Test Lab supporta dieci modelli di iPhone e iPad che eseguono sette diverse versioni di iOS, tra cui iOS 12.
Test Lab ha anche lanciato una serie di miglioramenti per Robo, uno strumento che esegue test completamente automatizzati sui dispositivi Android. Testare i giochi ora è più semplice, grazie alle "monkey action" (che possono fare clic a caso sul tuo schermo) e ai loop di gioco (che eseguono action pregenerate dagli script). Ora puoi personalizzare Robo persino di più se devi accedere all'inizio della tua app o aggiungere testo intelligente a un campo di ricerca.
Continuando il tema del testing, nel 2018 abbiamo lanciato gli emulatori per Firestore e Realtime Database, in modo da poter testare più facilmente le regole di sicurezza e incorporarle in un ambiente di integrazione continua. Questi emulatori vengono eseguiti localmente e consentono di testare le regole di sicurezza offline prima di passare alla produzione. Abbiamo anche creato una libreria di testing per semplificare il codice di test.
Sin dall'inizio Cloud Functions ha integrato fortemente le metriche di utilizzo importanti con Stackdriver, il potente servizio di monitoraggio di Google Cloud. Per ottenere un'integrazione persino maggiore, abbiamo collegato il Realtime Database a Stackdriver. Ora puoi visualizzare ancora più metriche di quelle fornite dalla Console Firebase, come il carico ripartito in base al tipo di operazione e le informazioni sui byte scaricati.
La vera potenza di questa integrazione è la capacità di impostare avvisi relativi a metriche o errori in modo da poter individuare e rispondere ai problemi prima che i clienti li notino.
A volte i dashboard della Console Firebase non offrono il livello di granularità o specificità dei data desiderata. È qui che entrano in gioco BigQuery, il data warehouse di Google Cloud, e Data Studio, lo strumento di visualizzazione dei dati di Google Cloud.
È possibile esportare i dati di Analytics in BigQuery già da tempo, ma quest'anno abbiamo aggiunto le integrazioni con Predictions e Crashlytics, in modo da poter esportare ancora più dati Firebase in un unico warehouse centrale. Ulteriori informazioni su come utilizzare Firebase e BigQuery insieme.
Cloud Firestore è il database di nuova generazione che offre molte delle funzionalità, che apprezzi in Realtime Database, combinate alla scalabilità e complessità di Google Cloud Platform. Nel corso del 2018 abbiamo lanciato una serie di miglioramenti di Firestore per renderlo più adatto alle imprese complesse.
Abbiamo anche aggiunto alcune funzionalità interessanti come l'ampliamento del supporto offline per l'SDK Web da una sola scheda a schede multiple del browser. Abbiamo lanciato un migliore supporto per la ricerca di documenti in base al contenuto dei loro array nonché svariate nuove posizioni per l'archiviazione dei dati di Firestore: Francoforte, Germania e Carolina del Sud negli Stati Uniti (e ne aggiungeremo altre nel 2019).
Per qualsiasi team, la Console Firebase è un elemento cruciale nel flusso di lavoro di Firebase. Quest'anno ci siamo impegnati moltissimo per renderla persino migliore. Riportiamo qui alcune delle nuove funzionalità.
Queste funzionalità ti rendono più produttivo e protetto nell'ambito della sicurezza e delle prestazioni dell'app. Non vediamo l'ora di aggiungere altre funzionalità alla console nel 2019!
È già da un po' che sentiamo dire che ti piacerebbe avere un'opzione per ottenere il supporto al livello aziendale di Firebase. Per rispondere a questa richiesta, abbiamo aggiunto il supporto per Firebase ai nostri pacchetti di supporto Google Cloud Platform (GCP), ora disponibili in versione beta.
Se hai già un pacchetto di supporto GCP a pagamento, la nostra versione beta ti consentirà di trovare risposte alle tue domande relative a Firebase sul canale di supporto GCP, senza costi aggiuntivi. Quando il nuovo supporto passerà alla disponibilità generale, includerà tempi di risposta target, gestione tecnica degli account (per il livello aziendale) e altro ancora. Ulteriori informazioni sul supporto GCP.
Se desideri mantenere il supporto di Firebase al livello gratuito, non preoccuparti: non abbiamo in programma di apportare modifiche all'attuale modello di supporto. Continua a rivolgerti al nostro fantastico team di supporto per qualsiasi esigenza o domanda!
È stato un anno eccezionale, e siamo pronti a ripartire alla grande a gennaio. Ti auguriamo un nuovo anno pieno di serenità. E se dovesse essere pieno anche di app mobili e Web, speriamo che userai Firebase! Buon lavoro!
Pubblicato da Purnima Kochikar, Director, Business Development, Games & Applications
Oggi abbiamo annunciato la nostra lista annuale Best of 2018, evidenziando i migliori contenuti su Google Play. Ti chiedi mai chi siano i creatori delle tue app e dei tuoi giochi preferiti, come PUBG MOBILE o Tasty? Bene, vogliamo dedicare un momento per celebrare loro, gli sviluppatori che hanno dato vita ai migliori giochi e app degli Stati Uniti del 2018. Quest'anno è stato ricco di intrattenimento, grazie alla creatività degli sviluppatori che hanno acceso la nostra immaginazione.
Ecco la lista completa degli sviluppatori che hanno dato vita ai migliori giochi e app del 2018 su Google Play.
Flutter Live si terrà il 4 dicembre, con un piccolo evento al Science Museum di Londra e un grande evento per il pubblico sul livestream globale. Celebriamo Flutter, l'SDK gratuito e open source di Google per la creazione delle app Android e iOS native di alta qualità, ottenute da una singola codebase.
Vai su g.co/FlutterLive e iscriviti agli aggiornamenti livestream. L'evento sarà trasmesso sul sito Web il 4 dicembre con un pre-show che inizia alle 16:00 GMT seguito poi dal keynote delle 17:00 GMT.
Puoi aggiungerlo direttamente al tuo Google Calendar facendo clic qui.
Organizzazioni in tutto il mondo ospitano feste gratuite per guardare e parlare di Flutter Live. Fra queste sessanta feste, trova quella più vicina a te, ed ecco la lista completa.
Flutter Live viene trasmesso dal Science Museum di Londra e stiamo cercando di ottimizzare l'esperienza in modo che possa raggiungere il più vasto pubblico di sviluppatori di dispositivi mobili possibile e offrire tutta la precisione e l'entusiasmo di un'esperienza personale al pubblico online globale. Indipendentemente da dove segui l'evento, ci sono tre modi per partecipare.
Flutter è open source e guidato dalla community. Apprezziamo la nostra community e vogliamo condividere le sue storie con il resto del mondo. Ecco perché ti diamo l'opportunità di farci conoscere la tua #MyFlutterStory. Queste sono le linee guida per inviarci la tua storia, che potrebbe essere presentata all'evento! Ti incoraggiamo anche a inviare un tweet del tuo video con l'hashtag #MyFlutterStory.
Andrew Brogdon del nostro team sarà presente per rispondere in tempo reale alle domande pubblicate con #AskFlutter. Twitta le tue domande e i tuoi commenti con questo hashtag e il tuo tweet potrebbe apparire sul livestream globale subito dopo il keynote.
Questo è l'hashtag generale per l'evento. Avremo un social wall che mostra costantemente i tweet in arrivo con #FlutterLive sia sul sito sia sul livestream. Assicurati di twittare con immagini, commenti, video e domande durante Flutter Live.
Siamo davvero contenti che parteciperai a Flutter Live con noi il 4 dicembre. Nel frattempo, seguici su Twitter all'indirizzo @flutterio e, per conoscere meglio Flutter, vai su flutter.io.
Pubblicato da Leo Sei, Product Manager di Android
Come probabilmente avrai sentito, in occasione di Android Dev Summit abbiamo annunciato l'espansione del supporto Android in modo che possa includere i Foldable, in attesa dei dispositivi prodotti dai nostri partner hardware, come ad esempio Samsung.
Ecco una serie di consigli e informazioni per garantire che la tua app offra un'esperienza utente eccezionale in relazione a questo nuovo fattore di forma (puoi anche vedere la specifica talk di Android Dev Summit qui).
Con questo nuovo fattore di forma, la tua app può passare automaticamente da uno schermo all'altro (ad esempio, quando pieghi o apri il telefono foldable).
Durante questa transizione, l'app riceverà una modifica della configurazione per il nuovo layout (e probabilmente anche della densità, in alcuni casi).
Per offrire un'esperienza utente ottimale passando da uno schermo all'altro, assicurati che l'app supporti correttamente la modifica della configurazione di runtime.
Come testarla: gli emulatori per i diversi dispositivi saranno disponibili a breve (ad esempio, in Q4 Samsung pubblicherà un APK per emulatori che si piegano/aprono, che dovrebbe funzionare sui tablet Samsung Galaxy S4 e sull'emulatore AOSP di Android Studio).
Attualmente se un'app è in modalità multi-finestra, ma non attivata, si trova nello stato OnPause.
Anche se offriamo indicazioni su come supportare la modalità multi-finestra, abbiamo notato che un notevole numero di app non gestisce lo stato onPause in base a queste indicazioni (video in pausa o interrotto, SMS non visualizzati ecc.).
Per aiutare gli sviluppatori a fornire la migliore esperienza multi-finestra possibile, e con il minimo sforzo, stiamo consentendo ai produttori di dispositivi di mantenere tutte le app in stato "resumed" quando adottano questa modalità in Android P.
Per attivare questo comportamento in Android P, aggiungi i seguenti metadati nel manifest dell'app:
<meta-data android:name="android.allow_multiple_resumed_activities" android:value="true" />
Nota: stiamo cercando di ottimizzare la compatibilità di questo comportamento nella prossima versione di Android.
Come testarlo: al momento non ci sono dispositivi che offrano questo comportamento, ma i produttori si stanno impegnando per aggiornare i dispositivi esistenti in modo che gli sviluppatori possano testarli. Resta sintonizzato per ulteriori novità da parte dei produttori di dispositivi.
A partire da Android 8.0 (API di livello 26), la piattaforma offre il supporto avanzato per display multipli. Se un'attività supporta la modalità multi-finestra ed è in esecuzione su un dispositivo con display multipli, gli utenti possono spostare l'attività da un display all'altro. Quando viene avviata un'attività, l'app può specificare su quale display eseguirla. Consulta qui la documentazione completa.
Come testarlo: puoi provarlo utilizzando l'opzione Developer options > Simulate secondary displays. Tieni presente che i display simulati non elaborano gli input.
Pubblicato da Leo Sei, Product Manager di Android Studio e R8
Gli sviluppatori Android sanno che le dimensioni dell'APK sono un fattore importante nel coinvolgimento degli utenti. Il code shrinking (compattazione del codice) consente di ridurre le dimensioni dell'APK eliminando il codice e le risorse inutilizzati, e di occupare meno spazio per il codice vero e proprio (noto anche come minification o obfuscation).
Ecco perché ci stiamo impegnando per migliorare il code shrinking e renderlo più veloce ed efficiente. Siamo felici di annunciare che il code shrinker di nuova generazione, R8, è disponibile in anteprima nella versione Android Studio 3.3 beta.
R8 esegue lo shrinking, il desugaring e il dexing, tutto in un solo passaggio. Se confrontato con l'attuale soluzione di shrinking Proguard, R8 compatta il codice più velocemente e migliora le dimensioni dell'output al tempo stesso.
I seguenti dati provengono dal benchmark dell'app Santa Tracker e i dettagli del benchmark relativi a questo progetto sono disponibili nel repository GitHub.
R8 è disponibile nella versione Android Studio 3.3 beta e segue le stesse regole di Proguard. Per provarlo, utilizza le seguenti impostazioni nel file gradle.properties del tuo progetto:
android.enableR8=true
Per i più audaci, R8 offre anche una modalità completa, che non è direttamente compatibile con Proguard. Per provarla utilizza le seguenti impostazioni nel file gradle.properties:
android.enableR8.fullMode=true
Questa modalità attiva altre ottimizzazioni, che possono ridurre ulteriormente le dimensioni dell'app. Tuttavia, potresti aver bisogno di alcune regole di mantenimento supplementari perché funzioni.
Abbiamo testato la correttezza e le prestazioni di R8 su un certo numero di app e i risultati sono stati promettenti, quindi prevediamo di adottare R8 al più presto come shrinker predefinito in Android Studio.
Ti invitiamo a provare R8 e a mandarci il tuo feedback. Puoi inviare un report sui bug utilizzando questo link.
Come abbiamo già accennato a maggio, le persone creano e utilizzano foto e video in molti modi diversi, quindi sosteniamo che sfruttarli meglio e farci ancora di più dovrebbe essere più semplice nell'ambito dei molti dispositivi e app che usiamo sempre. Ecco perché abbiamo prodotto l'API Google Photos Library, che offre la possibilità di creare esperienze di foto e video più intelligenti, veloci e utili all'interno dei tuoi prodotti.
Dopo un'anteprima di sviluppo ben accolta negli ultimi mesi, l'API Google Photos Library è ora disponibile per il pubblico. Se vuoi creare e testare la tua esperienza, inizia visitando la documentazione per sviluppatori. Puoi anche esprimere il tuo interesse aderendo al programma partner di Google Foto se stai pianificando un'integrazione più ampia.
Ecco una rapida panoramica dell'API Google Photos Library e come utilizzarla.
Sia che tu sia uno sviluppatore mobile, web o di backend, puoi utilizzare questa API REST per sfruttare il meglio di Google Foto e aiutare le persone a connettersi, caricare e condividere all'interno della tua app. Stiamo anche lanciando librerie client in diverse lingue che ti consentiranno di procedere più rapidamente.
Gli utenti devono autorizzare le richieste tramite l'API, in tal modo sono sempre al comando della situazione. Ecco cosa puoi aiutarli a fare:
Sfruttare il machine learning a vantaggio della tua app è semplice. Puoi utilizzare i filtri intelligenti, come le categorie di contenuti, per limitare o escludere determinati tipi di foto o video, e aiutare gli utenti a trovare più facilmente ciò che stanno cercando.
Ringraziamo tutti coloro che ci hanno fornito il loro feedback durante l'anteprima degli sviluppatori. Tutti i commenti ricevuti hanno contribuito a migliorare l'API. Sono disponibili le note sulla versione che accompagnano le nuove release della nostra API. Inoltre, se attualmente stai usando l'API Picasa Web Albums, ecco la guida alla migrazione che ti aiuterà a passare all'API Google Photos Library.
Recentemente ho fatto parte del fantastico team che ha lavorato all'app Android Google I/O 2018. È un'app complementare per conferenze che consente ai partecipanti e a chi si trova in remoto di cercare sessioni, creare programmi personalizzati e prenotare posti all'evento (se si ha la fortuna di essere lì!). Nell'app abbiamo sviluppato molte interessanti funzionalità animate che, a mio parere, hanno migliorato notevolmente l'esperienza utente. Il codice di questa app è appena stato reso open source e quindi vorrei segnalare alcuni dettagli e istanze di implementazione interessanti.
Ci sono 3 tipi di animazioni che abbiamo usato maggiormente nell'app:
Mi piacerebbe parlare più nel dettaglio di alcune di queste funzionalità.
Parte della funzione dell'app è creare entusiasmo e attesa per la conferenza. Pertanto, quest'anno abbiamo incluso un grande conto alla rovescia animato per marcare l'inizio della conferenza, visualizzato sia nella schermata di on-boarding sia nella sezione Info. È stata anche un'ottima opportunità per incorporare il marchio dell'evento nell'app dandole così più carattere.
Questa animazione è stata progettata da un motion designer e distribuita come serie di file JSON Lottie: ognuno di 1 secondo che mostra un numero animato in ingresso "in" e in uscita "out". Il formato Lottie ha semplificato il rilascio dei file in asset e ha persino offerto metodi convenienti come setMinAndMaxProgress che ci hanno permesso di riprodurre solo la prima o l'ultima metà di un'animazione (per mostrare un numero animato in ingresso o in uscita).
In generale è stato interessante gestire le varie animazioni del conto alla rovescia. Per ottenere questo obiettivo abbiamo creato una CountdownView personalizzata, che è un ConstraintLayout abbastanza complesso contenente diverse LottieAnimationViews. In questo caso abbiamo creato un delegato Kotlin per incapsulare l'avvio dell'animazione giusta. Ciò ci ha permesso di assegnare semplicemente un Int a ciascun delegato della cifra che doveva essere visualizzata e, a sua volta, il delegato eseguiva l'impostazione e l'avvio delle animazioni. Abbiamo esteso il delegato ObservableProperty per garantire che l'animazione fosse eseguita solo al variare della cifra. Quindi il nostro loop di animazione pubblicava un runnable ogni secondo (quando la visualizzazione era allegata) che calcolava la cifra da mostrare per ogni visualizzazione e poi aggiornava i delegati.
Una delle azioni chiave dell'app è consentire ai partecipanti di prenotarsi. Pertanto abbiamo messo questa azione in evidenza in un FAB nella schermata dei dettagli della sessione. Abbiamo ritenuto importante segnalare solamente che la sessione era stata riservata, una volta che l'operazione veniva completata correttamente sul backend (a differenza delle azioni meno importanti, come la valutazione di una sessione, per cui ottimisticamente l'UI veniva aggiornata subito). Ricevere una risposta dal backend poteva richiedere tempo quindi, per rendere il processo più dinamico, abbiamo creato un'icona animata per indicare che il processo è in corso e passare agevolmente al nuovo stato.
Il processo è complicato dal fatto che questa icona rappresenta diversi stati: la sessione che può essere prenotata, l'utente che può aver già prenotato, se la sessione è esaurita potrebbe essere disponibile una lista d'attesa o l’utente potrebbe essere già sulla lista d'attesa o, con l’avvicinarsi della sessione, le prenotazioni potrebbero non essere più disponibili. Ciò dà luogo a molte transizioni di stato da animare. Per semplificare queste transizioni, abbiamo deciso di passare sempre attraverso uno stato "in corso", ossia la clessidra animata mostrata sopra. Pertanto ogni transizione è costituita da una coppia di stati: stato 1 → in corso e in corso → stato 2. Questo approccio ha semplificato moltissimo le cose. Abbiamo creato ognuna di queste animazioni usando shapeshifter; vedi i file avd_state_to_state qui.
Per mostrare ciò, abbiamo utilizzato una visualizzazione personalizzata AnimatedStateListDrawable (ASLD). Se non hai mai usato ASLD, si tratta di una versione animata di StateListDrawable, come suggerisce il nome, che hai probabilmente già visto e consente, non solo di fornire diverse risorse drawable per stato ma anche transizioni tra stati (sotto forma di AnimatedVectorDrawable o AnimationDrawable). Ecco la risorsa drawable che definisce le immagini statiche e le transizioni in ingresso e uscita dello stato "in corso" per l'icona della prenotazione.
Abbiamo creato una visualizzazione personalizzata per supportare i nostri stati personalizzati. Le visualizzazioni offrono alcuni stati standard come Premuto o Selezionato. Analogamente, puoi definire il tuo stato e avere il Percorso di visualizzazione a tutte le risorse drawable mostrate. Abbiamo definito gli state_reservable, state_reserved ecc. Poi abbiamo creato un Enum dei diversi stati incapsulando lo stato della visualizzazione più eventuali attributi correlati, come la descrizione dei contenuti associati. La nostra logica business potrebbe semplicemente impostare il valore appropriato dall'Enum alla visualizzazione (tramite associazione dati) aggiornando lo stato della risorsa drawable che, a sua volta, ha avviato l'animazione tramite ASLD. La combinazione degli stati personalizzati e AnimatedStateListDrawable è stata un ottimo modo per implementare questo processo, mantenendo i diversi stati ai livelli dichiarativi e dando luogo a un codice di visualizzazione minimo.
Molte transizioni dello schermo funzionavano bene con le animazioni nelle finestre standard. La situazione era un po' diversa per la transizione nella schermata dei dettagli del relatore. Mostrava l'immagine dei relatori da entrambi i lati della transizione ed era una soluzione ideale per transizioni di elementi condivisi perché facilitava il cambio di contesto tra schermate.
Si tratta di una transizione di elementi condivisi standard che utilizza le classi ChangeBounds e ArcMotion della piattaforma su un ImageView.
L’aspetto più interessante è il modo in cui l'avvio di questa transizione si adattava al pattern Evento usato per la navigazione. In sostanza, questo pattern disaccoppia gli eventi di input (come l'azione di tocco di un relatore) dagli eventi di navigazione, incaricando ViewModel di rispondere all'input. In questo caso, il disaccoppiamento implicava che ViewModel esponesse un LiveData degli Eventi, che conosceva solo l'ID del relatore a cui indirizzarsi. L’inizializzazione di una transizione condivisa di elementi richiede la Visualizzazione condivisa che non avevamo a questo punto. Abbiamo risolto il problema memorizzando l'ID del relatore come tag sulla visualizzazione quando è associato, in modo che possa essere recuperato in un secondo momento per navigare verso una particolare schermata dei dettagli del relatore.
Una parte fondamentale dell'app per conferenze è filtrare gli eventi a cui siamo interessati. Ogni argomento viene associato a un colore per essere riconosciuto facilmente. Abbiamo anche ottenuto un ottimo design per il "chip" personalizzato da utilizzare per la selezione dei filtri.
Abbiamo preso in considerazione Chip di Material Components ma poi abbiamo optato per la nostra visualizzazione personalizzata che offriva un maggiore controllo sul display e sull'animazione tra i vari stati "selezionati". È stata implementata usando il disegno su canvas e uno StaticLayout per la visualizzazione del testo. La visualizzazione ha una singola proprietà di avanzamento [0-1] che indica la modalità selezionata-deselezionata. Per cambiare lo stato, il valore viene animato e la visualizzazione viene invalidata, consentendo al codice di rendering di interpolare linearmente le posizioni e le dimensioni degli elementi in base a ciò.
Inizialmente, durante l'implementazione, ho fatto in modo che la visualizzazione implementasse l'interfaccia Checkable e ho avviato l'animazione quando il metodo setChecked impostava un nuovo stato. Poiché si visualizzavano più filtri in un RecyclerView, ciò ha avuto lo sfortunato effetto di eseguire l'animazione se il filtro selezionato si spostava "out" e la visualizzazione veniva riassociata a un filtro non selezionato che si era spostato "in". Ops. Abbiamo quindi aggiunto un altro metodo per avviare l'animazione che ci permettesse di distinguere tra l'attivazione da clic e l'aggiornamento immediato quando si associavano nuovi dati alla visualizzazione.
Inoltre, quando abbiamo introdotto questa animazione toggle, abbiamo scoperto che si trattava di una procedura di janking, ovvero che comportava la perdita di fotogrammi. Era colpa del mio codice di animazione? Questi filtri sono visualizzati in un BottomSheet davanti alla schermata del programma principale della conferenza. Attivando un filtro, avviamo la logica del filtro da applicare al programma (e aggiorniamo il numero di eventi corrispondenti nel titolo del foglio del filtro). Dopo un'analisi approfondita di systrace abbiamo individuato il problema, ossia che quando i filtri venivano applicati, il ViewPager di RecyclerViews, che mostrava il programma diligentemente, si attivava e aggiornava in base ai dati appena forniti. Ciò determinava l'ingrandimento e l'associazione di diverse visualizzazioni. Tutto questo lavoro stava facendo saltare il budget dei fotogrammi... ma il programma di aggiornamento non era visibile perché era nascosto dal foglio del filtro. Abbiamo deciso di ritardare l'utilizzo del filtro vero e proprio fino a quando non veniva eseguita l'animazione, e quindi abbiamo rinunciato a una maggiore complessità di implementazione a favore di un'esperienza utente più fluida. Inizialmente ho implementato questa funzionalità usando PostDelayed ma ciò ha causato problemi durante i test dell'UI. Invece abbiamo cambiato il metodo che ha avviato l'animazione per accettare un lambda da eseguire alla fine. Ciò ci ha permesso di rispettare meglio le impostazioni di animazione dell'utente e testare correttamente l'esecuzione.
Nel complesso, penso che le animazioni abbiano davvero contribuito all'esperienza, al carattere, al branding e alla reattività dell'app. Speriamo che questo post abbia contribuito a spiegare sia il motivo sia il metodo utilizzati, e a fornirti buone indicazioni su come implementare le animazioni.
Animazione in un programma è stato originariamente pubblicato su Android Developers del blog Medium, utile per continuare la conversazione e offrire feedback su questa storia.
Attualmente Crashlytics elabora più di 3 miliardi di eventi al giorno per i nostri sviluppatori e li distilla in una serie di problemi strategici e actionable nel dashboard. Nel corso degli anni abbiamo ricevuto migliaia di richieste relative a come conoscere meglio i dati di arresto anomalo, ed è per questo che ora siamo particolarmente lieti di offrirti la possibilità di esportare i dati Firebase Crashlytics in BigQuery per un'analisi più approfondita!
Con pochi clic nel dashboard di Firebase Crashlytics puoi abilitare le esportazioni giornaliere di tutti i dati raw di arresto anomalo in base all'app o al progetto. Ciò include le tracce dello stack, i registri, le chiavi e qualsiasi altro dato di arresto anomalo.
Il dashboard Crashlytics conserva i dati per 90 giorni. Con BigQuery possiedi le politiche di conservazione e cancellazione che consentono al tuo team di monitorare più facilmente le tendenze dei dati di stabilità anno dopo anno.
BigQuery offre anche la possibilità di esportare dati in formato CSV, JSON e Avro. Ciò contribuirà a semplificare qualsiasi richiesta di estrazione dati GDPR che potresti ricevere.
Fino a ora, la visibilità nei report sugli arresti anomali tramite metadati personalizzati, come Experiment ID o un breadcrumb Analytics, è stata limitata, rendendo difficile l'identificazione delle varianti con minore stabilità in un esperimento o il livello di gioco con il maggior numero di arresti anomali. Ora, quando esporti i dati in BigQuery, è facile eseguire tutte le analisi approfondite che desideri per poi visualizzare il report con Data Studio o qualsiasi altro sistema aziendale utilizzato.
Ad esempio, supponi di configurare il tuo gioco Android in modo da poter registrare a quale livello avviene l'arresto anomalo con:
Crashlytics.setInt("current_level", 3);
Quando esporti i tuoi dati Crashlytics in BigQuery, puoi visualizzare la distribuzione degli arresti anomali per livello grazie a questa query:
#standardSQL SELECT COUNT(DISTINCT event_id) AS num_of_crashes, value FROM `projectId.crashlytics.package_name_ANDROID`, UNNEST(custom_keys) WHERE key = "current_level" GROUP BY key, value ORDER BY num_of_crashes DESC
Se sei già un utente Fabric, puoi accedere all'esportazione BigQuery e a tutte le altre funzionalità di Firebase, collegando la tua app al dashboard Fabric. Dai un'occhiata a questo link per scoprire ulteriori dettagli e consultare la documentazione.
Speriamo che questo miglioramento renda ancora più facile l'accesso ai dati dei tuoi report sugli arresti anomali e al debugging efficace della tua app! Come sempre, se hai domande, puoi trovarci su Twitter e su Stack Overflow. Buon debugging!
*Alcuni paesi non sono ammessi al programma della community degli sviluppatori, consulta i termini e le condizioni.
