Country not specified
Unknown website Share

Apps4all

Страна: -
Город: -
Был онлайн: -
О себе:
 
08-07-2016, 10:57
Apps4all

Дмитрий Моисеев (Контур.Эльба): «Несмотря на то, что Xamarin – кроссплатформенное решение, от разработчика требуется четкое понимание особенностей каждой мобильной ОС»

Сегодня редакция Apps4All пообщалась с Дмитрием Моисеевым, последние два года он занимается разработкой мобильного приложения Контур.Эльбы, а также оказывает посильную помощь при разработке мобильных приложений других команд СКБ Контур.

Дмитрий, добрый день. Расскажите, когда было запущено приложение?

Год назад мы выпустили мобильное приложение под Android и активно его развивали. Сейчас пришло время мобильной платформы iOS, второй по популярности среди наших пользователей. Несколько лет назад команда уже предпринимала попытку сделать приложение для iPhone, но результат вышел неоднозначный. Основной проблемой стало то, что разработка была «полуаутсорсовой» и приложение не удавалось эффективно развивать и поддерживать одновременно с веб-сервисом. В этот раз разработка велась при активном участии основной команды.

Поделитесь особенностями и ошибками, с которыми вам пришлось столкнуться.

Приложение под Android разрабатывалось для существующих пользователей Эльбы, поэтому в первой версии была возможность просматривать созданные в сервисе счета, документы и контрагентов. Позднее появилась возможность редактирования этих данных. А при создании iOS-приложения мы поставили иную цель – приносить пользу всем предпринимателям, а значит, предоставить возможность пользоваться приложением сразу после установки из AppStore, без регистрации.

Вторым отличием стали использованные технологии: Android-приложение мы писали с использованием родного Google-инструментария и на Java, а приложение под iOS – уже на кроссплатформенном фреймворке Xamarin и C#, чтобы задействовать тот же язык и платформу (.NET), что и на сервере.

После переноса на эту же платформу приложения под Android мы сможем одновременно развивать оба приложения с минимальными задержками между релизами новых фич. Кроме того, будут задействованы общие куски бизнес-логики на сервере и телефоне.

Для первого релиза мы выбрали минимальный набор возможностей: выставление счетов и отправка их по электронной почте или с помощью мессенджеров.

На первом экране пользователя встречает описание возможностей, а при создании документа нужно ответить всего на один вопрос: у вас ИП или ООО?

После выбора формы бизнеса можно выставить счет с фактурной частью и отправить контрагенту в виде PDF-файла или ссылки на документ. Перед этим следует заполнить реквизиты: ИНН и расчетный счет.

Без регистрации в приложении можно создать не более пяти счетов. Чтобы создавать неограниченное количество документов, нужно пройти регистрацию – указать электронную почту в качестве логина и придумать пароль. Никаких длиннющих форм :)

Несмотря на бесплатный тариф в веб-версии Эльбы, лимитов на создание счетов нет – бонус для пользователей приложения.

Как проходил процесс разработки?

Несмотря на то, что опыта разработки под iOS и Xamarin у нас не было, команда была настроена оптимистично. Xamarin на рынке уже не первый год, коммерческая версия на 1 платформу и 1 разработчика стоит 1 000 $ в год (Android + iOS соответственно 2 000 $), а значит, компания явно вкладывает силы и ресурсы в полировку своего продукта.

Увы, несмотря на возраст и большие амбиции, платформа оказалась сырой, причем по всем фронтам.

Редактор кода (Xamarin.Studio) – очень нестабилен. Может зависнуть в процессе сборки приложения, иногда перестает работать отладка или не открывается файл с версткой экранов. Не очень хорошо работают автодополнение кода. Настройки проекта могут измениться при открытии его в новой версии редактора. Подсветка синтаксиса может сработать неверно или совсем отключиться, а при переключении на русский язык недоступны горячие клавиши.

У Xamarin есть плагин, который позволяет писать код в Visual Studio под Windows, через локальную сеть компилируя и запуская приложение на Mac’. Но данный плагин тоже нестабилен, как и весь мир :) Поэтому процесс разработки у нас выглядит так:

  • код лежит в сетевой папке, доступной на Mac’е и на запущенной виртуальной машине Parallels;
  • основная часть кода пишется в Visual Studio под Windows внутри виртуалки;
  • отладка или сборка финальной версии происходит в Xamarin.Studio на Mac OS X, но не через плагин, а через ручное открытие того же кода в общей папке.

