Arhn - архитектура программирования

Firebase iOS - снимок не обновляется, а база данных обновляется?

У меня довольно долго возникала эта проблема случайным образом, когда я физически смотрю на свою консоль firebase и вижу, что я удалил часть данных, а затем в коде я вызову print (snapshot.ref) и см. правильную ссылку (скопируйте и вставьте в браузер для двойной проверки), но каким-то образом, когда я пытаюсь получить значения снимка / итерации по его дочерним элементам, снимок содержит старые данные, которых больше нет в базе данных.

let key2 = ref.child(users).child("Employees").observeSingleEvent(of: FIRDataEventType.value, with: { (snapshot) in


            print(snapshot)

            for child in snapshot.children
            {

                self.nameList.append((child as AnyObject).value)
            }


     })

Итак, моя база данных выглядит так: (картинка обрезана, но под ней нет детей)

введите описание изображения здесь

Но каким-то образом, когда я распечатываю снимок, я получаю:

Snap (Employees) {
    0 = "";
    1 = "name1";
    2 = "name1";
}

Это меня какое-то время расстраивает, похоже, что это может иметь какое-то отношение к старым значениям моментальных снимков, которые каким-то образом хранятся локально или каким-то образом не видят самую последнюю версию базы данных. Если это важно, у меня есть аналогичные вызовы .observeSingleEvent в этом файле, одна копия, вставленная выше, вложена в другую. Даже если бы это была проблема синхронизации, я все равно не знаю, как это могло сделать напечатанное значение старым.

Любая помощь будет так оценена.


Ответы:


1

Такое поведение, по-видимому, является преднамеренным. Это так странно, что я на самом деле связался с поддержкой Firebase по этому поводу, и мне сказали, что они рассмотрят возможность изменения поведения или документации, но не могут обещать дату, и я должен следить за их Примечания к выпуску URL для обновлений.

Это имеет небольшой смысл, если рассматривать это с точки зрения SDK. Вы звоните observeSingleEvent. Для Firebase это означает, что они должны звонить вам только ОДИН РАЗ. Разработчики, вероятно, запутались бы, если бы метод с таким именем производил более одного обратного вызова, верно?

Но если у вас включена настойчивость, все становится немного странно. Как и в случае с observeEventOfType, Firebase немедленно предоставит вам значение на диске, чтобы вы получили самое быстрое обновление пользовательского интерфейса, но затем он вызовет сервер для получения более свежего значения, чтобы быть уверенным, что с этого момента у него есть самые свежие данные. Проблема в том, что, поскольку вы говорите ему не перезванивать вам с этими данными, он запомнит их (так что вы увидите это в будущем, поэтому это кажется сбивающим с толку), но не скажет вам, что они прибыли.

Методом проб и ошибок я обнаружил, что инстинктивное стремление использовать observeSingleEvent в любом случае может быть сбито с толку с помощью Firebase. И iOS, и Android используют механизмы представления «переработчик» для представлений таблиц / коллекций, так что в любом случае в памяти одновременно находится лишь несколько элементов, даже на экранах с большим количеством данных. Помимо этой встроенной эффективности платформы, сама Firebase, кажется, работает отлично, даже управляя множеством десятков ссылок в памяти за раз. В своих приложениях я просто использую observeEventOfType для всех моих сценариев использования, за исключением тех случаев, когда у меня есть очень конкретная, а не теоретическая причина, по которой я использую observeSingleEvent. Производительность приложения была минимальной, и при этом данные работают гораздо лучше, чем вы ожидаете.

24.02.2017
  • Извините, что вы столкнулись с этим Чадом. Я действительно проповедовал в течение нескольких лет (в значительной степени с тех пор, как мы запустили постоянство диска), что сохраняемость диска и прослушиватели событий с одним значением плохо сочетаются. В общем, мы рекомендуем использовать обычных слушателей / наблюдателей, потому что для этого и была создана наша база данных. Но особенно при использовании сохранения на диске: не комбинируйте его с однозначными прослушивателями событий. См. Мое более подробное объяснение здесь: / questions / 34486417 / 24.02.2017
  • Спасибо, Фрэнк. Следует ли нам изменить то, как здесь был дан ответ на этот вопрос? Ваш вопрос немного более подробный, и это в значительной степени дублирующий вопрос. ИМО, важная деталь заключается в том, что Firebase соблюдает НАМЕРЕНИЕ ИМЕНИ метода: он обеспечивает единственный обратный вызов. Период. Менее ясно то, что для получения обновленных данных по-прежнему будет выполняться вызов сервера, но сохраненные данные будут немедленно возвращены. 24.02.2017
  • Меня больше всего волнует, что люди могут найти самую лучшую информацию. Так что мы можем пометить ваш как дубликат, чтобы сделать это более явным. Но так как вы не нашли моего ответа вовремя, то и ваш вопрос тоже хорошо (tm). 24.02.2017
  • Это проясняет ситуацию, спасибо. Я лично считаю такое поведение довольно противоречивым, и я бы хотел, чтобы оно было другим, я попробую отключить постоянство. Могу я спросить, поскольку вы говорите, что сейчас используете много вызовов .observeEventOfType, вы никогда с тех пор не сталкивались с этой проблемой? Если я правильно помню, я пробовал использовать это вместо этого, и у меня были некоторые похожие проблемы. Всегда ли .observeEventOfType получает самое актуальное значение? Если я хочу продолжить использование ObserverSingleEvent, могу ли я просто отключить сохранение? 24.02.2017
  • Кроме того, когда я пытался использовать ObserveEventOfType, у меня были проблемы с тем, что если я изменял / удалял данные в будущем, какой-то другой слушатель, который все еще работал, пытался выполнить и выдавать ошибку нулевого указателя. Я бы хотел, чтобы был более простой способ просто прочитать часть данных в том виде, в котором они есть в настоящее время, а затем закончить. 24.02.2017
  • Новые материалы

    Коллекции публикаций по глубокому обучению
    Последние пару месяцев я создавал коллекции последних академических публикаций по различным подполям глубокого обучения в моем блоге https://amundtveit.com - эта публикация дает обзор 25..

    Представляем: Pepita
    Фреймворк JavaScript с открытым исходным кодом Я знаю, что недостатка в фреймворках JavaScript нет. Но я просто не мог остановиться. Я хотел написать что-то сам, со своими собственными..

    Советы по коду Laravel #2
    1-) Найти // You can specify the columns you need // in when you use the find method on a model User::find(‘id’, [‘email’,’name’]); // You can increment or decrement // a field in..

    Работа с временными рядами спутниковых изображений, часть 3 (аналитика данных)
    Анализ временных рядов спутниковых изображений для данных наблюдений за большой Землей (arXiv) Автор: Рольф Симоэс , Жильберто Камара , Жильберто Кейрос , Фелипе Соуза , Педро Р. Андраде ,..

    3 способа решить квадратное уравнение (3-й мой любимый) -
    1. Методом факторизации — 2. Используя квадратичную формулу — 3. Заполнив квадрат — Давайте поймем это, решив это простое уравнение: Мы пытаемся сделать LHS,..

    Создание VR-миров с A-Frame
    Виртуальная реальность (и дополненная реальность) стали главными модными терминами в образовательных технологиях. С недорогими VR-гарнитурами, такими как Google Cardboard , и использованием..

    Демистификация рекурсии
    КОДЕКС Демистификация рекурсии Упрощенная концепция ошеломляющей О чем весь этот шум? Рекурсия, кажется, единственная тема, от которой у каждого начинающего студента-информатика..