Задний план

Хотя я хотел бы подробно рассказать о своем опыте работы в качестве разработчика программного обеспечения, что дало бы вам хорошее представление о моей системе взглядов, цель этого — помочь тем, кто ищет быстрый обзор мобильной платформы Ionic. . http://ionicframework.com/. Однако немного истории, которая поможет определить мою точку зрения.

Итак, вот короткая версия… У меня есть степень бакалавра и магистра компьютерных наук в двух разных университетах Калифорнии. Моя любовь к разработке программного обеспечения всегда была вытеснена моей целью жить и работать в Центральной долине Калифорнии. Звучит знакомо? Так не должно быть, большинство из нас, технарей, живут в более технологичных районах или рядом с ними. Я лично? Дайте мне пляж или дайте мне широкую открытую местность. У меня был пляж в колледже, когда пришло время переключаться и копаться, я выбираю здесь (Центральная долина). Так почему же это важно? Компании-разработчики программного обеспечения не склонны открывать свои двери здесь, и на то есть веские причины. Но это не значит, что разработки программного обеспечения не существует. В центральной долине есть ряд компаний, в которых есть ИТ-организации с разработчиками в штате, сельскохозяйственные, продуктовые и CPG-компании, и это лишь некоторые из них. Мне посчастливилось работать в одной из этих замечательных компаний.

Если вы все еще со мной, то, возможно, спросите: «Ну и почему это важно?» Ответ заключается в том, что разница между компанией-разработчиком программного обеспечения и одной из ранее упомянутых компаний заключается в том, что мы не занимаемся написанием программного обеспечения для продажи другим, вместо этого мы пишем программное обеспечение для улучшения нашего бизнеса и, следовательно, можем быть эгоистичными в технологиях, которые мы используем. выберите. Все это говорит о том, что я надеюсь, что следующее поможет в ваших исследованиях, но вы также отнесетесь к этому с недоверием. Долгая борьба одного разработчика с новой технологией может привести к сокращению пути другого.

Проблема

Проблема заключалась в необходимости предоставить мобильное приложение, которое доставляло бы аудио- и видеоконтент большому количеству пользователей. Приложение должно работать как на iOS, так и на Android (телефон и планшет/iPad). Одним из основных требований была возможность для пользователей делать контент по своему выбору доступным для просмотра в автономном режиме. Подобно тому, как Документы Google могут «закреплять» документы и делать их доступными вне сети. Конечно, поскольку это современное мобильное приложение, push-уведомления также требовались для связи с пользовательской базой в режиме реального времени. Это включало, но не ограничивалось глубинной привязкой пользователей к части приложения и возможностью рассылать сегментированные уведомления определенным группам пользователей (например, приложение MLB отправляет обновления Giant фанатам Giant). Наконец, версии приложения для iPad и планшетов должны были использовать доступное дополнительное пространство.

Как обычно, было много других требований, которые не нужно раскрывать для целей этой статьи, например, специальное социальное решение, созданное на PHP. Да, мы можем и иногда изобретаем велосипед, в основном по уважительной причине (в основном для конфиденциальности). Однако, в любом случае, конкретные проблемы лучше решать с помощью нестандартных решений. Когда мы строим исключительно для себя, мы можем позволить себе роскошь быть эгоистичными. Yammer во всей своей красе был недостаточно хорош, чтобы соответствовать нашим потребностям, иди дальше и выше.

Выбор

Сравнение нативных, xamarin и гибридных мобильных устройств (cordova+angular , ionic)

Итак, у нас есть свои требования, и мы знаем, что будем строить. Теперь как будем строить. Самое интересное, я говорю это с сарказмом. Я баловался с таким количеством различных сред разработки, и постоянно появляется все больше, что очень сложно выбрать правильный. Я думаю, что мне повезло, и я выбрал правильные фреймворки для работы. Django был одним из них, я никогда не забуду, насколько легкой стала моя жизнь после того, как я переписал кусок простого программного обеспечения для отслеживания продуктов на Django. Предыдущий стек представлял собой настройку клиентского сервера — мыльные сервисы Java, потребляемые TibcoUI (не спрашивайте!).

Что ж, мобильные устройства были для меня совершенно новой сферой. Я знал, что мне нужно выбрать правильный фреймворк, и знаю, что нативная разработка удовлетворит требованиям. Но кто на самом деле хочет создавать две отдельные базы кода для двух общих платформ? Не я, и это не говоря уже о том, что для того, чтобы быть адаптивным, нужно было учитывать как минимум 2 разных размера экрана для каждой платформы. Не поймите меня неправильно, настройка раскадровки была неплохой, и Swift многое добавляет к старой школьной альтернативе в Objective-C, но переключение между этим и Android Studio действительно ослабляет идею. Писать все дважды, а затем поддерживать это в слишком разных сборках не так уж и хорошо. Тогда я подумал, почему бы не гибрид, давайте закодируем его раз и навсегда.

