Is there a specific reason to why the authStateChanges() listener was placed in the Constructor instead of the initState() ?
Currently, the FirebaseAuth.instance.authStateChanges().listen(...) call is placed inside the App widget's constructor. This can lead to multiple redundant subscriptions if the App widget is reconstructed, causing unexpected behavior such as:
- Multiple listeners being attached to the Firebase authentication stream.
- Unnecessary state updates to LoginInfo.instance.user and ChatRepository.user.
- Potential memory leaks, since the listener is not properly managed within the widget lifecycle.
Proposed Change:
Move the listener logic to _AppState.initState(), ensuring that it is attached only once when the widget is first created.
Store the subscription in a variable and properly cancel it in dispose() to prevent memory leaks.
Is there a specific reason to why the
authStateChanges()listener was placed in the Constructor instead of theinitState()?Currently, the
FirebaseAuth.instance.authStateChanges().listen(...)call is placed inside the App widget's constructor. This can lead to multiple redundant subscriptions if the App widget is reconstructed, causing unexpected behavior such as:Proposed Change:
Move the listener logic to
_AppState.initState(), ensuring that it is attached only once when the widget is first created.Store the subscription in a variable and properly cancel it in
dispose()to prevent memory leaks.