Пользователь
0,0
рейтинг
2 июня 2014 в 11:26

Разработка → Анонсирован Xamarin 3

Анонсирован Xamarin 3 — кросс-платформенная среда разработки на C# для большинства мобильных платформ. Основные нововведения: дизайнер интерфейса для iOS Xamarin Designer, кросс-платформенная библиотека для построения пользовательского интерфейса Xamarin.Forms, улучшения IDE, новые методики повторного использования кода.

1. Xamarin Designer для iOS — визуальный дизайнер для iOS, работающий и в Xamarin Studio и Visual Studio. Поддерживается полная совместимость с форматом Storyboard, так что Visual Studio и Xamarin Studio могут использоваться совместно с Xcode Interface Builder. Нестандартные элементы управления прорисовываются прямо в дизайнере. Подробнее о Xamarin Designer.



2. Xamarin.Forms — новая библиотека, позволяющая строить родной UI для iOS, Android и Windows Phone на основании общей базы кода С# с помощью более чем 40 кросс-платформенных элементов управления и схем (layouts), которые связываются с родными элементами при выполнении программы, что означает полное соответствие платформе. Например Xamarin.Forms Entry становится UITextView на iOS, EditText на Android, и TextBox on Windows Phone. Xamarin.Forms поставляется как библиотека переносимых классов (portable class library) и позволяет легко смешивать общий код UI с плаформо-зависимыми интерфейсными API Xamarin. Например можно использовать Xamarin.Forms для экрана входа в приложение и Xamarin.iOS/Xamarin.Android для остальных экранов. Можно встраивать собственные представления, написанные непосредственно на Xamarin.iOS/Xamarin.Android, внутрь страниц Xamarin.Forms. Подробнее о Xamarin.Forms.



3. Существенные улучшения IDE



— Обновление внешнего вида. Xamarin Studio теперь включает в себя новый начальный экран, сотни новых иконок, улучшенную поддержку Retina-дисплеев и приятные улучшения внутри IDE.

— Улучшенная поддержка Visual Studio. Расширения для iOS и Android собраны в одно расширение Visual Studio, упрощая его установку, обновление и собственно процесс разработки и отладки.

— NuGet – Xamarin 3 включает в себя полную поддержку пакетов NuGet для ваших мобильных приложений как в Xamarin Studio, так и в Visual Studio, что дает вам возможность воспользоваться массой пакетов NuGet, которые теперь поставляются совместимыми с Xamarin

— Документация по .NET BCL — полная документация по по базовым библиотекам классов .NET теперь встроена в Xamarin Studio, спасибо нашим друзьям из Microsoft

— Поддержка F# — Xamarin Studio теперь поставляется со встроенной поддержкой разработки приложений для iOS и Android на набирающем популярность функциональном языке программирования F#

4. Улучшения в области повторного использования кода.

В Xamarin 3 представлены две новые техники для повторного использования кода на разных платформах:



Общие проекты (Shared Projects) обеспечивают простой и изящный подход к повторному использованию кода в кросс-платформенных приложениях. Разработчики могут использовать эти проекты для общего использования кода из под iOS, Android и Windows как в Xamarin Studio так и в Visual Studio.



Преимущества:

