Блог

Контекст: мы внедряем новостное приложение. На данный момент вы можете предположить, что новости одинаковы для всех пользователей и поддерживают порядок на основе установленных нами параметров (в соответствии с тенденциями и датой).

Проблема: мы не уверены, какая лучшая реализация для отслеживания того, что читают пользователи. Мы хотим иметь возможность настраивать способ, с помощью которого мы можем отслеживать, что пользователи читают, а что нет.

Предположение: можно предположить, что записи в базе данных расположены в порядке убывания в зависимости от времени.

Итак, идеальный сценарий таков: когда с сервера в приложении извлекаются сообщения: A, B, C, D, E, и пользователь читает A, B. Теперь пользователь видит C, D, E только при проверке следующих сообщений. Если они выполняют предыдущее, они видят сообщения в следующем порядке B-> A.

Кроме того, теперь, когда P, Q добавляются в базу данных, пользователь должен видеть следующие записи в порядке P-> Q-> C-> D-> E и так далее.

Пример: Предположим, что в нашем приложении сейчас 20 новостей, и Гэвин берет свой телефон и начинает читать из нашего приложения. В разгар его использования он оказывается занят какой-то другой работой, поэтому выходит из приложения после прочтения 5 новостных сообщений.

Сейчас перед нами стоит задача найти наилучший способ убедиться, что Гэвину не придется перечитывать 5 сообщений, которые он уже сделал.

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

Однако одна из проблем такого подхода заключается в том, что у нас может легко появиться 5 новых сообщений, когда Гэвин возьмет свой телефон и снова воспользуется нашим приложением. Итак, если у нас есть новости, основанные на дате, технически такой подход к индексации означает, что мы опускаем 5 непрочитанных новых сообщений вместо 5 прочитанных старых.

Мы также подумали о том, чтобы поддерживать три списка: прочитанные, непрочитанные и новые, чтобы мы извлекали только записи, которых нет в наших списках. Например, в моем первоначальном примере: A-B-C-D-E изначально находится в непрочитанном состоянии. Затем, после того, как пользователь прочитает A-B, чтение становится A-B. Между тем, когда P-Q добавляется в базу данных, P-Q добавляется в список непрочитанных записей как P-Q-C-D-E.

Как вы решаете эту проблему? Любые предложения приветствуются, поскольку мы думаем, что мы не думаем нестандартно, когда дело доходит до решения проблемы. Спасибо! 🙂

Когда я впервые прочитал проблему, решение, на мой взгляд, также имеет 2 разных списка, прочитанных непрочитанными, и новые добавляются в конец непрочитанных, а список непрочитанных отображается в обратном порядке, поэтому самые последние находятся вверху. Однако является ли это наиболее эффективным способом? Обсуждаемый. Например, если количество новых чисел сильно увеличивается, это приведет к неэффективности памяти. Но я предполагаю, что в целом небольшие числа.