Разработка мобильного приложения для поиска вакансий

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

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

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет бизнеса и менеджмента

Разработка мобильного приложения для поиска вакансий

Выпускная квалификационная работа

по направлению подготовки 38.03.05 Бизнес-информатика

образовательная программа «Бизнес-информатика»

Банщиков Артур Андреевич

Москва2019



ВВЕДЕНИЕ

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

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

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

стремительное развитие современных технологий, и, как следствие, рост популярности рынка мобильных приложений. По данным аналитической компании AppAnnie[1]только за 2018 год рост рынка мобильных приложений составил 20% по отношению к предыдущему году, достигнув отметку в 76 миллиардов долларов.

рост заинтересованности в поиске работы через онлайн - сервисы. Так, например, в Российской Федерации 76% людей ищут работу через различные онлайн - сервисы [2]. А ведь не так давно поиск работы представлялся возможным в основном только через всевозможные печатные издания, общественные доски объявлений, и личные контакты.

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

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

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

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

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

Разработать требования к мобильному приложению.

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

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

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

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



ГЛАВА 1. ОНЛАЙН - СЕРВИСЫ ПОИСКА ВАКАНСИЙ

1.1 Мобильные приложения

Рынок мобильных приложений растет колоссальными темпами с каждым днем, и его запас роста на сегодняшний день кажется практически безграничным. Количество приложения только для операционной системы iOSпревышает отметку в 2.1 миллиона [3].А в 2018 году мобильными телефонами пользуется более пяти миллиардов человек [4], что составляется около 68% от общего населения людей.

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

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

1.2Онлайн - сервисы поиска вакансий

Поиска вакансий онлайн - одна из сфер, подвергшихся наиболее сильному влиянию развития интернета.На сегодняшний день в мире более 55% [2] людей находят работу с помощью услуг онлайн - сервисов. Одним из самых главных преимуществ поиска работы через интернет является возможность обработки намного большего количества заявок, по сравнению с ранее популярными каналами поиска работы, такими как различные печатные издания или знакомства через семью и друзей.

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

1.2.1 HeadHunter

Компания HeadHunterна сегодняшний день является лидером на российском рынке интернет - рекрутмента. На сайте доступно свыше 40 миллионов резюме и 500 тысяч[6] предложений от более миллиона зарегистрированных работодателей. Для удобного взаимодействия пользователей с сервисомкомпания разработала как веб - приложение, так и мобильные приложения для операционной системы iOSи Android.

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

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

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

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

1.2.2SuperJob

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

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

Информация и функционал, предоставляемые компанией, обширнее, чем у многих конкурентов. Сервис SuperJobпредоставляет большой перечень полезной и наиболее актуальной информации[7] в области рынка труда: обзор заработных плат, рейтинги высших учебных заведений, аналитика рынка труда, помощь в составлении резюме, бесплатное тестирование и многое другое.

Компания SuperJobявляется явным лидерам со стороны технологичности разработанных приложений.

1.2.3Avito

Компания Avito предоставляет сервис не только для размещения или поиска вакансий, но также и для размещения объявлений о любых товарах: от машин до домашних животных.

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

С другой стороны, мобильное приложение компании удобно в использовании, а также дополнено приятным дизайном и технологией 3D-Touch [8 - 9]. Данная технологий, доступная пользователем iOS - устройств, чувствует, насколько сильно пользователь нажимает на дисплей, и в зависимости от силы нажатия дополняет интерфейс новыми элементами. Так, к примеру, при достаточно сильном нажатии на иконку приложения, появляются дополнительные кнопки, с помощью которых можно сразу же перейти в раздел сообщений или разместить новое объявление.

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

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

1.2.3Яндекс Работа

