-Поиск по дневнику

Поиск сообщений в rss_rss_hh_new

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 17.03.2011
Записей:
Комментариев:
Написано: 51


iOS+Kotlin. Что можно сделать сейчас

Понедельник, 25 Сентября 2017 г. 09:17 + в цитатник
adev_one сегодня в 09:17 Разработка

iOS+Kotlin. Что можно сделать сейчас

    В ветке master проекта Kotlin Native появился пример uikit. Это простое приложение под iOS, которое выводит на экран строку, введённую в поле ввода, и да, 100% кода написано на Kotlin. Выглядит оно так:



    Стоит ли думать о порте своего приложения уже сейчас?


    Да, но только если:
    0). Вам действительно нужна общая кодовая база мобильных приложений.
    1). Приложение мало завязано на платформу.
    2). У Вас есть время на написание некоторого количества кода на Kotlin, который в будущем стоит переписать на Objective-C или Swift.

    Причины пока не портировать


    ViewController, AppDelegate и даже main-функция в примере написаны на Kotlin. Те файлы, которые написаны на Objective-C нужны только чтобы XCode не выдавал ошибку и не включаются в конечную сборку (я не нашёл способов исправить положение). Т.е. полноценный interop как с Java, видимо, пока что, недоступен. Это совсем не значит, что положение дел не изменится к релизу (сейчас проект на стадии alpha preview, а об этом примере даже поста в блоге не было). Но спектр доступных сейчас возможностей довольно ограничен.

    Interop


    Идиоматический подход к написанию мультиплатформенного приложения на Kotlin — отдельно написать общую часть, отдельно — часть для каждой платформы. При этом на каждой платформе, по задумке, должны быть легко доступны все библиотеки, под неё написанные. В случае с Java работает хорошо. В случае с iOS дела сейчас обстоят следующим образом:

    @ExportObjCClass
    class KotlinViewController : UIViewController {
    
        constructor(aDecoder: NSCoder) : super(aDecoder)
        override fun initWithCoder(aDecoder: NSCoder) = initBy(KotlinViewController(aDecoder))
    
        @ObjCOutlet
        lateinit var label: UILabel
    
        @ObjCOutlet
        lateinit var textField: UITextField
    
        @ObjCOutlet
        lateinit var button: UIButton
    
        @ObjCAction
        fun buttonPressed() {
            label.text = "Konan says: 'Hello, ${textField.text}!'"
        }
    }

    То есть вполне неплохо. К каждому внешнему классу добавляем аннотацию @ExportObjCClass, к каждому графическому элементу из storyboard — @ObjCOutlet и @ObjCAction для каждого action. Классы на Objective-C доступны по их оригинальным именам.

    Если нужно вызвать Kotlin из Objective-C/Swift


    В этой статье описано, как это можно сделать. Через некоторое количество прослоек, с ручным преобразованием типов 2 раза, но зато можно звать Swift из Kotlin и Kotlin из Swift.

    Overhead


    В теории, вес приложения должен увеличиться примерно на 100 кб (отсюда).
    Вместо GC будет использоваться ARC, так что особой разницы в производительности со Swift быть не должно.

    Обратная совместимость


    Судя по докладам участников команды разрабатывающей язык, обратная совместимость — один из их основных приоритетов. Насколько это хорошо — судить вам. Лично я считаю, что это намного лучше, чем у Swift и, в целом, язык хорош и большинство паззлеров выглядят надуманными. Но есть 1 вещь, которая, по моему мнению, может быть «бомбой замедленного действия», при этом не может быть исправлена с соблюдением обратной совместимости.

    inline


    Для реализации сопрограмм, которые делают так, чтобы синхронный и асинхронный код выглядели почти одинаково в язык было введено всего одно новое ключевое слово suspend, чем разработчики заслуженно гордятся. Но для того чтобы методы-расширения (forEach, map...) работали так же быстро, как и обычный for (и для вывода общих типов во время исполнения программы), было введено целых 3 (inline, crossinline, noinline). Они явно не делают код читаемее. JIT теряет часть возможностей для оптимизации (подкаст об этом), а опыт C показывает, что разработчики не умеют правильно пользоваться такими возможностями языка. В целом, не понимаю, почему то же самое нельзя было сделать аннотацией. Для меня inline выглядит как плохое решение достойной проблемы.

    Заключение


    — На Kotlin скоро можно будет писать под все 3 основные платформы (Android, iOS, Web).
    — Скорее всего, будет хорошая совместимость с Objective-C и Swift. Возможно лучше, чем та, что есть между этими языками. Учитывая опыт JetBrains в разработке компиляторов и IDE, в это можно поверить.
    — У Kotlin легковесный Runtime языка под Android и Web. Под iOS, судя по всему, тоже будет не тяжёлым.
    — Уже сейчас можно что-нибудь написать.
    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/337958/

    Метки:  

     

    Добавить комментарий:
    Текст комментария: смайлики

    Проверка орфографии: (найти ошибки)

    Прикрепить картинку:

     Переводить URL в ссылку
     Подписаться на комментарии
     Подписать картинку