Файл: Критерии выбора средств разработки мобильных приложений (Разработка мобильного приложения для курьерской службы доставки «Ptichka»).pdf

После выбора города пользователю должны быть представлены поля ввода для номера и согласия на обработку персональных данных [7].

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

При вводе корректного кода пользователь должен перенаправляться на страницу, содержащее поле ввода для имени и фамилии.

После ввода имени и фамилии пользователю должны быть доступны основные страницы приложения.

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

Приложение должно предоставлять возможность определения геолокации пользователя и отправки ее на сервер.

Приложение должно иметь возможность взаимодействовать с веб- сервером путем отправления запросов к нему за информацией о:

● доступных пользователю заказах;

● выполняемых пользователем в данный момент заказах;

● завершенных заказах пользователем за последние 48 часов;

● текущем балансе пользователя;

● истории операций, проводимых с балансом пользователя;

● материалах, содержащих информацию о работе «Ptichka».

Передаваемая и получаемая информация должна быть представлена в формате JSON [9].

Для каждого запроса к веб-серверу в заголовке должен быть указан токен, полученный при регистрации пользователя.

Приложение должно иметь возможность получать push-уведомления от сервера, содержащие информацию о:

● новом доступном заказе;

● отмене клиентом заказа, который выполняет пользователь;

● уведомлении для пользователя.

Приложение должно быть доступно на:

● Android версии 4.4 или более поздней;

● IOS версии 9.0 или более поздней.

2.4. Выбор технологии для реализации приложения

Обязательным требованием при разработке приложения является кроссплатформенность. Соответственно, приложение должно быть доступно на платформах Android и IOS. Данное требование сильно усложняет разработку в короткие сроки и при отсутствии большой команды разработчиков:

● у каждой платформы есть свои ограничения и особенности в разработке, которые нужно учитывать при реализации функций приложения;

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

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

Возможные варианты реализации приложения:

● проектировать и реализовывать приложение для каждой платформы отдельно на нативных языках: Java для Android и Swift для IOS;

● использовать технологии, позволяющие писать один код для обеих платформ.

Создание приложения для каждой платформы отдельно имеет ряд плюсов:

● приложение будет оптимизировано: быстрый запуск и быстрая работа, а также малый размер установочного файла;

● при реализации можно будет использовать все возможности, предоставляемые платформой.

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

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

Данный подход позволяет

● экономить ресурсы, требуемые для получения знаний необходимых для реализации проекта, и время, затрачиваемое на его реализацию;

● переиспользовать написанный код;

● легко добавлять новый функционал и обновлять версии существующих приложений;

Среди таких технологий самыми популярными и развитыми являются Xamarin и React Native. Обе технологии являются фреймворками для разработки кроссплатформенных приложений и позволяют определять один пользовательский интерфейс и привязывать к нему единственную логику приложения для разных платформ [1].

При использовании Xamarin исходный код приложения пишется на языке C#. При использовании React Native исходный код реализуется на языке JavaScript.

В связи с наличием практического опыта разработки с использованием JavaScript и его технологий, и отсутствие такового в разработке с использованием C#, было принято решение реализовывать приложение при с использованием React Native.

React Native – это фреймворк для разработки кроссплатформенных приложений для IOS и Android от компании Facebook.

На протяжении всего периода разработки и поддержки проекта, с использованием этого фреймворка, разработчик работает с кодовой базой, написанной на JavaScript. При необходимости написанный код компилируется в нативные форматы: .apk для Android и .ipa для IOS, которые можно будет добавить в магазины: PlayMarket для Android и Appstore для IOS, где их смогут загрузить потенциальные пользователи.

Проектирование архитектуры приложения, описание классов, функций, методов реализуется основываясь на функционале и возможностях этого языка. React Native никак не ограничивает разработчика в использовании JavaScript – фреймворк лишь предоставляет элементы, которые могут быть скомпилированы в нативные и методы для работы с функциями мобильного устройства: получение геолокации, работа с камерой устройства, доступ к локальному хранилищу устройства и тд. [2].

Поэтому все преимущества работы с JavaScript, также доступны и в разработке мобильных приложений, используя React Native:

● JavaScript очень популярный язык: это единственный язык для разработки клиентский приложений и у него огромное сообщество разработчиков. Поэтому существует множество библиотек и готовых модулей, написанных другими разработчиками, которые находятся в открытом доступе и которые можно использовать в своем проекте;

● JavaScript имеет низкий порог вхождения: этот язык можно изучить в короткие сроки и сразу же начать писать код для решения реальных задач;