Сервис Яндекс Работа, являясь так же сервисом, объединяющим популярные интернет - ресурсы для поиска работы онлайн,будет в целом единственным конкурентом для разрабатываемого в рамках данной работы приложения. Явными плюсами сервиса Яндекс Работа над разрабатываемым сервисом является наличие самой обширной базы вакансий в Российской Федерации и странах Содружества Независимых Государств, наличие веб - приложения, а также мобильного приложения для операционной системы Android.

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

Ограничение поиска по местоположению. Поиск вакансий через сервис Яндекс Работа на данный момент возможен только по Москве и Московской области.

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

Отсутствие всех популярных сервисов вакансий. Сервис Яндекс Работа даже с учетом наличия огромной базы вакансий, не производит поиск, к примеру, по популярному сервису Avito, который был ранее описан в этой главе.

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



ГЛАВА 2. ТРЕБОВАНИЯ И АРХИТЕКТУРА ПРИЛОЖЕНИЯ

2.1 Разработка требований к приложению

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

Разработка функциональных требований.

Разработка требований к дизайну.

Описание use - case.

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

Возможность поиска вакансий по ключевым словам

Возможность поиска вакансий без требуемого опыта работы

Возможность поиска вакансий с желаемой заработной платой

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

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

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

Правильно выбранная цветовая гамма не только способна привлечь внимание пользователей, но и улучшить узнаваемость продукта. Влияние цветов на конечный выбор покупателя неоднократно было доказано с помощью проведения многочисленных исследований и экспериментов. Интересное исследование под названием «Impactofcolorinmarketing» [11] показало, что цвета также ассоциируются с конкретным параметром товара. В результате проводимого исследования для разрабатываемого приложения в качестве основных цветов были выбраны черный и серый. Подобный выбор обусловлен влиянием этой пары цветов на параметры покупаемого продукта. Черный и серые цвета по данным исследования являются лидерами в ассоциации с высоким качеством, технологичностью и надежностью[12].

Определившись с выбором цветовой гаммы, можно переходить кразработке требований для UI/UXдизайна. Хороший мобильный UI/UXдизайн должен в первую очередь быть всегда ориентированным на конечного пользователя. Он должен предоставлять пользователю максимально удобный и визуально приятный интерфейс для быстрого решения основных задач. Следующей важной проблемой, которую должен решать разрабатываемый пользовательский интерфейс является простота использования. Пользователь должен четко и интуитивно понимать, как пользоваться вашим приложением, в противном случае он может закрыть и удалить его, даже не попробовав воспользоваться предлагаемыми услугами. С учетом определения первоначальных обязательных требований, предъявляемых к разрабатываемому дизайну, были сформированы следующие дополнительные требования[13 - 14]:

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

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

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

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

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

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

Возможность использования основного функционала приложения лишь с помощью большого пальца. Дизайнер Стивен Хубер в результате своего исследования[15]определил, что более 49 процентов людей используют большой палец при взаимодействии со своим мобильным телефоном. Рисунок ниже показывает три области экрана, которые может достичь большой палец пользователя. Зеленая область определяет примерную зону экрана смартфона, до которой пользователю комфортно достать большим пальце, желтая область - предполагает затрату усилий для достижения, а достижение красной области требует от пользователя изменения способа держания своего мобильного телефона. Для обеспечения максимальной удобности пользования разрабатываемым мобильным приложением, основные элементы приложения стоит разместить в границах зеленой области.

Рисунок 1. Ориентировочная схема охвата мобильного устройства

Мобильный UX-дизайн: основные принципы [Электронный ресурс] / Medium. -URL: https://medium.com/@grifer163/мобильный-ux-дизайн-основные-принципы-6f50ea47e55f

Завершающим этапом разработки требований к мобильному приложению будет написание основных use-case'овили проще говоря - сценариев использования [16]. В рамках разработки мобильных приложений технику use - caseприменяют для описания взаимодействия приложения и пользователя, которое в дальнейшем поможет при непосредственной разработке и тестировании программы. Данная техника состоит из базовой части, описывающей участников взаимодействия, триггера -события, являющегося инициализатором сценария, и конечного результата [17]. Основной поток событий в свою очередь является перечислением событий сценария [18].

