Local blog for Italian speaking developers
Consigli di design delle API per widget Flutter complessi
10 aprile 2019
Pubblicato da
Amir Hardon
Come chiedere a un widget di essere qualcosa invece di fare qualcosa
A volte, quando scriviamo widget che gestiscono uno stato non banale, può essere difficile mantenere l'API pulita. In molti casi, penso che questo sia dovuto al fatto che per le API raggiungiamo delle limitazioni di espressività in base a chi le ha create. Abbiamo avuto a che fare con casi del genere nel core team di Flutter e, anche se non si trattava di un problema estremamente complesso, trovo che non essere consapevoli di queste limitazioni possa essere svantaggioso. Riconoscere il problema e tenere conto delle limitazioni è stato utile per me, quindi vorrei condividere qui ciò che ho imparato.
Iniziamo da un esempio: diciamo di voler creare un widget WebView che mostri contenuti Web incorporati. Per ragioni di chiarezza, cominciamo da una superficie API minima. Vogliamo poter caricare un determinato URL e specificare se JavaScript sia abilitato. Vogliamo che l'API sia "Fluttery", quindi creiamo un widget con i parametri del creatore per questi 2 controlli. Che API semplice! Ogni sviluppatore di Flutter si sentirà subito a suo agio! Vuoi caricare la home page di YouTube? Basta creare il widget:
WebView(url: ‘https://youtube.com’ , javascriptEnabled: true)
Vuoi disabilitare JavaScript? Basta ricreare il widget:
WebView(url: ‘https://youtube.com’ , javascriptEnabled:
false
)
OK, diciamo che prima di ricreare WebView con
javascriptEnabled=false
, l'utente abbia fatto clic su un link e WebView si sia spostata su un URL diverso. Prima di ricrearla, WebView era su https://flutter.dev. Cosa dovrebbe dunque fare il widget quando viene ricreato con
(url: ‘https://youtube.com’ , javascriptEnabled:
false
)
? Deve tornare a https://youtube.com? O deve rimanere nella stessa pagina? Nessuna di queste due opzioni è ottimale poiché le diverse app potrebbero volere una cosa diversa in momenti diversi. L'app deve essere in grado di esprimere quale delle 2 possibilità deve verificarsi.
Un altro interessante punto di riflessione: come progetteresti un'API basata sui parametri del widget per aggiornare la pagina corrente?
Essere qualcosa o fare qualcosa?
Un'applicazione utilizza l'API di un widget per chiedergli di fare delle cose.
Possiamo classificare, anche se in modo un po' artificiale, ciò che un'applicazione chiede al widget di fare in 2 categorie:
Essere qualcosa
o
fare qualcosa
(a volte indicati rispettivamente come
trigger di livello
e
trigger di limite
).
Quando un'app dice a un widget di avere un determinato colore o, ad esempio, quando dice al widget WebView di avere JavaScript abilitato, penso che sia una richiesta del tipo "essere qualcosa", ossia "sii un widget con un colore di sfondo rosso". Le richieste di "essere qualcosa" si comportano secondo un accordo speciale tra l'app e il widget: una richiesta di "essere qualcosa" rimane valida per il widget fino a quando l'app fa una richiesta di essere qualcosa di diverso per lo stesso parametro. Tornando all'esempio del colore, il widget non può cambiare la proprietà del colore internamente o attraverso un qualsiasi altro meccanismo fino alla successiva richiesta di "essere qualcos'altro" da parte dell'app. Quindi, dopo che l'app chiede al widget di essere rosso, l'app sa che il widget sarà rosso (*) finché non gli chiederà di essere di un altro colore.
Le richieste di essere qualcosa sono buoni modelli per i parametri del widget, infatti la creazione di un widget con una serie di parametri è il modo in cui l'app gli chiede di essere qualcosa. Dopo aver creato un widget
Container(color: red)
, l'app sa che il contenitore è rosso finché l'app non ricreerà il contenitore con un parametro diverso. Pertanto non ha senso fare di nuovo la stessa richiesta di essere qualcosa, poiché è già garantito che il widget sarà conforme alla precedente richiesta.
Le richieste di
fare qualcosa
invece non implicano che il widget mantenga le garanzie appena descritte. La richiesta a un widget WebView di mostrare un URL specifico può essere modellata come la richiesta di "fare qualcosa". Non è un problema se l'utente naviga verso una pagina diversa e l'URL corrente non è più l'ultimo URL che l'app ha chiesto alla WebView di mostrare. L'app non presuppone che, solo perché ha chiesto a WebView di mostrare un URL specifico, lo stia ancora mostrando.
Le richieste di "fare qualcosa" non sono buoni modelli per i parametri del widget, perché il widget non può controllare quando e come vengano ricreati, non può "ricreare se stesso" con un nuovo URL ogni volta che l'utente fa clic su un link.
Quindi, come creiamo un'API con le richieste di "fare qualcosa"? Ciò che mi sembra che funzioni meglio finora è eseguire chiamate imperative. Per l'esempio dell'URL, significa avere un controller per WebView e fare una chiamata
webViewController.loadUrl(..)
. Esatto, non tutto deve essere controllato tramite i parametri del widget e non è un peccato utilizzare i controller (infatti Flutter utilizza alcuni controller nel framework, come
PageController
e WebViewController nel plug-in
webview_flutter
).
Una decisione importante
Tieni presente che è possibile ottenere la stessa funzionalità di un'API di tipo "fare qualcosa" con un'API "essere qualcosa". Ad esempio, nel caso dell'URL di WebView possiamo estrarre dal widget la gestione della proprietà Posizione corrente: quando l'utente fa clic su un link, il widget richiama un gestore di eventi che lo ricrea con la nuova posizione, lasciando sostanzialmente la gestione dello stato posizione corrente all'app. Nel caso di loadUrl, la gestione dello stato Posizione corrente è piuttosto complessa (immagina una pagina web con iframe multipli, ognuno con una posizione di scorrimento diversa. Un utente fa clic su un link in uno di questi iframe; il nuovo stato che l'applicazione deve comunicare alla WebView è tutt'altro che banale, ed è difficile da mantenere), quindi abbiamo deciso di far "fare qualcosa" all'API.
E se voglio mostrare solo uno specifico URL?
Continuando con l'esempio di URL WebView, per il caso semplice (e comune) in cui l'app vuole mostrare una singola pagina, senza link (ad esempio, la pagina della licenza), sarebbe utile evitare di richiedere allo sviluppatore di gestire l'istanza di un controller.
A questo scopo in webview_flutter abbiamo incluso il parametro del widget
initialUrl
. Quando viene creato il widget per la prima volta, viene caricato anche initialUrl. Le modifiche successive a questo valore vengono ignorate durante la ricreazione del widget.
Sebbene ciò sia utile per casi di utilizzo semplici, può confondere gli sviluppatori che tentano di modificare successivamente il valore initialUrl (vai a vedere questo
problema su GitHub
per capire quanto possa essere complesso).
Quando valuti se aggiungere un parametro
initialFoo
, tieni presente che nonostante sia utile in alcuni casi d'uso semplici, può essere fonte di confusione per gli sviluppatori.
Questo è ciò che volevo condividere nel post, avendo scoperto che separare questi tipi di richieste al widget ("essere qualcosa" o "fare qualcosa") aiuta nel design di API per widget complessi (come WebView o una mappa). Spero che ti sia stato utile!
* Questo non è del tutto corretto, ad esempio, quando consideriamo widget di animazione impliciti, come
AnimatedOpacity
, l'app non sa che il widget è impostato a un'opacità di "1.0" dopo aver ricreato il widget, ma può ancora essere considerata come una richiesta del tipo "essere qualcosa": sii il widget che anima con opacità di 1.0 (indipendentemente se l'animazione sia terminata o ancora in corso).
Etichette
Android
Firebase
machine learning
Google Cloud Platform
GDL
Eventi
Google Developers Live
Google Play
TensorFlow
App
Chrome
Cloud
api
GDLItalia
GDE
GDG
Google Assistant
iOS
Kotlin
Actions on Google
Deep Learning
AppEngine
AMP
BigQuery
Cloud Functions
Flutter
Android Studio
Google Developers Expert
Università
Google AppEngine
JavaScript
AI
Android Wear
GAE
Google Play Store
HTML5
Maps
security
Android App Development
AngularJS
IoT
Kubernetes
Annunci
Cloud Firestore
Cloud Machine Learning
Google I/O
Polymer
Android Things
Community
DevTools
Google App Engine
intelligenza artificiale
Entrepreneurship
Firebase Analytics
GSoC
Games
Google Cast
ML
open source
Crashlytics
Dart
Diversity
Drive
Google Data Studio
Google Play Games
TensorFlow Lite
Android Developers
Android O
Cloud Spanner
Cloud TPU
Compute Engine
DevFest
Google Compute Engine
Google Developers
Material Design
Mobile
PWA
Python
Startup
AIY Project
ARCore
Android Jetpack
AndroidDev
Androidq
Apps Script
Artificial Intelligence
Augmented Reality
Firebase Cloud Messaging
Google Cloud
Google Maps
Gsuite
IO19
ML kit
Research
VR
coding
unity
#io19
AR
Android Dev Summit
Android Developer
Android Q
Cardboard
Cloud AI
Coral
Developers
Dialogflow
Firebase Realtime Database
Gmail
Google AI
Google Cloud Messaging
Google ContainerEngine
Google Play Console
Kotlin Coroutines
NLP
Programming
Responsive Design
TensorFlowjs
Testing
WTM
Women
beacons
cloud storage
developer
node JS
student programs
women techmakers
API Cloud Vision
Add-ons
Android P
AndroidDevStory
Animation
AutoML
Brillo
Classroom
DSC
Database
Developer Student Clubs
Edge TPU
Fabric
Featured
Flutter Web
G Suite
GWT
GoLang
Google
Google Brain
Google Cloud Next
Google Container Engine
Google Developer Groups
Google I/O Extended
Graph
Hosting
Instant Apps
Keras
Livedata
Mobile Sites
Prediction
Privacy
Project Tango
SDK
Stackdriver
Tales
UI
Udacity
Virtual Reality
Web
Web Development
YouTube
analytics
android security
api.ai
courses
google io
indies
natural language processing
reti neurali
sign-in
young developers
2d Animation
3d
AIY
ARkit
Adversarial Learning
Alpha
Android App
Android App Developmen
Android App bundle
Android Architecture
Android Architecture Components
Android Auto
Android Automotive OS
Android Dev Summit Android Developer
Android Developer Challenge
Android Developers GooglePlayAwards
Android Development
Android Go
Android Instant App
Android Pie
Android Q Scoped Storage
Android Q audio
Android Styles
Android audio playback capture
Android codelabs
AndroidTV
AndroidX
Angular
Aogdevs
Api Design
App Development
App Distribution
Apps
Architecture
Architecture Components
Arduino
Best Practices
Betatesting
Bugs
C++
Certification
Cloud Anchors
Cloud Next
Cloud Run
Cloud Service Platform
Cloud Shell
Cloud Study Jam
Coached Conversational Preference Elicitation
Commerce
Community Connector
Computer Science
Consistency
Containers
Converge
Conversation Design
Crash Reporting
DLS Design
Dagger
Data Science
Databases
Dependency Injection
Design
Developer Communities
Developer Community
Developer Culture
Developer Story
Developing Media Apps
Development
Eager
Edge TPU Dev Board
Education
Emulatore Android
Error Message
Eslint
Europe
Firebase Extensions
Firebase Summit 2019
Firebasehosting
Flutter 1.5
Flutter at IO
FlutterDark
GCE
GDD
Game Development
Gboard
Gesture Navigation
Glass
Go
Google AI Quantum
Google App Script
Google Cloud Functions
Google Cloud billing
Google Coral
Google Developer Days
Google Home Hub
Google IOS Android
Google Identity Platform
Google Launchpad
Google Lens
Google Now
Google Photos
Google Play Devs
Google Play Indie Games Festival
Google Play Instant
Google Plus
Google codelabs
Google+
GoogleDevWeekly
GoogleLaunchpad
GooglePlay
Graphics
Healthcare
I/O
IO
IO19 Flutter
In-app Billing
Indie Games
Indie Games Festival
Indie games showcase
Indie showcase
Ingress
Instant Games
Issues
Java
Jetpack
Knative
Kotlin Beginners
Kotlin Everywhere
Kotlin codelabs
Lighthouse
Live Caption
Live Streaming
Localization
Location
M-Theory
Mondaygram
Monetization
NYT
NativeScript
Navigation
Neural Graph Learning
Neural Structured
Nodejs
OS
OS Updates
Olivex
One Time Codes
Online Education
PHA
Performance Monitoring
Policy
Posenet
Project Mainline
Project Treble
Quantum Computing Theory
Reactive Programming
Regression
Remote Config
Resonance Audio
Room
Scoped Storage
Semantics
Semi Supervised Learning
Serverless
Sms Retriever Api
Sms Verification
Speech Recognition
Swift
Tensorflow Core
Tensorflow Hub
Test Lab
Text
Tokenizer
Tpu
Transformers
UX
UX Design
UX Research
Universal Sentence Encoder
Unsupervised Data Augmentation
Unsupervised Learning
User Experience
Viewmodel
Voice
WWW
Wear OS
WebAssembly
Widget
Women in Tech
WomenTechmakers
android kotlin
app stability
assistant
audio recording
augmented faces
authsub
best practices and updates
billing
botnet
business
c++ games
cancer
chatbot
chrome privacy
codelab
codelabs
competition
daydream
designer
dominio .dev
error handling
event
firebase games
firebase gdc
firebase hosting
firebase unity
game center authentication
game testing
games authentication
gdc
google summer of code
googledevelopers
grow
hashcode
indie
indie developers
internship
kids
machine intelligence
machine learning accelerator
maker
multi-platform
nearby
oauth
openid
performance
persistent AR
privacy sandbox
prizes
prototype
purchase flows
queries
realtime
responsible AI
security rules
showcase
solutions challenge
startup africa roadtrip
startup times
students
summer of code
unity crashlytics
verify apps
win
Archivio Blog
2020
feb
gen
2019
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2018
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2017
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2016
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2015
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2014
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2013
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
Feed
Follow @GoogleDevsItaly
