#ios #swift #firebase #firebase-realtime-database
#iOS #swift #firebase #firebase-база данных в реальном времени
Вопрос:
Моя цель — добавлять 1 каждый день к глобальной переменной в Firebase, чтобы отслеживать, сколько дней прошло. Я создаю приложение, которое каждый день предоставляет новые факты, и в 19:00 UTC я хочу, чтобы номер заявления о случае (глобальная переменная day day) увеличивался на 1.
Некоторые предложили мне сравнить две даты и получить дни, которые прошли таким образом. Если бы я это сделал, я мог бы жестко запрограммировать начальное время, когда я впервые хочу, чтобы приложение запускалось в 19:00 когда-нибудь. Затем, когда функция reached1900UTC() вызывается каждый день после этого, сравните ее с меткой времени Firebase того текущего времени, которое должно быть 19:00 . Теоретически, это должно показывать, что прошел 1 день или более дня.
Это лучшее решение на данный момент, благодаря @DavidSeek и @Jay, но я все равно хотел бы разобраться с одновременной записью, если у кого-нибудь есть решение на этом фронте. До тех пор я отмечаю ответ Дэвида как правильный.
Как мне сделать так, чтобы он не мог увеличиваться более чем на 1, если это вызовут несколько человек? Потому что я боюсь, что, когда, скажем, 100 человек вызывают эту функцию, она увеличивается на 1 для каждого человека, который ее вызвал.
Мое приложение работает по глобальному времени, и эта функция вызывается каждый день в 19:00 UTC. Поэтому, когда вызывается эта функция, я хочу, чтобы количество дней увеличивалось на единицу.
Комментарии:
1. почему бы вам просто не использовать NSDate? Например, если вы хотите, чтобы они считались с сегодняшнего дня, используйте текущую дату в качестве метки времени, а затем посчитайте даты между меткой времени и новой текущей датой?
2. Как вы сказали. Если у вас будет 100 человек, чтобы использовать ваше приложение, и каждый из них вызывает функцию в 19:00, которая ставит глобальную переменную 1, тогда это будет 100
3. Возникает такая же проблема, хотя я верю. Допустим, я сравниваю две временные метки, и если прошло 24 часа, добавьте 1. Разве это не добавило бы 1 для всех?
4. смотрите мой ответ. я думаю, что я тоже ответил на этот вопрос
5. Самое простое решение — сохранить узел с двумя дочерними элементами: counter и last_updated . Когда пользователь входит в систему, он сравнивает дату в last_updated с сегодняшней датой, и если это не сегодня, то увеличьте счетчик. Если это сегодня, не увеличивайте счетчик. Однако… Firebase не имеет логики на стороне сервера, поэтому все зависит от ежедневного входа хотя бы одного пользователя; что, если ни один пользователь не войдет в систему в день, что тогда? Возможно, вы захотите переосмыслить, как вы отслеживаете, сколько дней прошло, или даже почему это нужно сохранить. Может ли каждый пользователь отслеживать это на своем устройстве?
Ответ №1:
Вы должны использовать транзакции для обработки одновременной записи:
https://firebase.google.com/docs/database/ios/read-and-write#save_data_as_transactions
Комментарии:
1. Мне нравится эта идея. Я довольно новичок в firebase, есть ли шанс, что вы могли бы дать мне пример кода?
2. @bradfordgray проверьте предоставленную мной ссылку. Примеры кода как в ObjC, так и в Swift есть
Ответ №2:
Возможно, вы это знаете, но в Firebase нет способа автоматического увеличения счетчика, поскольку нет логики на стороне сервера, поэтому увеличение счетчика в 19:00 UTC невозможно без взаимодействия с клиентом, который в это время входит в систему.
При этом довольно просто заставить первого пользователя, который войдет в систему, увеличить этот счетчик — тогда любые другие клиенты, вошедшие в систему после этого, не увеличат его и получат доступ к новому контенту этого дня.
Взгляните на Zapier.com — это сервис, который может запускать триггеры, основанные на времени, для вашего приложения, что может сделать свое дело.
На момент написания этой статьи Zapier и Firebase плохо сочетаются друг с другом, однако существует ряд других опций запуска, которые Zapier может использовать с вашим приложением, продолжая использовать Firebase для хранения.
Еще одна мысль…
Вместо того, чтобы иметь дело со счетчиками и подсчетом дней, почему бы просто не хранить содержимое каждого дня в узле для каждого дня, и когда каждый пользователь входит в систему, приложение получает содержимое этого дня:
2016-10-10
fact: "The Earth is an Oblate Spheroid"
2016-10-11
fact: "Milli Vanilli is neither a Milli or a Vanilli. Discuss."
2016-10-12
fact: "George Washington did not have a middle name"
Это устранило бы ряд проблем, таких как счетчики, обновления, одновременная запись в Firebase, триггеры и т. Д.
Он также динамичен и расширяем, и пользователь может легко увидеть факты за этот день или факты за любой предыдущий день (-ы)
Комментарии:
1. Много хороших вещей, о которых стоит подумать. Я слышал о Zapier, мне нужно будет провести еще несколько исследований. Ваша идея с узлами хорошая. Конечно, все упрощает. К сожалению, я уже принял решение @Davids для работы. Несмотря на это, спасибо, что добавили к обсуждению и предоставили мне другое решение.
Ответ №3:
Я пытаюсь разделить ваш вопрос на разные разделы.
1) Если вы хотите использовать глобальную переменную для подсчета дней, скажем, с сегодняшнего дня. Затем я бы жестко установил временную метку в приложении, которое устанавливает NSDate.
Затем в моем приложении, когда мне нужно узнать, сколько дней прошло, я бы вызвал функцию, подсчитывающую дни от метки времени до NSDate() .
2) Если в вашем приложении есть функция, которая подсчитывает 1 в Firebase, то ваши опасения верны. Это будет считаться 1 для каждого пользователя, который использует приложение.
3) Если вы хотите, чтобы у каждого пользователя было количество переменных, начиная с того момента, когда они используют свое приложение, тогда я бы обработал регистрацию пользователя. Итак, у меня есть «идентификатор пользователя», а затем я бы установил такое дерево Firebase:
Идентификатор пользователя ——-> FirstOpen ——-> Дата
Таким образом, вы могли бы обрабатывать первое открытие каждого пользователя. Затем вы можете установить временную метку и вызвать 1 для каждого пользователя независимо. Потому что тогда вы устанавливаете 1 для каждого пользователя в их userId .child
Комментарии:
1. Я боюсь, что это решение использует NSDate(), работает с людьми в разных часовых поясах и дает людям возможность менять свои часы. Я подумал, что я мог бы получить временную метку firebase и сравнить ее с временной меткой при открытии приложения. Я думаю, что сначала я мог бы попробовать поработать с параллельными записями и посмотреть, может ли это сработать. Если я не смогу заставить параллельную запись работать, я вернусь и отмечу ваш ответ правильным.
2. Хорошо. Я бы не стал сильно беспокоиться о разных часовых поясах. Поскольку NSDate = NSDate. Неважно, в моем или вашем часовом поясе. 24 часа — это 24 часа. Если вам нужно, чтобы все использовали одни и те же «часы», я бы жестко запрограммировал NSDate, который использует один и тот же часовой пояс.
3. Единственное, что вы упомянули, это возможность того, что люди могут изменять время своего iPhone. Тогда я бы просто обработал дату с сервера…
4. здесь вы получаете время, основанное на значении на стороне сервера. Таким образом, никто не может подделать это, подделав время iPhone. обработайте это, и у вас будет одинаковое время для каждого пользователя. преобразуйте это время api в строку и сохраните его в userId. дочернее дерево и сравните его с меткой времени из серверного API, и вы обработали все возможности