Таблица 1. Участники взаимодействия описываемого use - case'а.

Система	Мобильное приложения поиска вакансий
Основное действующее лицо	Пользователь
Цель	Найти желаемую работу среди популярных сервисов поиска вакансий
Триггер	Пользовательхочет найти работу и использует мобильное приложение для поиска вакансий
Результат	Результаты поиска вакансий представлены в приложении

Таблица 2. Основной поток событий описываемого use - case'а.

№ шага	Действующее лицо	Шаг	Комментарий
1	Приложение	Запрашивает фильтры для осуществления поиска
2	Пользователь	Вводит желаемые фильтры	Фильтрами могут быть любые ключевые слова, например название профессии или компании, желаемая заработная плата, местоположение и так далее.
3	Приложение	Делает поиск по полученным фильтрам
4	Приложение	В случае успешного поиска и наличия подходящих вакансий переходит на новый экран и отображает пользователю полученный результат в виде таблицы. В противном случае сообщает пользователю об ошибке или отсутствии результатов поиска и предлагает попробовать произвести поиска снова.
5	Пользователь	В случае успешного отображения результатов поиска выбирает желаемую вакансию и переходит на страницу вакансии, размещенную на сайте соответствующего сервиса.

Важность выбора правильной архитектуры

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

Сбалансированное распределение обязанностей между сущностями с соблюдением строгих правил. Распределение обязанностей между сущностями позволит разбить сложный модуль на необходимые слои. Это значительно снизит сложность понимания написанного кода для других разработчиков, обеспечит возможность повторного использования любой из сущности в другом месте программы или даже в другом проекте, а также позволит быстро определить,где именно могла возникнуть та или иная проблема [19].

Тестируемость. Созданный разработчиком программный код должен быть написан таким образом, чтобы была возможность легко тестировать каждый из слоев модуля [20].

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

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

В контексте разработки мобильных приложения для операционной системы iOS самыми популярными являются архитектуры MVC, MVP, MVVM, VIPER. Каждая из них будет описана и проанализирована, в результате чего будет выбрана наиболее подходящая для выполнения поставленных задач [2].

MVC. Model - View - Controller

Один из самых популярных архитектурных паттернов, применяемых как при проектировании мобильных приложений для iOS, так и в других сферах разработки программного обеспечения. В рамках данного архитектурного решения существуют три основных слоя - модель (model), представление (view), контроллер (controller) [21]. В классической реализации MVCмодельотвечает за бизнес - логику и является хранилищем данных,предоставляя их представлению по команде контроллера. Контроллер в свою очередь реагирует на действия пользователя, оповещая об этом модель. Представление лишь отображает данные пользователю, полученные от модели. Основная проблема, практически сразу исключающая данное архитектурное решения для реализации поставленных задач, заключается в тесной связи между слоями: каждый из слоев знает о двух других. Это сразу же снижает возможность повторного использования и тестирования каждого из них.

Рисунок 2. Графическое представление архитектурного паттерна MVC

OrlovB. iOSArchitecturePatterns[Электронный ресурс] / Medium. -URL: https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

В разработке мобильных приложения для операционной системы iOSбольшая часть представлений наследуют базовый класс UIViewController. Из-за этого, представление и контроллер задействуются как в отображении необходимого контента, так и в обработке действий пользователя [22]. Это наглядно показано на рисунке ниже. Ввиду этого их достаточно сложно отделить друг от друга. Если большую часть данных и бизнес - логику еще представляется возможным разместить в модели, то отделить представление и контроллер в рамках данного архитектурного решения очень сложно, что ведет к одной серьезной проблеме - отсутствие возможности тестировать представление или контроллер.

Рисунок 3. Графическое представление архитектурного паттерна MVC от Apple

OrlovB. iOSArchitecturePatterns [Электронный ресурс] / Medium. - URL: https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

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

