• архитектура проекта делает упор на минимизацию использования динамической памяти. Если память и выделяется, она выделяется исключительно на инициализации подсистем
• использовать динамическую память нужно так, как будто не существует операционной системы, постоянно помнить о фрагментации. Удаление памяти происходит в строго обратном порядке создания (за этим следит простой механизм контроля удаляемых указателей)
• использование сторонних библиотек сведено к минимуму и должно быть аргументировано, зачастую это потенциальный источник фрагментации памяти
• игровая сцена представляет собою готовую для использования память, сгенерированная редактором уровней
• работа с объектами сцены игры ведется исключительно через идентификаторы, динамически создать объект невозможно
• использование fixed point вместо float
• мультиплатформенность
• официальный язык проекта — си

Вчера компания JetBrains выпустила релиз Kotlin 1.2. Новая версия — большой шаг на пути к тому, чтобы сделать Kotlin наиболее удобным инструментом для разработки всех компонентов современного приложения.

В версии Kotlin 1.1 мы официально выпустили поддержку JavaScript — возможность транслировать код на Kotlin в JS и выполнять его в браузере. В этой версии мы добавляем к этому возможность переиспользования кода между JVM и JavaScript. Теперь вы можете использовать одну и ту же реализацию бизнес-логики во всех компонентах вашего приложения — бэкэнде, фронтэнде в браузере и мобильном приложении под Android. Мы также работаем над библиотеками, которые в этом помогают — в частности, над кросс-платформенной библиотекой для сериализации.

• мультиплатформенность — чтобы иметь возможность писать мультиплатформенные библиотеки с использованием реактивного программирования и распространять их внутри компании;
  
• Null safety — система типов Kotlin защищает нас от «ошибки на миллиард долларов», так что значения null должны быть допустимы (например, Observable<String?>);
  
• ковариантность и контравариантность — ещё одна очень полезная особенность Kotlin, дающая возможность, например, безопасно привести тип Observable<String> к Observable<CharSequence>.
  

Привет! Меня зовут Юрий Влад, я Android-разработчик в компании Badoo и принимаю участие в создании библиотеки Reaktive — Reactive Extensions на чистом Kotlin.

В процессе работы мы столкнулись с тем, что в случае с Kotlin Multiplatform continuous integration и continuous delivery требуют дополнительной настройки. Необходимо иметь в распоряжении несколько виртуальных машин на различных операционных системах, чтобы собрать библиотеку полностью. В этой статье я покажу, как настроить continuous delivery для вашей Kotlin Multiplatform библиотеки.

1. Краткое описание шаблона MVI, постановка задачи и создание общего модуля с использованием Kotlin Multiplatform.
2. Интеграция общего модуля в iOS- и Android-приложения.
3. Модульное и интеграционное тестирование.

Flutter набирает популярность среди разработчиков. Большенство подходов в построении приложений уже устоялись и применяются ежедневно в разработке E-commerce приложений. Тема навигации опускают на второй или третий план. Какой API навигации предоставляет Фреймворк? Какие подходы выработаны? Как использовать эти подходы и на что они годятся?

Введение

Начнём с того, что такое навигация? Навигация — это метод который позволяет перемещаться между пользовательским интерфейсом с заданными параметрами.
К примеру в IOS мире организовывает навигацию UIViewController, а в Android — Navigation component. А что предоставляет Flutter?

Navigator

Экраны в Flutter называются route. Для перемещениями между route существует класс Navigator который имеющий обширный API для реализации различных видов навигации.

Привет, Хабр! Я Миша Игнатов, тимлид в компании Профи. Моя команда отвечает за клиентские мобильные приложения на Android и iOS. Мы используем Kotlin Multiplatform в production с 2019 года. Расскажу, почему мы выбрали именно эту технологию, как внедряли её, какие ключевые этапы прошли и какие сделали выводы.

Как и множество других компаний, мы в hh.ru с интересом приглядываемся к Kotlin Mobile Multiplatform. Особенно нас заинтересовал вопрос, связанный с удобством работы iOS-разработчиков с общим SDK. Наши iOS-инженеры пишут на Swift, поэтому нам важно было убедиться: то публичное API, которое мы сформируем, будет выглядеть на Swift так же удобно и классно, как и в Kotlin. Мы провели объёмный ресёрч, в рамках которого подготовили специальный репозиторий "Kotlin-Swift-Interopedia", которым и хотим поделиться с сообществом.

На портале документации KMM можно найти страницу, посвящённую интеропу между Kotlin и Swift. Но в ней не рассматриваются все возможные конструкции языка Kotlin-а, поэтому даже после чтения документации оставалось множество вопросов.

Как поведут себя abstract-классы? Что будет с sealed-интерфейсами? Удобно ли мне будет работать с лямбдами в качестве аргументов функций? Enum-ы превратятся в Swift-овые enum-ы?

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

Относительно недавно на Хабре анонсировали специальный инструмент, который может немного улучшить опыт iOS-разработчиков — плагин moko-kswift от компании IceRock. Но даже с его помощью не все боли могут быть исправлены прямо сейчас.

.NET Multi-platform App UI – фреймворк, который пишут профессионалы. Тем не менее, код некоторых его функций выглядит так, будто разработчики забыли о последствиях разыменования нулевых ссылок.