ок )

@InjectViewState  я ответил

надеюсь, что понятно расписал)

архитектура Чичероне продумывалась очень долго)

"возьмите имя класса и можно делать switch" - лишняя рефлексия.

"Для добавления в ваш вариант новой команды с дополнительным параметром (screenKey + Data + еще что-то) придется менять базовый класс Command - это оченьплохо, когда расширение требует изменения базовых классов" - не обязательно менять базовый класс, можно просто не использовать не нужные поля, но в большинстве случаев screenName нужен.

Как в ваш вариант добавить команду: MagicAnimationForward(ScreenKey, InitData, Animation) ?

Вы, я смотрю, любите вынимать фразы из контекста. Не надо так

Наследовать от Command и добавить нужные геттеры и сеттеры

И? Выходит что часть надо будет делать наследованием, а часть добавлением типа

Только лишняя сложность архитектуры

Хм, ну да.

Ну ок, я Вас понял.

Ко всему вышесказанному хочу добавить, что может свитч м проще читается, но по всему коду Command(type) - гораздо менее читабельно. Представьте, если бы нам пришлось прогать указывая всегда Object с типом.... Типа Object(Type.STRING), Object(Type.BOOLEAN) и тд. Был бы ад. Типы объектов это хорошо. Это механизм языка и надо его юзать имхо.

Посмотрел я вашу библиотеку. Выглядит интересно. Но вот некоторые моменты я не могу понять. У вас комманды Forward и Replace в качестве параметров принимаюь Object. Это что получается - и вызывающая сторона, и принимающая должны знать каким это объект должен быть?

Например, в вашем примере вот здесь https://github.com/terrakok/Cicerone#predefined-navigators вызывающая сторона должна знать, что она туда может ложить только инты, иначе каст зафейлится. А ведь у меня может быть и больше одного параметра на вход. И значит структура данных усложняется.
А еще могут понадобиться данные для Shared Elements Transition. И их туда же засовывать? При этом всегда надо помнить, что если мы хотим что-то в этих данных поменять, то нужно это менять в двух местах? Или же вводить еще одну прослойку, которая и будет конвертить эти данные туда-обратно?

Как по мне, это ведет к не совсем красивому и очевидному коду. Или я чего-то не понимаю?

+

Взять, к примеру, Shared Elements Transition. Для них же можно завести свое поле, какой нибудь ArrayMap<String, View>, по умолчанию null. Тогда даже в вашем FragmentNavigator или SupportFragmentNavigator можно реализовать пробег по этой мапе и дляя всех элементов сделать что-то типа transaction.addSharedElement(value, key)

Отличный вопрос) Отвечаю:
на практике это выглядит так - при запуске нового экрана у его презентера есть статик класс InitParams именно его и создает и заполняет запускающий. Выбран именно Object для гибкости, чтобы там можно было передавать что угодно.
Здесь есть несколько спорный момент с тем, что при создании целевого экрана надо передать туда этот параметр, но не хотелось делать Serializable, так как передать параметр можно не только через аргументы.

возможно в будущем там будет интерфейс маркер, но пока не гарантирую

Я так понимаю, что вы бы хотели стандарт для передачи параметров. Например мапу ключ-значение. Но тогда мы очень ограничим использование...
а может это и хорошо)

Тоесть для того, чтобы с презентера А перейти на окно В, я должен в презентере А созать Object params = new B.InitParams(a, b)?