● как правило, при работе с этим языком не используются массивные фреймворки с большой кодовой базой, поэтому можно плавно повышать сложность реализуемых проектов путем изучения отдельных библиотек при их интеграции;

● для создания мобильных приложений разработчику не нужны будут знания и опыт в их разработке. Достаточно иметь опыт в разработке клиентский приложений с JavaScript. Соответственно, гораздо легче будет найти людей для разработки/поддержки проекта;

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

Как было описано ранее, использование React Native не накладывает никаких ограничений на структуру проекта и работу с JavaScript. Поэтому можно было использовать разные архитектурные подходы при реализации приложения.

При создании приложения было принято решение использовать Flux, как архитектурный подход. Такое решение было обосновано:

● наличием опыта работы с данным подходом ранее;

● популярностью Flux в сообществе разработчиков. Поэтому в большинстве примеров и обучающих материалах (в том числе по React Native) использовался именно он;

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

Flux-архитектура – архитектурный подход или набор шаблонов программирования для построения пользовательского интерфейса веб- приложений, сочетающийся с реактивным программированием и построенный на однонаправленных потоках данных [3].

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

Flux-архитектура состоит из трех компонентов:

● представление – компонент, реализующий выдачу информации пользователю. В клиентских приложениях может быть представлен страницей в веб-браузере (или в мобильном приложении) или обособленным модулем на ней. У представления есть доступ к чтению информации из хранилища, но нет возможности напрямую изменять ее: добавлять новые данные, редактировать или удалять существующие. Как пример представления, можно привести страницу со списком доступных заказов для пользователя в разрабатываемом приложении. Вся информация по заказам хранится в хранилище, в представлении она лишь преобразуется для удобного отображения в интерфейсе пользователя;

● хранилище – объект, в котором хранятся все данные, используемые в приложении. Данные из хранилище можно считывать, но нельзя изменять напрямую. Для их изменения существуют действия, которые можно отправлять в хранилище из представлении и других модулей проекта. И уже в зависимости от типа действия и данных, указанных в нем, хранилище само определит, какие изменения нужно произвести с данными;

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

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

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

Из-за того, что представление не может напрямую изменять данные в хранилище, не будет конфликтов при добавление новых интерфейсов (представлений) в проект и изменение существующих.

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

Язык программирования JavaScript имеет динамическую типизацию: типы для всех переменных определяются уже во время выполнения программы [4]. Этой несет за собой большие недостатки при создании приложений на нем:

● во время разработки на динамически типизированных языках много времени уходит на решение ошибок связанных с неправильным обращением к данным. Например, вызов метода у объекта, у которых этих методов нет или передачей некорректных данных в функцию или метод класса [5];

● типы переменных, помимо того, что сразу указывают на ошибки при неверном обращении к данным, так же хорошо документируют код. Хорошо семантически названный класс или интерфейс позволяют быстро понимать назначение созданных объектов, что является очень полезным при работе над большим проектом или при работе в команде;

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

Ускорить работу JavaScript не предоставляется возможным, но возможность добавить статическую типизацию в процесс разработки приложения на нем есть. Существует ряд технологий, позволяющих реализовать статический контроль типов в языке JavaScript. Самыми популярными на данный момент является TypeScript от компании Microsoft и Flow от компании Facebook. Обе технологии являются статическими типизаторами кода и предоставляют набор синтаксических конструкций, для прямого указания типа переменной [6].

В связи с тем, что Flow существенно проще интегрировать в проект, чем TypeScript и то, что его разрабатывает та же компания, что и используемый при разработке фреймворк React Native, а из этого следует, что поддержка React Native у Flow лучше, чем у TypeScript, было принято использовать при разработке именного его.

Expo – это набор утилит, библиотек и сервисов, упрощающих разработку на React Native. Использование Expo при разработке мобильных приложений с React Native избавляет от решение некоторых технических вопросов, и также позволяет использовать дополнительный функционал при разработке и после создания приложения [7]:

● для компиляции JS-файлов в формат исполняемых файлов- приложений (.apk/.ipa) не будут требоваться инструменты для нативной разработки (такие как Xcode для IOS и Android Studio для Android). Компиляция JavaScript кода в исполняемые файлы будет происходить на сервере Expo. После завершения установочный файл можно будет загрузить с сервера на свой компьютер. Данное преимущество очень весомое, как минимум из-за того, что Xcode, который необходим для сборки приложений под IOS, может быть установлен только на устройствах с операционной системой MacOS;