Введите Xamarin, ну почему бы и нет? Мне нравится идея писать программы на одном языке и компилировать их для двух платформ. Так что инстинктивно я начал создавать начальный проект в Xamarin IDE, очень приятно, что я был впечатлен. У них хорошая настройка раскадровки, похожая на Xcode, и они позволяют создавать общие библиотеки для использования между платформами. Я не большой разработчик .NET, и, честно говоря, я нахожу идею программирования в .NET отвратительной, но я написал немало проектов в Visual Studio, и это всегда получалось хорошо. Это действительно хорошо продуманный язык. Что-то вроде брокколи. Я знаю, что это полезно для меня, но… В любом случае, после создания демо-проекта и развертывания на моем iPhone, я перешел к сборке Android и столкнулся с кирпичной стеной. Опыт был не тем, что я ожидал от IDE, я вернулся на дикий-дикий запад Android-разработки. Нет хорошей раскадровки, я вернулся к проприетарной XML-схеме Android. Почему я не мог просто использовать ту же раскадровку для Android? Тьфу... Ну неужели у тебя не может быть все правильно? Это было возможное решение: у него была хорошая IDE, компилируемый язык коммерческого уровня, и он позволял мне использовать общие библиотеки в разных сборках. Так что я оставил его в шорт-листе и пошел дальше.

Веб-разработка не чужда мне, поэтому я, конечно, чувствовал себя более комфортно с идеей решения Cordova/PhoneGap. С чем я действительно боролся, так это с реализацией правильного веб-материала для мобильных устройств. Я видел несколько гибридных мобильных приложений, и они оставляли желать лучшего. Это не было близко к родному, и вы, как правило, почти затаили дыхание, пытаясь щелкнуть в приложении, поскольку кнопки и навигация оказываются слишком маленькими или слишком большими и всегда медленно реагируют на взаимодействие с пользователем. И насколько надежными могут быть эти плагины?

Мне не стыдно сказать, что я немного покопался, пытаясь применить гибридную сеть. Я наткнулся на несколько фреймворков, включая MeteorJs, которые выглядели многообещающе, но предлагали слишком много законченного решения. Мне нужна была структура для создания мобильного приложения, а не вся мобильная архитектура. Ближе к концу, когда я начал возвращаться к Xamarin как к окончательному решению, я столкнулся с Ionic Framework. В то время они все еще находились в стадии бета-тестирования, используя Angular 1, но это выглядело идеально, и так оно и было. Не нужно беспокоиться об отдельной библиотеке для материалов или объединении библиотек JS, вместо этого AngularJS и директивы ionic идеально подходят друг другу. Быстрое доказательство концепции, и мы ушли с надеждой на успешную реализацию проекта и раннего кандидата на выпуск Ionic.

Борьба

Так что помните, что борьба всегда реальна, нет одной волшебной схемы, которая сделает все за вас. В типичной быстро меняющейся среде время выхода на рынок имеет большое значение, и обычно оно сводится к обратной зависимости между временем и деньгами. Также будьте уверены, что вы не читаете другую статью «Hello World», которую мы создали в мобильном приложении Ionic, и мы сделали это в обоих магазинах приложений. Вот история:

С Ionic мы смогли очень быстро оторваться от земли. На самом деле у них есть несколько шаблонов приложений, с которыми вы можете начать работу. По сути, они составляют маршрут с несколькими шаблонами, контроллером и бах! теперь у вас есть семя для развития вашего приложения.

$ ionic запустить боковое меню myApp

Следующие шаги также становятся очень простыми и понятными. Обратите внимание, что в приведенном выше аргументе командной строки используется команда ionic. Команда Ionic проделала выдающуюся работу по абстрагированию разработчика от всех тонкостей веб-разработки и мобильного развертывания, чтобы вы могли сосредоточиться на своем приложении. Следующим шагом было погрузиться и начать настройку маршрутов Angular с соответствующими шаблонами, чтобы соответствовать требованиям нашего нового мобильного приложения. Что было полезно, так это возможность запустить сервер разработки, который будет следить за файлами в вашем приложении, обнаруживать любые обновления и обновлять ваш браузер, чтобы вы могли проверить свои изменения. Последнее — это действительно «наблюдение за глотком» с добавленной тонкостью и удобством запуска сервера разработки из командной строки, чтобы вы могли быстро выполнять итерации обновлений кода.

Прокси и CORS

Команда ionic serve (аналогичная ng serve: Angular) также позволяет вводить прокси-серверы разработки. Это позволит вам обойти проблему CORS при разработке в браузере. Конечно, после развертывания приложения на мобильном устройстве CORS не является проблемой, поскольку приложение работает на локальном хосте. Это упростило разработку. Большая часть разработки приложения была сделана в браузере. Когда требовались аппаратные точки соприкосновения, мы переходили на эмулятор/аппаратное обеспечение.

