JessYan

看commit日志

什么意思，没懂

你的最后一个问题，很简单，在 ResponseErrorListener 的 handleResponseError 中就可以全局处理所有错误逻辑，也就是项目中使用了 ErrorHandleSubscriber 的地方发生错误都会走到你定义的逻辑，不用每个接口都写一遍逻辑 但是第一个问题是无法实现的，因为 onError 中只能拿到的是 Retrofit 抛的 Exception，Retrofit 抛的这个 Exception 里面包装了什么信息，不是我能决定了，是 Retrofit 决定的，它不把 URL 或者请求头，放 Exception 里，我也没什么办法

可能是混淆的问题，不要混淆这个文件

https://github.com/JessYanCoding/MVPArms/issues/358

谢谢你写这么多，我在常用 [**Issues**](https://github.com/JessYanCoding/MVPArms/wiki/Issues#11) 中已经说了，重用 **Presenter** 和 重用 **Model** 都没问题，包括你重用 **Contract** 也没问题，但是不可能每个业务逻辑都是一样的，有的复杂有的简单，所以没有一个可以统一并且完美的解决方案，在逻辑简单的页面重用上面说到的任何类都没问题，但如果在逻辑复杂或者变更特别频繁的地方就应该使用独立的几个类来处理，我只提供工具和脚手架，实际开发中只有你们自己按照自己的需求和实际情况灵活使用才能真正的发挥 **Arms** 的价值做好一个完美的软件 **因为没有完美的解决方案，所以对任何情况都统一使用同一种解决方案都是愚蠢的**，只有在不同情况下使用不同解决方案，发挥每个解决方案的长处才能尽可能的让软件完美，随机应变才是一个程序员解决问题的正确方向

所以我建议大家在社群里多讨论，说出自己的想法，哪怕有瑕疵，但任何对 MVP 的优化意见我都是欢迎的，所有人看到后都可以积极的去尝试，这才叫开源，但是我并不会将某个方案作为官方的指定的统一解决方案，原因上面也说了

我不完善 **Demo** 以展示更多情况无非有四点: 1. 我不希望 **Demo** 太过复杂，让任何一个刚刚接触 **Arms** 的人就望而生畏，上面说的这些问题都是熟练 **Arms** 并且开始大量使用到实际开发中才会遇到的 2. 我鼓励新手直接将 **Demo** 更改包名后直接作为开发的 **Module**，这样可以直接使用 **Demo** 的包结构，加快开发效率，所以不能让 **Demo** 太复杂，类太多，这样增加别人工作量 3. 向我上面说的一样没有一个可以统一并且完美的解决方案，即使是我也不可能把所有情况考虑完整，所以 **Demo** 有最初级的使用方式就可以了，我不会官方的指定任何方案来约束复杂的情况，这样大家才能发挥自己想法随机应变，这才是成长 4. 我很忙优化框架已经占用我很多时间，多维护一个代码，都是需要从其他时间里挤出来的，所以我希望大家自己讨论 最后再重申 **Demo** 的所有内容只是为了展示并不是让大家必须按照 **Demo**...

@Yanqilong 我建议 **reopen** 这个 **issues**，在你的方案和我的回答之上大家一起讨论更多可行的方案

@androidSWY 兄弟，行动上支持一下！