- Русские Блоги
- [Android] Использование Dagger2 в MVVM
- задний план
- составлять
- 1. gradle
- 2. Application
- AppModule.kt
- AppComponent.kt
- App.kt
- 3. Activity
- MainActivityBuilder.kt
- MainActivity.kt
- 4. Fragment
- MainFragmentModule.kt
- MainActivityBuilder.kt
- MainFragment.kt
- 5. Retrofit
- Api.kt
- ApiModule.kt
- AppComponent
- App.kt
- 6. ViewModel
- ViewModelFactory.kt
- ViewModelModule.kt
- ViewModelModule.kt
- MainViewModel.kt
- MainUseCase.kt
- MainRepository.kt
- MainFragmentModule.kt
- MainFragment.kt
- PS1: зависимости интерфейса UseCase, Repository и т. Д.
- MainModule.kt
- AppComponent.kt
- PS2: создание ViewModel
- MainFrgment.kt
- В конце концов
- Современная Android разработка на Kotlin. Часть 2
- Архитектура MVVM + Паттерн Repository + Android Manager Wrappers
- Пару слов об Архитектуре в мире Андроид
- Что такое MVVM паттерн?
- Пример кода
- Android MVVM with Dagger 2, Retrofit, RxJava, Architecture Components
- What is MVVM?
- Project Configuration
- Project Structure
- Setting Up Retrofit Interface
- Setting Up Application Class, Base Activity, Base Fragment
- Setting Up Dagger 2 Component & Modules
- Creating Custom ViewModel Factory
- Setting Up ViewModel
- Setting Up Fragment
- Creating RecyclerView Adapter
Русские Блоги
[Android] Использование Dagger2 в MVVM
задний план
Стандартная архитектура Android MVVM реализуется путем многоуровневого планирования, и между уровнями существуют четкие зависимости. С помощью Dagger2 Завершение внедрения зависимостей, необходимых для каждого уровня MVVM, может сделать структуру проекта более чистой и удобной в обслуживании.
Хотя Dagger2 имеет определенный порог использования, структура проекта MVVM в основном такая же. Dagger2 + Retrofit2(+OkHttp3) + ViewModel Практика наименьшей композиции имеет определенное эталонное значение для других подобных проектов.
составлять
1. gradle
Конфигурация различных зависимых библиотек: Dagger2 、 Retrofit2 、 AAC , И библиотека Json, рекомендованная J GodMoshi
2. Application
AppModule.kt
AppComponent.kt
- Использование компонентов @Component.Factory Замена @Comonent.Builder ,СправкаСравнение фабрики и строителя
- Добавление зависимости AndroidInjectionModule в Component позволяет избежать дополнительной зависимости AndroidSupportInjectionModule и уменьшить зависимость DispatchingAndroidInjector
App.kt
Наследование приложений DaggerApplication , Упростите код, больше не нужно onCreate Вводить
3. Activity
MainActivityBuilder.kt
Ограничено в модуле активности @ActivityScope
MainActivity.kt
MainActivity унаследован DaggerAppCompatActivity , Упростите код, больше не нужно вызывать AndroidInjection.inject (this) в DaggerAppCompatActivity
Пока что Activity было внедрено в AppComponent и может использоваться во время выполнения
4. Fragment
MainFragmentModule.kt
MainActivityBuilder.kt
MainFragment наследует DaggerFragment и может быть реализован автоматически HasAndroidInjector И без AndroidSupportInjection.inject(this) 。
MainFragment.kt
5. Retrofit
Api.kt
ApiModule.kt
AppComponent
Обновить AppComponent , Добавить ApiModule
App.kt
6. ViewModel
ViewModelFactory.kt
Чтобы иметь возможность динамически передавать параметры для ViewModel, мы определяем фабрику
ViewModelModule.kt
ViewModelModule.kt
MainViewModel.kt
Создайте MainFragment Необходимо использовать в MainViewModel
потому как MainViewModel Нужно использовать UseCase , Введен через конструктор.
MainUseCase.kt
MainUseCase Нужно вводить MainRepository`
MainRepository.kt
MainRepository Нужно вводить Api
MainFragmentModule.kt
Обновить MainFragmentModule ,в MainFragment Объем (добавить @FragmentScope ) Добавить MainViewModel , Для использования во время выполнения.
MainFragment.kt
Наконец, в MainFragment Внедрить в него ViewModelFactory и создать его во время выполнения MainViewModel
После завершения сборки весь код Dagger сгенерирован, и связь внедрения зависимостей будет успешно установлена.
PS1: зависимости интерфейса UseCase, Repository и т. Д.
В приведенном выше примере UseCase 、 Repository Они напрямую вводятся в требуемые объекты, но в реальных проектах они могут зависеть от интерфейсов, таких как зависимости ViewModel. MainUserCase Интерфейс вместо MainUseCaseImpl
В это время вы можете добавить еще один модуль, чтобы отделить зависимую реализацию от интерфейса.
MainModule.kt
AppComponent.kt
PS2: создание ViewModel
Используется в приведенном выше коде lateinit var Объявите ViewModel, а затем передайте ViewModelProvider Создайте ViewModel во время выполнения.
Android-KTX предоставляет новейшие функции, которые могут помочь нам оптимизировать этот текст.
MainFrgment.kt
Вы можете использовать фабрику по умолчанию для создания ViewModel следующими способами:
Когда вам нужно использовать настраиваемую фабрику, как в примере:
Сделана одна строка кода, что сокращает ненужный код шаблона.
В конце концов
В приведенном выше примере показано, как использовать Dagger для создания минимального проекта MVVVM. Некоторые конкретные аннотации Dagger подробно не используются. При необходимости вы можете обратиться к официальному веб-сайту Dagger. Документация на официальном веб-сайте все еще очень подробная.
Начать работу с Dagger сложно.Большинство реальных проектов предоставляют некоторый шаблонный код, подобный приведенному выше, а затем добавляют модуль или компонент сзади. Поскольку Dagger сложно начать, я написал эту статью, чтобы помочь вам быстро приступить к работе. Как только вы начнете использовать его в проекте, вы обнаружите, что Dagger действительно мощный и несравнимый с другими фреймворками DI. Я предлагаю вам попробовать его смело.
Источник
Современная Android разработка на Kotlin. Часть 2
Привет, Хабр! Представляю вашему вниманию перевод статьи «Modern Android development with Kotlin (Part 2)» автора Mladen Rakonjac.
Примечание. Данная статья является переводом циклов статей от Mladen Rakonjac, дата статьи: 23.09.2017. GitHub. Начав читать первую часть от SemperPeritus обнаружил, что остальные части почему-то не были переведены. Поэтому и предлагаю вашему вниманию вторую часть. Статья получилась объёмной.
«Очень сложно найти один проект, который охватывал бы всё новое в разработке под Android в Android Studio 3.0, поэтому я решил написать его.»
В этой статье мы разберём следующее:
- Android Studio 3, beta 1 Часть 1
- Язык программирования Kotlin Часть 1
- Варианты сборки Часть 1
- ConstraintLayout Часть 1
- Библиотека привязки данных Data Binding Часть 1
- Архитектура MVVM + Паттерн Repository + Android Manager Wrappers
- RxJava2 и как это помогает нам в архитектуре Part 3
- Dagger 2.11, что такое внедрение зависимости, почему вы должны использовать это Part 4
- Retrofit (with Rx Java2)
- Room (with Rx Java2)
Архитектура MVVM + Паттерн Repository + Android Manager Wrappers
Пару слов об Архитектуре в мире Андроид
Довольно долгое время андроид-разработчики не использовали какую-либо архитектуру в своих проектах. В последние три года вокруг неё в сообществе андроид-разработчиков поднялось много шумихи. Время God Activity прошло и Google опубликовал репозиторий Android Architecture Blueprints, с множеством примеров и инструкций по различным архитектурным подходам. Наконец, на Google IO ’17 они представили Android Architecture Components — коллекцию библиотек, призванных помочь нам создавать более чистый код и улучшить приложения. Component говорит, что вы можете использовать их все, или только один из них. Впрочем, я нашёл их все реально полезными. Далее в тексте и в следующих частях мы будет их использовать. Сперва я в коде доберусь до проблемы, после чего проведу рефакторинг, используя эти компоненты и библиотеки, чтобы увидеть, какие проблемы они призваны решить.
Существуют два основных архитектурных паттерна, которые разделяют GUI-код:
- MVP
- MVVM
Трудно сказать, что лучше. Вы должны попробовать оба и решить. Я предпочитаю MVVM, используя lifecycle-aware компоненты и я напишу об этом. Если вы никогда не пробовали использовать MVP, на Medium есть куча хороших статей об этом.
Что такое MVVM паттерн?
MVVM — это архитектурный паттерн, раскрывается как Model-View-ViewModel. Я думаю это название смущает разработчиков. Если бы я был тем, кто придумал ему имя, я бы назвал его View-ViewModel-Model, потому что ViewModel находится посередине, соединяя View и Model.
View — это абстракция для Activity, Fragment‘а или любой другой кастомной View (Android Custom View). Обратите внимание, важно не путать эту View с Android View. View должна быть тупой, мы не должны писать какую-либо логику в неё. View не должна содержать данные. Она должна хранить ссылку на экземпляр ViewModel и все данные, которые нужны View, должны приходить оттуда. Кроме того, View должна наблюдать за этими данными и layout должен поменяться, когда данные из ViewModel изменятся. Подводя итог, View отвечает за следующее: вид layout’а для различных данных и состояний.
ViewModel — это абстрактное имя для класса, содержащего данные и логику, когда эти данные должны быть получены и когда показаны. ViewModel хранит текущее состояние. Также ViewModel хранит ссылку на одну или несколько Model‘ей и все данные получает от них. Она не должна знать, к примеру, откуда получены данные, из базы данных или с сервера. Кроме того, ViewModel не должна ничего знать о View. Более того, ViewModel вообще ничего не должна знать о фреймворке Android.
Model — это абстрактное имя для слоя, который подготавливает данные для ViewModel. Это класс, в котором мы будем получать данные с сервера и кэшировать их, или сохранять в локальную базу данных. Заметьте, что это не те же классы, что и User, Car, Square, другие классы моделей, которые просто хранят данные. Как правило, это реализация шаблона Repository, который мы рассмотрим далее. Model не должна ничего знать о ViewModel.
MVVM, если реализован правильно, это отличный способ разбить ваш код и сделать его более тестируемым. Это помогает нам следовать принципам SOLID, поэтому наш код легче поддерживать.
Пример кода
Сейчас я напишу простейший пример, показывающий как это работает.
Для начала, давайте создадим простенькую Model, которая возвращает некую строчку:
Обычно получение данных — это асинхронный вызов, поэтому мы должны ждать его. Чтобы сымитировать это, я поменял класс на следующий:
Я создал интерфейс OnDataReadyCallback с методом onDataReady . И теперь метод refreshData реализует (имплементирует) OnDataReadyCallback . Для имитации ожидания я использую Handler . Раз в 2 секунды метод onDataReady будет вызываться у классов, реализующих интерфейс OnDataReadyCallback .
Давайте создадим ViewModel:
Как вы можете видеть, здесь есть экземпляр RepoModel , text , который будет показан и переменная isLoading , которая хранит текущее состояние. Давайте создадим метод refresh , отвечающий за получение данных:
Метод refresh вызывает refreshData у RepoModel , который в аргументах берёт реализацию OnDataReadyCallback . Хорошо, но что такое object ? Всякий раз, когда вы хотите реализовать (implement) какой-либо интерфейс или унаследовать (extend) какой-либо класс без создания подкласса, вы будете использовать объявление объекта (object declaration). А если вы захотите использовать это как анонимный класс? В этом случае вы используете object expression:
Когда мы вызываем refresh , мы должны изменить view на состояние загрузки и когда данные придут, установить у isLoading значение false .
Также мы должны заменить text на
Обратите внимание, что я использую val вместо var, потому что мы изменим только значение в поле, но не само поле. И если вы захотите проинициализировать его, используйте следующее:
Давайте изменим наш layout, чтобы он мог наблюдать за text и isLoading. Для начала, привяжем MainViewModel вместо Repository:
- Изменим TextView для наблюдения за text из MainViewModel
- Добавим ProgressBar, который будет виден только если isLoading true
- Добавим Button, которая при клике будет вызывать метод refresh из MainViewModel и будет кликабельна только в случае isLoading false
Если вы сейчас запустите, то получите ошибку View.VISIBLE and View.GONE cannot be used if View is not imported . Что ж, давайте импортируем:
Хорошо, с макетом закончили. Теперь закончим со связыванием. Как я сказал, View должна иметь экземпляр ViewModel :
Источник
Android MVVM with Dagger 2, Retrofit, RxJava, Architecture Components
Jul 7, 2018 · 3 min read
I used to work with MVP pattern until now. However, when Google released nice-to-use components like the ViewModel along with the Android Jetpack, I have tried to work with MVVM pattern. In this article, we will see how can we use the MVVM pattern with Retrofit, RxJava, and Dagger 2.
What is MVVM?
Model-View-ViewModel architecture consists of 3 parts.
- The View gets user’s actions and sends to the ViewModel , or listens live data stream from the ViewModel and provides to the users.
- The ViewModel gets user’s actions from the View or provides data to View .
- The Model abstracts the data source. View and ViewModel uses that on data stream.
Project Configuration
We implement Android Lifecycle, Retrofit, RxJava, ButterKnife and Dagger 2 libraries in addition to Support libraries.
Project Structure
We will create packages by features. It will make your code more modular and manageable.
Setting Up Retrofit Interface
We have used G ithub API for Json source and as you see Single<> return type in order to observe data with RxJava .
Setting Up Application Class, Base Activity, Base Fragment
We have to use DaggerApplication , DaggerAppCompatActivity and DaggerFragment classes for injecting objects with ContributesAndroidInjector annotation.
We have used abstract layoutRes() function in order to get resource layout id from Activity which extends BaseActivity .
Setting Up Dagger 2 Component & Modules
As you can see, we have wrote only AndroidSupportInjectionModule , ActivityBindingModule and ViewModelModule to the module parameter. We will write other required modules in which Activity or Fragment they needed.
If explain what we have did in that code snippet;
- provideRetrofit — Provides Retrofit adjusted with base url , adapter and converter factories. addCallAdapterFactory() function gets adapter factory for supporting service method return types, add instance of RxJava2CallAdapterFactory for RxJava support.
- provideRepoService — Provides Retrofit interface class for making requests.
Creating Custom ViewModel Factory
ViewModelFactory is a factory that extends ViewModelProvider.Factory in order to provide ViewModel instances to consumer fragment classes. We have injected that class with the ViewModelModule .
Setting Up ViewModel
In ViewModel , we will assign the data which loaded with Retrofit to the MutableLiveData . So, how we can use MutableLiveData? We assign the data to MutableLiveData with setValue or postValue methods, and observe this data in LifeCycleOwner (Activity or Fragment). When we make any changes on the MutableLiveData , this change is dynamically declared to the view. Also, It does not oblige us to check whether View is alive in every transaction.
As you can see, we didn’t use any component injecting code, because we have injected all required classes in the MainFragmentBindingModule and also we have did same thing for activities in the ActivityBindingModule .
Setting Up Fragment
As you know, fragment is our View part. We have injected ViewModelFactory and started to observe LiveData objects.
Creating RecyclerView Adapter
In recyclerView adapter, we have only observed List LiveData and bind them to the recyclerView .
Источник