Skip to content
This repository has been archived by the owner on Feb 25, 2019. It is now read-only.

Discuss #2

Open
xiaobailong24 opened this issue Aug 14, 2017 · 27 comments
Open

Discuss #2

xiaobailong24 opened this issue Aug 14, 2017 · 27 comments
Assignees

Comments

@xiaobailong24
Copy link
Owner

如果有什么想法或者建议,可以随时交流。欢迎大家一起贡献。
Welcome to communicate and discuss.

@xiaobailong24 xiaobailong24 self-assigned this Aug 16, 2017
@JessYanCoding
Copy link
Collaborator

First 😃

@JakeWoki
Copy link

LiveData和rxjava用一个就行了,官方说明
Note: If you are already using a library like RxJava or Agera, you can continue using them instead of LiveData. But when you use them or other approaches, make sure you are handling the lifecycle properly such that your data streams pause when the related LifecycleOwner is stopped and the streams are destroyed when the LifecycleOwner is destroyed. You can also add the android.arch.lifecycle:reactivestreams artifact to use LiveData with another reactive streams library (for example, RxJava2).
很多东西不应该放到库里,比如eventbus、glide、cardview、recyclerview等,最好是databinding、lifecycle和ViewModel的封装做为一个库,在这个基础上再加上rxjava和retrofit做为另一个库,其它的没必要加入库中

@xiaobailong24
Copy link
Owner Author

@JakeWoki 感谢。
上面那个官方说明我也看过,一开始是RxJava用习惯了,还有个作用是线程切换比较方便。正在考虑移除RxJava,更好地使用LiveData。
关于第二个,一开始做的想法是有助于新项目快速上手开发。但是你说的很有道理,接下来看看怎么拆分一些不必要的模块。

@alittlecup
Copy link
Collaborator

@JakeWoki 个人觉得 RxJava和LiveData并不冲突,说一下我的理解,在Model中使用Rxjava,然后在返回到ViewModel中的时候转化为LiveData。

@alittlecup
Copy link
Collaborator

`@FragmentScope
public class WeatherNowViewModel extends BaseViewModel
implements IRetry {
private final LiveData<List> mContents;
private MutableLiveData locationName = new MutableLiveData<>();
private String mLocationName = "";

@Inject
public WeatherNowViewModel(Application application, WeatherNowModel model) {
    super(application, model);
    mContents = Transformations.switchMap(locationName, input -> Transformations.map(getWeather(input), newResource -> {
        if (newResource == null) {
            newResource = Resource.error("", null);
        }
        Timber.d("Load weather now: %s", newResource.status);
        if (newResource.status == Status.LOADING) {
            STATUS.set(Status.LOADING);
        } else if (newResource.status == Status.ERROR) {
            STATUS.set(Status.ERROR);
        } else if (newResource.status == Status.SUCCESS) {
            List<TextContent> contents = new ArrayList<>(3);
            WeatherNowResponse.NowResult result = newResource.data.getResults().get(0);
            contents.add(new TextContent("地点", result.getLocation().getPath()));
            contents.add(new TextContent("天气", result.getNow().getText()));
            contents.add(new TextContent("温度", result.getNow().getTemperature() + "º"));
            STATUS.set(Status.SUCCESS);
            return contents;
        }
        return null;
    }));
}

public void loadWeatherNow(String mLocationName) {
    locationName.setValue(mLocationName);
}

private LiveData<Resource<WeatherNowResponse>> getWeather(String mLocationName) {
    Map<String, String> request = new HashMap<>(4);
    request.put(Api.API_KEY_KEY, Api.API_KEY);
    request.put(Api.API_KEY_TEMP_UNIT, "c");
    request.put(Api.API_KEY_LANGUAGE, "zh-Hans");
    request.put(Api.API_KEY_LOCATION, mLocationName);
    return mModel.getWeatherNow(request);

}`

这个是我项目里面目前的写法,参照的是这个FlexbleViewModel,想法的就单一的改变一个响应对象,然后一整套响应式动作到UI

@alittlecup
Copy link
Collaborator

还有一个想要交流的地方就是,其实MVVM并不是一个完成的架构,它只是在UI或者说是在Android项目层面提供一个解决方法,主要的功能还是分离View 和 ViewModel,但是这两天我重构代码的时候发现,其实这么写之后大部分的代码还是会堆积到ViewModel中,是不是应该在ViewModel中再分离出一部分放到Model中,比如业务逻辑,ViewModel只是进行渲染UI和接受UI事件。

@JakeWoki
Copy link

JakeWoki commented Nov 24, 2017

