Адаптация Xamarin.Forms к разработке корпоративных и B2E приложений

в 14:44, , рубрики: b2e, devops, xamarin.forms, аналитика, архитектура приложений, безопасность, корпоративная разработка, разработка мобильных приложений, советы и рекомендации, метки: , ,

Немного об авторе:
Adam Pedley (Microsoft MVP, Xamarin MVP, Xamarin Certified Developer)

Корпоративные или Business to Employee (B2E) мобильные приложения могут сильно отличаться от их B2C-аналогов. B2C приложения, как правило, сосредоточены на небольшом количестве экранов для основного использования, а дополнительные экраны используются не так часто, там, где необходимо выполнять вспомогательные функции.

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

Архитектура приложения

Я предполагаю, что большинство из вас уже слышали о MVVM и Dependency Injection. Я рекомендовал бы это для любой разработки на Xamarin.Forms, не только корпоративной. Использование MVVM с Dependency Injection, поможет вам создать качественное приложение на Xamarin.Forms. Как спроектировать архитектуру вашего приложения, если оно будет иметь очень большую кодовую базу — это еще одна история, но в этой статье она рассмотрена не будет.

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

API

Если вы используете один API, то вы его контролируете, вам повезло. К сожалению, так не всегда происходит в корпоративных приложениях. У вас может быть небольшое количество API, которые вы не контролируете, и они могут меняться в течении жизни вашего приложения, особенно если вы имеете дело с плохо реализованными API.

Чтобы противостоять этому, я всегда создаю сервис для своих репозиториев на общем уровне. Класс репозитория — это просто код, который соединяется с API и передает/извлекает данные между ними.

Схема устройства слоя доступа к данным

Это защищает ваше приложение от изменений API и удаляет его как зависимость при модульном тестировании.

Сложная навигация

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

  1. Не позволяйте кнопке «Назад» вернуть пользователя на страницу входа в систему;
  2. Начать заполнение многостраничной формы, с возможностью уйти, затем вернуться и ожидать возобновления в том же состоянии;
  3. Предупреждать или останавливать навигацию, если пользователь не выполнил требуемые действия;
  4. Просмотр страницы, но не сохранение в навигационном стеке, когда пользователь двинулся дальше;
  5. Избегайте дублирования страниц в стеке навигации и загружайте существующие, если они есть.

Эти варианты навигации являются достаточно сложными и не входят в стандартную поставку распространенных MVVM фреймворков, за исключением Exrin. Это одна из главных причин, по которой Exrin был создан.

Безопасность

Системы безопасности корпоративного класса, на самом деле, не более безопастны чем и стандартная система безопасности, обычно они сложнее, а следовательно повышается риск неправильной реализации. Вы можете обратиться к Citrix, Microsoft Online или Azure Active Directory. Если вам повезет, у вас будет хороший OAuth API.

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

  1. Используйте устаревающие токены для аутентификации. Не храните ни одного имени пользователя или пароля;
  2. Не помещайте в свой код ключ для дешифровки или конфиденциальную информацию. С помощью реверс-инжиниринга она становится публичной;
  3. Не храните конфиденциальные сведения, если не нужно;
  4. Если необходимо хранить конфиденциальную информацию, убедитесь, что она зашифрована.

Ключ шифрования должен быть сгенерирован мобильным приложением во время выполнения, а затем безопасно сохранен, например в KeyChain или KeyStore.

Убедитесь, что вы также следуете отраслевым стандартам, таким как OWASP Mobile Security Testing Guide.

Автономное использование

B2C приложения в основном имеют роскошь говорить — «Вы должны быть подключены к Интернету», при использовании приложения. B2E приложения не всегда имеют такую возможность, например в шахтах или пробелы Wi-Fi зон в больших зданиях. Это означает, что вам потребуется какое-то автономное хранилище. В этом случае, чтобы избежать осложнений, лучше всего всегда запускать приложение из базы данных с помощью службы синхронизации, чтобы обеспечить подключение к API.

Схема реализации слоя доступа к данным при автономном использовании

DevOps

DevOps устанавливает набор процессов для взаимодействия между специалистами по разработке и информационно-технологическому обслуживанию. Это похоже на Agile и Continuous Delivery, но добавляет дополнительное освещение специалистов по управлению и ИТ-обслуживанию, которые обычно исключены из цикла рабработки. DevOps это не то, что вы найдете в небольшой компании, но сможете найти на уровне предприятия.

Как DevOps связан с разработкой на Xamarin.Forms? По сути, никак, но есть вещи которые могут сделать вашу жизнь проще.

  1. Создание конфигурационных файлов основанных на JSON, а не жестко закодированные. Это поможет при развертывании в различных окружениях, например тестировании или UAT;
  2. Настройка VSTS (или другие) и подключить к HockeyApp или Mobile Center;
  3. Настройка аналитики в вашем приложении для записи релевантных метрик по сравнению с ожидаемым результатом.

Аналитика

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

Например, если цель была простой, сэкономить время сотрудников. Во-первых необходимо установить базовый уровень, который определяет бизнес в данный момент. Если заполнение бумажной формы займет приблизительно 2 минуты, и еще 2 минуты для чего-то, чтобы скопировать в систему и возможно еще 2 минуты, чтобы исправить какие-то ошибки, в среднем это занимает 6 минут. Убедитесь, что вы измеряете время, необходимое, чтобы заполнить форму в мобильном приложении, и как часто это делается. Тогда у вас будет точная метрика сэкономленного времени сотрудника. Далее бизнес может связать это с внутренней оценкой того, сколько будет стоит время сотрудника.

Управление мобильными устройствами

Когда вы являетесь крупной компанией, у вас уже должен быть MDM-набор, чтобы управлять всеми мобильными устройствами своих сотрудников. К сожалению, эти системы иногда не имеют API, который может подключиться к вашему автоматизированному процессу сборки. Я рекомендую использовать HockeyApp или Mobile Center, чтобы обеспечить тестирование и UAT возможности, затем ручное развертывание в MDM, когда будете готовы к выходу в продакшн.

Заключение

Некоторые основные отличия в корпоративных приложениях, которые необходимо учитывать:

  1. Абстрактные вызовы API;
  2. Спланируйте навигацию перед началом разработки;
  3. Требования безопасности, вероятно, будут выше;
  4. Ожидать автономного использования;
  5. Настройте свой проект, для простого DevOps;
  6. Убедитесь, что аналитика настроена и соответствует ожиданиям бизнеса;
  7. Аккаунт для MDM’s в вашем процессе Continuous Delivery.

Автор: Evgeniy Pakalo

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js