Размещено на http://www.allbest.ru/

Аннотация

QRPurchase - мобильное приложения для учета трат на покупки в продовольственных магазинах посредством считывания информации с qr-кодов на чеках. В QRPurchase используются практически весь набор функций, анонсированных Apple на конференции WWDC 2017, где компания впервые продемонстрировала работу iOS 11. Речь идёт о ARKit, Face ID, CoreML и QR-reader. Для получения информации о покупках после считывания qr-кода требуется клиент-серверное взаимодействие, для этого приложение будет использовать соответствующее заранее разработанное API. Модель, распознающая продукты, будет заранее обучена и имплементирована в приложение, так как обучать модель на смартфоне CoreML не позволяет, а так же все прочие функции будут реализованы в соответствие с гайдлайнами Apple.

Ключевые слова -- ARKit, CoreML, Face iD, QRcode, клиент-сервер, iOS разработка



Abstract

QRPurchase, a mobile application for reflecting spendings in grocery stores by reading information from qr-codes on checks. QRPurchase uses almost the entire set of features announced by Apple at the WWDC 2017 conference, where the company demonstrated the work of iOS 11 for the first time. These are ARKit, Face ID, CoreML and QR-reader. To obtain information about purchases after reading the qr-code, client-server interaction is required, for this purpose the application will use the corresponding pre-developed API. The model that recognises purchased products will be pre-trained and implemented in the application, since it is not possible to teach the model on the CoreML smartphone, and all other functions will be implemented in accordance with Apple's guidelines

Keywords -- ARKit, CoreML, Face iD, QRcode, client-server, iOS-development



Введение

Тема финансового учета и планирования актуальна во все времена, но в последнее время она приобретает все большую популярность. Лидеры мнений в области финансового планирования считают*, что со временем разница в капиталах богатых и бедных людей будет только увеличиваться, а численность "среднего класса" будет стремительно уменьшаться (*Роберт Кийосаки, "Квадрант денежного потока). Для того, чтобы обрести финансовую независимость и иметь возможность помогать близким материально необходимо составить финансовый план и следовать ему, в частности контролируя свои расходы. Опыт большинства российских семей показывает, что основной статьей расходов чаще всего становится продовольствие. Продовольственные продукты - очень широкий рынок для анализа, в нем практически любой продукт можно заменить более дешевым аналогом без потери качества. Существует множество различных сервисов для учета расходов, как привязанных к банковскому счету, так и независимых, но никакой из них пока не позволяет проанализировать траты на конкретные продовольственные наименования, например "шоколад" или "кофе". С этой задачей справляется QRPurchase, считывающий все совершенные в магазине покупки по qr-коду на чеке и хранящий их у себя на сервере.

Доступ к приложению QRPurchase осуществляется по Face ID - технологии сканирования лица, открывающей доступ к данным только заранее авторизованным лицам. Далее пользователю доступны 3 функции, каждой из которых соответствует один пункт меню. Первая функция - занести покупки в приложения, отсканировав QR-code, для этого нужно просто навести камеру на чек, далее данные о покупках сами появятся в приложении. Вторая функция - вывод графика расходов с помощью камеры смартфона в виде дополненной реальности с помощью технологии ARKit, пользователь сможет увидеть график через камеру прямо перед собой на столе или любой другой ровной поверхности. Третья функция - умное распознавание продуктов с помощью технологии CoreML; наведя камеру на любой продукт в магазине пользователь сможет узнать рекомендованную/минимальную цену на этот тип товара. Эта функция использует обученную заранее математическую модель нейросети, натренированную на большом объеме открытых данных определять различные продукты, затем отправляет результат сканирования на сервер и запрашивает для него рекомендованную цену.

Целью данной ВКР является как создание приложения, так и выявление наиболее оптимальных фреймворков, шаблонов проектирования, инструментов и подходов к разработке для проектов подобного масштаба.

В ходе создания конечного продукта потребуется решить следующие задачи:

1) Изучить существующие и разрабатываемые мобильные приложения и веб-сервисы для учета персональных расходов

2) Разработать требования к мобильному приложению, которое сделают опыт пользователя QRPurchase максимально комфортным

