Comments 12
Да и RecyclerView тоже не сохранил бы позицию скролла автоматически.
Это распространенное заблуждение. RecyclerView, как и любой другой скроллящийся контейнер в Андроиде, сохраняет свою позицию скролла автоматически при наличии id. Затем во время первого onLayout он пытается в эту позицию проскроллить. Если к этому моменту не передать данные, позиция потеряется. Конкретно у RecyclerView этим всем занимается LayoutManager, можете посмотреть сырцы.
Причина, по которой у вас это не работает, кроется в том, что вы неправильно передаете данные адаптеру после переворота экрана (или don't keep activities). Скорее всего у вас используется что-то типа handler.post(this::setData), возможно неявно, поэтому данные прилетают после первого onLayout.
У меня есть небольшой пост на эту тему.
Молодец, интересную тему описала. Но более интересный вопрос с службами(сервисами). Их кажется нет пока тоже. Напиши про них. Точнее как делать сервисы без плюшек из коробки ?
Как ни странно, тимлид ревьюил.
С большим количеством замечаний согласна, спасибо что указали (1, 2, 3, «Может быть Navigator должен быть Restorable», 6, 9)
«использование статических классов вот так это вообще антипаттерн», 7, 8 — мне думалось что для изложения материала в статье следует максимально упрощать, чтобы читатель не заморачвался на что-то помимо основной идеи. То есть все это служит для иллюстрации, и понятно что не должно использоваться в реальном приложении как есть. Но, судя по вашей реакции, это так себе позиция, и возможно стоит либо встявлять сноски формата «это допущение, для реального проекта можно было бы сделать таким-то образом», либо делать пример более многословным.
5 — не уверена, что правильно поняла, что вы имели в виду. Если поясните, будет здорово (лучше я буду выглядеть тупо (да все равно ведь уже успела), чем в итоге не пойму :))
Если это было про то и дело мелькающее «extends» в виджетах и их состояниях, так эта лошадь не моя, такую реализацию требует flutter.
По поводу «стоит ли заморачиваться» — на мой взгляд стоит, так как это достаточно частый кейс либо на слабеньких девайсах, либо на тех, которые пытаются оптимизировать батарейку.
И немножко не по теме обсуждения: мне кажется, что «агрессивная» подача в целом менее эффективна, чем доброжелательная (Разумеется, вы вовсе не обязаны быть любезным с кем бы то ни было, делайте как вам больше нравится.)
6) Зачем в кросплатформенном фреймворке сохранять что либо нативно? Неужели нет кросплатформенного storage для хранения данных? Конечно есть.
Ну да, плагин shared_preferences.
Разве автор не его использует?
Мне кажется вы неправильно готовите flutter. В нём пользовательский интерфейс — это отражение состояний (state), сам по себе он и не должен сохраняться, это должен реализовывать программист. Вопрос только в том, как именно сохранять состояния.
У flutter сейчас есть 3 плагина, которые можно использовать для персистентности:
Shared preferences https://pub.dartlang.org/packages/shared_preferences — самый подходящий, если нужно просто сохранить небольшое состояние интерфейса.
SQFLite для данных побольше.
Firebase с возможностью хранить в сети. Тут точно не нужен.
В принципе, этого достаточно. Хотя очень хотелось бы увидеть какой-нибудь синтаксический сахар для автоматического сохранения данных состояния. Через аннотации, например.
Не знаю как там в iOS и Flutter, но если бы в Андроиде не было автоматического сохранения состояния вьюх, фрагментов, стека активити и прочего-прочего, было бы очень больно жить.
Соответственно хотелось бы, чтобы Flutter тоже умел все сохранять так, как это делает нативный SDK.
Здесь речь не о персистентности, а о сохранении состояния между переходами в жизненном цикле компонентов.
Порхающие* велосипеды. Что делать с сохранением состояния во Flutter?