@alittlecup 你这个只用了LiveData吧,如果真是rxjava,switchMap用map之类就可以转换了,MVVM一般还要加一个Navigator,还是参考这个吧tivi,不过感觉也不是很标准,官方给的那个框架使用上感觉也不是特别好

@alittlecup
Copy link
Collaborator

上面那个例子中使用RxJava的地方是在Model中,ViewModel中只有LiveData

@JakeWoki
Copy link

JakeWoki commented Nov 24, 2017

所以说不是很标准啊,RxJava用在Model是错误的

@JessYanCoding
Copy link
Collaborator

我说下我的看法, Android 架构组件除了 Room, 源码我全部认真的看完了, LiveData 相比于 Rxjava, 真的是太简陋了, LiveData 是和官方的 生命周期组件 结合使用的, 如果除去这个 生命周期组件, 那这个 LiveData 仅仅是一个简单的观察者模式, 功能就是调用 setValue(T) 遍历通知之前注册的所有观察者, 就算加了生命周期组件, 也仅仅是与 Activity 或 Fragment 的生命周期做绑定, 达到在生命周期改变时停止和恢复事件的功能, 这相比于 Rxjava 没有任何优势, Rxjava 强大的操作符完爆他, 加上 RxLifecycle 也可以达到一样的功能, 并且 RxLifecycle 也适配了 生命周期组件, 可以直接使用 生命周期组件, 如果是 LiveDataRxJava 只能用一个我没有任何理由使用 LiveData, 他能做的事 Rxjava 都能做, 他不能做的事 Rxjava 也能做, 并且 Rxjava 不仅仅是 Rxjava, 他是一个生态链, 他还有 Retrofit RxLifecycle RxAndroid 等很多强大的衍生库, 我们离开他做很多事都非常不方便, LiveData 能给我带来什么?

@JessYanCoding
Copy link
Collaborator

JessYanCoding commented Nov 24, 2017

LiveDataRxjava 一起使用, 我并不反对, 也许我没在项目中使用过 MVVM 我不了解 LiveData 有什么不可替代, 非他不可的需求场景, 但我觉得 ViewModel 或者 Model 中都返回一个 Observable, 调用者只用继续在这个数据流中继续处理后续的操作就可以完成的需求, 为什么要一边返回 LiveData 一边返回 Observable, 然后在他们之间相互转换来完成需求, 多做的这些操作, 是为了使用 LiveData 而使用 LiveData , 还是真的 LiveData 相比于 Observable 在处理数据流方面有优于 RxJava 的绝大优势? 如果没有, 那只使用 Rxjava 有何不可?

@JakeWoki
Copy link

如果用rxjava,也用LiveData,我觉得LiveData只用于ObservableField或ObservableBoolean之类的变化监听

@JessYanCoding
Copy link
Collaborator

JessYanCoding commented Nov 24, 2017

以上是我自己的拙见, 我也没在项目中实际使用过 MVVM, 只是在自己的 MVPArms 框架中考虑集成并尝试修改 Android 架构组件中部分源码已达到自己的需求时, 对源码进行了深层次的研究, 有什么说的不对的地方望指正

@JakeWoki
Copy link

JakeWoki commented Nov 24, 2017

MVP不做出模板的话,是不好用的

@JessYanCoding
Copy link
Collaborator

@JakeWoki 什么模版

@JakeWoki
Copy link

Moxy
参考这个的moxy-templates

@JessYanCoding
Copy link
Collaborator

JessYanCoding commented Nov 24, 2017

@JakeWoki 哦, 我有, 根据包名一键生成整个新项目也在 开发中

@alittlecup
Copy link
Collaborator

说一下我的看法,首先LiveData仅仅就是一个LiveData,作用就是上面说的那些,是在Rx强大的操作符下,LivaData的只有两个操作符显得毫无作用,但是这就是LivaData,它不需要也没有必要去拥有别的更多的功能,它只要做好生命周期响应通知数据就可以了。然后说Rx,作为响应式的流操作它的强大无可厚非,但是我觉得它应该做的也是一个流操作,而不应该掺杂其他的东西,就是良好的线程控制和强大的数据操作,那为什么我要在数据的操作过程中去关心数据的生命周期?其实在我的理想架构中,LiveData和Rx是能够相处的十分融洽的,VM中使用LivaData,Model中使用Rx,把所有的业务逻辑,数据的获取,保存,处理都放在Model层,VM层只有两个功能根据数据去渲染UI,而是接受UI输入去获取数据。那LiveData在VM中能完美发挥,并且Rx也能在Model中展现出强大的实力。说RxLifecycle,只是对Android的妥协

@JakeWoki
Copy link

JakeWoki commented Nov 24, 2017

Rxjava和LivaData一起使用,LivaData适合响应通知,不适合转换