3) Разработать архитектуру iOS приложения QRPurchase

4) Разработать интерфейс iOS приложения QRPurchase

5) Реализовать iOS приложение QRPurchase на языках Swift и Objective-c



Глава 1. Мобильный функционал приложения для учета персональных расходов

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

1.1 Общий сравнительный анализ приложений для учета персональных расходов

Анализируемые приложения - топ 5 сервисов для учета персональных расходов по версии авторитетного в России издания Lifehacker. Это CoinKeeper, RocketBank, Tinkoff bank, Деньги ОК, HomeMoney. Эти приложения являются популярными среди пользователей платформы iOS. На основе анализа функций, предоставляемых данными программами, можно понять, реализация какого функционала даст QRPurchase конкурентное преимущество. Для начала, проведем общий анализ предоставляемых конкурентами функций и сравним их с реализованными в приложении QRPurchase.

Общий анализ приложений-конкурентов будет содержать в себе сравнение приложений по следующим критериям:

1) Возможность хранить покупки на сервере

2) Возможность просматривать детально покупки по чеку

3) Авторизация по Face ID/ Touch ID

4) Возможность вывести аналитику трат

5) Определение товаров с помощью ИИ

6) Авторизация через социальную сеть

7) Сканирование QR-кода на чеке.

Данные сравнения приведены в таблице 1, представленной ниже.

Таблица 1. Сравнительный анализ конкурентов

Rocket	CoinKeeper	Д О	Tinkoff Bank	HomeMoney	QRPurchase
Хранение покупок на сервере	+	-	+	+	-	+
Детализация чека	-	-	-	+	-	+
Авторизация по FaceId	+	-	+	+	+	+
Авторизация через соц.сеть	-	-	-	-	+	+
Сканирование с помощью ИИ	-	-	-	-	-	+
Сканирование QR	-	+	+	-	+	+
Аналитика	+	+	+	+	+	+

мобильный приложение персональный чек

Как видно на таблице 1, сканирование продуктов с помощью искусственного интеллекта является функцией, реализованной только в QRPurchase. Также авторизация в один клик через социальную сеть кроме QRPurchase реализована лишь в HomeMoney. Возможность узнать, какие именно покупки совершал пользователь по чеку (или по банковской транзакции) есть только у Tinkoff Bank - они первыми в России внедрили эту технологию для широкой аудитории, но их приложением может пользоваться только держатель карты Tinkoff.

Можно заметить, что аналитика есть во всех приложениях для учета расходов, но ни одно из них не использует анонсированный в 2017 году набор инструментов ARKit для отображения графиков в качестве дополненной реальности для увеличения визуального эффекта - это делает только QRPurchase.

1.2 Функции, предлагаемые QRPurchase

1.2.1Авторизация в приложении

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

В приложении QRPurchase возможна авторизация с помощью аккаунта в Facebook, через Face iD, а также анонимная авторизация.

1.2.2 Отображение контента

Список покупок в приложении QRPurchase отображается на главном экране привычным для пользователя iOS способом - в виде пролистываемого списка, именуемого таблицей. Одна ячейка представляет собой один проанализированный ранее чек. Ячейки кликабельны, каждая из них по нажатию демонстрирует экран с детализацией соответствующей покупки, адресом ее совершения и всеми данными, содержащимися в чеке.

1.2.3 Сканирование нового чека

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

1.2.4 Сканирование продуктов

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

1.2.5 Вывод аналитики

QRPurchase поддерживает вывод 3D графика трат в виде дополненной реальности. Пользователю нужно выбрать в меню на главном экране “Вывести аналитику” и через камеру смартфона разместить объемный график на любой ровной поверхности перед собой. После чего график закрепится на поверхности относительно пользователя и последний сможет рассмотреть его со всех сторон.

1.2.6 Удаление контента

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

Выводы по главе

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



Глава 2. Проектирование архитектуры приложения для персонального учета расходов на покупки

2.1 Архитектурные подходы