MVP. Model - View - Presenter

Данный архитектурный паттерн решает основную проблему описанного ранее MVC. В концепции MVP представление совсем ничего не знает о модели [23], да и вообще ничего не знает, так как полностью отделено от любой логики.

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

Cточки зрения распределения обязанностей MVPимеет хорошее преимущество над тем же MVC. Каждый слой имеет лишь одну обязанность. Хорошая тестируемость описываемого архитектурного решения достигается отсутствием связи между представлением и моделью. Концепция MVPдостаточно легка в понимании, однако требует написания довольно большого количества кода.

Рисунок 4. Графическое представление архитектурного паттерна MVP

OrlovB. iOSArchitecturePatterns[Электронный ресурс] / Medium. -URL: https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

MVVM. Model - View - ViewModel

Архитектурный паттерн MVVM [5]очень похож на MVP. В нем также отсутствует прямая связь между представлением и моделью, а ViewModel ничего не знает о представлении. Представление и модель в MVVM выполняют такие же функции, что и в MVP. Однако новый слой, называемый ViewModel, несколько отличается от презентера. ViewModel хранит состояние текущего представления. Вызывая методы из модели, ViewModel обновляет свое состояние, а вместе с ним, с помощью соответствующей привязки обновляется и само представление. Представление выступает в качестве наблюдателя [24] за изменениями ViewModel. При инициализации представление подписывается на необходимые изменения ViewModel. После того, как изменения происходят, представление получается уведомление, производя в ответ необходимые изменения.

Распределение обязанностей в MVVMне такое сбалансированное, как в MVP, потому что представление имеет дополнительную обязанность - подписываться и обрабатывать изменения ViewModel. Данный архитектурный паттерн имеет высокий уровень тестируемости, обусловленный незнанием ViewModelо представлении.

Рисунок 5. Графическое представление архитектурного паттерна MVVM

OrlovB. iOSArchitecturePatterns [Электронный ресурс] / Medium. - URL: https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

VIPER. View - Interactor - Presenter - Entity - Router

Последним рассматриваемым архитектурным решением является VIPER [25], имеющий пять слоев-представление (view), интерактор(interactor), презентер (presenter), сущность (entity), роутер (router). Представление, как и в некоторых вышеописанных паттернах, отвечает за отображение необходимого контента. Представление оповещает презентер о действиях пользователя. Презентер в свою очередь может обратиться к интерактору и роутеру. Интерактор отвечает за бизнес логику, а также управляет сущностями (entities). Сущность - это модель данных, не содержащая какой-либо бизнес логики. Роутер ответственен за инициализацию и навигацию модуля.

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

Рисунок 6. Графическое представление архитектурного паттерна VIPER

OrlovB. iOSArchitecturePatterns[Электронный ресурс] / Medium. -URL: https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

приложение поиск вакансия

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

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

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



ГЛАВА 3. РАЗРАБОТКА ПРИЛОЖЕНИЯ

3.1 Выбор языка программирования

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

В случае с разработкой мобильных приложений для iOSсуществуют два официальных языка программирования-Objective-Cи Swift.Последний язык программирования был представлен в недалеком 2014 году компанией Appleна ежегоднойвсемирной конференции разработчиков на платформах компании - WWDC. Objective - Cв свою очередь достаточно старый язык программирования, и до презентации Swiftявлялся единственным официально поддерживаемым языком программирования для разработки программного обеспечения на платформах Apple. В таблице ниже приведены плюсы и минусы обоих языков программирования.

Таблица 3. Сравнение языков программирования Swiftи Objective-C

	Swift	Objective - C
Плюсы	Статическая типизация Опциональные значения Простой синтаксис Частые обновления и добавление нового функционала	Стабильность Возможность интеграции сторонних библиотек, написанных на С или С++
Минусы	Наличие багов Нет поддержки стабильности бинарного интерфейса приложения	Сложный синтаксис Больше не поддерживается компанией Apple Угроза появления ошибок из - за динамической типизации.