@JessYanCoding
Copy link
Collaborator

JessYanCoding commented Nov 24, 2017

你可能想的过度完美, 像你说的 LivaData 只相当于有两个操作符的功能, 如果 ViewModel 中只有 LiveData, 是可以的, 但 ViewModel 中哪怕不处理数据, 只通知 Ui 也会夹杂着很多其他的逻辑, 比如说频繁点击的过滤, 定时, 以及一些对数据无关但是对于 UI 有关, 并且 DataBinding 又做不到的逻辑, 所以 ViewModel 只有你说的这两个功能完全是你自己想象的, 是不切实际的, 完成这两个功能之前就肯定有一些其他的逻辑需要加入, 这时 LiveData 对这些逻辑的处理没有任何帮助, 所以必须自己去写一些大量的逻辑, 但是 Rxjava 的强大的操作符就可以轻松完成这些操作, 为什么我们还要自己写呢
另外你对 Rxjava 的理解也是错的, Rxjava 代表的是 响应式, 函数式 等思想的实现, 切换线程和数据流的操作只是他附带的功能以及特点, 并不代表他的全部, 所以把他用在数据的处理还是 UI 逻辑的处理是没有任何关系和限制的, 用它并不代表我只是想处理数据流, 而是使用一个思想, 而官方为什么建议他们之中只使用一个, 也是因为他们都是基于观察者模式, 只是 Google 赋予 LiveData 通知 UI 的能力, ReactiveX 赋予 RxJava 更强大的操作符和切换线程的能力, 而他们所基于的思想能做什么事是没有任何限制的, 不过是被传统的方式, 被别人的思想灌输久了, 本能的觉得这个只能做什么事, 那个只能做什么事,这样思想也被牢牢的限制在某个思维模式下, 这也是看一个事物, 没看透本质的表现

@alittlecup
Copy link
Collaborator

我理解并尊重你的想法,没有一个完美的架构能够解决所有的问题,大家都是在为了同一个目标前进并努力着。我十分同意你的后半段

另外你对 Rxjava 的理解也是错的, Rxjava 代表的是 响应式, 函数式 等思想的实现, 切换线程和数据流的操作只是他附带的功能以及特点, 并不代表他的全部, 所以把他用在数据的处理还是 UI 逻辑的处理是没有任何关系和限制的, 用它并不代表我只是想处理数据流, 而是使用一个思想

想了一下,确实是我的想法有些片面,一个强大的工具可以在任意地方发挥它的作用。

但是我还是要那个完美的场景去尝试,努力,寻求一个个恰当的解决方案。

@JessYanCoding
Copy link
Collaborator

JessYanCoding commented Nov 24, 2017

是的, 我也认同你的看法, 没有完美的解决方案, 不过是在没有更好的解决方案之前, 对一些事物的妥协, 找到一个适合自己的解决方案, 我上面也是说了, 我只是发表下我自己的看法, 我没有在实际的场景使用过, 也是自己片面的理解, 所以大家可以一起讨论, 大家如果都有收益, 那也是极好的, 如果有言语之中有冒犯到, 还请见谅🙏

@alittlecup
Copy link
Collaborator

对,其实你后面说的是对的,赋予的是能力而不是具体的使用方式,我们可以用这种能力去做某些事情,但并不是仅仅的局限在这些事情上面,是我理解的不够

@JessYanCoding
Copy link
Collaborator

JessYanCoding commented Nov 24, 2017

@alittlecup 因为我个人喜欢做一些和传统解决方式不同的解决方案, 我们站在巨人的肩膀上没错, 但是我们要学会在巨人肩膀身上成长, 而不只是乘凉, 更不能局限于巨人的思维之下, 没有创新就没有进步

@xiaobailong24
Copy link
Owner Author

LiveData的一个优势是不需要关心View,是数据驱动UI,所以内存泄漏的问题可以避免。

@ditclear
Copy link

ditclear commented Dec 8, 2017

liveData的功能跟 RxJava和DataBinding都有点重合,但前者并非不可替代,所以我更偏向于使用后者,更习惯,而且功能更强大

@colryzen
Copy link

还有一个想要交流的地方就是,其实MVVM并不是一个完成的架构,它只是在UI或者说是在Android项目层面提供一个解决方法,主要的功能还是分离View 和 ViewModel,但是这两天我重构代码的时候发现,其实这么写之后大部分的代码还是会堆积到ViewModel中,是不是应该在ViewModel中再分离出一部分放到Model中,比如业务逻辑,ViewModel只是进行渲染UI和接受UI事件。

文档有建议复杂的业务需要抽离到Presenter 类,减少ViewModel 的大小

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants