![](http://webcf.waybackmachine.org/web/20200413082318im_/https://habrastorage.org/getpro/habr/avatars/36f/124/eac/36f124eaca7e5fc9a94d638d43cb1a47.png)
Дайджест интересных материалов для мобильного разработчика #340 (6 — 12 апреля)
- Блог компании Цифровые Экосистемы,
- Разработка под iOS,
- Разработка мобильных приложений,
- Разработка под Android
![](https://webcf.waybackmachine.org/web/20200413082318im_/https://habrastorage.org/webt/qe/ut/od/qeutodmnhc4o_drjuw0zpfyem9u.jpeg)
Любому продукту, который в данный момент находится в сторе, грозят релизы. Наш проект не является исключением. Мы работаем по методологии scrum, разработка делится на спринты, обычно спринты не привязаны ко времени, а делятся на временные отрезки, зависящие от скоупа спринта. По итогам спринта обычно проводится релиз приложения в стор, который включает в себя новые фичи и некоторый багфикс.
Однако, из-за специфики проекта не все фичи сразу попадают в релиз по завершению спринта. Из-за такого подхода появляются фичи, которые нельзя выпускать в прод. При всем при этом, никто не отменял критические баги, мелкие фиксы и просто выпуск готовых фич. Можно выделить несколько видов релизов:
В условиях постоянных релизов возникает вопрос: «Как же вести разработку?».
Ведь каждый разработчик должен делать задачи, делать ветки на эти задачи и куда-то по итогу их мерджить.
Привет! Меня зовут Алиса и мы вместе с командой https://meetups-online.ru/ продолжаем собирать он-лайн события в одном месте.
Когда только запустили каталог онлайн-митапов, то думали, что фронтендеры и тут будут впереди планеты. Ну, у них и сообщество в каждом городе, и вообще ребята активные. Но вот уже больше 100 ивентов на сайте, а лидируют совсем не они. А кто впереди можно понять из списка под катом.
Недавно я наткнулся на статью о проблеме c Java-сериализацией объектов в Kotlin. Автор предложил решать её добавлением метода readResolve
к каждому объекту, который наследуется от java.io.Serializable
.
Этот способ выглядит абсолютно правильным, однако его поддержка может оказаться слишком проблематичной. С учетом того, что в нашем проекте эта проблема возникала только при использовании объектов внутри Bundle, мы решили использовать проверку через is
для каждой ветки when
-выражений в случае sealed
классов.
Тем не менее, размышляя об этом, я никак не мог понять, почему Kotlin не генерирует readResolve
в компиляторе, поддерживая singleton-свойства объектов. Мне казалось, что это работа для инструментов, а не для человека. Но раз Kotlin не добавляет эту функцию сам, мы можем ему помочь! Этим мы сейчас и займёмся.