Каждый из выбранных языков имеет как свои плюсы, так и свои минусы. ОднакоObjective - Cболее не поддерживается компанией Apple, а это означает, что никогда больше он не будет обновляться. Ввиду своей относительной простоты, а также вышеупомянутым фактом, высокоуровневый язык программирования Swiftбыл выбран для разработки приложения [26 - 27].

Обзор разрабатываемого приложения

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

Мобильное приложение будет состоять из двух основных модулей:

1. Модуль поиска вакансий.

2. Модуль результата поиска.

Под модулем [28] подразумевается некая самодостаточная часть программы, которая не зависит от остальных частей программного кода. Как правило структура и поведение модуля подчиняются конкретным заранее определенным правилам. Оба модуля приложения будут разрабатываться по правилам архитектурного паттерна VIPER. Первый позволит делать первоначальный поиск вакансий по введенным параметрам пользователя, после чего будет происходить инициализация и переход во второй модуль, основная задача которого будет заключаться в отображении результата поиска и совершении дополнительной загрузки вакансий по мере необходимости.

Модуль поиска вакансий

Модуль поиска вакансий является первой точкой взаимодействия пользователя и приложения. Инициализация описываемого модуля реализуется в методе, который вызывается объектом UIApplication [29]при успешном завершении запуска приложения. Каждое приложение для операционной системы iOSвсегда имеет лишь один экземпляр UIApplication. UIApplicationявляется централизованной точкой координации и управления для всех приложений. Именно объект UIApplicationвызывает соответствующие методы делегата UIApplicationDelegate [30], в одном из которых как раз и будет происходить инициализация модуля поиска вакансий.

Инициализация модуля происходит в результате вызова метода createModule в слое навигации. Слой навигации определяется классом JobSearchRouter. Статический метод createModule создает роутер - JobSearchRouter, интерактор - JobSearchInteractor, презентер - JobSearch Presenter, и наконец представление - JobSearchViewController. После инициализации экземпляров описанных ранее классов, метод возвращает представление, которое будет являться корневым для созданного системой экземпляра класса UIWindow. UIWindowявляется фоном для пользовательского интерфейса в iOSприложениях [31], а также и объектом, который отправляет различные события в представления. Cпомощью UIWindow реализуется возможность отображать любой контент и реагировать на действия пользователя.

Представление данного модуля является наследником класса UIViewController.UIViewController управляет иерархией представлений, которые отвечают за отображение контента внутри прямоугольной области [32].На каждом этапе жизненного цикла [33] представления разработчик может вызывать необходимый программный код. Очень важно точно знать в какой именно момент времени и на каком конкретном этапе жизненного цикла представления будет происходить вызов необходимого программного кода. Ниже отображены основные этапы жизненного цикла каждого разрабатываемого в рамках данной работы UIViewController'а.

Рисунок 7. Жизненный цикл UIViewController

UIViewControllerlifecyclemethods [Электронныйресурс] / Safari. - URL: https://www.oreilly.com/library/view/learning-xamarin-studio/9781783550814/ch06s02.html

