26-07-2016, 08:00 1025
Apps4All

Алексей Колесов (Контур.Бухгалтерия): «Основные силы бросим на развитие приложения iOS»

Более года назад команда онлайн-сервиса Контур.Бухгалтерия компании СКБ Контур выпустила мобильное приложение для Android для совместной работы бухгалтера и директора. Оно дополнило веб-версию сервиса: в нем бухгалтер мог вести учет, а директор — смотреть документы, следить за долгами контрагентов и отправлять счета. Приложением стали активно пользоваться клиенты сервиса.

Редакция Apps4All пообщалась с Алексеем Колесовым, разработчиком и главным «идеологом» мобильной Контур.Бухгалтерии. Он рассказал, как создавалось мобильное приложение, что изменилось в нем за последний год и что еще изменится. Поговорили и о долгожданном приложении для iOS, появившемся совсем недавно.

История создания мобильного приложения Контур.Бухгалтерия

Сложности в разработке

Начнем с того момента, когда вообще появилась идея создания мобильного приложения. Когда встал вопрос о том, что нам оно нужно, мы выбрали платформу Xamarin. Она позволяет писать кроссплатформенные приложения на хорошо знакомом нам языке C#.

Первым появилось приложение для Android. Поскольку это была наша проба пера, и мы хотели выпустить приложение как можно скорее, код на тот момент сильно зависел от операционной системы Android и не был готов к работе на других платформах — iOS или Windows Phone.

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

Что появилось и чего не появилось за год

Об отправке актов и накладных

Мы добавили возможность создания основных документов. Если раньше речь шла только о создании счета, то теперь у нас появилось создание акта и накладной. Изначально счет можно было только смотреть.

О работе с контрагентами

Самое «вкусное» обновление — это создание и редактирование контрагентов, поиск их по ИНН. Если у вас есть интернет, можете нажать кнопку «найти контрагента», и мгновенно получите результат — карточку с уже заполненными данными.

О нумерации документов

Мы добавили автонумерацию создаваемых документов, о которой очень просили пользователи. Теперь при создании документа не нужно указывать номер вручную — он проставится автоматически, в зависимости от наличия документов такого же типа в текущем году.

О том, от чего отказались

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

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

Интересные решения

«Сердцем» нашего приложения была выбрана библиотека MvvmCross. В интернете много статей, в которых воспеваются ее преимущества, но, как это часто бывает, ничего не говорится о довольно специфических проблемах, с которыми можно столкнуться в процессе разработки. Тем не менее, надо отдать должное создателям этой библиотеки. Ребята активно развивают ее, правят баги, и редкий пост на stackoverfow остается без комментария самих разработчиков или участников сообщества.

Кейс 1: Отказ от контейнера Autofac

Первое техническое изменение, которое мы внесли в процессе активного использования MvvmCross, была замена IoC-контейнера Autofac, который на тот момент жил в нашем приложении, на встроенный контейнер самого MvvmCross. Замену нельзя назвать равноценной — Autofac довольно мощная библиотека и с лихвой покрывала наши нужды, но, с другой стороны, посмотрев все ее возможности, мы поняли, что при наличии уже встроенного контейнера в MvvmCross использование Autofac было избыточным. Встроенный контейнер MvvmCross имеет сравнительно скромные возможности, зато быстр и не требует дополнительных зависимостей.

Как бы то ни было, к этому другому решению я бы вернулся, если требования к архитектуре поменяются. Благо, решение уже существует.

Кейс 2: Изменение механизма навигации

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

Изначально MvvmCross позволяет передавать очень простые данные: строки, числа, несложные объекты. Это хорошо работает в описанном выше случае с просмотром документа, но не будет работать при создании товара. В итоге было решено немного «прокачать» встроенный механизм навигации, научив его распознавать передачу сложных объектов с данными. С помощью сериализатора такой объект упаковывался на одном экране приложения и распаковывался уже на другом, позволяя проводить с ним какие-то дальнейшие манипуляции.

Кейс 3: Принудительный апдейт