В iOS разработке на данный момент являются популярными 4 архитектурных подхода: MVC (Model View Controller), MVP (Model View Presenter), MVVM (Model View ViewModel) и VIPER (View Interactor Presentation Entity Router). В данной главе будет подробно разобрана каждая архитектура, в результате чего будет сделан вывод о том, предоставляет ли одна их них исчерпывающий функционал для приложения, подобного по масштабу QRPurchase, или оптимальнее будет разработать собственную архитектуру.

2.1.1 Критерии качественной архитектуры приложения

Выделяюся 3 основных критерия оценки качества архитектуры проекта:

Распределение ответственности. Четкое разграничение ответственности между различными компонентами программы позволяет поддерживать код читаемым и гибким (быстро поддающимся изменениям), а также дает быстрое представление о полноце функционала класса разработчику. Качественное распределение зависимостей является прямым следствием соблюдения принципа разработки SOLID - принципа одиночной ответственности (Single Responsibility Principle).

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

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

Выбор наиболее подходящей архитектуры для реализации приложения QRPurchase будет производиться по представленным выше критериям.

2.1.2 Model View Controller

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

Рисунок 1. MVC by Apple

Архитектура MVC от Apple подразумевает три сущности:

Модель (Model) - используется для хранения и маппинга данных во время жизненного цикла приложения

Представление (View) - содержит пользовательский интерфейс

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

Однако на практике на языках, разработанных корпорацией Apple, предоставляется возможным реализовать архитектуру только отдаленно напоминающую задуманную компанией. Ее принцип работы описан на схеме:

Рисунок 2. Apple MVC

Говоря о минусах данной архитектуры, можно заметить, что Отображение и Контроллер в ней тесно связаны, что не является хорошим тоном при имплементировании архитектуры MVC. Тесная связь на практике подразумевает, что Контроллер и Вид, по сути, отвечают за одно и то же, а это противоречит критерию распределения ответственности и осложняет покрытие проекта тестами. Также данный подход не предъявляет никаких требований к размеру классов и интерфейсов, в связи с чем разработчики сталкиваются с проблемой, именуемой в коммьюнити Massive View Controller - слишком большими классами, которые сложно поддерживать.

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

2.1.3 Model View Presenter

Архитектура MVP по составным сущностям схожа с MVC, но некоторые из них выполняют разные роли: функции изменения View из Model в MVP находятся в Controller (и вызываются из Model), который здесь называется Presenter. Схема, абстрактно описывающая данную архитектуру выглядит следующим образом:

Рисунок 3. MVP

Отличия данной архитектуры от MVC наглядно отображено на следующей иллюстрации:

Рисунок 3. MVP & MVC difference

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

Таким образом, мы видим, что использование данного подхода позволяет избежать сложности сепарирования и покрытия тестами, как в MVC, но по-прежнему не решает проблему Massive View Controller'а.

2.1.4 Model View ViewModel

В последнее время в сообществе разработчиков ведется много разговоров об использовании MVVM архитектуры в iOS-приложениях в целом и о том, как она помогает избежать Massive View Controllers в частности.

MVVM - это не изобретение одного из iOS-программистов, эта архитектура использовалась несколько лет в сообществе .NET разработчиков. Уже несколько лет она успешно используется в крупномасштабных WPF (Windows Presentation Foundation) приложениях.

Следует отметить, что сравнивать .NET WPF framework и iOS framework не полностью корректно, так как WPF использует XAML и, как следствие, подход под названием "Dependency Properties", который позволяет верстать UI на подобие веб-приложений без жесткой привязки к классам. В iOS мы не имеем ничего похожего на Dependency Properties, чтобы программировать UI как в XAML.

Основная идея паттерная проектирования MVVM в том, что каждое View на экране определяется View Model'ом, который представляет данные для этого view. Это значит, что если мы разрабатываем приложение-новостной обозреватель, то view может содержать UITableView, которое позволяет отображать элементы, а соответствующая view model будет содержать данные, отображаемые в новости, такие как заголовок, описание, автор, источник и так далее.

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

Рисунок 4. MVVM

2.1.5 VIPER

Viper (View Interactor Presenter Entity Router) - шаблон проектирования, имплементирующуй парадигму "разделение ответственности" (separation of concern). За одну функцию отвечает один модуль. Для каждого модуля VIPER имеет пять (иногда четыре) разных класса с конкретными ролями. Эти классы следующие:

