company_banner
14 апреля в 15:31

AppCode 2017.1: улучшенная поддержка Swift, новые возможности кодогенерации и многое другое

Привет, Хабр! Недавно мы выпустили AppCode 2017.1, сейчас готовим первое обновление — пора рассказать обо всех изменениях в этой версии.


Swift


Поддержка языка


Мы реализовали поддержку множества изменений в Swift 3, среди которых особенно хочется отметить:

  • SE-0005 — улучшили и автодополнение, и навигацию, и в целом связку Objective-C и Swift AppCode стал понимать значительно лучше:



  • SE-0062 — научились корректно парсить выражения с #keyPath (и изменения в синтаксисе #selector тоже):




  • SE-0091 — доработали автодополнение для ключевых слов prefix, postfix, infix и реализовали корректную навигацию между декларацией оператора в протоколе и его реализацией. Кроме этого, теперь можно быстро сгенерировать заглушку для таких операторов через Override/Implement:



  • SE-0033 — поддержали импорт констант из Objective-C с помощью __attribute__((swift_wrapper(struct))) и __attribute__((swift_wrapper(enum)))

С полным списком изменений можно ознакомиться вот тут.

Кроме этого, мы реализовали поддержку метатипов, научились корректно обрабатывать nullability audited regions и nullability attributes в Objective-C и улучшили резолв для super.init() и self.init().

Create from usage


В прошлой версии мы реализовали возможность создавать переменные, функции, методы и даже свойства классов из их использований. А в этой мы сделали то же самое для типов (классов, структур, перечислений, протоколов) и их инициализаторов:



Override/Implement


Override/Implement (^O/^I) позволяет генерировать определения сразу для нескольких методов какого-либо класса или протокола. В AppCode 2017.1 мы сделали диалог Override/Implement для Swift более удобным, а генерацию кода — более корректной:

  • Элементы в диалоге теперь показываются иерархично:



  • Для инициализаторов всегда отображается тип (convenience/required)
  • Перегрузки class-методов корректно генерируются, а перегружать статические методы мы больше не предлагаем
  • Optional-методы предлагаются только в случае вызова Override (^O)

Автодополнение


Теперь AppCode умеет фильтровать список автодополнения для методов и функций не только по их названиям, но и по названиям их параметров:



Кроме этого, мы добавили ключевые слова dynamic, lazy, postfix, prefix и indirect в список автодополнения там, где это необходимо.

Structure view


Нас долго просили добавить в Structure view (⌘7) и popup-окно File Structure (⌥F12) отображение комментариев вида //MARK, //TODO и //FIXME для Swift, и вот мы это сделали:



Если нужен список только //TODO и //FIXME, можно, как и раньше, использовать TODO view (⌘6):



C++


По традиции, улучшения поддержки C++, реализованные командой CLion, доступны и в AppCode. Про них можно прочитать в этом посте в разделе C++14 и C++17.

IDE


Сообщения сборки


В окне сообщений сборки (⌘0) появилась возможность фильтрации сообщений по типу:



Xcode-like breakpoints


По умолчанию, нажатие на breakpoint в продуктах IntelliJ убирает его, что иногда может мешать (например, если breakpoint срабатывает в случае определенного условия, заданного в его настройках). Теперь можно избежать подобной ситуации, выбрав Drag to the editor area в разделе настроек Preferences | Build, Execution, Deployment | Debugger | Remove breakpoint:



Поддержка эмодзи


Как и все продукты JetBrains, AppCode теперь корректно отображает эмодзи в редакторе кода и различных окнах IDE:



Find in Path


Изменилось окно полнотекстового поиска Find in Path — интерфейс стал лаконичнее, необходимость переключаться между несколькими вкладками в окне отпала:



Демо


Небольшое демо (на английском) с демонстрацией новых возможностей от нашего девелопер-адвоката Фила Нэша:


