0
votes

Est-ce que SetState () se déclenche lorsque des variables et des données changent comme le flux et le streambuilder?

class _LocationScreenState extends State<LocationScreen> {
WeatherModel weather = WeatherModel();


String weatherMessage;
String weatherIcon;
String cityName;
int temperature;

@override
void initState() {
super.initState();
updateUI(widget.locationWeather);
}

void updateUI(dynamic weatherData) {
setState(() {
temperature=weatherData['main']['temp'].toInt();
var condition = weatherData['weather'][0]['id'];

cityName=weatherData['name'];
weatherIcon=weather.getWeatherIcon(condition);
weatherMessage=weather.getMessage(temperature);
});

}
Hi I am getting confused with what setState() does. If the value of temperature or condition or anything changes inside that of setState does setState() trigger itself to update the UI and build UI with updated temp or condition or do I have to invoke updateUI function myself to invoke setState and update the UI?

flutter dart setstate

0 commentaires

4 Réponses :

0
votes

SetState reconstruit la méthode de construction chaque fois que cela appelle.

SetState Ne jamais l'appeler, vous devez l'appeler. Si vous changez de valeur de votre variable et que vous n'avez pas utilisé SSTATE, il ne se réfléchira pas à l'interface utilisateur, de le faire, vous devez appeler SSTATE.

Lorsque vous vous mettez votre code dans UPTATEUI dans SETState, il mettra donc à jour l'interface utilisateur chaque fois que vous appelez cette méthode, où, comme si vous n'utilisez pas SSTATE, il ne reflétera pas les modifications de l'interface utilisateur.

2 commentaires

Alors Streambuilder aidera? Parce que pour le moment si je veux refléter des changements d'interface utilisateur avec modification de la température et de la condition, je dois redémarrer à chaud.

Non, vous pouvez appeler SSTATE chaque fois que vous modifiez la valeur de la variable que vous effectuez dans la méthode UpdateUI.

0
votes

Documentation stipule que STSTATATE (FN ()) CODE>, appelant SSTATE notifie le cadre que l'état interne de cet objet a changé d'une manière pouvant avoir une incidence sur l'interface utilisateur dans ce sous-arbre, ce qui provoque la Cadre pour planifier une version pour cet objet d'état.

Chaque fois qu'un ensemble d'instate appelé l'interface utilisateur sera programmé pour une construction basée sur le nouvel état. p>

 class _MyWidgetState extends State<MyWidget> {
  String text;

  @override
  void initState() {
    super.initState();
    text = "Hello";
  }

  void updateUI(String action) {
    setState(() {
      text = action;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Column(children: [
      Text(text, style: Theme.of(context).textTheme.headline4),
      MaterialButton(
          onPressed: () {
            updateUI("Pressed");
          },
          child: Text("Change state"))
    ]);
  }
}

0 commentaires

0
votes

SetState (): strud>

notifier le cadre que l'état interne de cet objet a changé. P>

Chaque fois que vous modifiez l'état interne d'un objet d'état, faites le Changement d'une fonction que vous passez à SetState: P>

setState(() { _myState = newValue; });

0 commentaires

0
votes

Nope, vous devez l'appeler afin de "re-dessiner" le widget d'état actuel. Je crois que la variable qui a changé n'a pas besoin d'être enveloppée à l'intérieur de l'ensemble de l'ensemble, tant que cela est changé avant la création de l'ensemble.

0 commentaires