View: Класс, содержащий весь код для отображения интерфейса пользователю и для обработки их действий. При обработке действий View обращается к Presenter'у.

Presenter: Это мозг модуля. Он обрабатывает ответ пользователя из View и работает обособленно. Это единственный класс, который может коммуницировать с другими компонентами. Он обращается к Router для построения каркаса UI (wire-framing) приложения, к Interactor'у для маппинга данных (запросов к сети или к локальной базе данных), к вью - для обновления пользовательского интерфейса.

Interactor: Содержит бизнес логику приложения. Первым делает вызовы API для маппинга (обработки) данных из источника. Отвечает за обращение к данным, но не обязательно от себя (через вызов self).

Router: Отвечает за wire-framing - построение каркаса пользовательского интерфейса. Подписан на уведомления от Presenter'а на каждом экране для их отображения и исполнения.

Entity: Содержит самописную модель данных, используемую interactor'ом.

Диаграмма компонентов VIPER выглядит следующим образом:

Рисунок 5. VIPER diagramm

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

2.1.6 Выбор архитектурного решения

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

Наиболее четкое разделение ответственности среди программных компонентов предоставляет VIPER, но его поддержка не целесообразна в небольшом проекте с точки зрения временных затрат. С проблемой Massive View Controller довольно успешно справляется архитектура MVVM, однако для ее имплементации и поддержки разработчикам потребуются специальные знания и ряд договоренностей.

Таким образом, было принято решение разработать свою архитектуру, взяв из анализируемых некоторые правила. Схема архитектуры, которая была использована при написании QRPurchase выглядит следующим образом:

Рисунок 6. My own architecture diagramm

Можно заметить, что внешне архитектура напоминает MVP. В ней также используются 3 сущности, но нет таких строгих ограничений по функциональности каждой их них.

В данной архитектуре Модель используется для хранения файлов во время жизненного цикла приложения, а также для распределения данных по полям модели (в модель передается объект с данными, и она же данные из него в динамическом методе распределяет по своим полям)

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

Контроллер отвечает за работу приложения с сетью и за любые обращения к API. Передает данные в модель.

2.2 Тестирование приложения

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

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

Эмпирически было определено, что использование сторонних фреймворков для написания тестов нецелесообразно по времени для проектов масштаба QRPurchase, поэтому использовался встроенный в XCode инструмент для тестирования - XCTest.

2.3 Хранение данных

Одним из наиболее распространенных встроенных хранилищ данных в XCode является CoreData, однако для обеспечения высокопроизводительного многопоточного общения приложения с этой базой требуются специальные навыки, а риск ошибки при получении данных при это возрастает. Так как QRPurchase не содержит личных или секретных данных пользователя, то использование Core Data избыточно. Было принято решение использовать локальное хранилище NSUserDefaults, располагающееся в памяти смартфона в папке с приложением.

Так выглядит схема данных, спроецированная на используемую архитектуру:

Рисунок 6. Модель локально хранящихся данных

2.4 Работа с сетью

В данном разделе описывается взаимодействие приложения QRPurchase с сетью и свод используемых при этом правил.

2.5 Работа с API

Работа с сетью в iOS приложении содержит несколько правил, которых придерживается QRPurchase:

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

- Все url-адреса в приложении должны быть вынесены в константы

- В user-agent для контроля версий приложения и API должна передаваться версия первого

Для получения информации о каждой покупки в чеке посредством отправки QR-кода QRPurchase использует открытое API частного сервиса brand.cash. Данный запрос выглядит следующим образом: "http://brand.cash/v1/receipts/get?", в который передается GET параметром конвертированный в NSString* отсканированный QR. В ответ приходит json с информацией по каждой покупке, для распределения данных из ответа по свойствам модели используется самописный json парсер.

Для валидации отсканированного QR-кода используется API POST метод открытого сервера "http://brand.cash/v1/receipts/check?"

Для получения истории покупок конкретного пользователя используется GET метод https://qrtests.herokuapp.com/api/gethistory.

