The post has been translated automatically. Original language: Russian
Imagine a thousand-page book with no content. To find the right chapter, you'll have to scroll through it all. With the content, it takes seconds. The index works the same way in the data.
When there are a hundred records in the table, the search is fast in any way. When there are ten million records, the search method becomes crucial.
Without an index, the program looks through the records one by one. With the index, she immediately knows where the right thing is.
The index is based on the fields that are most often searched for: order number, phone number, date.
There is a price for speed. The index takes up space, and it needs to be updated with each new entry. Therefore, indexes are not made for all fields, but only for those used in the search.
The order of the fields is also important. The city and date index helps you search by city, but it doesn't help you search by date alone.
The rule of thumb is simple: look at the most frequent data queries and build indexes for them. Usually there are few such requests, and they give almost all the winnings.
Do you know which five requests to your data are performed most often?
Человек заходит в метро, связь пропадает, и приложение либо продолжает работать, либо превращается в пустой экран. Разница не в качестве связи, а в том, как приложение устроено.Основная идея простая. Приложение хранит копию нужных данных у себя на устройстве и показывает её сразу, не дожидаясь ответа сервера. Связь появилась, данные обновились.Из этого следует приятный побочный эффект. Даже при хорошем интернете приложение выглядит быстрее, потому что список открывается мгновенно из своей копии, а обновление подгружается уже потом.Сложнее с действиями пользователя. Человек отметил задачу выполненной, а связи нет. Действие сохраняется в очередь на устройстве и отправляется, когда соединение вернётся. В интерфейсе полезно показывать, что изменение пока не отправлено.Здесь появляется главный вопрос: что делать, если за это время данные изменились на сервере. Вариантов немного. Можно считать правильным последнее изменение по времени. Можно оставить решение за пользователем и показать оба варианта. Можно запретить изменение отдельных полей без связи. Выбор зависит от того, насколько дорога ошибка.Есть и то, о чём легко забыть. Копия данных на устройстве занимает место, поэтому её размер стоит ограничивать. Обычно хватает последних записей и того, что человек открывал недавно.И самое важное для пользователя это честность интерфейса. Понятная отметка о том, что данные показаны на такое-то время и обновятся при появлении связи, вызывает гораздо меньше вопросов, чем молчаливый устаревший список.А ваше приложение показывает данные из своей копии или каждый экран ждёт ответа сервера?