Android приложение для XXI Апрельской Международной Научной Конференции

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

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

На тему «Android приложение для XXI Апрельской Международной Научной Конференции»

по направлению подготовки 09.03.04 «Программная инженерия»

Выполнил студент группы БПИ164 4 курса бакалавриата образовательной программы «Программная инженерия»

А.Г. Чичканов

Москва 2020



Реферат

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

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

Работа содержит 29 страниц, 3 главы, 12 рисунков, 1 таблицу, 8 источников, 4 приложения

Ключевые слова: android; приложение; апрельская научная конференция

There are myriads of scientific conference apps that come with a slew of useful features. All of them are developed with a simple reason in mind, to deliver a customer value on a basic level, however, when it comes to implementation of non-typical behavior or insertion of advanced functionality to the app, most of them are unable to meet the expectations. It occurs, mainly, because of such apps are constrained by a predefined template, as well as, they are poorly customizable in terms of design and architecture.

This work describes April Academic Conference application for Android, that provides all of required featured for conference participant, making it easier for him to stay up to date with all the latest news and ability to discover the most exciting events.

The paper contains 29 pages, 3 chapters, 12 figures, 1 table, 8 sources, 4 attachments

Keywords: android; application; april academic conference



Основные определения, термины и сокращения

Android - операционная система, разрабатываемая компанией Google.

Kotlin - статически типизированный язык программирования, разрабатываемый компанией JetBrains.

MVVM - Model-View-ViewModel. Шаблон проектирования архитектуры приложения.

Clean Architecture - архитектурный подход, разработанный Бобом Мартиным.

REST - Representational State Transfer. Архитектурный стиль взаимодействия компонентов распределённого приложения в сети.

API - Application Programming Interface. Интерфейс программирования приложений, позволяющий сервисам взаимодействовать, получать доступ и обмениваться данными

JWT - JSON Web Token. Открытый стандарт (RFC 7519) для создания токенов доступа, основанный на формате JSON.



Оглавление

Введение

Глава 1. Обзор существующих решений

Глава 2. Принципы работы и архитектурные особенности

2.1 Сценарии использования приложения

Глава 3. Реализация приложения

3.1 Язык программирования и основные средства разработки

3.2 Реализация избранных событий

Заключение



Введение

Мобильные телефоны изменили способ потребления информации. Они принесли в наш мир множество новых возможностей и упростили многие рутинные задачи. В настоящее время у 45% людей есть смартфоны [1], среди которых 74% работают под управлением ОС Android [2]. Это связано с тем, что устройства, работающие под управлением ОС Android, дешевле, чем устройства конкурентов, и в то же время эта платформа предоставляет практически те же возможности с точки зрения функциональности, которые могут быть интегрированы в флагманское приложение.

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

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

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

Данная работа посвящена разработке приложения для XXI Апрельской Международной Научной Конференции для мобильной платформы Android. Целью работы является создание клиентского приложения под ОС Android. Для достижений этой цели требуется решить следующие задачи:

Проанализировать существующие решения в сфере приложений для конференций

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

Реализовать бизнес слой приложения в соответствии с функциональными требованиями

Настроить клиент-серверное взаимодействие в соответствии с API, предоставленным backend- разработчиком

Настроить кэширование данных на мобильном устройстве

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

Разработать техническую документацию

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

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



Глава 1. Обзор существующих решений

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

Приложение Апрельской Конференции прошлых лет

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

Whova и Eventicious

Данные приложения предлагают основных функционал для конференций по модели white-label. Из-за этого нельзя взять их код и интегрировать свой функционал. Однако их можно использовать как референс для основного функционала приложения.

Таблица 1. Сравнение текущих решений

Название приложения	Расписание	Навигация по месту проведения	Стабильность	Кастомизация
HSE April Conference Application 20182019	+	-	-	-
Whova	+	-	+	+
VK Fest	+	+	+	-
Eventicious apps	+	-	+	+

1.1 VK Fest

Приложение для фестиваля ВКонтакте. Его также нельзя использовать как программную основу для нового продукта, так как код закрыт. Однако опять же, можно использовать как референс для нового функционала.

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



Глава 2. Принципы работы и архитектурные особенности

