MVPArms
MVPArms copied to clipboard
JessYanCoding
JessYan: 意见收集 😘，请进 QQ 群: 455850365
谢谢！整合了好多新兴技术，加法做了好多，什么时候做做减法呢？
JessYan 回复: Arms v2.5.0 版本开始, 已经在拆分 Arms 中非必须的库, 并且通过扩展库的方式，保证对旧版本的完美兼容，现在已经拆分了 support-design、AndroidEventBus、Glide、AndroidAutoLayout 等库，这样的好处是使框架使用者可以自由的选择某种类型的三方库，还可以减轻 Arms 的体积，后面还将继续对 Arms 进行拆分，让 Arms 的扩展性更强，体积更轻，新增的功能或库，也将采用 接口 + 扩展库 的方式进行集成
@JessYanCoding 牛逼的不要不要的。看了那么多RxJava、MVP、Retrofit等等的文章和例子，如今终于可以整合了！感谢无私分享，正在学习，准备使用本框架重构旧项目。
@ReepicheepRed BaseApplication 通过 AppDelegate 来做一些框架需要的操作,就是为了让开发者不是必须要继承 BaseApplication, AppDelegate 可以让开发者很方便的自定义一些可以满足自己需求的 Application,并且也不会影响到框架的运行,你的想法是站在 App 开发的角度, 需要框架很方便的实现自己的需求, 我站在框架设计的角度,要满足每个开发者每个 App 的需求是不可能做到的,所以我要做的是提供扩展的方式,让开发者能根据自己的需求自己去扩展,而不是一味的满足每个人的需求,这个是恶性循环,你需要 MultiDexApplication ,其他人可能并不需要,人家为什么要为了方便你的需求,而去被迫继承一个自己并不需要的 Application ,这个对于别人来说是不划算的事
有木有相对简单的mvp模式demo，这个看着有些蒙蔽，熟悉点的只有rxjava,retrofit..。。看引用了很多的框架，，要一个一个学习再学习你在这个哇
@zhou9527 不管是 MVP ,还是 RxJava ,以及 Retrofit 和 Dagger , Github 简单的 Demo 真的太多,一搜一大堆,你就自己找吧,就是因为 Github 上大部分的此类型 App 或 Demo ,写的是在太简单了,所以我才写的这个框架属于进阶版,这个框架自动屏蔽没入门的朋友,因为你没入门根本看不懂,更说明你可成长的空间非常大,这时候你应该感到焦虑而更努力的自己主动去学,这些技术已经不算最火的技术了,我 16年 初就把这个框架写出来了,大部分人都会,大部分人都会的东西,而你不会,那无论面试还是工作肯定会有些许劣势,但现在这个时候才去学也不晚,你也有好处,那就是现在这方面的资料真的太多了,坑被踩完了,学习起来非常快,所以别问我了,直接花时间去硬啃
@hxlailfh1314 现在框架不是强制使用 AndroidAutoLayout ,不声明 Androidmanifest 中的 meta,就不会使用, AndroidAutoLayout 虽然不维护了,但是并不代表他没有价值,依然有很多项目在使用它,带来了很多便利,作为使用两年的老用户,也并没遇到什么大的 Bug ,在某些使用场景使用起来非常愉快,所以暂时不会移除,以后看情况再做打算,如果你不喜欢用,可以不声明 meta
框架上少引用了“com.squareup.retrofit2:converter-scalars:2.3.0” 所以不能支持返回参数是 String 类型。 不知道你这边 是否考虑加上这个。
@hxlailfh1314 框架已经提供了 Retrofit 和 Okhttp 扩展参数的方式, 你自己引用, 自己使用就好了, 框架只需要让开发者能够按需扩展自己的需求, 而不需要自己去满足所有人的需求, 这就是框架作者和 App 开发者思想上最大的差别
想问个问题哦，发现MVPArms更新迭代蛮快的，但是好像没有向下兼容，当依赖的新版本的时候，会造成很多兼容性问题。有的时候想更新版本，又怕更新出问题
@yeyueduxing 集成化框架和其他功能性框架不一样, 功能性框架只是调用某些 API, 所以他可以很好的屏蔽一些风险, 但是集成化框架要复杂的多, 涉及到的方面远不是简单的调用几个 API 这么简单, 发布新版本时我也是尽量做到不影响旧版本, 在一些做了更改会影响到旧版本更新的地方, 我也在 更新日志 给出了详细的批注以及减小升级成本的方式, 我公司一个十几个模块几百个页面的组件化项目是直接远程依赖 Arms 的, 我每次也都是第一时间升级最新版本, 所以我心里是清楚升级最新版本所花费的成本的, 基本上我这个几百个页面的大项目升级的时间都是在半个小时以内, 大多都是几分钟就搞定, 所以更新你大可不必太过担心, 我这个项目十几个模块几百个页面, 如果更新成本太大我这个项目也是受影响最严重的, 我不可能自己坑自己的, 后面的更新也都会很稳定的
@JessYanCoding 你好，关于UserActivity等所有的activity和fragment初始化有个建议：dagger2其实有新的方式来规避，（可以让基类实现baseactivity集成HasActivityInjector），这样一劳永逸！setupActivityComponent这个方法都可以不用再多次初始化，甚至都没必要了。后续所有集成基类的activity或者fragment，都已经有对应HasActivityInjector，HasSupportfragmentInjector的方法了。然hou维护一个androidinjection（是为了activity和fragment oncreate的时候吧它们对应的inject进来！）望采纳。
@kinzirva 谢谢你的建议, 关于 Dagger2 的新特性我也很久没关注了, 一直在忙别的东西, 第二个原因也是因为怕框架使用新的 特性 会影响之前的用户, 我后面会仔细研究下 Dagger2 以及 Dagger.Android 等新功能, 后续会推出
@JessYanCoding 有个小建议哈，其实咱后面，也可以来一版kotlin的项目。我个人现在对app团队要求就是新的业务场景使用kotlin来实现。毕竟是个趋势了。（搞个实验室项目，主要收集和拓展新的框架或者语言特性，像微信 Tinker和360 Repugin那样。研发人员参与进来有贡献就ok）
@kinzirva 你这个建议也是可以的, 但是这个框架, 目前来说基本上是我一个人来维护和迭代升级, 你看我每个月的提交记录也知道我从来就没休息过, 一直在完成自己对这个项目规划的一些目标, 所以在完成现有的一些规划之前, 实在抽不出时间搞其他实验版, 随着项目用户的增长, 我的压力也越来越大, 毕竟没有一个完美的框架可以应对所有用户的需求, 只有不断的用时间去做优化以及对一些东西做取舍框架才能更完美, 但这个推进的速度也许会很慢, 毕竟一个人的力量比不了那些专业团队
在FragmentDelegate类中，有直接插入这个initData方法用于展示数据和网络请求 @Override public void onActivityCreate(Bundle savedInstanceState) { iFragment.initData(savedInstanceState); } 但是，如果Fragment想使用懒加载，在setUserVisibleHint中进行判断的话，就只能重新写个网络请求和数据加载的方法了。所以这个方法是不是可以优化下呢
你不实现 initData(), 在 setUserVisibleHint() 中调用自己写的方法进行网络请求就可以了, 预设的方法只是为了规范, 并不强制你在当前的需求中一定会用到
@yeyueduxing 可以参考下 https://github.com/xiaobailong24/MVVMArms/blob/master/arms/src/main/java/me/xiaobailong24/mvvmarms/base/BaseFragment.java
也知道这个，就是Activity中使用initData,Fragment使用其他的，强迫症感觉不对啊(。・`ω´・)。也没啥事就是了，谢谢了啊