Комментарии 13
Ни чем из этого не пользуюсь. Практически ни чем.
Мне нужен java-код только для работы с полностью нативными приложениями. Полностью нативное приложение - это приложение привязанное к данной архитектуре и оно не сможет выполняться на другой архитектуре.
Это не значит, что разработанное мной приложение не будет работать на других архитектурах, это означает, что для каждой архитектуры будет свой нативный код.
Я создаю активити, прописываю необходимые методы и использую данные в нативном коде.
Что из перечисленного позволит мне сделать то же самое?
Вас можно только поздравить, скорость разработки ваших приложений на несколько порядков ниже, чем с использованием перечисленных в статье библиотек)
Ну... на несколько порядков, это в 10-100-1000 и т.д. раз медленнее.
Почему-то я в этом не уверен. Сейчас вроде не 2000-й год, когда для нативного кода ни каких наработок нет. )))
А так да, медленнее, но в сборке, обычно быстрее.
на несколько порядков, это в 10-100-1000 и т.д. раз медленнее.
@Seenkao Да, всё правильно) Не в 1000 раз, конечно, но в 100 раз точно медленнее.
Разбивая по этапам:
Работа с базой - SQLite vs SqlDelight.
Работа с сетью - OkHttp vs Ktor.
UI - View vs Compose.
Асинхронная работа - AsyncTask vs Coroutines.
Мультиплатформенность - Nope vs Kotlin Multiplatform.
Если нет своих решений, то каждый пункт - x10 времени реализации для Java)
А если ещё взять мультиплатформу, умножаем всё на 2)
Есть разные задачи, и они требуют разных решений.
Допустим кроссплатформенность. Я использую полностью нативный код (конечный компилируемый), а не java-код под разные платформы. Создавая приложение (допустим) под Windows, это приложение практически без переделок можно запустить на Android. Под Linux, MacOS собирается вообще без переделок, понимаем, что для мобильных платформ надо учитывать специфику платформы и взаимодействия с ней.
Многое, собрано до меня. Многие решения сделаны до меня. Какие-то решения сделал лично я. А многие необходимые библиотеки уже готовы к сборке под любую платформу и сделано это теми людьми, кто разрабатывает эти самые библиотеки.
Так что да, какие-то приложения будут дольше разрабатываться из-за того что надо создавать UI и работать с ним, а где-то наоборот, допустим игры. Их проще сделать нативно, ведь там как раз разработка основная не создание UI и работы с ним, а работы самой программы с графикой, при чём UI в данном случае в наименьшем виде. И! Для большинства создаваемых игр UI для игры уже создан. Создавать одно и то же для каждой игры... как-то боком выйдет.
Ну и то же самое с программами, которые активно используют графику, где графический интерфейс нативный, по большей части.
Для понимания, это не опровержение ваших слов! Это просто другая сторона.)))
Но мы отошли от моего вопроса: что из перечисленного в статье поможет мне именно с нативной составляющей программ? )))
Время разработки приложения = Время освоения инструментов разработки + время разработки собственно приложения..
Какое время освоения всего выше перечисленного? Сколько раз за время освоения инструментов разработки они успевают обновиться, сколько процентов из этих обновлений потребуют повторного времени на освоение, не считая времени на ликвидацию последствий?
kotlin он же под капотом тот же java, это грубо говоря как typescript для javascript который позволяет писать более быстрый и эффективный код чем если бы вы писали на чистой java.
Я их между собой приравниваю. Да, я не изучал котлин, но не думаю что там что-то сложнее и проще. Просто по другому немного.
На яве пишу, потому что привык и мне много ява-кода не нужно.
Не скажите. TypeScript - это чисто типизация для JavaScript и не более того. Его даже языком сложно назвать, т.к. там кроме типизации ничего и нет.
Kotlin же предлагает солидное количество полезных фич, которых на момент выхода, в Java ещё не было. И это прямо полноценный язык, который компилируются в байт код, а не Java код.
Когда пишешь один, можно творить любую дичь )
Все четко и по делу, надо сохранить куда-то
Может меня закидают тапками, но мне как фронту интересно, почему React Native никак не упомянут в данной статье, может ли это быть альтернативой для разработки под мобилки или данный фрейм еще слишком сырой?
Разработка под Android в 2024 году