Недавно я наткнулся на статью о проблеме c Java-сериализацией объектов в Kotlin. Автор предложил решать её добавлением метода readResolve к каждому объекту, который наследуется от java.io.Serializable.

Этот способ выглядит абсолютно правильным, однако его поддержка может оказаться слишком проблематичной. С учетом того, что в нашем проекте эта проблема возникала только при использовании объектов внутри Bundle, мы решили использовать проверку через is для каждой ветки when-выражений в случае sealed классов.

Тем не менее, размышляя об этом, я никак не мог понять, почему Kotlin не генерирует readResolve в компиляторе, поддерживая singleton-свойства объектов. Мне казалось, что это работа для инструментов, а не для человека. Но раз Kotlin не добавляет эту функцию сам, мы можем ему помочь! Этим мы сейчас и займёмся.

Badoo разрабатывает несколько приложений, и каждое из них — это отдельный продукт со своими особенностями, менеджментом, продуктовыми и инженерными командами. Но все мы работаем вместе, в одном офисе и решаем похожие проблемы.

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

Тогда мы решили прийти к структуре, которая дала бы нам возможность переиспользовать фичи между приложениями. Теперь вместо разработки функциональности в отдельных проектах мы создаём общие компоненты, которые интегрируются во все продукты. Если вам интересно, как мы к этому пришли, добро пожаловать под кат.

За последние два года Android-разработчики в Badoo прошли длинный тернистый путь от MVP к совершенно иному подходу к архитектуре приложений. Мы с ANublo хотим поделиться переводом статьи нашего коллеги Zsolt Kocsi, описывающую проблемы, с которыми мы столкнулись, и их решение.

Это первая из нескольких статей, посвящённых разработке современной MVI-архитектуры на Kotlin.