Спасибо за труды. Хотелось бы понять как вы решаете такие кейсы:
Процесс убился и мы хотим что-то восстановить из Bundle'а при пересоздании Activity/Fragment. Как это может быть реализовано?
Предположим у нас есть какой-нибудь большой список, как часть State'а. Выглядит так, что каждый раз, когда нам приходит новый State, придётся прогнать список через DiffUtil или что-то подобное. Получим значительный оверхед на любое изменение состояния. Или такие вещи не включаются в State вовсе?
Обычно считается, что Clean и MV* — это ортогональные вещи (Clean — разделение бизнес-логики от фреймворков и системы, MV* — разделение presentation слоя). Мне показалось, что у вас часть бизнес-логики попадает в Feature и пр. классы фреймворка. Можете прокомментировать?
У нас тут какое-то недопонимание, я не понял что вы сейчас хотели сказать. При повороте окна + configChanges=«orientation» как раз ничего не пересоздаётся.
А отвечал я комментатору выше, почему configChanges=«orientation» не стоит по-умолчанию.
А если вам не надо сохранять данные или запускать/останавливать сервисы etc., то зачем привязывать ЖЦ activity к ЖЦ приложения?
Вообще странно, что по умолчанию GOOGL не сделал активити android:configChanges=«orientation» а фрагмент retain
Да нет в этом ничего странного. configChanges=«orientation» не стоит по дефолту, т.к. могут быть разные layout'ы для разных ориентаций. А фрагменты не retained, потому что содержат UI и должны пересоздаваться по такими же правилам, как и activity.
Может я вас не понял, но вы сами говорите, что у вас есть splash, который задаётся как windowBackground. У вас splash и является фоном для всех фрагментов? Или вы его в своей активити/фрагменте в рантайме подменяете, как только всё загрузилось?
Ну вот, получается, что если мы хотим Single-Activity, то получаем overdraw на каждом экране, т.к. нам нужно нарисовать фон ещё и поверх splash'а. Не смертельно, но всё же.
Отвечу на первый вопрос.
Можно повесить тему непосредственно, на root элемент в layout'е. И это будет даже лучше, чем указывать это в манифесте, т.к. всё что касается отображения конкретного окна будет в одном месте.
Более интересные вопрос что делать с штуками типа windowBackground. Тут видимо придётся либо использовать один background на всё приложение, либо в каждом фрагменте указывать фон явно.
Это не статья для начинающих, автор сам только начал писать под Android. Неокрепшим умам может быть очень вредно.
1. KeyBoardListener — гвоздями прибит к MainActivity, это какой-то жуткий анти-паттерн. Сама клавиатура должна предоставлять интерфейс, позволяющий подписаться на нажатие клавиш. А тут есть Listener, который знает о том как клавиатура внутри устроена, editText сам обновляет и MainActivity в конструктор принимает.
2.
«А почему мы не сделаем hide или не вызовем метод gone?» А я вам отвечу, это связано с жадным сборщиком мусора android. Если мы вызовем этот метод, то все указатели на кнопки пропадут, и все отклики не будет работать.
Видимо имеется в виду setVisibility у View. Конечно никакой «жадный» GC ничего не будет собирать, на все вьюхи останутся жесткие ссылки.
3. То что Вы назвали «библиотека в Android Java ExecutorServise» никакая не библиотека, а просто класс из стандартного пакета java.util.concurrent.
4. ExecutorThread прекрасен во всех отношенях.
Принимает TextView, что черевато утечками и крашами. Activity уже давно умрёт, а поток из executor'а будет всё ещё держать ссылку на TextView, а значит и на всю activity + будет ещё и пытаться что-то обновить на уже «мертвой» activity.
doWork каждый раз вызывает newSingleThreadExecutor, что убивает всю идею executor'ов.
Это прям беглым взлядом и про совсем ахинею.
Автор пару советов:
1. Сделайте клавиатуру отдельной вьюхой.
2. Почитатйте про Executor'ы, у вас нет понимания зачем они вообще нужны.
А отвечал я комментатору выше, почему configChanges=«orientation» не стоит по-умолчанию.
Да нет в этом ничего странного. configChanges=«orientation» не стоит по дефолту, т.к. могут быть разные layout'ы для разных ориентаций. А фрагменты не retained, потому что содержат UI и должны пересоздаваться по такими же правилам, как и activity.
Можно повесить тему непосредственно, на root элемент в layout'е. И это будет даже лучше, чем указывать это в манифесте, т.к. всё что касается отображения конкретного окна будет в одном месте.
Более интересные вопрос что делать с штуками типа windowBackground. Тут видимо придётся либо использовать один background на всё приложение, либо в каждом фрагменте указывать фон явно.
1. KeyBoardListener — гвоздями прибит к MainActivity, это какой-то жуткий анти-паттерн. Сама клавиатура должна предоставлять интерфейс, позволяющий подписаться на нажатие клавиш. А тут есть Listener, который знает о том как клавиатура внутри устроена, editText сам обновляет и MainActivity в конструктор принимает.
2. Видимо имеется в виду setVisibility у View. Конечно никакой «жадный» GC ничего не будет собирать, на все вьюхи останутся жесткие ссылки.
3. То что Вы назвали «библиотека в Android Java ExecutorServise» никакая не библиотека, а просто класс из стандартного пакета java.util.concurrent.
4. ExecutorThread прекрасен во всех отношенях.
Это прям беглым взлядом и про совсем ахинею.
Автор пару советов:
1. Сделайте клавиатуру отдельной вьюхой.
2. Почитатйте про Executor'ы, у вас нет понимания зачем они вообще нужны.