2.1 Сценарии использования приложения

Рисунок 1. Сценарии использования приложения

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

Авторизация. После первого входа участнику будет предложена авторизация в приложении. Она предоставит участнику уникальный QR код, с которым он сможет быстро регистрироваться на события на специальных станциях в корпусе на Покровском бульваре. Так же авторизованный пользователь сможет добавить карточку участника в Google Pay [3].

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

Просмотр обычных новостей. Под новостями от редакции пользователь может ознакомиться со всеми новостями конференции и перейти на детальный просмотр и Chrome Custom Tab [4].

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

Просмотр ассоциированных мероприятий. Участник может просматривать список ассоциированных мероприятия, а также перейти на детальный просмотр мероприятия в Chrome Custom Tab.

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

Просмотр расписания конференции. Участник может просматривать полное расписание конференции. Предусмотрена возможность фильтрации: по секции, языку, времени, типу сессии. В случае, если пользователь не может найти событие, есть поиск, в котором при помощи Elastic [5] он может искать желаемое событие по любым наборам слов, встречающихся в этом событии. Так же отсюда можно добавить событие в избранное.

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

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

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

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

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

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

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

Многомодульный подход

Рисунок 2. Модули приложения

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

Core -сосредоточена общая логика и компоненты приложения

Schedule - логика и компоненты для работы с расписанием

Featuring - логика и компоненты для работы с новостями, ассоциированными мероприятиями и партнерами конференции

Info - логика и компоненты для работы с информацией о конференции

HseNavigation - логика и компоненты для работы с навигацией по корпусу на Покре

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

Структура модулей

Рисунок 3. Структура модуля Schedule

Каждый модуль приложения использует реализован в соответствии с архитектурным подходом Clan Architecture, разработанный Бобом Мартиным.

Рисунок 4. Схема слоев Clean Architecture

Presentation Layer - платформозависивый слой, который содержит в себе UI приложения и ответственен за обработку пользовательского взаимодействия с приложением.

Domain Layer - платформонезависивый слой с бизнес логикой приложения. Не зависит от остальных слоев и взаимодействует с data и presentation слоем при помощи интерфейсов.

Data Layer - платформозависивый слой, который содержит в себе детали реализации взаимодействия приложения с базой данных, API и кэшем.

Отдельный слой, который был добавлен в приложение - di (Dependency Injection). В нем содержится граф зависимостей данного модуля.

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

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



Глава 3. Реализация приложения

3.1 Язык программирования и основные средства разработки

В качестве языка программирования был выбран Kotlin, разрабатываемый компанией JetBrains. В 2018 году Google сделала его официальным языком для разработки под Android, с этих пор все новые и большинство старых приложений переходят на него.

В качестве среды разработки была выбрана IDE Android Studio, которая является стандартом для разработки под Android.

Реализация Presentation слоя

Рисунок 5. Схема MVVM

До 2018 года в Android не было стандарта для разработки presentation слоя. И лишь в начале 2018 компания Google начала создавать общим компоненты, приняв за основу архитектуру MVVM.

В качестве подхода для реализации слоя отображения был выбран именно MVVM (Model View ViewModel). Впервые этот подход был предложен Джоном Госсманом [6] как альтернатива существующим MVC и MVP. View - это элемент отображения, на котором располагаются кнопки, текстовые поля и так далее. ViewModel - объект, в котором описывается логика поведения View. Здесь может быть описана логика по формированию текстовых полей, реакция на нажатие кнопки и так далее. Model - это логика, которая связана с данными приложения.

Рассмотрим реализацию на примере работы с экраном информации о конференции.

class InfoViewModel @Inject constructor(

private val screensNavigator: ScreensNavigator, private val userUseCase: UserUseCase ) : BaseViewModel() {

val state = MutableLiveData<State>()

val openDeuathSheet = SingleLiveEvent<Void>()

val error = SingleLiveEvent<Throwable>()

init {

userUseCase.getUserStatus()

.applySchedulers()

.subscribe(

{ state.value = State(it) },

{ Timber.e(it, "Error get user status") }

)

.addDisposable()

}

В отрывке кода для экрана информации о конференции видно как View подписан на события state, openDeauthSheet, error. ViewModel в соответствии с логикой поведения решает в какой момент нужно вызвать эти события, а View на это реагирует.

override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) initRv()

