Как стать автором
Обновить
7
0
Dmitry Dronov @wardrone

Мобильная разработка

Отправить сообщение

Добрый день. Спасибо за статью. Хотелось бы добавить несколько уточнений, т к имею опыт работы в мобилках как в нативке (приложения под android, ios) так и в кроссплатформе (cocos2dx, unity3d, flutter)

  1. "Это связано с тем, что Kotlin Multiplatform вообще не поддерживает пользовательский интерфейс. Вместо этого она позволяет реализовывать бизнес-логику для приложений на Android и iOS."

    - Еще задолго до КММ для этого подходили C/C++ (c JNI мостиком на стороне android, зато с замечательной совместимостью на ios). На самом деле тут можно привести много примеров, компилируемых языков, которые мы можем использовать.

  2. "Для этих платформ потребуется прослойка между нативным и ненативным кодом."

    - Но ведь и для связи Kotlin и Swift нужно писать интерфейсы. На мой взгляд, это такая-же прослойка, как и каналы в Flutter

  3. "И в любом случае общий UI между платформами не является необходимостью. При обобщении UI требуется несколько итераций, чтобы сделать его и поведение приложения более нативными. Что, разумеется, требует дополнительных циклов разработки."

    - Действительно, качественный универсальный UX требует хороших специалистов (как дизайнеров, так и разработчиков). Но вот про дополнительные циклы разработки не соглашусь. Общий UI не является необходимостью, но это одна из точек экономии затрат на проекте именно из-за уменьшения циклов разработки/тестировния.

  4. "А поскольку Kotlin Multiplatform работает с нативными экосистемами каждой платформы, разработчики могут использовать инструменты и библиотеки, которые они всегда использовали"

    - Ребята, при желании это можно и к Flutter присоединить. Только вот незачем. Не кажется ли вам что просто мы все заждались Compouse for IOS (но тогда надо упомянуть что он так же на Skia)?

  5. "Любые ограничения, с которыми вы сталкиваетесь, всегда можно обойти с помощью Kotlin, Swift или любого другого языка, который удобен для решения конкретных проблем с наименьшим риском. Но в случае с Flutter вы должны оставаться верным только Dart, а с React Native — только JS."

    - Повторюсь, flutter взаимодействует с нативкой через каналы. И это очень просто, ну правда. К тому же, если команда созрела на кроссплатформу то придется опускаться и в kotlin и в swift. Без этого никак.

  6. "Вы должны писать на ненативном языке в ненативной экосистеме. В то же время в Kotlin Multiplatform очень легко писать собственный код на любом уровне абстракции и на любом уровне архитектуры"
    - Разработка под KMM != Разработке под Android и уж совсем далека от разработки под iOS, везде свои особенности, библиотеки и инструменты, которые придется изучать

Привет. Спасибо за вопрос.
Обычно в мобилках используется большая "тяжелая" база для серьезной бизнес-логики ( в таком случае нам необходим весь функционал работы с большими базами, например, какие-нибудь хитрые выборки) и легковесные базы, умеющие просто сохранять данные по ключу. 

В нашем примере Moor -«тяжелая» база со всеми возможностями но и с тяжелым и ресурсоемким движком. SharedPreferences - легковесная база (базируется на нативных легковесных решениях, с урезанным функционалом) но с легким запуском движка. Использование разных решений - это вопрос оптимизации мобилок. Бывают случаи, когда нет необходимости поднимать движок "тяжелой" базы, и сохранить какой-либо признак достаточно в легковесной базе.

И key-value и реляционные хранилища имеют свои преимущества в разных кейсах использования, которые актуальны для мобилок. Также отмечу, что использование 2 разных каналов общения с хранилищами, чуть повышает отказоустойчивость, а особенно в нашем самом проблемном кейсе - изолятах (бэкграунд сервис). Чем чаще выполняются параллельные запросы в Moor, тем больше она сбоит (что мы наблюдали в крашлитике), а SharedPreferences себя хорошо показывают в этом кейсе (за счёт нативной safe-multi-thread реализации)

Благодарим вас за ответ!

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

Вторая проблема читабельность контракта, если вы в одной части кода выбрасывается ошибку, а ловите ее в другой, у вас нет четкого контракта, какая именно ошибка может возвращаться (это не следует из сигнатуры метода)

Следовательно, мы разделяем для себя 2 вида ошибок:

– Критические ошибки, такие выбрасываются через throw и не обрабатываются в бизнес логике, потому что это какое-то критическое исключение.

- Обрабатываемые ошибки, такие являются корректным результатом вызова и являются типизированной частью ответа = веткой Either, их мы обрабатываем в бизнес логике и на их базе строим какое-то поведение.

Таким образом Either позволяет сделать наш код чище и сильно проще для восприятия, а также вы неизбежно будете обрабатывать ветку left и не забудете об обработке ошибок.

Здравствуйте. Спасибо за статью, начинание действительно хорошее, сравнивать актуальные технологии кросс-платформенной разработки. Но хотелось бы уточнить пару технических моментов при сравнении Flutter и KMM для мобильной разработки.

1) В статье ничего не сказано о том, что Flutter имеет свою рендер систему на skia, в отличии от того-же KMM. Т е на flutter мы уже сейчас можем верстать один раз, в то время как на KMM мы либо используем нативный UI либо ждем, когда Compouse сделают совместимым с ios

2) Что вы имели в виду под сравнением производительности flutter/KMM ? Если вы имели ввиду производительность release сборок, то hotReload во flutter только для debug режима (т к только он собирается с VM). Если же вы сравниваете производительность человека, пишущего на той или иной технологии, то хотелось бы понять, по каким критериям.

3) пункт Дизайн пользовательского интерфейса - тоже вызвал вопросы. Могли бы вы уточнить критерии сравнения?

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Зарегистрирован
Активность

Специализация

Software Developer, Mobile Application Developer
Lead
Java
Kotlin
Android development
Dart
Flutter
SWIFT
iOS development