Развертывание Xcode

Развертывание Xcode было несложным, как только среда была настроена правильно. Следуя руководству по началу работы с Ionic, я смог добавить свои платформы iOS и Android. Вначале я обнаружил, что развертывание на тестовом устройстве лучше всего выполнять путем «компиляции» проекта и развертывания через Xcode. Более поздние достижения в Ionic позволили развертывать непосредственно из командной строки.



Android

О, Андроид, эти отношения любви-ненависти у меня с тобой. Как и многие, я начинал с разработки исключительно для iOS. Правильно, это гибридная среда: я разработаю приложение в браузере Chrome и отправлю его на устройства iOS для тестирования точки касания оборудования, что может пойти не так? Фу. Помните, что в то время Ionic находился в стадии бета-тестирования. После развертывания моего приложения для iOS и поиска его по магазинам — в основном, демонстрируя Ionic, — я решил попробовать развернуть его на оборудовании Android. Проще говоря, опыт был не идеальным: одно и то же приложение, которое казалось родным для iOS, было «прерывистым», медленным и работало по-разному в зависимости от оборудования, на котором оно работало. Что! Не может быть, команда Ionic не могла такого продвигать, и не было, и не было. В разных версиях Android приложение отображалось в разных версиях браузера Android, поэтому в бета-версии интерфейс был разным. Решение состояло в том, чтобы использовать браузер под названием Crosswalk и упаковать его в Android APK. Используя браузер Crosswalk, можно почти гарантировать производительность и функциональность на устройствах Android. Однако вам все равно придется следить за этими плагинами, поэтому мы закончили разработку и тестирование более популярных устройств Android. В более поздних версиях Ionic Crosswalk был развернут по умолчанию.

Что помогло

Уведомления

Частью требований нашего приложения была возможность отправлять сегментированные push-уведомления. После борьбы с доморощенной системой, которая у нас была, я решил поискать в другом месте. У Amazon было решение, которое начиналось с бесконечного чтения документации, с чем я согласен, но я чувствовал, что в то время их решение не было отполировано. У меня действительно не было времени, чтобы купить двигатель и построить машину вокруг него. Нам нужно было что-то, что могло бы понимать сегменты, с чем было бы легко взаимодействовать и что-то вроде панели инструментов для отчетов/отладки. Нам нужна была вся машина! В итоге мы воспользовались сервисом под названием Urban Airship. Я не могу сказать достаточно об этом сервисе, это машина коммерческого класса. В итоге мы сделали довольно сложную сегментацию push-уведомлений (вспомните Facebook), и эта штука съела их и выплюнула. Простая панель администратора, простой интерфейс, но то, что скрывалось внутри, было тонной лошадиных сил — о да, мне тоже нравится их логотип.

Ионный материал

Большим подспорьем стала возможность использовать Ionic для UX. Это не только помогло нам оставаться в рамках рекомендаций по стилю UX для IOS и Android, но и быстро освоило приложение. Конечно, по большей части мы оставались в рамках Ionic Box трюков UX, но это было бы хорошо. После того, как мы разработали приложение с использованием материалов Ionic, мы смогли использовать CSS и обновить глобальный стиль, чтобы он соответствовал нашему видению. В итоге приложение выглядело великолепно, оно выглядело естественно, и мы получили массу похвал за дизайн. Мы добавили некоторые из наших собственных приемов JavaScript/CSS в тех местах, где нам нужно было дополнительное прикосновение и вау-эффект, но этого было немного. Если бы в этой части истории была мораль, а ее нет, но если бы она была, то я бы сказал, оставайтесь в рамках. Если вам нужно добавить «летающих кошек» в свое приложение (посмотрите на замечательное приложение Zappos), вам, возможно, придется выбрать нативное.

Результаты

Когда наконец выпустили, некоторые из наших колледжей упомянули, что они никогда не видели другого ионного приложения в Appstore, что они были впечатлены, и что, судя по тому, что они читали о фреймворке до сих пор, это должно быть нелегко. Наоборот, я чувствую, что их многочисленные достижения в создании кода на Objective-C были намного лучше. Но для каждой работы есть подходящий инструмент, и я считаю, что Ionic подойдет для многих мобильных приложений. Если вам удобно кодировать современное веб-приложение и вам нужно создать мобильное решение, то, вероятно, этот инструмент для вас (при условии, что летающие кошки не требуются). Честно говоря, вы, вероятно, можете реализовать кошку, использующую зонтик для прыжка с парашютом в Ionic, мне просто нравится использовать аналогию. А мне нравится Заппос.