Для авторизации в приложении используется метод получения уникального access_token'а используется метод Facebook API "https://graph.facebook.com/me?access_token=".

2.6 Процессы разработки мобильного приложения QRPurchase

Так как в разработке приложения QRPurchase принимал участие один человек, для консолидации процесса была выбрана методология Waterfall Model (Водопад), которая подразумевает последовательное выполнение задач с их последующим тестированием и отладкой и выкладкой в магазин приложений как итог. Данный подход описывает следующая схема:



Рисунок 7. Waterfall Model

Выводы по главе

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



Глава 3. Разработка приложения QRPurchase

Данная глава содержит описание и особенности разработки каждого компонента приложения QRPurchase. А именно, будет рассмотрена реализация аналитики с помощью ARKit, считывания QR-кода с помощью QRReader, авторизация с помощью FaceID и отображение рекомендованных цен на товары с помощью модели CoreML.

3.1 Авторизация через FaceID

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



Рисунок 8. FaceID workflow

Во время распознавания лица пользователю на UIVIewController накладывается привычная пользователю iOS анимированная UIView, изображенная на рисунке 9



Рисунок 9. FaceID animation

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

- (IBAction)enterByFaceId:(id)sender {

NSError *defaultError;

BOOL couldAuthentication = [self.context canEvaluatePolicy:LAPolicyDeviceOwnerAuthentication error:&defaultError];

if (couldAuthentication) {

[self.context evaluatePolicy:LAPolicyDeviceOwnerAuthentication localizedReason:@"FaceID" reply:^(BOOL success, NSError * _Nullable error) {

if (success) {

UIAlertController *alertVC = [UIAlertController alertControllerWithTitle:@"Authorization success" message:nil preferredStyle:UIAlertControllerStyleAlert];

[alertVC addAction:[UIAlertAction actionWithTitle:@"Ок" style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {

}]];

[self presentViewController:alertVC animated:YES completion:nil];

} else {

NSLog(@"%@",error);

}

}];

}

}

3.2 Авторизация через Facebook

На экране авторизации находится кнопка "Войти через Facebook", которая позволяет авторизоваться в приложении QRPurchase, используя данные из представленной социальной сети. Авторизация производится по системе oAuth 2.0, запрос в общем виде реализуют 2 метода:

- (void)viewDidLoad {

[super viewDidLoad];

// FACEBOOK

_facebookLoginButton.readPermissions =

@[@"public_profile", @"email", @"user_friends"];

if ([FBSDKAccessToken currentAccessToken]) {

// User is logged in

[Network getFacebookIDwithAccessToken:[[FBSDKAccessToken currentAccessToken] tokenString] completion:^(NSString *facebookID) {

Network.userToken = [@"fb_" stringByAppendingString:facebookID];

_facebookLoginButton.delegate = self;

}];

}

}

- (void)loginButton:(FBSDKLoginButton *)loginButton didCompleteWithResult:(FBSDKLoginManagerLoginResult *)result error:(NSError *)error {

[Network getFacebookIDwithAccessToken:[[FBSDKAccessToken currentAccessToken] tokenString] completion:^(NSString *facebookID) {

Network.userToken = [@"fb_" stringByAppendingString:facebookID]; UINavigationController *viewController = [[self storyboard]instantiateViewControllerWithIdentifier:@"NavigationController"];

[self presentViewController:viewController animated:true completion:nil];

}];

}

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

3.3 Авторизация анонимных пользователей

В приложении QRPurchase доступна авторизация для анонимных пользователей. Выбирая эту функцию (кнопка "Пропустить" на экране авторизации), пользователь попадает на экран истории покупок без привязки уникального токена, соответственно без возможности сохранять свои покупки в облаке. Но локально приложение будет хранить его данные до выхода из своей учетной записи или до входа в новую.

3.4 Аналитика расходов с помощью ARKit

Аналитика расходов в приложении QRPurchase представлена выводящейся на экран 3D диаграммой во время работы камеры смартфона. Таким образом, приложение создает визуальный эффект расположения диаграммы на плоской поверхности перед пользователем, также предоставляя возможность взаимодействовать с графиком - возможно рассматривать его через камеру как любой другой материальный объект. Такой эффект достигается посредством применения технологии ARKit, общая схема ее работы изображена на схеме:

