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

В QRPURCHASE используются практически весь набор функций, анонсированных Apple на конференции WWDC 2017, где компания впервые продемонстрировала работу IOS 11. Для получения информации о покупках после считывания qr-кода требуется клиент-серверное взаимодействие, для этого приложение будет использовать соответствующее заранее разработанное API. Модель, распознающая продукты, будет заранее обучена и имплементирована в приложение, так как обучать модель на смартфоне COREML не позволяет, а так же все прочие функции будут реализованы в соответствие с гайдлайнами Apple. 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.Лидеры мнений в области финансового планирования считают*, что со временем разница в капиталах богатых и бедных людей будет только увеличиваться, а численность "среднего класса" будет стремительно уменьшаться (*Роберт Кийосаки, "Квадрант денежного потока). Для того, чтобы обрести финансовую независимость и иметь возможность помогать близким материально необходимо составить финансовый план и следовать ему, в частности контролируя свои расходы. Доступ к приложению QRPURCHASE осуществляется по Face ID - технологии сканирования лица, открывающей доступ к данным только заранее авторизованным лицам. Первая функция - занести покупки в приложения, отсканировав QRCODE, для этого нужно просто навести камеру на чек, далее данные о покупках сами появятся в приложении. Вторая функция - вывод графика расходов с помощью камеры смартфона в виде дополненной реальности с помощью технологии ARKIT, пользователь сможет увидеть график через камеру прямо перед собой на столе или любой другой ровной поверхности.В данной главе проводится анализ существующих IOS приложений для учета персональных расходов, доступных в магазине APPSTORE, а так же производится анализ функций, предоставляемых мобильным приложением QRPURCHASE и определяются функциональные требования к разрабатываемому продукту. На основе анализа функций, предоставляемых данными программами, можно понять, реализация какого функционала даст QRPURCHASE конкурентное преимущество. Для начала, проведем общий анализ предоставляемых конкурентами функций и сравним их с реализованными в приложении QRPURCHASE. Общий анализ приложений-конкурентов будет содержать в себе сравнение приложений по следующим критериям: 1) Возможность хранить покупки на сервере Возможность узнать, какие именно покупки совершал пользователь по чеку (или по банковской транзакции) есть только у Tinkoff Bank - они первыми в России внедрили эту технологию для широкой аудитории, но их приложением может пользоваться только держатель карты Tinkoff.В данной главе был проведен анализ существующих конкурентов, а так же представлены основные функциональные требования к приложению учета персональных расходов на покупки, необходимые для удобного его использования.В данной главе будет подробно разобрана каждая архитектура, в результате чего будет сделан вывод о том, предоставляет ли одна их них исчерпывающий функционал для приложения, подобного по масштабу QRPURCHASE, или оптимальнее будет разработать собственную архитектуру. Четкое разграничение ответственности между различными компонентами программы позволяет поддерживать код читаемым и гибким (быстро поддающимся изменениям), а также дает быстрое представление о полноце функционала класса разработчику. Позиционирование данной архитектуры со стороны компании Apple выглядит следующим образом: Рисунок 1. Архитектура MVC от Apple подразумевает три сущности: Модель (Model) - используется для хранения и маппинга данных во время жизненного цикла приложения Архитектура MVP по составным сущностям схожа с MVC, но некоторые из них выполняют разные роли: функции изменения View из Model в MVP находятся в Controller (и вызываются из Model), который здесь называется Presenter.Эти классы следующие: View: Класс, содержащий весь код для отображения интерфейса пользователю и для обработки их действий. Он обращается к Router для построения каркаса UI (wire-framing) приложения, к Interactor"у для маппинга данных (запросов к сети или к локальной базе данных), к вью - для обновления пользовательского интерфейса. Однако, данная архитектура в следствие своего относительно недавнего появления не пользуется большой популярностью у разработчиков, имеет достаточно высокий порог входа и требует написания большого количества кода для поддержания единого стиля паттерна. В данной архитектуре Модель используется для хранения файлов во время жизненного цикла приложения, а также для распределения данных по полям модели (в модель передается объект с данными, и она же данные из него в динамическом методе распределяет по своим полям) При этом вид имеет доступ ко всем компонентам: к контроллеру обращается для получениях данных из сети (тех, что не нужно хранить в модели), а к модели - за данными, хранящимися локально.