Google Sample android-architecture kotlin 分析

本文深入探讨了Android MVVM架构的实现方式,特别是在TaskDetail模块中的应用。通过具体示例详细解释了Presenter与Fragment如何相互获取引用,以及为何在Activity而非Fragment中实例化Presenter的原因。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

android-architecture 是Google推荐一些架构,包括各种情况下的mvp和mvvm,最近kotlin兴起,也加入了kotlin分支。由于对kotlin不熟悉,记录下源码阅读中出现的坑。

架构浅析

以TaskDetail模块为例

TaskDetailActivity.kt:

val taskDetailFragment = supportFragmentManager
        .findFragmentById(R.id.contentFrame) as TaskDetailFragment? ?:
        TaskDetailFragment.newInstance(taskId).also {
            replaceFragmentInActivity(it, R.id.contentFrame)
        }
// Create the presenter
TaskDetailPresenter(taskId, Injection.provideTasksRepository(applicationContext),
        taskDetailFragment)

这里是Presenter拿到了Fragment的实例。
TaskDetailPresenter.kt:

init {
    taskDetailView.presenter = this
}

在Presenter中,又把自己的引用给了Fragment。Presenter如何把自己给Fragment呢?如果提前在Fragment中定义Presenter,那更换Presenter就需要改动Fragment了,所以在接口TaskDetailContractBaseView

interface TaskDetailContract {

    interface View : BaseView<Presenter> {
        ...
    }

    interface Presenter : BasePresenter {

        fun editTask()
        ...
    }
}
interface BaseView<T> {
    var presenter: T
}

在Fragment中使用泛型也可以,但是这样就优雅多了。

总体来看,就是M与P完全独立,两个的交集只在Contract的接口中。

疑问

以TaskDetail模块为例

Fragment何时获得的Presenter的实例?

TaskDetalFragment.kt

override lateinit var presenter: TaskDetailContract.Presenter
...
override fun onResume() {
    super.onResume()
    presenter.start()
}

onResume中,我们发现TaskDetalFragment直接使用了presenter实例,而presenter在整个TaskDetalFragmen中并没有初始化,只是lateinit ,而且,TaskDetalFragment实现的TaskDetailContract.View接口,但kotlin中接口的Field是必须重写的,那么presenter是在哪里init的呢?

回头再看TaskDetailActivity.kt:

val taskDetailFragment = supportFragmentManager
        .findFragmentById(R.id.contentFrame) as TaskDetailFragment? ?:
        TaskDetailFragment.newInstance(taskId).also {
            replaceFragmentInActivity(it, R.id.contentFrame)
        }
// Create the presenter
TaskDetailPresenter(taskId, Injection.provideTasksRepository(applicationContext),
        taskDetailFragment)

TaskDetailActivity 中,获得taskDetailFragment 后立刻初始化了TaskDetailPresenter ,并将taskDetailFragment 传入。

我们发现TaskDetailPresenter 并没有返回值。进去看一下:

init {
    //这里的taskDetailView就是传入的taskDetailFragment
    taskDetailView.presenter = this 
}

TaskDetailPresenter 在初始化的时候把自己的实例赋值给了taskDetailFragment

也就是TaskDetailPresenterTaskDetailFragment 互相获得引用,当TaskDetailFragment 发生点击或者其它事件时,逻辑交给Presenter处理,然后再调用Fragment来处理界面相关的行为。

为什么Presenter的实例化在Activity中而不是Fragment中?

由上面看其实完全可以在TaskDetailFragment 的构造器中实例化TaskDetailPresenter ,为什么要在Activity中呢?

为了解耦,如果在Fragment中实例化Presenter,不管更换Fragment还是更换Presenter都会引起两个文件的改动,写测试文件时也需要引入另一个类,而这种写法可以实现两个类互相独立,只需要定好接口就可以。

Fragment的初始化语句解析

以TaskDetail模块为例

TaskDetailActivity.kt:

val taskDetailFragment = supportFragmentManager
        .findFragmentById(R.id.contentFrame) as TaskDetailFragment? ?:
        TaskDetailFragment.newInstance(taskId).also {
            replaceFragmentInActivity(it, R.id.contentFrame)
        }

supportFragmentManager.findFragmentById(R.id.contentFrame) as TaskDetailFragment? 这一段为获得一个可以为空的TaskDetailFragment

?: TaskDetailFragment.newInstance(taskId) 这一段为如果获得的TaskDetailFragment 为空,就实例化一个新的。

.also { replaceFragmentInActivity(it, R.id.contentFrame) } 这一段为实例化后先执行这一段再赋值给taskDetailFragment

TaskDetailFragment.kt:

companion object {

    private val ARGUMENT_TASK_ID = "TASK_ID"

    private val REQUEST_EDIT_TASK = 1

    fun newInstance(taskId: String?) =
            TaskDetailFragment().apply {
                arguments = Bundle().apply { putString(ARGUMENT_TASK_ID, taskId) }
            }
}

使用工厂模式。因为FragmentManager经常销毁Fragment,所以重要的数据需要保存在Bundle中,每次都要传入重要数据保存到arguments。然后在Activity中和Fragment获得使用。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值