— Позволяют создавать код, общий для нескольких проектов
— Общий код может разветвляться (be branched ) в зависимости от платформы с использованием директив компилятора (например #if __ANDROID__, как описано в документе Building Cross Platform Applications).
— Проекты приложений могут включать в себя платформо-зависимые ссылки, которые сможет использовать общий проект (такие как использование Community.CsharpSqlite.WP7 в пример Tasky для Windows Phone).

Недостатки:

— В отличие от других типов проектов общие проекты не имеют «выходной» сборки. При компиляции файлы рассматриваются как часть связанного проекта и компилируются в его DLL. Если вы хотите выносить общий код в DLL, то вам лучше подойдут переносимые библиотеки классов.
— Рефакторинг, затрагивающий код внутри «неактивных» директив компилятора не будет обновлять код

Переносные библиотеки классов (Portable Class Libraries) — это библиотеки, которые используются на большом количестве совсем разных .Net платформ. С Xamarin 3 можно создавать и использовать переносные библиотеки классов как в Xamarin Studio так и в Visual Studio.



Преимущества:

— Позволяют создавать код, общий для нескольких проектов
— Рефакторинг всегда обновит все зависимые части кода

Недостатки:

— Нельзя использовать директивы компилятора
— Доступна лишь часть .Net framework, в соответствии с выбранным профилем (больше информации в Introduction to PCL)

Новость в блоге Xamarin.
@Vedomir
карма
90,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

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

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

  • +4
    Xamarin.Forms очень интересная штука — попытка достигнуть 100% общего кода на шарпе под все платформы (правда, не без помощи костылей типа

    // Accomodate iPhone status bar.
    Padding = new Thickness(10, Device.OnPlatform(iOS: 20, Android: 0, WinPhone: 0), 10, 5);

    причем страницы можно верстать прямо в XAML для всех платформ, а потом на каждой подправлять (если надо) при помощи Custom renderers. Пока сыровато, но ребята достаточно активно обновляют пакет в нугете и живенько отвечают на форуме.
    • 0
      Радует, что они продолжают поддерживать удобные совместимости с Windows Phone, который по сути к самому Xamarin отношения не имеет.
    • 0
      Что характерно, эти самые значения, которые так предлагают подменять через Device.OnPlatform, имеют разный физический смысл даже в пределах одной платформы — на iPhone и iPad используется единый тип юнитов, но по бóльшей стороне их 1024 на планшете и 480 либо 568 на телефоне, а значит надо проверять еще Device.Idiom и попытка сделать «универсальный» код в xaml превращается в страшную пытку, либо возврат к загрузке разных файлов интерфейса для разных устройств и dpi, но т.к. родных возможностей для этого нет, выходит такое себе занятное лапшестроение.
      • 0
        Я не так много случаев могу придумать, когда надо завязываться на размер экрана в пикселях. Есть grid, например, (который впрочем у них не работает как надо).

        В большинстве случаев принципиально именно определить телефон это или планшет, а адаптивную верстку xaml позволяет сделать.
        • 0
          Не так важен размер экрана в юнитах. Важно то, что на разных устройствах помещается существенно разное количество этих юнитов на экран. Например, на Windows Phone мы знаем, что там от 800 до 853 «пикселей» в Xaml разметке, на Android есть device independent pixels и с некоторыми оговорками можно написать 20dp и знать, как это будет выглядеть на разных устройства, на iOS всего два с половиной размера экрана и можно делать отдельные nib файлы с едиными биндингами. Но тут мы пишем Padding=«20,0,0,0» и на iPhone это значит 5% экрана, а на iPad 2%. С размерами шрифтов все еще хуже: на Android есть юнит «sp», тут же размеры Medium, Large и пр., но они не подогнаны под устройства. Размер Large на iPad вполне нормален для кнопок и пр., а на iPhone кнопка с таким шрифтом может занимать четверть экрана.
          Теоретически это можно было бы все пережить, если бы хорошо работали привязки к краям контейнера в лейаутах, но поведение HorizontalOptions в каждом контейнере особое, а описание формул для RelativeLayout в XAML коде выглядит как какой-то кошмар, еще и с константами в пикселях, если нам нужно, например, центрирование или привязка к правому краю.
          Отдельный разговор про Grid, который по задумке хорош, но сейчас крашится если в размере столбца есть звездочка, а вообще будучи включенным в состав StackLayout не умеет перемасштабировать своих чайлдов, т.е. не подходит для «резинового» дизайна.

          В целом, я не очень доволен фреймворком. У него есть потенциал, но нет еще абсолютно никакой гибкости. Подразумевалось, что как бы все вкусные фичи из UI разных платформ найдут там применение, но на деле получилось усреднение до того, что есть у всех этих платформ общего. Т.е. кнопки только без картинок, отсутствие бекграунд-изображений в принципе, отсутствие тап событий для не-кнопок (хотя тап-видимость они перекрывают), отсутствие декораций вроде скругленных углов, теней, бордюров, картинок и пр. на контролах, отсутствие жестов iOS, сложных лейаутов Android, стилей и темплейтов Windows Phone.
          • 0
            Со второй частью поста полностью согласен — Фреймворк сырой.

            Но насчёт пикселей. Эти 20 условных енотов можно спокойно домножать на коэффициент зависящий от dpi. Тогда на разных девайсах это будет физически (в мм) примерно одинаковое расстояние. То что это разный процент от экрана — нормально. В том же андроиде 20dip — разный процент экрана.

            Со шрифтами реально сложнее. Особенно с кастомными. iOS может шрифт из того же файла рисовать отлично от Андроид или WP. Вероятно из-за такой фигни это пока не реализовали.
            • 0
              20dip в андроиде это некая величина, имеющая смысл. Если говорить не о китайдевайсах, то ее можно пересчитать в миллиметры и будет она что-то значить, причем на устройствах с одной диагональю — одно и то же. Тут же еноты в разметке смысла не имеют и для каждого девайса их надо вручную в коде пересчитывать в проценты, миллиметры, физические пиксели или что-то еще, убивающее на корню смысл файлов разметки. Аналогично происходит и в нативном iOS, но там прозрачно можно менять файлы разметки для разных устройств и хорошо работают привязки к сторонам экрана.
              А вот со шрифтами в Xamarin.Forms вообще все в зачаточном состоянии — кроме проблем с размерами, нет никаких настроек написания и только на iOS работают кастомы, а на других ОС хватаемся за голову и рисуем собственные рендереры.
              • 0
                Тут же еноты в разметке смысла не имеют и для каждого девайса их надо вручную в коде пересчитывать


                Это можно учесть на уровне Фреймворка, они этого не сделали? (я не проверял).

                PS. Вы сейчас пишите продукт на Xamarin.Forms???
                • 0
                  Не сделали. Если бы можно было все юниты при старте на что-то умножить, сразу бы головняка стало меньше. Пока экспериментирую со скейлом всей страницы, но там есть баги.

                  Продукт надо писать, сейчас провожу ресерч, сделал пару страниц, но серьезно думаю о разделении на отдельно Xamarin.iOS и Xamarin.Droid.
  • 0
    Ради интереса, я так понимаю, для написания кода на С# платформы Android, Xamarin используют для бизнес приложений, а Unity3D для игр? Или их совмещают?
    • 0
      эмм, нет, Unity3D использует C# для скриптовки движка
      и ничто не мешает использовать C# под Xamarin для рендеринга при помощи OpenGL
    • +1
      В принципе Xamarin универсален и игры на нем тоже можно писать — были попытки портировать XNA в рамках MonoGame и даже Cocos2D-XNA на C#.

      Но смысл не совсем понятен — Unity не только специализирован на играх и поддерживает ряд чисто игровых платформ вроде приставок, которые не поддерживает Xamarin, но и стоит намного дешевле. Минимальная лицензия Xamarin для инди — 300 долларов в год за платформу, Unity в базовой версии вообще бесплатен для большинства платформ.

      А совмещать игры и бизнес-приложения — это как? В принципе Unity использует для скриптов на C# проект Mono который лежит в основе Xamarin, но надстройки над ними разные.
      • 0
        Более того, для 2d-игр Xamarin весьма удобное решение, за счет Monogame кроссплатформенность можно достичь очень быстро и без каких-либо дополнительных трудозатрат. Немного про опыт работы с Monogame упоминал.

        Типичные платформо-зависимые части: аудио, сохранения, синхронизация.
        • +1
          Да, но при этом Xamarin в разы дороже Unity который умеет все то же самое и еще много чего. Собственно говоря я не знаю как кратко описать разницу в цене между бесплатным Unity в базовой редакции и 300 долларов в год за каждую платформу для Xamarin.
          • 0
            300$ включают обновления в течение года (т.е. дальше можно пользоваться как раньше, но без них), или я ошибаюсь?

            habrahabr.ru/post/204032/
            • 0
              Честно говоря так глубоко не вникал, ориентируюсь тупо на:

              $299 / year
              Per platform, per developer

              store.xamarin.com/

              Жалко что на Unity бизнес-приложения нельзя писать. ))
              • 0
                почему это? а вот: habrahabr.ru/company/kelnik/blog/198572/ можно ещё найти несколько неигровых приложений, написанных на Юнити.
                Юнити предназначена для создания 3d-миров, а не именно для игр. Игры — это только наиболее часто встречаемая сфера применения.
                Вот ещё пример: habrahabr.ru/post/142180/ Тут даже не Юнити, а вообще Unreal Engine.
                • 0
                  Я имел в виду абсолютно стандартные (двухмерные) приложения с формами и прочим, которые очень хотелось бы попробовать писать на кроссплатформенном C# не платя 300 долларов в год за каждую платформу.

                  В Xamarin мне нравится все, кроме стоимости для некоммерческого применения.
  • 0
    Скажите, 3 версия для разработки приложений под IOS в VS все так же требует наличия OSX в сети?
  • +2
    Скажите пожалуйста, каким образом код написанный на винде под iOS, компилируется, подписывается и выкладывается в стор? Все равно нужна мак машина или все таки нет? Новый Delphi XE5 позволяет подобное делать, в связи с чем, возник интерес
    • +2
      Нужен мак с запущенным на нем Build Host. Вся компиляция и дебаг под iOS происходит на маке по сети. И естественно если нужно дебажить на устройстве оно тоже должно быть подключенно к маку
      • 0
        То есть и Xamarin и XE работают аналогично? Разница только в том, что вместо мака каждому разработчику покупается один на всех, а разработчики сидят на винде?
        • 0
          Да. Но я не уверен насчет количества одновременно подключенных девелоперов к маку. Я просто игрался один мак+я за виндой.
          Но тут кроется небольшой подвох это цена за такое использование. За возможность использования Visual Studio придется отдать 999$ в год. А на windows ios поддерживается только из под visual studio. в Xamarin Studio под Win можно только под Android писать. Но если у вас уже есть студия и заказчик адекватный и не жмот то использование Xamarin очень оправдан. Все таки на быстрее вы разработаете приложения под 3 платформы и можно вовремя выводить новые фичи\багфиксы на всех платформах.
          Поставьте Xamarin, поиграйтесь (есть 30 дневный триал)
        • 0
          К одному Билдхосту на маке может подключится только один экземпляр студии.
      • 0
        А мак обязательно реальный должен быть, или виртуалка хакинтошная тоже пойдет?
        • +1
          должна подойти, главное, чтоб в одной подсети.
  • 0
    2SonkoDmitry
    C учетом нехилой (имхо) стоимости Xamarin, покупка мака — не самая большая из проблем.

    UPD: Xamarin Forms доступны от $299/год. В принципе — нормально, отбивается с одного проекта.
    • 0
      $299/год в год за одну платформу. В принципе если сравнить с годовой зарплатой разработчика с соответствующими навыками, то вполне нормально. Но для инди и самостоятельного изучения уже тяжеловато — четко видна ориентация только на коммерческие компании.
  • +7
    Самый большой минус Xamarin — это непредсказуемая и неадекватная ценовая политика.

    Нет никакой гарантии, что к концу разработки они не повысят цену.

    А так — и идея кросплатформенного C# замечательная, и реализация неплохая (с оговорками).
    • 0
      Ничего, мне кажется что уже в этом году их купит Microsoft.
      Мнe так же кажется, что все этого только и ждут :)
      • 0
        Не уверен, что так уж сильно. Пока они сохраняют самостоятельность есть определенная гарантия того, что они всегда останутся по-настоящему кросс-платформенными. А вот если их купит Microsoft то возникнет конфликт интересов — Microsoft надо свою платформу продвигать.

        Сейчас, когда своя платформа у Microsoft полудохлая, они конечно заинтересованы скорее в переносе приложений с других платформ и играют в корпорацию добра, но что будет через несколько лет?

        Ну или какой-нибудь очередной директор решит вообще отказаться от мобильного направления в духе IBM и Oracle.

        Я все-таки надеюсь что Xamarin сам сделает платформу доступнее для некоммерческих разработчиков.
      • 0
        судя по очень близким источникам, покупать их не будут.
        Зачем MSFT выкладывать $$$, когда Xamarin и так делает то, что им нужно, в очень тесном сотрудничестве
        • 0
          Зачем Xamarin продаваться, если они могут себе позволить переманить разрабов из команды студии, например. Дела у них иду хорошо, значит.
    • 0
      Витали слухи, что у Microsoft есть желание купить Xamarin. Да еще что б потом бесплатной сделать. Я думаю от этого бы выиграла и Microsoft и разработчики и потребители.
      • 0
        Не согласен, в ближайшей перспективе вроде бы да. Пришли бы новые разработчики, при наличии большого количества качественных приложений подтянулись пользователи, майкрософтв плюсе. Но что потом? Где гарантии, что став царем горы товарищи из Редмонда не начнут тащить одеяло на себя?

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