Жизненный цикл UIViewController'а начинается с инициализации. На данном этапе для нового представления выделяется необходимое количество памяти в системе, а также проводится настройка каких - либо базовых параметров, например размера.Следующим этапом является вызов метода loadView. Каждый UIViewController имеет поле view, которое является контейнером для всего, что видит пользователь. Система загружает ранее созданное разработчиком представление и присваивает его полю view.Следующим этапом является вызов метода viewDidLoad, сигнализирующий об успешной загрузке представления UIViewController'ом. На данном этапе происходит добавление основного контента, который будет показан пользователю. Также здесь может начинаться загрузка необходимых данных для последующего отображения. После успешной загрузки представления происходит вызов метода viewWillAppear, который оповещает о том, что представление вскоре будет отображено пользователю. Данный метод, в отличие от viewDidLoad, вызывается каждый раз, перед тем как представление будет показано пользователю, вне зависимости от того, было ли оно загружено в память системы до этого или нет. После появления представления на экране пользователя, вызывается метод viewDidAppear, в котором, к примеру, может быть реализована логика появления клавиатуры для ввода необходимых данных пользователем. После того как пользователь производит переход к другому UIViewController'у или при исчезновении представления по любой другой причине, вызывается метод viewWillDissapear, который оповещает о скором исчезновении представления с экрана пользователя.Следующим этапом является вызов метода viewDidDissapear, сигнализирующем о событие полного исчезновения представления с экрана пользователя. Предпоследним этапом жизненного цикла UIViewController'а является вызов метода viewDidUnload, который в свою очередь сообщает о том, что представление было полностью выгружено из памяти системы. Финальный этап - деинициализацияUIViewController'а, оповещающая о его полном освобождении из памяти.

Методы класса UIViewControllerпредоставляют отличную возможность для управления представлением на любом этапе жизненного цикла. В разрабатываемом модуле представление будет являться UIViewController'ом, однако, следуя правилам архитектурного паттерна VIPER, оно не будет иметь возможности решать, что конкретно нужно сделать на каждом этапе своего жизненного цикла или при определенном взаимодействии пользователя с пользовательским интерфейсом. Вместоэтогопредставление будет оповещать о наступлении необходимого этапа жизненного циклапрезентеру, который дальше будет сам определять какие действия необходимо совершить. Или, в случае конкретного действия пользователя, оповещать презентер об этом. Для наглядностибудетприведен пример взаимодействия представления и презентера в разрабатываемом модуле, а также и остальных слоев. Но сначала стоит продемонстрировать каким визуально получился разработанный модуль.

Рисунок 8. Визуальное представление модуля поиска вакансий

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

Основной задачей, которую решает данный модуль, является предоставление интерфейса пользователю для ввода параметров поиска. После введение необходимых параметров для поиска вакансии, пользователь нажимает на кнопку «искать работу». Представление оповещает об этом событие презентер, который в свою очередь обращается обратно к представлению для получения данных, введенных пользователем, а также для отображения загрузочного индикатора. После получения данных,презентер обращается к необходимому для совершения поиска вакансий методув интеракторе, передавая полученные данные в качестве параметров.Интерактор, получив необходимые данные для начала поиска вакансий, обращается к сущностям (entities), которые совершают поиск вакансий, и оповещает о полученном результате интерактор. Каждая из сущностей соответствует сервису поиска вакансий. Сущности, получив от интерактора параметры, начинают поиск одновременно.После окончания загрузки результатов поиска, сущность передаетих интерактору. Получив результаты загрузок с каждой сущности, интерактор группирует их, а по завершении передает презентеру.Презентер, получив результаты загрузкиот интерактора, подготавливает их, а затем обращается к роутеру для инициализации и презентации модуля результатов поиска, передав их в качестве параметров при инициализации.

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

Для описания результатапоиска будет использован перечисляемый тип. Эта структура данных представляет собой множество значений - идентификаторов, с помощью которых предоставляется возможность для описания различных состояний. В разрабатываемом приложении перечисляемый тип будет называться Result и иметь два состояния - errorи success. Каждое из описываемых состояний имеет ассоциативное значение, представляющее дополнительную информацию, значение и тип которой может варьироваться в зависимости от места использования. Для состояния error ассоциативным значением будет перечисляемый тип, описывающий всевозможные ошибки. Ассоциативное значение состояния success будет обобщенным, что позволит передавать значение любого произвольного типа. Подобное решение описания результата позволит в дальнейшем легко егоиспользовать как внутри описываемого модуля, так и в любой другой части приложения.

Модуль результата поиска

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

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