Третья проблема, с которой сталкиваются все разработчики приложений с возможностью хранения данных, — это обеспечение совместимости одной версии приложения с другой. В первых версиях Android-приложения это решалось определенной схемой миграции данных из старой версии приложения в новую. В какой-то момент мы увидели, что пользователей, которые используют старую версию приложения, не мало, а значит, нам с каждым новым релизом нужно будет правильно обеспечивать пользователю переход с его версии на новую, не поломав сохраненные данные. Было решено попробовать принудительно переводить пользователей на новые версии, а старые поддерживать в течение трех месяцев, после чего вычищать весь код, который хоть как-то касался старого функционала.

Технически такая функциональность была реализована с двух сторон: приложение на телефоне пользователя с помощью библиотеки Refit с каждым запросом к серверу отправляет информацию о текущей версии приложения, а сервер, если версия довольно свежая, отправляет набор данных либо возвращает ошибку, если приложение пора обновить.

Вопреки нашим ожиданиям, такая схема не вызвала резкой критики пользователей, а нам в свою очередь позволила держать код чистым от «костылей» для обратной совместимости.

Немного о будущем: планы, задачи, мечты

«Основные силы бросим на развитие приложения iOS»

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

Тем не менее, мы стараемся брать в разработку именно те задачи, за которые голосует большинство наших пользователей, например создание счетов-фактур и финансовую аналитику. У нас уже есть накопившийся пул задач, так называемый «бэклог», на него мы и ориентируемся. Основные силы в этом году мы бросим на развитие приложения под iOS.

O приложении для iOS

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

В визуальном плане мы хотели сделать его максимально похожим на приложение под Android, это хорошая практика и в целом легче для разработки. С момента, как мы приступили к написанию кода, прошло всего два месяца. Мы рассчитываем, что в течение трех месяцев приложение по функциональности догонит версию для Android.

Процесс разработки iOS

К началу работы над iOS-приложением мы подошли подготовленными. У нас было «ядро», содержащее всю бизнес-логику, код для работы с сетью и хранения данных. По сути, все сводилось к тому, чтобы аккуратно заверстать экраны и правильно связать данные с их отображением.

Начало разработки было очень динамичным. Я работал в паре с коллегой, у которого уже был опыт разработки под iOS-платформу, и первый экран — экран авторизации — появился уже буквально на второй день. Процесс был приятным еще и от того, что не приходилось думать о проблемах, которые когда-то всплывали при разработке Android-приложения: все они были уже решены. Уже потом, в процессе тестирования, мы вспоминали, что даже не посмотрели, как работают те или иные части приложения, но, все-таки проверив их, убедились, что они просто работают и что старый код не подвел и в этот раз.

Работа велась на двух машинах: на одной, под управлением Windows, оперативно решались проблемы с мелким рефакторингом и проставлением данных в верстку. На второй, под управлением OS X, делалась вся верстка и запускался эмулятор. Иногда нам удавалось делать в день по несколько экранов, иногда под рефакторинг отводились целые дни, потому как при таком темпе разработки технические решения и код не всегда были изящными.

Одной из проблем, с которыми мы столкнулись потом, в процессе тестирования приложения, была сборка и работа приложения в релизном (Release) режиме. Проблема эта довольно известная, и касается она линковки кода приложения. Суть этого процесса в том, чтобы избавить приложение от кода, который не используется. Плюс этого очевиден — размер файла приложения уменьшается в несколько раз. Но есть и минус: вместе с ненужным кодом из приложения может исчезнуть и нужный. Так было и у нас, и я не могу сказать, что починили это очень быстро, пришлось покопаться.

Практически постскриптум

«Было бы интересно попробовать писать под Windows»

Будет ли приложение для Windows Phone? Мне как разработчику было бы интересно попробовать писать под Windows. Когда мы только начинали задумываться о мобильном приложении и анализировать рынок, доля тех, кто был на Windows Phone, была мала. Сейчас ситуация не сильно изменилась, и у нас был всего один запрос. Так что пока разработка этой версии откладывается.

Краткая справка: что может мобильное приложение для Android сейчас

  • Показать вам всю информацию по деньгам и долгам.
  • Собирать статусы отчетов: принят / не принят / требует внимания бухгалтера / пришло требование из налоговой.
  • Напоминать вам о сроках выплаты взносов и отчетности.
  • Создавать, редактировать и отправлять по электронной почте счета, акты и накладные.
  • Создавать и редактировать контрагентов, искать контрагентов по ИНН.

Алексей, спасибо, успехов!

 
приложение
интервью
разработка
ios
android
бухгалтерия
0 0 0

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