Рисунок 10. ARKit classes diagram

В приложении экран с представленной диаграммой выглядит следующим образом:

Рисунок 11. ARKit analytics

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

3.5 Аналитика действий пользователи

Для анализа поведения пользователя внутри приложения на каждом экране размещены трекеры, отправляющие информацию о действиях пользователя на соответствующий сервер. Для получения более точной статистики используются следующие сервисы: Google Analytics, App Metrika, Fabric.

Данные сервисы среди множества других отобраны опытным путем, как наиболее легко встраиваемые и надежные.

3.6 Распознавание продуктов

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

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

Процесс реализации данной функции выглядит следующим образом:

1. Написать/найти и обучить модель Caffe, XGBoost (на требуемом объеме данных) или в любом другом удобном формате.

2. С помощью python скрипта скновертировать модель в формат .mlmodel

3. Импортировать модель в XCode проект приложения и использовать ее в коде.



Рисунок 12. CoreML converting

В нижней части UIVIewController расположена UITableView, в которой первые пять UITableViewCells отображают 5 наиболее вероятных названий продукта на экране.

3.7 Валидация и распознавание QR-кодов

Основной функцией приложения QRPurchase является сканирование, валидация QR-кодов и добавление информации о каждом товаре в покупке в приложение.

Схема работы данного экрана следующая:

1. Пользователь QRPurchase нажимает на главном экране кнопку "сканировать QR-код", после чего открывается камера.

2. При попадании QR-кода в область видимости камеры, приложение с помощью фреймворка AVCaptureSession конвертирует изображение кода в формат данных AVMetadataMachineReadableCodeObject*, который можно привести к строке.

3. Эта строка отправляется POST запросом на API открытого сервиса brand.cash для проверки валидности данного кода.

4. В случае получения статуса 200 (success status) от сервера, на сервер brand.cash отправляется GET запрос со строкой, полученной в результате конвертирования QR-кода, для получения детального списка покупок в формате json.

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

Данную схему в программе реализуют следующие методы:

