После того, как все изменения в среде IDE (все платформы по теме изменены) в этом году, я хочу понять, каково состояние технологии для этих платформ.
Каковы сильные и слабые стороны каждого из них? Есть некоторые ограничения одного из этих подходов?
У меня есть хороший опыт работы на С# и Javascript, чем нет влияния программного языка, которое может опираться на одну сторону.
Как сообщается Тим Андерсон
Кросс-платформенная разработка - это большая проблема, и она будет продолжаться до тех пор, пока не наступит день, когда все используют одну и ту же платформу. Android? HTML? WebKit? IOS? Окна? Xamarin? Титановый? PhoneGap? Corona? ЕСС.
Иногда я слышу, что он сказал, что существуют по существу два подходадля кросс-платформенных мобильных приложений. Вы можете использовать встроенную браузера и напишите веб-приложение , завершенное как родное приложение, так как в Adobe PhoneGap/Cordova или аналогичный подход Sencha, или вы можете использовать кросс-платформенный инструмент , который создает собственный приложения, такие как Xamarin Studio, Appcelerator Titanium или Embarcardero FireMonkey.
Однако во второй категории существует разнообразие. В частности, они различаются в зависимости от степени, в которой они абстрагируют пользователя интерфейс.
Вот компромисс. Если вы создаете свою кросс-платформенную структуру, вы может заставить ваше приложение работать практически одинаково на каждой платформе. Если вы используете дизайн пользовательского интерфейса на всех платформах, сложно Сделайте свой дизайн одинаково правильным во всех случаях. Это может быть лучше принять подход, принятый большинством игр, используя дизайн, который отличительные для вашего приложения и сделать добродетелью его согласованности в платформ, хотя он не имеет собственного внешнего вида и любая платформа.
edit Xamarin v3 в 2014 году начал предлагать выбор Xamarin.Forms, а также чистый родной, который все еще следует за философия, упомянутая здесь (освободилась от встроенного редактирования, потому что такой отличный ответ)
Xamarin Studio, с другой стороны, не пытается предоставить общую инфраструктуру графического интерфейса:
Мы не пытаемся предоставить слой абстракции пользовательского интерфейса, который работает на всех платформах. Мы считаем, что это плохой подход, который приводит к самые низкие общие знаменательные пользовательские интерфейсы. (Нат Фридман Тиму Андерсону)
Это правильно; но недостатком является стремление поддерживать два или более пользовательских интерфейсов для вашего приложения.
Сравнение о PhoneGap и Titanium хорошо сообщается в блоге Kevin Whinnery.
Цель PhoneGap - разрешить веб-приложения на основе HTML. развертываться и устанавливаться как собственные приложения. Сеть PhoneGap приложения обернуты в оболочку собственного приложения и могут быть установленных через собственные приложения для нескольких платформ. Кроме того, PhoneGap стремится предоставить общий собственный набор API который обычно недоступен для веб-приложений, таких как базовые доступ к камере, контакты устройства и датчики, которые еще не браузер.
Чтобы разработать приложения PhoneGap, разработчики создадут HTML, CSS, и JavaScript в локальном каталоге, так же, как разработка статический веб-сайт. Подход к качеству пользовательского интерфейса собственного качества в браузер - нетривиальная задача - в Sencha работает большая группа веб-сайтов программисты, посвятившие полный рабочий день решению этой проблемы. Даже поэтому на большинстве платформ в большинстве браузеров сегодня производительность пользовательского интерфейса с собственным качеством и отзывчивость просто не возможна, даже с каркасом, продвинутым как Sencha Touch. Это браузер уже "достаточно хорош"? Это зависит от ваших требований и чувств, но он, несомненно, менее хорош, чем собственный пользовательский интерфейс. Иногда гораздо хуже, в зависимости от браузера.
PhoneGap не так по-настоящему кросс-платформенный, как можно было бы верить, не все функции одинаково поддерживаются на всех платформах.
Javascript - это не язык программирования приложений, слишком много глобальных взаимодействий, а разные библиотеки не очень хорошо сосуществуют. Мы потратили много часов, пытаясь заставить knockout.js и jQuery.mobile хорошо играть вместе, и у нас все еще есть проблемы.
Фрагментированный ландшафт для фреймворков и библиотек. Слишком много вариантов, и слишком много не достаточно зрело.
Как ни странно, для нужд нашего приложения может быть достигнута достойная производительность (но не с jQuery.Mobile). Мы попробовали jqMobi (не очень зрелый, но быстрый).
Очень ограниченная возможность взаимодействия с другими приложениями или возможностями cdevice, и в любом случае это не будет кросс-платформой, так как в HTML5 нет никаких стандартов в HTML5, за исключением нескольких, таких как геолокация, камеры и локальные базы данных.
Цель Titanium Mobile - обеспечить высокоуровневую, межплатформенную среду JavaScript и API для мобильных (сегодня мы поддерживаем iOS, Android и Windows Phone. Титан фактически имеет больше общего с MacRuby/Hot Cocoa, PHP или node.js, чем с PhoneGap, Adobe AIR, Corona или Rhomobile. Титан построен на двух утверждениях о мобильная разработка: - Существует ядро мобильных API разработки, которые могут быть нормализованы на разных платформах. Эти области должны быть нацелены на повторное использование кода. - Существуют специфичные для платформы API-интерфейсы, пользовательские интерфейсы и функции, которые разработчики должны учитывать при разработке для этой платформы. Для этих вариантов использования должен существовать определенный для платформы код, чтобы обеспечить наилучший возможный опыт.
Итак, по этим причинам Титан не является попыткой "написать один раз, работать везде" . То же, что и Xamarin.
Титан собирается сделать следующий шаг в направлении, аналогичном таковому Xamarin. На практике они будут делать два слоя разной глубины: слой Titanium (в JS), который дает вам пчелу JS-of-Titanium. Если вы хотите перейти на более низкий уровень, создали дополнительный слой (называемый Hyperloop), где (всегда с JS), чтобы перезвонить вам непосредственно на собственные API SO
Xamarin (первоначально подразделение Novell) за последние 18 месяцев вывел на рынок свою собственную среду IDE и оснастку для Visual Studio. подчеркивающей предпосылкой Mono является создание разрозненных мобильных приложений используя С# при сохранении собственных стратегий разработки пользовательского интерфейса.
В дополнение к созданию визуальной дизайнерской платформы для разработки приложений, у них есть интегрированные комплекты для тестирования, встроенные библиотечная поддержка и хранилище компонентов стиля Nuget. Недавно они предоставил визуальный дизайн iOS через их IDE, освободив разработчика от открытия XCode. В Visual Studio теперь все три платформы поддерживается и набор облачных тестов находится на горизонте.
С самого начала Xamarin предоставил богатый визуальный дизайн Android опыт. Мне еще нужно загрузить или открыть Eclipse или любую другую среду IDE кроме того Xamarin. Что действительно удивительно, так это то, что я могу использовать LINQ для работы с коллекциями, а также для создания пользовательских делегатов и событий что освободит меня от objective-C и ограничений Java. Многие из библиотеки, которые я испортил, как Newtonsoft JSON.Net, работает отлично во всех трех средах.
По моему мнению, есть несколько ОГРОМНЫХ преимуществ, включая
Обновление для меня - это использование Xamarin и MVVMCross в сочетании. Это все еще совершенно новая структура, но она родилась из опыта нескольких других фреймворков (таких как MvvmLight и monocross), и теперь она используется в нескольких выпущенных кросс-платформенных проектах.
Мой выбор, зная все эти кадры, заключался в выборе инструмента разработки на основе потребностей продукта. В общем, однако, если вы начнете использовать инструмент, с которым вам удобно (даже если он требует более высоких начальных накладных расходов) после того, как вы будете использовать его навсегда.
Я выбрал Xamarin + MVVMCross, и я должен сказать, что доволен этим выбором. Я не боюсь подходить к Native SDK для обновлений программного обеспечения или видеть ограниченную функциональность системы или самую тривиальную особенность графических элементов. Хороший структурированный код записи (DDD + SOA) очень полезен, чтобы иметь основной проект, совместно используемый с реализацией реализаций С#.
Я не очень много работал с Appcelerator Titanium, но я расскажу об этом в конце.
Я могу говорить немного больше о различиях между PhoneGap и Xamarin, поскольку я работаю с этими двумя 5 (или более) днями в неделю.
Если вы уже знакомы с С# и JavaScript, то вопрос, который я предполагаю, ли бизнес-логика лежит в области, более подходящей для JavaScript или С#?
PhoneGap предназначен для того, чтобы вы могли писать свои приложения с помощью JavaScript и HTML, и большая часть функциональных возможностей, которые они предоставляют, предназначена для имитации текущих предлагаемых спецификаций для функциональных возможностей, которые в конечном итоге будут доступны с HTML5. На мой взгляд, большое преимущество PhoneGap заключается в том, что, поскольку вы используете пользовательский интерфейс с HTML, его можно легко портировать между платформами. Недостатком является то, что вы переносите один и тот же интерфейс между платформами, но он не будет чувствовать себя как дома ни в одном из них. Это означает, что без дополнительной настройки у вас не может быть приложения, которое полностью чувствует себя дома в iOS и Android, что означает, что у него есть стиль iOS и Android. Большая часть вашей логики может быть написана с использованием JavaScript, что означает, что она также может быть перенесена между платформами. Если текущий PhoneGap API делает большую часть того, что вы хотите, то довольно легко вставать и работать. Если, однако, есть вещи, которые вам нужны с устройства, которые не входят в API, то вы получите удовольствие от Разработка плагинов, которая будет на языке на собственном языке разработки устройств (с одним предостережением, но я доберусь до этого), а это значит, что вам, скорее всего, придется быстро ускориться в Objective-C, Java и т.д. Хорошая вещь об этой модели - вы обычно можете адаптировать множество разных собственных библиотек для вашей цели, а многие библиотеки уже имеют плагины PhoneGap. Хотя у вас может не быть большого опыта работы с этими языками, по крайней мере будет использовать множество примеров.
Xamarin.iOS и Xamarin.Android(также известный как MonoTouch и MonoDroid), предназначены для того, чтобы вы могли иметь одну библиотеку бизнес-логики и использовать ее в своем приложении и подключать к ней ваш пользовательский интерфейс. Поскольку он основан на .NET 4.5, вы получаете несколько замечательных лямбда-нотаций, LINQ и целую кучу других достоинств С#, которые могут сделать вашу бизнес-логику менее болезненной. Недостатком здесь является то, что Xamarin ожидает, что вы хотите, чтобы ваши приложения действительно ощущали себя родными на устройстве, а это означает, что вы, вероятно, закончите переписывание вашего пользовательского интерфейса для каждой платформы, прежде чем подключать его вместе с бизнесом логика. Я слышал о MvvmCross, который предназначен для упрощения для вас, но у меня пока не было возможности заглянуть в нее. Если вы знакомы с системой MVVM на С#, вы можете посмотреть на это. Когда дело доходит до родных библиотек, MonoTouch становится интересным. MonoTouch требует Binding библиотека, чтобы сообщить вашему С# -коду , как ссылаться на базовый Objective-C и код Java. В некоторых из этих библиотек уже есть привязки, но если их нет, то создание может быть интересным. Xamarin создал инструмент под названием Objective Sharpie, чтобы помочь в этом процессе, и по большей части он получит вы 95% пути. Остальные 5%, вероятно, возьмут 80% вашего времени, пытаясь связать библиотеку.
Обновление
Как отмечено в комментариях ниже, Xamarin выпустил Xamarin Forms, который представляет собой абстракцию кросс-платформы вокруг специфичные для платформы компоненты пользовательского интерфейса. Определенно стоит посмотреть.
Теперь, потому что я сказал, что доберусь до него, оговорка, упомянутая в PhoneGap выше, - это Гибридный подход, где вы можете использовать PhoneGap для части, а Xamarin - для части. У меня довольно много опыта с этим, и я бы предупредил вас об этом. Высоко. Проблема с этим заключается в том, что это такая no mans 'landчто, если вы когда-нибудь столкнетесь с проблемами, почти никто не приблизится к тому, что вы делаете, и поставите под сомнение то, что вы пытаетесь сделать очень. Это выполнимо, но это определенно не забавно.
Как я уже упоминал ранее, я не много работал с Appcelerator Titanium, поэтому для различий между ними я предлагаю вам посмотреть Сравнение титана и Phonegap или Сравнение между Corona, Phonegap, Titanium, поскольку у него есть очень подробное описание различий. В принципе, кажется, что хотя оба они используют JavaScript, то как интерпретируется JavaScript, немного отличается. С титаном вы будете писать свой JavaScript в Titanium SDK, тогда как с помощью PhoneGap вы напишете свое приложение используя PhoneGap API. Поскольку PhoneGap соответствует стандартам HTML5 и JavaScript, вы можете использовать практически любые библиотеки JavaScript, которые вы хотите, например JQuery. С помощью PhoneGap ваш пользовательский интерфейс будет состоять из HTML и CSS. С титаном вы получите выгоду от своего кросс-платформенного XML, который выглядит как генерировать собственные компоненты. Это означает, что у него, безусловно, будет лучший внешний вид и внешний вид.
Я работал с Xamarin. Вот положительные и отрицательные результаты, которые я нашел:
Положительного
Отрицательных
Телефонная связь довольно медленная: нажатие на кнопку может занять до 3 секунд, чтобы отобразить следующий экран. iscroll медленный и нервный.
Там были и другие смешные ошибки и проблемы, которые я смог преодолеть, но в целом - не полностью созрели.
EDIT: Per Grumpy, это не Phonegap, который на самом деле медленный, это родной движок JS/Browser
Там также AppHyver Steroids, который прекрасно сочетает PhoneGap и Native UI.
С помощью Steroids вы можете добавлять в приложение PhoneGap такие вещи, как собственные вкладки, собственную навигационную панель, собственные анимации и переходы, собственные модальные окна, собственный ящик/панель (внешнее меню facebook) и т.д.
Вот демо: http://youtu.be/oXWwDMdoTCk?t=20m17s
В качестве альтернативы вы можете проверить BridgeIt на сайте bridgeit.mobi. Open source, он решил проблему эффективности/согласованности браузера, рассмотренную выше, в том, что она использует стандартный браузер на устройстве и браузер веб-просмотра. Он также позволяет вам получить доступ к собственным функциям, не беспокоясь о развертываниях магазинов приложений и/или собственных контейнерах.
Я использовал, если для простого доступа к камере и доступа к сканеру, и он хорошо работает для простых приложений. Документация немного освещена. Не уверен, как это будет делать в более сложных приложениях.