Помимо редактора кода, есть другой нюанс: для iOS написано множество готовых библиотек и компонентов на Object-C или Swift, а для Xamarin’а их заметно меньше. В Xamarin-проекте можно создавать обертки вокруг Object-C кода для iOS или Java-кода для Android, но тогда теряется главное преимущество – код на одном языке на сервере и телефоне.

Несмотря на то, что Xamarin – кроссплатформенное решение, от разработчика требуется четкое понимание особенностей каждой мобильной ОС. Когда при работе над iOS-приложением мы использовали привычки, приобретенные за время разработки Android-версии, поняли – некоторые вещи устроены радикально иначе, например, работа с фоновыми процессами. Xamarin не сглаживает эти моменты.

Кроме основного продукта Xamarin, мы использовали библиотеку Xamarin.Forms, которая появилась в середине 2014 года. Это дополнительная обертка, позволяющая создавать верстку экранов сразу для обеих мобильных версий. К сожалению, и тут выяснились некоторые «нюансы»:

1. Кроссплатформенные компоненты не всегда имеют те же свойства, что и родные. Может не оказаться настройки отступов, цвета, выравнивания текста, замены шрифта, анимации, поддержки свайпа и т. п. Чтобы их добавить, требуется определенное время на доработку.

2. В библиотеке есть баги, в том числе крупные. Мы, например, столкнулись с такой проблемой: некоторые элементы управления на экране просто не появлялись, если их скрывать / показывать из кода. Причем этот баг возникал не всегда. Решение-костыль для него подобрать удалось, но неприятный осадок остался.

3. Через библиотеку нельзя управлять некоторыми возможностями. Например, нельзя поместить элементы управления в навигационную панель iOS приложений, а также усложняется создание анимации или каких-то специфичных эффектов.

4. Эта прослойка работает медленнее, чем родные компоненты, поэтому приходится помучиться над дополнительной оптимизацией.

В общем, напрашивается вопрос: а стоит ли использовать Xamarin, если требуется создать приложение для нескольких мобильных платформ сразу? Пожалуй, все-таки стоит, но с парой оговорок:

1. Нужно быть готовым к тому, что в продукте есть заметные баги и их придется обходить.

2. Продукт не до конца скрывает особенности платформ, так что изучать все нюансы работы с iOS и Android все равно придется.

А как проходила передача дизайна разработчикам?

При работе с версткой на первых порах нам помог продукт Zeplin, позволяющий экспортировать проект прямо из Sketch’а.После этого разработчик может посмотреть все размеры, отступы, шрифты, не дергая по каждому спорному вопросу проектировщика интерфейсов.

К сожалению, и в нем встретились баги с показом размеров, из-за которых неверно работает округление. Поэтому мы перешли на бесплатный плагин Sketch под названием marketch –он экспортирует проект в HTML-формат, после чего можно смотреть результат в любом браузере. Багов с пересчетом размеров пока не замечено, и обрадовало то, что не нужно ставить отдельный софт каждому разработчику.

Модерация в App Store: какие там подводные камни?

Премодерация приложения в App Store стала для нас отдельным приключением, которое требует своей истории. На эту тему мы опубликовали целую статью с подробностями общения с модераторами.

Если в двух словах, проблем было две:

1. Мы поместили в приложение ссылку на промо-сайт. А так как на сайте можно купить Эльбу, такие ссылки в приложении ставить нельзя.

2. Много времени пропало из-за взаимного недопонимания. Модераторы по какой-то причине требовали убрать из приложения регистрацию или добавить in-app purchase, а мы объясняли, что приложение бесплатно, в нем нечего покупать, а значит, и в in-app purchase нет нужды.

Вывод из этого простой: модераторы App Store тоже люди и могут ошибаться, так что кнопка апелляции в интерфейсе сделана неспроста.

Следствие из вывода: время прохождения модерации никак не гарантированно, нужно закладывать время на возможные форс-мажорные обстоятельства.

Какие теперь у вас планы?

В ближайших планах у нас:

  • Доработать iOS приложение, чтобы оно по возможностям догнало Android-приложение.
  • Перенести Android-приложение на Xamarin.
  • Добавить новые фичи, которые уже давно ждут своего часа, например – распознавание документов из фотографий. 

Дмитрий, спасибо вам за то, что поделились с нами опытом, удачи!

 
интервью
приложение
разработка
советы начинающим
0 0 0

Чтобы оставлять комментарии вам необходимо зарегистрироваться