Владимир, то есть никакой цели нет, просто с++ потому что это круто? Для написания программ под десктоп есть нормальные языки(С#, Java, Kotlin). Написание движка это вообще вещь в себе. Для нормального движка нужны сотни человеколет и миллионы долларов.
Илья Колпаков, я же тебе говорю - это определенное поведение, они его выкатили в релиз, и теперь должны поддерживать. Никакой проблемы починить это я не вижу. Достаточно провалидировать, что на всех путях выполнения инициализация происходит только один раз. Может я чего-то не знаю, конечно.
BitNeBolt, у нас Стейт живёт примерно столько же, сколько контроллер. Когда нужно сохранить временно в бандл, он тоже сохраняется, поэтому он Parcelable. Вместе с аппликейшн он, конечно, не живёт.
По сути, каждый экран(контроллер) имеет свой Стейт. Есть большие фичи, в которых много экранов, тогда Стейты этих экранов объединены в общем Стейте фичи(открой в Яндекс.Картах поиск, или маршрут, это примеры таких больших фичей). Экраны реализованы в дочерних контроллерах, а каждая фича имеет один контроллер-точку-входа.
Маппер, таким образом, обычно один на экран. Он очень легковесный, у него минимум зависимостей. Это не аксиома, может быть несколько мапперов на один экран, если Стейт очень сложный.
Что такое StateProvider это уже другой вопрос, в принципе, такую штуку можно вписать и в обычный MVP,и тогда этот провайдер может просто содержать в себе Publish/BehaviorSubject, в который презентер будет эмиттить измененный Стейт при любых действиях. Некоторое время мы так жили. Если презентер не слишком сложный, то ок получается.
Сейчас у нас почти всё написано на Redux(самописная реализация), и в его терминах Store<State> == StateProvider<State> + Dispatcher
Вообще Redux классная идея, рекомендую изучить. Кажется, для андроида есть какие-то реализации, но в принципе, ты можешь его и сам написать, там ничего сложного. У нас каждая большая фича имеет свой собственный инстанс редакса, привязанный к жизненному циклу контроллера. Редакс параметризуется стейтом. Классически всё приложение должно быть описано одним стейтом, но мы пришли к тому, что для нашего случая это не работает, потому что а) получаются циклические Стейты, б) все фичи знают друг о друге.
Всё, что я говорю про контроллеры, 1-в-1 переносится на фрагменты, это непринципиально.
Это не стоит того, чтобы заранее их изучать. Я на собеседованиях спрашиваю, знаком или нет, если да - в чём различия с новыми версиями. Если не знаком, это в минус не идёт.
Может есть более эффективный способ изучения Java, чем книги?
Прочитал первую книгу по джаве после трёх лет знакомства с ней(один год использования в проде, и два - в универе). Самый эффектиный способ изучения любого языка программирования - это писать код. Книжку почитаешь, когда станет понятно, где пробелы, что непонятно, что интересно понять.