- (void)viewDidLoad {

[super viewDidLoad];

// Initializing camera

self.view.backgroundColor = [UIColor blackColor];

_captureSession = [[AVCaptureSession alloc] init];

self.navigationController.navigationBar.barTintColor = [UIColor colorWithRed:140/255. green:255./255. blue:160./255. alpha:0];

[self.navigationController.navigationBar

setTitleTextAttributes:@{NSForegroundColorAttributeName : [UIColor whiteColor]}];

NSError* inputError = nil;

AVCaptureDevice* videoCaptureDevice = [AVCaptureDevice defaultDeviceWithMediaType: AVMediaTypeVideo];

AVCaptureDeviceInput* videoInput = [AVCaptureDeviceInput deviceInputWithDevice:videoCaptureDevice error: &inputError];

if (inputError != nil)

//TODO: Error handling

return;

if ([_captureSession canAddInput:videoInput])

[_captureSession addInput:videoInput];

else {

[self cameraOpeningFail];

return;

}

AVCaptureMetadataOutput* metadataOutput = [[AVCaptureMetadataOutput alloc] init];

if ([_captureSession canAddOutput:metadataOutput]) {

[_captureSession addOutput:metadataOutput];

[metadataOutput setMetadataObjectsDelegate:self queue: dispatch_get_main_queue()];

metadataOutput.metadataObjectTypes = [NSArray arrayWithObject:AVMetadataObjectTypeQRCode];

} else {

[self cameraOpeningFail];

return;

}

_previewLayer = [AVCaptureVideoPreviewLayer layerWithSession:_captureSession];

_previewLayer.frame = self.view.layer.bounds;

_previewLayer.videoGravity = AVLayerVideoGravityResizeAspectFill;

[self.view.layer addSublayer:_previewLayer];

[_captureSession startRunning];

// Initializing indicator view

_activityIndicator = [[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleWhiteLarge];

[_activityIndicator setCenter:self.view.center];

[self.view addSubview:_activityIndicator];

}

-(void) cameraOpeningFail {

UIAlertController* ac = [UIAlertController alertControllerWithTitle:@"Scanning not supported" message:@"You device does not support scanning a code from an item" preferredStyle:UIAlertControllerStyleAlert];

[ac addAction:[UIAlertAction actionWithTitle:@"OK" style: UIAlertActionStyleDefault handler:^(UIAlertAction * action)

{

NSLog(@"OK pressed.");

}]];

[self presentViewController:ac animated:YES completion:nil];

_captureSession = nil;

}

- (void)didReceiveMemoryWarning {

[super didReceiveMemoryWarning];

// Dispose of any resources that can be recreated.

}

-(void)captureOutput:(AVCaptureOutput *)captureOutput didOutputMetadataObjects:(NSArray *)metadataObjects fromConnection:(AVCaptureConnection *)connection {

[_captureSession stopRunning];

if (metadataObjects.firstObject != nil){

AVMetadataMachineReadableCodeObject* readableObject = (AVMetadataMachineReadableCodeObject*)metadataObjects.firstObject;

AudioServicesPlaySystemSound(kSystemSoundID_Vibrate);

_qrString = readableObject.stringValue;

}

_receipt = [[Receipt alloc] initWithQRString:_qrString];

[_activityIndicator startAnimating];

[Network checkAuthenticity:_receipt completion:^(BOOL success, NSString *error) {

[_activityIndicator stopAnimating];

if (success && !error) {

[self showSuccessAlertViewController];

} else {

[self showFailureAlertViewController];

}

}];

}

-(BOOL) prefersStatusBarHidden {

return true;

}

-(UIInterfaceOrientationMask) supportedInterfaceOrientations {

return UIInterfaceOrientationMaskPortrait;

}

- (void)showSuccessAlertViewController {

UIAlertController *ac = [UIAlertController alertControllerWithTitle:@"Успех" message: @"QR код в порядке!" preferredStyle:UIAlertControllerStyleAlert];

UIAlertAction* add = [UIAlertAction actionWithTitle:@"Добавить" style:UIAlertActionStyleDefault

handler:^(UIAlertAction * action)

{

// Present another VC with new receipt

[_activityIndicator startAnimating];

[Network fillReceipt:_receipt completion:^(NSError *error, Receipt *filledReceipt) {

if (!error) {

[_activityIndicator stopAnimating]

; [_delegate qrScannerViewController:self didEndReadingReceipt:filledReceipt];

[self.navigationController popViewControllerAnimated:YES];

}

else;

//TODO: вывод ошибки получения данных

}];

}];

UIAlertAction* cancel = [UIAlertAction actionWithTitle:@"Отмена" style:UIAlertActionStyleDefault

handler:^(UIAlertAction * action) {

[ac dismissViewControllerAnimated:true completion:nil];

[_captureSession startRunning];

}];

[ac addAction:add];

[ac addAction:cancel];

[self presentViewController:ac animated:true completion:nil];

}

- (void)showFailureAlertViewController {

UIAlertController *ac = [UIAlertController alertControllerWithTitle:@"Неудача" message: @"Не удалось проверить валидность QR кода." preferredStyle:UIAlertControllerStyleAlert]

UIAlertAction* ok = [UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleDefault

handler:^(UIAlertAction * action) {

[ac dismissViewControllerAnimated:true completion:nil];

[_captureSession startRunning];

}];

[ac addAction:ok];

[self presentViewController:ac animated:true completion:nil];

}

1. 

3.8 Главный экран приложения

Рисунок 13. Main screen

Главный экран приложения представляет собой экран, реализующий класс-наследник UINavigationController, в который встроена UITableView, где каждая строчка - это кликабельная UITableViewCell, содержащая всю информацию о купленном товаре.

Меню, активное на рисунке 13 - это UIActionSheet, вызванное нажатием на кнопку "+" типа UINavigationRightBarButtonItem.



Выводы по главе

В заключительной главе были описаны особенности реализации всех основных составных частей мобильного приложения для учета персональных расходов на покупки для платформы Apple iOS, а именно: работа с фреймворком ARKit при выводе 3D аналитики, авторизация через социальные сети и биометрические данные (FaceID или TouchID), сканирование QR-кодов и использование модели с помощью фреймворка машинного обучения внутри приложения. Также была приведена программная реализация некоторых компонентов и представлены наглядные схемы работы всех компонентов.



Заключение

В ходе исследования было выявлено, что наиболее оптимальным фреймворком для работы с сетью в инди-проекте является AFNetworking, паттерном - собственная архитектура, напоминающая смесь MVC и MVVM, контролем версий - Git, а подходом к разработке - TDD.

В финальной стадии, отвечая всем приемочным тестам, приложение является лишь прототипом реальной персональной бухгалтерии, которая может находиться в мобильном телефоне. Оно выполняет базовый пользовательский функционал по подсчету расходов на покупки: хранит названия магазинов и товаров, цены за продукты и даты совершения покупок; показывает через камеру смартфона аналитические графики, а так же определяет наименование и рекомендуемую цену некоторых товаров по их изображениям. Тем не менее, эта работа не является исчерпывающим все пользовательские потребности продуктом, а задает вектор развития подобных приложений, демонстрируя возможности и области применения новейших технологий. В приложении может работать более обученная модель, аналитика в виде графиков может быть более детальной, а так же данные пользователя могут синхронизироваться с другими устройствами. Эти вещи можно легко реализовать, пользуясь данной пояснительной запиской и документацией, не используя новых технологий, а лишь надстраивая известные решения над существующим функционалом. Исходный код приложения QRPurchase доступен по адресу: www.github.com/ar7style/qrpurchase.

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

Для достижения цели были решены следующие задачи:

Были проанализированы мобильные приложения, учитывающие персональные расходы на покупки

Была полностью разработана документация к iOS приложению учета персональных расходов на покупки

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

Был спроектирован и разработан пользовательский интерфейс приложения QRPurchase

Реализовано мобильное приложение QRPurchase для платформы Apple iOS



Список использованных источников

1) iOS developer's blog [Электронный ресурс] / Apple. Режим доступа: https://www.appcoda.com/ios-programming-course/, свободный. (дата обращения: 22.04.2018).