viewModel.openDeuathSheet.observeValue(this) { showDialog(DeuathSheet(), DEUATH_DIALOG)

}

viewModel.error.observeValue(this) { showErrorDialog(it)

}

viewModel.state.observeValue(this) { state -> with(infoAdapter) { clear()

if (state.userStatus is UserStatus.UserExists) { add(UserInfoItem(state.userStatus.user)) add(QrItem { viewModel.onQrClick() })

} else {

add(AuthItem { viewModel.onAuthClick() })

} приложение навигация экран авторизация

При наступлении события openDauthSheet, View открывает диалог. При наступлении события error, View показывает диалог с ошибкой. При возникновении события state, View рисует экран с новыми данными.

Во ViewModel при помощи внедрения зависимостей в конструктор передаются параметры: scrensNavigatior - интерфейс с переходами необходимыми для этого экрана и userUseCase - интерфейс сценария взаимодействия с пользовательскими данными.

Реализация Domain слоя

interface UserUseCase {

fun login(login: String, password: String): Computable

fun isAuthorized(): Boolean

fun getUserStatus(): Observable<UserStatus>

fun updateUser(): Completable

fun deauthorize(): Completable

}

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

class UserUseCaseImpl @Inject constructor( private val userService: UserService, private val userRepository: UserRepository, private val loadQrUrlUseCase: LoadQrUrlUseCase, private val fcmTokenUseCase: FcmTokenUseCase, private val context: Context ) : UserUseCase {

override fun login(login: String, password: String): Completable = userService.login(login, password)

.map {

userRepository.token = it.token updateUser().blockingAwait()

}

.flatMapCompletable { fcmTokenUseCase.attach() }

.doOnError {

userRepository.token = null userRepository.user = null

}

.doOnComplete { preloadQr() }

override fun isAuthorized(): Boolean = !userRepository.token.isNullOrBlank() override fun getUserStatus() = userRepository.getUserStatus()

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

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

Реализация Data слоя

В Data слое выделено два основных типа сущностей: сервисы (Service) и репозитории (Repository). Сервисы служат для взаимодействия с внешним миром (API), репозитории ответственены за хранение данных на устройстве (память, кэш, база данных).

interface UserService {

fun login(login: String, password: String): Single<LoginResult>

fun getUser(): Single<User>

fun getGPayUrl(): Single<String>

fun attachDevice(fcmToken: String): Computable fun deleteDevice(fcmToken: String): Completable

}

interface UserRepository { var token: String? var user: User?

fun getUserStatus(): Observable<UserStatus>

}

В деталях реализации сервиса спрятана логика по работе с API:

class UserServiceImpl @Inject constructor( private val userApi: UserApi,

private val loginResultResponseTransformer: LoginResultResponseTransformer, private val userResponseTransformer: UserResponseTransformer, context: Context

) : UserService, BaseService(context) {

override fun login(login: String, password: String) = execute(userApi.login(LoginRequest(login, password)))

.map { loginResultResponseTransformer.transform(it) }

interface UserApi {

@POST("user/auth")

fun login(@Body loginRequest: LoginRequest): Single<LoginResultResponse> @GET("user/me")

fun getUser(): Single<UserResponse>

@GET("user/gpay")

fun getGPayUrl(): Single<GpayResponse>

@POST("notifications/device")

fun attachDevice(@Body fcmTokenRequest: FcmTokenRequest): Completable

// Костыль для окттп, так как оне не умеет в @DELETE и Body одновременно @HTTP(method = "DELETE", path = "notifications/device", hasBody = true) fun deleteDevice(@Body fcmTokenRequest: FcmTokenRequest): Completable

}

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

class UserRepositoryImpl @Inject constructor( private val prefs: SharedPreferences, private val moshi: Moshi ) : UserRepository {

private companion object {

private const val KEY_TOKEN = "auth_token" private const val KEY_USER = "user"

}

private val userStatusSubject = BehaviorSubject.create<UserStatus>() override var token: String?

get() = prefs.getString(KEY_TOKEN, null)

set(value) = prefs.edit { putString(KEY_TOKEN, value) }

override var user: User? get() {

val json = prefs.getString(KEY_USER, null) ?: return null val adapter = moshi.adapter<User>(User::class.j'ava) return try {

adapter.fromJson(json)

} catch (e: Exception) { null

}

}

set(value) {

val adapter = moshi.adapter<User>(User::class.java) prefs.edit { putString(KEY_USER, adapter.toJson(value)) } emitUserStatus(value)

}

Реализация DI (Dependency Injection) слоя

По мере роста проекта растет и количество зависимостей в нем. Сначала может быть удобно создавать все их через конструктор, но потом это начинает занимать слишком большое количество времени разработчика, появляются баги. Для этого в проект была внедрена библиотека Dagger 2 [7], разработанная компанией Google и помогающая предоставлять зависимости во всем проекте, в соответствии с паттерном Dependency Injection и легко его масштабировать.

@Component(

modules = [FeaturingModule::class, NavigationFeaturingModule::class], dependencies = [ScheduleComponent::class]

)

interface FeaturingComponent {

val featuringViewModel: FeaturingViewModel

val newsListViewModel: NewsListViewModel

val reportersListViewModel: ReportersListViewModel

val reporterDetailsViewModel: ReporterDetailsViewModel

val plenaryEventsViewModel: PlenaryEventsViewModel

val associatedEventsViewModel: AssociatedEventsListViewModel

}

В фрагменте кода можно видеть граф зависимостей для модуля Featuring. Здесь описаны модули, которые этот граф использует, другие графы, от которых этот граф зависит и зависимости, которые этот граф предоставляет. Некоторые предоставляемые зависимости вынесены в отдельный модуль, фрагмент кода которого представлен ниже:

@Module(includes = [FeaturingModule.BindsModule::class]) class FeaturingModule {

@Provides

fun featuringApi(retrofit: Retrofit): FeaturingServiceImpl.FeaturingApi =

retrofit.create()

@Module

abstract inner class BindsModule {

@Binds

abstract fun featuringService(arg: FeaturingServicelmpl): FeaturingService @Binds

abstract fun featuringUseCase(arg: LoadFeaturingUseCaseImpl): LoadFeaturingUseCase

@Binds

abstract fun reporterScheduleUseCase(arg: LoadReporterScheduleUseCaseImpl): LoadReporterScheduleUseCase }

}

Реализация навигации между экранами

В одномодульном приложении это тривиальная задача. Но. Когда модулей несколько, чтобы перейти из экрана из одного модуля на другой экран из другого модуля, нужно ставить в зависимости два этих модуля. Но что если эти модули содержат переходы в обе стороны между собой? Тогда появится циклическая зависимость и проект не будет собираться. Для этого было решено поделить все переходы на flow: каждый модуль имеет строго ограниченный набор переходов, указанные в интерфейсе (рисунок 17). Реализация этого интерфейса лежит в главном модуле app. Именно он занимается сборкой всех сценариев переходов и внедряет их в граф зависимостей (рисунок 18). Таким образом получаем навигацию между модулями без явного указания зависимостей между модулями.

Ниже представлены фрагменты кода переходами модуля featuring:

interface ScreensNavigator : BaseScreensNavigator { fun navigateToEventDetails(eventUi: EventUi) fun navigateToNewsList(newsUi: List<NewsUi>) fun navigateToPlenaryEventsList()

fun navigateToAssociatedEventsList(associatedEventsContainerUi: AssociatedEventsContainerUi)

fun navigateToReportersList(reporters: List<Person>) fun navigateToReporterDetails(reporter: Person)

}

Реализация переходов модуля featuring. Лежит в главном модуле app

class FeaturingScreensNavigatorImpl @Inject constructor( private val router: Router

) : BaseScreensNavigatorImpl(router), ScreensNavigator {

override fun navigateToEventDetails(eventUi: EventUi) = router.navigateTo( Screens.EventDetailsScreen(eventUi)

)

override fun navigateToNewsList(newsUi: List<NewsUi>) = router.navigateTo( Screens.NewsListScreen(newsUi)

)

override fun navigateпoPlenaryEventsList() = router.navigateTo( Screens.PlenaryEventsListScreen()

)

Реализация способа хранения данных

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

^Synchronized

private fun saveCacheEventSections(sections: List<EventSection>) {

val type = Types.newParameterizedType(List::class.java, EventSection::class.java) val adapter = moshi.adapter<List<EventSection>>(type)

File(context.filesDir, "sections")

.writer ()

.use { it.write(adapter.toJson(sections)) }

}

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

^Synchronized

private fun getCachedEventSections(): List<EventSection> { if (eventsSectionsMemoryCache == null) { eventsSectionsMemoryCache = try {

val type = Types.newParameterizedType(List::class.java,

EventSection::class.java)

val adapter = moshi.adapter<List<EventSection>>(type) adapter.fromJson(

File(context.filesDir, "sections")

.reader()

.readText()

)!!.toMutableList()

} catch (e: Exception) { mutableListOf()

}

}

return eventsSectionsMemoryCache!!.toList()

}

Реализация авторизации пользователя

Рисунок 6. Экран авторизации

Добавление карточки участника в Google Pay

Для авторизации пользователя требуются его данные: электронная почта или номер телефона и пароль. Есть возможность восстановить пароль в случае утраты. Данные передаются на сервер по защищенному протоколу https, в ответ приходит JWT токен, с которым можно делать авторизованные запросы и получить по нему карточку участника, содержащую основную информацию о нем. Для отправки запроса с токеном он подставляется в http header: Bearer ***token***. В ответ может придти 403 ошибка - в таком случае юзер будет деавторизован и придется пройти регистрацию заново. Это сделано в целях безопасности. Например, если кто-то авторизовался на другом неизвестном устройстве, можно деавторизовать этого пользователя на других устройствах.

Рисунки 7-8. Добавление карточки участника в Google Pay

Некоторым пользователям удобно хранить все привязанные карты и пропуска в Google Pay. Для этого был разработан функционал добавления карточки участника в Google Pay. Он доступен только авторизованным пользователям.

На сервер идет запрос с токеном авторизации на получение данных для отображения кнопки «Добавить в GPay», по клику на которую передаются зашифрованные данные на экране добавления карточки средствами Google. При нажатии на кнопку «Сохранить» карточка будет доступна в приложении Google Pay.

3.2 Реализация избранных событий

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



Рисунки 9-12. Избранное

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

Для реализации такого поведения был применен паттерн Subscriber-Observer, реализованный в библиотеке RxJava 2 [8]. В приложении есть глобальный объект ScheduleRepositoryImpl, который содержит в себе детали реализации работы с сессиями и избранными событиями. При добавлении или удалении из избранного, все подписчики получат об этом оповещение и перерисуют экран в соответствии с новыми данными.

class ScheduleRepositoryImpl @Inject constructor( private val context: Context, private val moshi: Moshi

) : ScheduleRepository {

private val eventsSubject = BehaviorSubject.create<List<EventSection>>()

private val favoriteEventsSubject = BehaviorSubject.create<List<EventSection>>()

private var eventsSectionsMemoryCache: MutableList<EventSection>? = null

override fun getEventSections(): Observable<List<EventSection>> { eventsSubject.onNext(getCachedEventSections()) return eventsSubject

}

override fun getFavoriteEventSections(): Observable<List<EventSection>> { favoriteEventsSubject.onNext(getFavoriteCacheEventSections()) return favoriteEventsSubject

}

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



Заключение

В рамках выполнения выпускной квалификационной работы было разработано мобильное приложение на ОС Android для Апрельской Международной Научной Конференции.

Таким образом, в ходе выполнения ВКР были решены следующие задачи:

Проанализировать существующие решения в сфере приложений для конференций

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

Реализовать бизнес слой приложения в соответствии с функциональными требованиями

Настроить клиент-серверное взаимодействие в соответствии с API, предоставленным backend- разработчиком

Настроить кэширование данных на мобильном устройстве

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

Разработать техническую документацию

Среди дальнейших путей развития можно отметить:

Интеграция навигации по новым корпусам

Разработка нового функционала, предложенного. заказчиком

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

...