Comments (38)
如果把livedata的移除了,这个架构就失去了意义
因为MVVM架构中,RxJava
比LiveData
更适合作为观察者模式的组件,LiveData
唯一比RxJava
的优势就是原生支持DataBinding
,而如果移除了DataBinding
,LiveData
对于集成了RxJava
依赖的项目来说意义不大,因此我决定在后面的版本中移除LiveData
。
我们来看看Google官方的描述:
我们可以看到,无论是Room还是Paging等其它官方组件,Google官方还额外提供了RxJava
响应式的额外原生支持,这本身就说明了Google
对RxJava
的肯定,如果RxJava
作为三方库有缺陷或者说LiveData
本身就比RxJava
更优秀,Google
有必要提供这样额外的支持吗?
参考dagger
,其本身就是优秀的,但是Google
依然不满意其反射带来的性能开销,而转身开发了一个dagger2
,这也正是体现了Google
某种精益求精的执拗。
因此,我完全有理由去站队RxJava
,正如我所说的:
因为目前来看,离开了DataBinding,LiveData和RxJava相比没有任何优势。
2019/6/12 补充
我对自己学习的思路是,不断学习优秀的代码,保持对自己代码的怀疑,并督促自己对现有代码的优化。
我在日志中提出了 “离开DataBinding,LiveData毫无意义“,实际上在最近的学习中,我发现我的这个观点是片面、不成熟的,因为作为异步的实现思路之一, 协程 越来越成熟了,因此LiveData + 协程也是一个不错的MVVM的实现方式。
现在,我重新组织自己的语言,移除LiveData的原因应该是:因为项目中使用RxJava作为异步代码的组织者(而不是协程),因此暂时移除了LiveData。😃
from mvvm-architecture.
求求大佬注释多写点,中文哈.
from mvvm-architecture.
见笑了,那么 还能做到数据驱动UI吗?看代码 还是通过找到相应的id设置属性或者值。
嗯,这个应该是不同的人有不同的理解,对于 数据驱动UI
,我的理解是—— View观察唯一数据源的变更,并进行对应的更新。
对于DataBinding
,View观察LiveData内,并仅根据唯一的这个LiveData
进行UI自动更新,所以说,LiveData
内的这个数据,驱动了UI的更新——DataBinding
只是把更新的逻辑写在了xml里面,实际上本质仍然是编译器生成java代码对UI更新的,这个和我们直接在Activity中进行更新,是一样的。
需要理解的是,“驱动”一词的关键在于 观察者模式 和 唯一的数据源,因此重点在于 LiveData
(我也说过了RxJava
更强大,完全有能力替代前者),而不是DataBinding。
个人观点,欢迎讨论哈。
from mvvm-architecture.
感谢作者,学到了很多东西,希望作者能改进一下网络请求:
1.添加cookie ,失败重试等
2.可不可以添加一下上传和下载的功能
毕竟网络请求是非常重要的,在整个app中。想学习一下!
谢谢!!!
from mvvm-architecture.
@qingmei2
刚刚在掘金看到作者这篇文章,大赞,尤其是文中对 数据驱动 UI 和 RxJava 的本质的精确描述。
事实上,数据驱动 UI 和 RxJava 都属于函数式编程的应用,函数式编程主要是为了解决 过程的一致性问题,也即,只有一个入口,只有一个出口,过程不被外界从旁干预,也不对外产生副作用。
DataBinding 本质上是一个外挂,它不是一个强约束的框架,没有彻底迫使 原视图系统 贯彻函数式编程的**,使得视图树在构建后,仍然可以通过 mBinding 拿到视图实例。
但只要理解了函数式编程**的目的 —— 解决过程的一致性问题,就能恰到好处地使用 DataBinding。
数据驱动 UI 框架,在解决 视图调用 的一致性问题 上,是不可替代的,比如 “横竖屏布局控件存在差异” 这种情况,以往需要手动判空来解决 null 安全问题,但手动判空并不可靠,因为视图实例一旦能在 Activity 中拿到,就会不受控制地遍布在各种方法中,也即这个方法判空了,另外的方法却可能疏忽。
而目前来说,只有 DataBinding 能妥善解决这个问题 —— 通过数据来驱动 —— 视图在?那么就能被绑定到的数据驱动;视图不在?ok 没问题,啥事也没有,不会有视图调用的 null 安全问题。
所以个人认为,从软工安全角度来看,DataBinding 的存在有其不可替代的因素,仍然值得存在于 MVVM 架构中。唯一可与之竞争的,只有更加纯粹和强约束的数据驱动框架:Jetpack Compose。
from mvvm-architecture.
感謝,透過這個 Project 學到不少,期待未來版本。
from mvvm-architecture.
接下来的开发方向
考虑优先级从高到低,删除线表示已完成:
- 增加更多页面,扩展更多功能;
- 增加
Paging3
的使用示例; 提供 Jetpack + 协程 的实现方式提供 Jetpack + RxJava 的实现方式优化Room
/Navigation
/Paging
的使用示例;更新Login
界面的逻辑;移除DataBinding
;移除LiveData
;
如果您有其它的建议,欢迎在本页面进行提出,我将在第一时间进行回复。 🤝
from mvvm-architecture.
之前一直在使用RxJava,最近在项目中使用了databinding+livedata,实践中也遇到了一些问题,虽然最终都找到办法解决了,但是总感觉不是最佳实践的方式,看到你上面的解答,发现确实RxJava能处理应付的场景还是要多很多,正如Google官方解释的那样,已经上手RxJava的开发者,继续使用RxJava会是更好的选择
from mvvm-architecture.
跨组件通讯我也不会优先考虑类似RxBus
,EventBus
或者LiveDataBus
,这些在我看来其实就是对Android
机制本身的不熟悉,不说ViewModel
这些组件和类似Bundle、startActivityForResult
这些原生的API,原生提供的AIDL甚至可以进行跨进程通讯。
消息机制的可选择性很多,而类似EventBus
虽然便于上手,但是很容易造成滥用。比如你所说的:
一个页面 写了8个消息注册和处理 用的是eventbus 感觉不好 但是这部分代码又无法省略
其实这一点我觉得应该还是可以优化的,毕竟极少有页面真的需要注册这么多观察者。
如果使用了多Module构建的项目,使用EventBus
没有什么问题,但是我个人认为,越是业务复杂的项目,类似dagger
的依赖注入系统意义越大。
综上所述,你说的都是三方库上的问题,我的观点是,涉及三方库的选型的问题就不是问题,因为每个人都有不同的理解,这个看个人爱好就可以了。
另外,从**上来说,我认为RxJava
和协程
都是非常优秀的异步处理组件,选哪个都无不可,但是同时使用,那就没必要了。
from mvvm-architecture.
首先表达对楼主开源和务实精神的支持,这里谈一谈我对于楼主livedata和RxJava观点的看法,livedata是Google提供的一个套件,体现了Google在处理响应式变更上的思路,相比于一般的响应式UI体系,Android需要考虑自身的生命周期问题,livedata将这些内容都做了封装,可以认为官方指导了一下在Android上应该如何去做响应式数据封装。而RxJava最开始的意图是优雅的处理异步问题,随着在创建响应式业务模型的问题上(简而言之是创建特定的数据流变化和相关事件订阅)体现出优势,被广大开发者接受并推广,Google15年推出databinding,随后才逐步推出JetPack中的各种套件,当时RxJava(RxAndroid)已经广泛使用了,所以Google认可他并提供相关的扩展是正常的。 当然,用任何的异步处理框架去实现响应式数据都是可以的,我记忆中Google推出jetPack时提到过,有很多用户抱怨Google没有像Apple在iOS的生态中那样,为开发者提供各种成熟的开箱可用的套件,大多数都是靠社区和广大开发者维护,所以Google痛定思痛决定对自家人好点,也弄点东西给大家用用。
而databinding呢,他的设计理念是为了让写响应式UI设计更简单一点,并不利于View的复用。
from mvvm-architecture.
不知道楼主是否有关注最新的compose Ui,我越来越坚定的认为目前的什么基于Activity的开发方式后面都会被干掉,转而走向与React、Vue一样响应式的组件化开发,mvvm这一套也注定是一个时期过渡品,在接触了Web的开发之后,我发现app的开发思路很多都是从web借鉴过来的,目前React和Vue的开发(Flutter同)方式真的非常优越
from mvvm-architecture.
为啥要移除liveData, 我觉得livedata挺好的, 如果把livedata的移除了,这个架构就失去了意义
from mvvm-architecture.
如果说把databinding去掉,那么mvvm会大打折扣
from mvvm-architecture.
嗯,我没仔细看。MVI是啥?我还是第一次了解。 你这边对jetpack讲得挺好的
from mvvm-architecture.
我觉得如果mvvm没有了databinding,感觉这个框架就缺少很多。
from mvvm-architecture.
DataBinding 还会加入进来吗?核心组件移除了,MVVM还有啥意义呢
from mvvm-architecture.
DataBinding 还会加入进来吗?
DataBinding
已经被抛弃了,因此不考虑再加进来。
核心组件移除了,MVVM还有啥意义呢
MVVM代表的是一种**,Google从来没有说过DataBinding
是MVVM的核心组件,如果有更好的代替品(或者本身有严重的缺陷),当然要义无反顾的抛弃它。
from mvvm-architecture.
生命周期这一块,以后可能会麻烦些。 去掉DataBinding livedata以后 这个生命周期可能会受什么影响 比如?
from mvvm-architecture.
生命周期这一块,以后可能会麻烦些。 去掉DataBinding livedata以后 这个生命周期可能会受什么影响 比如?
生命周期相关的是Lifecycle
组件,去掉DataBinding livedata对生命周期不会有任何影响的。
from mvvm-architecture.
生命周期这一块,以后可能会麻烦些。 去掉DataBinding livedata以后 这个生命周期可能会受什么影响 比如?
生命周期相关的是
Lifecycle
组件,去掉DataBinding livedata对生命周期不会有任何影响的。
见笑了,那么 还能做到数据驱动UI吗?看代码 还是通过找到相应的id设置属性或者值。
from mvvm-architecture.
之前一直在使用RxJava,最近在项目中使用了databinding+livedata,实践中也遇到了一些问题,虽然最终都找到办法解决了,但是总感觉不是最佳实践的方式,看到你上面的解答,发现确实RxJava能处理应付的场景还是要多很多,正如Google官方解释的那样,已经上手RxJava的开发者,继续使用RxJava会是更好的选择
如果您已经习惯了RxJava
的**,RxJava
毫无疑问是项目中代码组织的强有力武器,但是坦诚的说,协程确实学习成本更低、对于不熟悉RxJava
的开发者而言 协程 代码可读性也更强,因此 协程 也是一个不错的选择。
感谢你的回复,我已经将我最新的理解在 6楼进行了补充更新,开发者应该根据自身情况选择合适自己的工具。 🤝
from mvvm-architecture.
之前一直在使用RxJava,最近在项目中使用了databinding+livedata,实践中也遇到了一些问题,虽然最终都找到办法解决了,但是总感觉不是最佳实践的方式,看到你上面的解答,发现确实RxJava能处理应付的场景还是要多很多,正如Google官方解释的那样,已经上手RxJava的开发者,继续使用RxJava会是更好的选择
如果您已经习惯了
RxJava
的**,RxJava
毫无疑问是项目中代码组织的强有力武器,但是坦诚的说,协程确实学习成本更低、对于不熟悉RxJava
的开发者而言 协程 代码可读性也更强,因此 协程 也是一个不错的选择。感谢你的回复,我已经将我最新的理解在 6楼进行了补充更新,开发者应该根据自身情况选择合适自己的工具。 🤝
赞同你的看法,我也在关注协程的发展,其目前也越来越稳定,非常期待能在这个项目中看到你对livedata+协程的实践探索 😊
from mvvm-architecture.
是否有计划更新下retrofit2.6.0对suspend的支持?
from mvvm-architecture.
是否有计划更新下retrofit2.6.0对suspend的支持?
协程很不错,但是现有的框架中已经有了RxJava
,我个人认为RxJava
比协程更优秀,目前为止,协程能实现的功能RxJava
都能实现,反之则不行,因此我暂时不会考虑使用它。
from mvvm-architecture.
请问一下,每一个Model里面的ModelFactory相关代码都是手写的么。还是用模板写的呀
from mvvm-architecture.
请问一下,每一个Model里面的ModelFactory相关代码都是手写的么。还是用模板写的呀
模版手写都可以,模版已经配置好了:
from mvvm-architecture.
你好 最近的 一些思考 希望能一起交流
我目前的框架改造成这样
1 rxandroid +okhttp =负责获取数据 同时 负责监听view生命周期 在销毁的时候 不会发出请求
2 用携程的AutoDispose 解决rx 的泄漏问题
3 然后在自己的viewmodel 做了以下事情:
1 首先按照页面或者 功能模块来划分 职责 比如首页 HomeViewModel 会员 MermViewModel
2 最开始 我的viewmodel 就是一个普通的类
3 用于功能的函数入参和调用 比如login 同时我 在接受回来的参数的采用了消息机制来进行数据的更新通知 之前是用的evenbus 现在采用 liveeventBus 有点类似 livedata 的角色功能 但是不仅仅是
因为我有时候需要跨组件进行通知
4 因为用了databing 的原因 我还在viewmodel 里面封装了一些参数的改造和逻辑的处理 。但是我是在页面上接受到参数 在去调用 viewmodel 的DataChange() 然后返回处理进行databing 的set
5 如果我的viewmodel 真的要做数据的持有我大可不必用官方的
4 一些问题 :
1 不管是 什么消息的发送 传递数据 那么页面上不可避免的会在view 上进行很多注册接受消息的地方
目前我有一个页面 写了8个消息注册和处理 用的是eventbus 感觉不好 但是这部分代码又无法省略
2 databing 没有想象的那么强大和好 他只是帮你省略了一些工作我感觉 比如在控件上的显示隐藏 我会引入工具类 来进行判断 和settext 背景 样式 但是如果说我需要根据不同的状态显示不通的图片 你只能吧这个代码写到view 里面 然后如果你用只能用3元表达式进行一些比较简单的判断 其他的 我暂时我还没感受到
3 至于其他的 RxPermissions 感觉还是不错 rxbin 感觉有点不能满足需求
4 至于dagge2 我目前看不到他有很大的必要使用在我的项目 ;
rx 的就感觉像Promise 很像 一个一个任务的数据流水线的去执行 也可以任务失败就终止 ,最后我发觉协程确实可以解决很多问题 。
from mvvm-architecture.
你好 最近的 一些思考 希望能一起交流
我目前的框架改造成这样
1 rxandroid +okhttp =负责获取数据 同时 负责监听view生命周期 在销毁的时候 不会发出请求
2 用携程的AutoDispose 解决rx 的泄漏问题
3 然后在自己的viewmodel 做了以下事情:
1 首先按照页面或者 功能模块来划分 职责 比如首页 HomeViewModel 会员 MermViewModel
2 最开始 我的viewmodel 就是一个普通的类
3 用于功能的函数入参和调用 比如login 同时我 在接受回来的参数的采用了消息机制来进行数据的更新通知 之前是用的evenbus 现在采用 liveeventBus 有点类似 livedata 的角色功能 但是不仅仅是
因为我有时候需要跨组件进行通知
4 因为用了databing 的原因 我还在viewmodel 里面封装了一些参数的改造和逻辑的处理 。但是我是在页面上接受到参数 在去调用 viewmodel 的DataChange() 然后返回处理进行databing 的set
5 如果我的viewmodel 真的要做数据的持有我大可不必用官方的
4 一些问题 :
1 不管是 什么消息的发送 传递数据 那么页面上不可避免的会在view 上进行很多注册接受消息的地方
目前我有一个页面 写了8个消息注册和处理 用的是eventbus 感觉不好 但是这部分代码又无法省略
2 databing 没有想象的那么强大和好 他只是帮你省略了一些工作我感觉 比如在控件上的显示隐藏 我会引入工具类 来进行判断 和settext 背景 样式 但是如果说我需要根据不同的状态显示不通的图片 你只能吧这个代码写到view 里面 然后如果你用只能用3元表达式进行一些比较简单的判断 其他的 我暂时我还没感受到
3 至于其他的 RxPermissions 感觉还是不错 rxbin 感觉有点不能满足需求
4 至于dagge2 我目前看不到他有很大的必要使用在我的项目 ;rx 的就感觉像Promise 很像 一个一个任务的数据流水线的去执行 也可以任务失败就终止 ,最后我发觉协程确实可以解决很多问题 。
rx适合多任务处理的场景,看业务需求,一般项目里协程就能解决的场景可能要多些,我觉得可以尝试两者搭配着来
from mvvm-architecture.
支持你去掉databinding,除了bug的问题外,其实以下这些方面也是考虑的因素:后期代码维护,热补丁,app的编译大小,闪退快速定位等等,都是datebinding可能存在的潜在的风险;
from mvvm-architecture.
DataBinding的一些思考
我使用过的MVVM
1.Web端 Angular+RxJS 算是强制吧UI数据绑定代码写在HTML里面 类似于 data binding
2.iOS端 Swift + RxSwift,目前是UI数据绑定代码写在Controller里面的,可能未来SwiftUI成熟了 支持在SwiftUI界面布局代码里面直接写UI数据绑定代码吧
3.Xamarin.Form C#+原生响应代码 Xamarin.Form是原生支持MVVM的 和databinding 类似 UI数据绑定的代码是强制写在XML布局代码里面的
所以 我觉得就是2个方案 一个是UI数据绑定代码写在布局文件XML里面。另一个方案是在代码里面获取UI的reference,然后在代码里面进行UI和数据的绑定。我觉得两种都可以把,具体看个人喜好
from mvvm-architecture.
不知道什么时候能看到大佬的databinding+livedata+协程版本
from mvvm-architecture.
不知道什么时候能看到大佬的databinding+livedata+协程版本
LiveData+Coroutine
版本已经出来了呀,databinding
的话应该不会加进去了,不过这个组件比较独立,添加起来很方便,直接在xml
中使用ViewModel
的LiveData
属性就可以了。
from mvvm-architecture.
移除DataBinding 的原因是?
from mvvm-architecture.
移除DataBinding 的原因是?
对于大体量的项目而言,DataBinding的「魔法糖」是毒药(我觉得魔法糖比语法糖更适合形容它)。
对此,你可以参考南尘的 这篇文章, 随着业务复杂度的指数级上升,DataBinding最终会成为限制项目架构的瓶颈,同时多人开发模式下也会面临滥用的问题。
from mvvm-architecture.
Databinding XML里逻辑IDE没什么检查提示,逻辑很难找不喜欢
Butterknife 模块化 R2 问题,还有编译期生成类IDE查找时候不喜欢
还是kotlinx,真香
from mvvm-architecture.
有个小问题想请教一下大佬,为什么_stateLiveData每次post的时候都使用copy而不直接创建一个新的对象,不改变的值使用默认值
from mvvm-architecture.
如果把livedata的移除了,这个架构就失去了意义
因为MVVM架构中,
RxJava
比LiveData
更适合作为观察者模式的组件,LiveData
唯一比RxJava
的优势就是原生支持DataBinding
,而如果移除了DataBinding
,LiveData
对于集成了RxJava
依赖的项目来说意义不大,因此我决定在后面的版本中移除LiveData
。我们来看看Google官方的描述:
我们可以看到,无论是Room还是Paging等其它官方组件,Google官方还额外提供了
RxJava
响应式的额外原生支持,这本身就说明了RxJava
的肯定,如果RxJava
作为三方库有缺陷或者说LiveData
本身就比RxJava
更优秀,参考
dagger
,其本身就是优秀的,但是dagger2
,这也正是体现了因此,我完全有理由去站队
RxJava
,正如我所说的:因为目前来看,离开了DataBinding,LiveData和RxJava相比没有任何优势。
2019/6/12 补充
我对自己学习的思路是,不断学习优秀的代码,保持对自己代码的怀疑,并督促自己对现有代码的优化。
我在日志中提出了 “离开DataBinding,LiveData毫无意义“,实际上在最近的学习中,我发现我的这个观点是片面、不成熟的,因为作为异步的实现思路之一, 协程 越来越成熟了,因此LiveData + 协程也是一个不错的MVVM的实现方式。
现在,我重新组织自己的语言,移除LiveData的原因应该是:因为项目中使用RxJava作为异步代码的组织者(而不是协程),因此暂时移除了LiveData。😃
liveData最重要的其实是生命周期.使用他可以减少太多内存泄漏了
from mvvm-architecture.
你好 最近的 一些思考 希望能一起交流
我目前的框架改造成这样
1 rxandroid +okhttp =负责获取数据 同时 负责监听view生命周期 在销毁的时候 不会发出请求
2 用携程的AutoDispose 解决rx 的泄漏问题
3 然后在自己的viewmodel 做了以下事情:
1 首先按照页面或者 功能模块来划分 职责 比如首页 HomeViewModel 会员 MermViewModel
2 最开始 我的viewmodel 就是一个普通的类
3 用于功能的函数入参和调用 比如login 同时我 在接受回来的参数的采用了消息机制来进行数据的更新通知 之前是用的evenbus 现在采用 liveeventBus 有点类似 livedata 的角色功能 但是不仅仅是
因为我有时候需要跨组件进行通知
4 因为用了databing 的原因 我还在viewmodel 里面封装了一些参数的改造和逻辑的处理 。但是我是在页面上接受到参数 在去调用 viewmodel 的DataChange() 然后返回处理进行databing 的set
5 如果我的viewmodel 真的要做数据的持有我大可不必用官方的
4 一些问题 :
1 不管是 什么消息的发送 传递数据 那么页面上不可避免的会在view 上进行很多注册接受消息的地方
目前我有一个页面 写了8个消息注册和处理 用的是eventbus 感觉不好 但是这部分代码又无法省略
2 databing 没有想象的那么强大和好 他只是帮你省略了一些工作我感觉 比如在控件上的显示隐藏 我会引入工具类 来进行判断 和settext 背景 样式 但是如果说我需要根据不同的状态显示不通的图片 你只能吧这个代码写到view 里面 然后如果你用只能用3元表达式进行一些比较简单的判断 其他的 我暂时我还没感受到
3 至于其他的 RxPermissions 感觉还是不错 rxbin 感觉有点不能满足需求
4 至于dagge2 我目前看不到他有很大的必要使用在我的项目 ;rx 的就感觉像Promise 很像 一个一个任务的数据流水线的去执行 也可以任务失败就终止 ,最后我发觉协程确实可以解决很多问题 。
你好 最近的 一些思考 希望能一起交流
我目前的框架改造成这样
1 rxandroid +okhttp =负责获取数据 同时 负责监听view生命周期 在销毁的时候 不会发出请求
2 用携程的AutoDispose 解决rx 的泄漏问题
3 然后在自己的viewmodel 做了以下事情:
1 首先按照页面或者 功能模块来划分 职责 比如首页 HomeViewModel 会员 MermViewModel
2 最开始 我的viewmodel 就是一个普通的类
3 用于功能的函数入参和调用 比如login 同时我 在接受回来的参数的采用了消息机制来进行数据的更新通知 之前是用的evenbus 现在采用 liveeventBus 有点类似 livedata 的角色功能 但是不仅仅是
因为我有时候需要跨组件进行通知
4 因为用了databing 的原因 我还在viewmodel 里面封装了一些参数的改造和逻辑的处理 。但是我是在页面上接受到参数 在去调用 viewmodel 的DataChange() 然后返回处理进行databing 的set
5 如果我的viewmodel 真的要做数据的持有我大可不必用官方的
4 一些问题 :
1 不管是 什么消息的发送 传递数据 那么页面上不可避免的会在view 上进行很多注册接受消息的地方
目前我有一个页面 写了8个消息注册和处理 用的是eventbus 感觉不好 但是这部分代码又无法省略
2 databing 没有想象的那么强大和好 他只是帮你省略了一些工作我感觉 比如在控件上的显示隐藏 我会引入工具类 来进行判断 和settext 背景 样式 但是如果说我需要根据不同的状态显示不通的图片 你只能吧这个代码写到view 里面 然后如果你用只能用3元表达式进行一些比较简单的判断 其他的 我暂时我还没感受到
3 至于其他的 RxPermissions 感觉还是不错 rxbin 感觉有点不能满足需求
4 至于dagge2 我目前看不到他有很大的必要使用在我的项目 ;
rx 的就感觉像Promise 很像 一个一个任务的数据流水线的去执行 也可以任务失败就终止 ,最后我发觉协程确实可以解决很多问题 。rx适合多任务处理的场景,看业务需求,一般项目里协程就能解决的场景可能要多些,我觉得可以尝试两者搭配着来
dagger是为了减少模板代码,以及方便测试用的
rx的线程切换只是基操,好用的地方还是各种操作符,写成简单易用,但是你要做个比如500ms内最新的一次搜索,你想想用协程好做么,要写多少样板
from mvvm-architecture.
Related Issues (20)
- sharedpref读取问题 HOT 1
- 大佬看下QQ邮件哦
- 无网络情况下请求接口闪退 HOT 5
- 网络请求 HOT 1
- 大佬 buildSrc 依赖配置是怎么实现。求赐教 HOT 1
- 首页列表上下滑动时好卡啊 HOT 2
- 登陆退出 HOT 2
- 可以加入开发行列一起丰富这个框架吗 HOT 2
- master分支代码爆红 HOT 2
- 【关于】作者本人对这个MVVM项目的定位是什么? HOT 2
- 登陆 HOT 2
- 登录返回401,Unauthorized HOT 2
- com.google.protobuf plugin找不到的问题 HOT 1
- 关于状态管理的疑问 HOT 4
- ViewModelScope.launch HOT 1
- SSL peer shut down incorrectly HOT 1
- 关于gradle的插件 versionPlugin HOT 3
- 请教一个问题
- 升级viewmodel到2.3.0 升级lifecycle到2.2.0 ,在LoginViewModel中如果构造函数有参数时,就会提示这个错误,不知道怎么改,是代码要修改还是google版本的bug呢
- 大佬我写的列表库和网络请求完美支持MVVM给我个友链如何 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mvvm-architecture.