2) Swift 4.0 documentation [Электронный ресурс] / Apple. Режим доступа: https://swift.org/blog/swift-4-0- released, свободный. (дата обращения: 11.04.2018)

3) Objective-c documentation [Электронный ресурс] / Twitter Inc. Режим доступа: https://objective-c.org/, свободный. (дата обращения: 21.04.2018)

4) AppMetrica tutorial [Электронный ресурс] / Yandex. Режим доступа: https://tech.yandex.ru/ appmetrica/, свободный. (дата обращения: 21.04.2018)

5) Remote frameworks hosting documentation [Электронный ресурс] / Cocoapods. Режим доступа: https://cocoapods.org/, свободный. (дата обращения: 21.04.2018)

6) iOS developer's blog [Электронный ресурс] / Medium. Режим доступа: https://medium.com/ios-tips, свободный. (дата обращения: 15.04.2018)

7) Fabric documentation [Электронный ресурс] / Firebase. Режим доступа: https://

get.fabric.com/docs/, свободный. (дата обращения: 20.05.2018)

8) AFNetworking documentation [Электронный ресурс] / AFNetworking. Режим доступа: https://github.com/AFNetworking/AFNetworking, свободный. (дата обращения: 18.05.2018)

9) SwiftyJSON [Электронный ресурс] / GitHub. Режим доступа: https://github.com/ SwiftyJSON/, свободный. (дата обращения: 24.05.2018)

10) Facebook developers [Электронный ресурс] / VK. Режим доступа: https://developer.facebook.com/ios_sdk, свободный. (дата обращения: 17.04.2018)

11) Future of the economics [Электронный ресурс] / Litres. Режим доступа: https:// litres.ru/future-of-the-economics/, свободный. (дата обращения: 19.05.2018)

12) iOS Architecture Patterns [Электронный ресурс] / Medium. Режим доступа: https:// medium.com/ios-development/ios-architecture-patterns, свободный. (дата обращения: 22.05.2018)

Размещено на Allbest.ru

...