Единственным решением в самом начале казалось использование API[34] каждого из сервисов поиска вакансий. APIспособен предоставить удобный механизм для получения всех необходимы данных. Сделав соответствующий запрос, можно легко загружать информацию, например, в JSON - формате [35], автоматическая обработка которой позволит извлечь все необходимые данные и сразу же показать пользователю. Все былобы очень просто, если бы каждый из сервисов предоставлял APIв открытом доступе и совершенно бесплатно. Многие сервисы предоставляют доступ к своему APIпо подписке, а некоторые и вовсе полностью закрывают доступ по личнымили техническим соображениям. Ввиду отсутствия даже минимальных инвестиций для создания приложения, а также отсутствия доступа к APIмногих онлайн - сервисов, требовалось придумать другое решение.

Для разрешения проблемы получения данных было придумано следующее решение. Каждый из сервисов поиска вакансий имеет веб - приложение, с помощью которого можно совершать поиск вакансий. Для осуществления обычного поиска не требуется авторизация на сайте, а это значит, что все данные предоставляются в открытом доступе. Каждая веб страница представляет собой текстовый файл в XML/HTML [36]формате. Как правило, HTMLиспользуется для форматирования и отображения данных, в то время как XMLотвечает за передачу данных. Ранее было указано, что результаты поиска вакансий предоставляются в открытом виде, а значит и соответствующие веб - страницамXML/HTMLдокументы, которые содержат всю необходимую информацию о вакансиях, которую можно извлечь. Далее будет описан пример получения вакансий с сервиса HeadHunter.

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

Рисунок9. Пример URL - адреса запроса поиска вакансий на сервисе HeadHunter

Все URL - адреса запросов для поиска вакансий на данном сервисе имеют одинаковый фрагмент -https://hh.ru/search/vacancy. Он будет локально храниться в приложении и каждый раз использоваться при генерации запроса на получение вакансий через сервис HeadHunter. Следующим параметром запроса является поле text, которое содержит введенные ранее ключевые слова. Поле area определяет в какой зоне будет произведен поиск. Так, значение area=1 позволяет искать по Москве и Московской области. Все названия полей будут локально храниться в приложении и использоваться для генерации запросов на конкретном сервере. Подобным образом будут генерироваться адреса запросов для каждого из сервисов поиска вакансий.После загрузки веб - страницы с результатом поиска, с помощью браузера можно просмотреть соответствующий ей текстовый файл.

На рисунке ниже изображен лишь фрагмент кода XML-документа, который описывает место работы, заработную плату, обязанности и требования, указанные в самой первой вакансии поиска. Таким образом можно найти всю представленную информацию на сервисе HeadHunterпо каждой вакансии, которая была найдена в результате поиска. Следующим шагом будет являться непосредственное извлечение данной информации из XML/HTML-документа для последующего отображения в приложении.

Рисунок10. Пример фрагмента XML - документа веб - страницы сервиса HeadHunter

Каждый элемент, который пользователь видит на веб - странице, будь то кнопка или текстовый фрагмент, описан в XML-документе. Для обеспечения доступа к любому элементу XML - документа используется язык запросов XPath, который позволит извлечь всею необходимую информацию из списка найденных вакансий. На данный момент для каждой вакансии приложение извлекает из XML-документа название компании, которая предоставляет вакансию, название вакансии, требования, обязанности, заработную плату, дату создания [37 - 38].

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

На уровне приложения процесс получения и обработки данных выглядит несколько сложнее. Язык программирования Swift, на котором разрабатывается приложение, предоставляет многофункциональный APIдля загрузки данных через протокол HTTP, который в свою очередь обеспечивает обмен произвольными данными между приложением и сервером. Cпомощью данного APIсоздаются задачи для извлечения содержимого указанного URL - адреса для каждого сервиса поиска вакансий. В результате выполнения каждой задачи вызывается замыкание, параметрами которого являются data-битовое представление данных, полученных в качестве ответа сервера, response-объект, который предоставляет метаданные, такие как код состояния, error-объект ошибки, определяющий причину неуспешного завершения запроса.

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

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