На этом все — читайте о других возможностях продукта у нас на сайте, следите за обновлениями в нашем англоязычном блоге, и задавайте любые возникшие вопросы в комментариях к этому посту.
Автор: @yeswolf
JetBrains
рейтинг 110,93
Похожие публикации

Комментарии (22)

  • 0
    Салют, очень хочется увидеть возможность запуска аппкода на винде, так чтобы, при наличии мака в сети, компиляция и прочие необходимые действия выполнялись на нём.
    • 0
      Что? ))
      • +1
        Да, звучит жутко, в мои планы, отлично-бы вписалась возможность разрабатывать иос-приложения, с винды.
    • 0
      Кейз редкий и специфичный, а вот задача крайне сложная. Вряд ли мы за это когда-либо возьмемся.
      • 0
        Спасибо, я не мог не попытаться.
        Но возможно вдруг задумаетесь, когда-нибудь, а бизнес модели «аппкод-на-винде + арендуемый-удалённый-мак»
        • 0
          Можно воспользоваться Xamarin (правда язык другой)
    • 0
      Кстати, такое реализовано в Delphi для компиляции под OS X и iOS.
      • 0
        И Xamarin из Visual Studio под iOS компилируется именно таким образом: с mac os в сети
    • –1
      Но зачем? Не уж то винда имеет столько преимуществ перед MacOS в плане разработки?
      • 0
        Бывают люди которым мак не нравится/ не по карману(билдсервер на маке может быть один на несколько компов, хотя это не совсем легально)
        • –1
          Не по карману — это, увы, не аргумент. Любая разработка требует затрат. Если быть категоричным — если вы не тянете затраты на разработку — стоит от нее отказаться.

          Не нравится — это аргумент. Весомый, как по мне. Я по этой причине никогда не планировал изучать C# — на нем нормально писать можно только под Windows, что слишком уж гемморойно для меня в качестве фановой задачи.

          Я правильно понимаю, что преимуществ, за исключением цены и привычного интерфейса — нет?
          • +1
            Преимуществ винды перед маком? ну тут можно много детализировать и дискутировать. Но чаще всего разница между любыми ОС сводится к удобству использования для конкретных задач и цене.
            • –1
              Преимущество винды над маком в плане разработки приложений не для Windows. Собственно мне и нужна детализация и дискуссия, ибо я вижу только недостатки. Хотелось бы узнать про преимущества.

              Цену мы уже упомянули. Еще есть?

              Я к чему спрашиваю — мне до сих пор не понятно стремление разработчиков сидеть на винде вместо более удобного линукса или мака. Надо же понять, что ж за киллерфича в винде есть, которой нет в линуксе и маке. Глядишь, дойдут руки запилить.
              • +1
                Лично мне ни мак ни линукс неудобны как пользователю. Ну вот такой я. А еще консоль не люблю.
                Плюс все IDE которыми я пользовался оказывались менее удобными, чем Visual Studio. Опять же для меня. Вот и все киллер-преимущества.
  • 0

    Планируете ли вы когда-нибудь встраивать конвертер Objective-C в Swift?

    • 0
      В ближайшее время — нет.
      • +2

        А работу со сторибордами? :)

        • +1

          Мне кажется ребятам нужно сначала добить Swift до приемлемого уровня.
          Потому что например на таких конструкциях до сих пор все плохо:


          let a = [0.0, 1.0]
          
          a.enumerated().forEach { i, element in
            // оба i & element неизвестного типа
          }
          • 0
            Похоже, проблема вот тут. Будем править, спасибо!
        • 0
          И тут пока нет — причины кратко тут.
      • +1

        Если надумайте, то обратите внимание на то, как это делает Swiftify :)

        • 0
          Говорят — говорят — им не хватает только command-line интерфейса, в который можно прокинуть лицензионный ключ, чтобы быть интегрированными в AppCode примерно так же, как они интегрировались в Xcode.

          Менюшку, пункты меню легко можно сделать через External tools, потом повесить нужные шорткаты, никаких плагинов не надо даже.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка