Доступ к FirebaseUser во всех штатах

Question

Я хотел бы знать, каков наилучший способ доступа вошедшего в систему пользователя во всех приложениях. и не делайте FirebaseAuth.instance.currentUser().then((result) {...}); во всех состояниях инициализации.

У меня есть две идеи: создать синглтон, который инициализируется при запуске приложения. И слушай onAuthStateChanged.

class GlobalDataAppli {
  static final GlobalDataAppli _appData = new GlobalDataAppli._internal();

  FirebaseUser user;
  IdTokenResult userToken;
  List<Post> myListPost;

  factory GlobalDataAppli() {
    return _appData;
  }

  GlobalDataAppli._internal();
}
final globalData = GlobalDataAppli;

Или я вижу Унаследованные виджеты. Но это будет делить моих пользователей только с дочерними виджетами, а не при смене видов.

Я также хотел бы поделиться списком постов в приложении. Действительно, одно и то же сообщение может быть видно на нескольких страницах, поэтому я хочу сохранить в памяти все отображаемые в данный момент сообщения, чтобы каждый виджет сообщений основывался на одной и той же переменной. Таким образом, изменение сообщения в представлении отражается в каждом представлении, в котором отображается это сообщение. (В настоящее время я передал этот список в качестве параметра для каждого представления, и он работает, но я знаю, что это неправильный способ сделать это).

Кто-нибудь знает лучшую практику для этого?

Answer 1

Наиболее распространенные варианты:

1. Использовать FirebaseAuth.instance.currentUser(). Хотя вы явно говорите, что не хотите этого делать, на самом деле это то, что я бы порекомендовал в качестве первой реализации, так как это, скорее всего, даст вам актуальное состояние аутентификации.

2. Прослушайте поток onAuthStateChanged , который гарантирует, что вы также сможете получать информацию, например, когда пользователь выходит из системы (например, если вы отключите его учетную запись в консоли Firebase). Это немного больше, чем просто получить currentUser().

3. Передать текущее пользовательское значение в SharedPreferences. Мне меньше нравится этот подход, так как он требует от меня написания кода для управления состоянием, который уже делает Firebase.

Если вы склонны не использовать один из первых двух подходов, вы ' Я хочу тщательно подумать, почему это так, и подтвердить эти предположения. Например: оба подхода работают из состояния локальной аутентификации после первого вызова, что означает, что производительность будет такой же хорошей, как и у любой альтернативы, которую вы реализуете сами.