这个library的名字，Mosby，是为了致敬著名电视连续剧 How I Met Your Mother 中的灵魂人物建筑师 Ted Mosby 。这个库的目的是帮助你用一个干净的Model-View-Presenter架构来构建先进的android应用程序。此外，Mosby通过引入 ViewState 和保留Presenters帮助您处理屏幕方向的更改。
这是一个library，而不是一个framework
乍一看Mosby看起来很像一个框架。有一些类你可以继承，例如 MvpFragment，但重点是，你不必非得这样做。Mosby的核心是一个基于委托（delegation）的很精简的库。所以如果你不想的话，你就不必使用 MvpFragment 。您可以使用委托（delegation）和组合（composition ）将Mosby整合到您自己的开发栈中。因此，你不会陷入使用框架的那些边边框框和限制。
入门
在 Mosby翻译(二) : 入门 部分，包含以下内容
- 一些简单的例子，教你如何使用Mosby建立基于MVP的程序。
- 因为Mosby也支持Kotlin，所以也会有一个简单的Kotlin例子。
- 您可能正在寻找由Mosby开发的真正的 app，那么您应该查看 第一个应用程序部分，这是一个复杂的电子邮件客户端应用程序。
依赖
Mosby被分为不同的模块。你可以从下面的依赖列表中选择你需要的模块：1
2
3
4dependencies {
compile 'com.hannesdorfmann.mosby:mvp:2.0.1'
compile 'com.hannesdorfmann.mosby:viewstate:2.0.1'
}
迁移到Mosby 2.0
在Mosby 2.0中，所有第三方依赖和库（例如 Butterknife 和 FragmentArgs）已被移除。这也意味着许多Mosby 1.0中的模块已经被移除，就像 core（包括 MosbyActivity 和 MosbyFragment）、dagger1 、modules 、retrofit 和 rx 。原因是这些第三方依赖关系导致了很多问题，所以他们不应该成为Mosby的一部分。
一个具体的例子是Mosby中集成了 Butterknife 。在Mosby 1.1.0 的 MosbyActivity 中使用了 Butterknife 6 的 Butterknife.inject() ，然后使用 Butterknife.bind() 替代 Butterknife.inject() 的 Butterknife 7 发布，所以我们把Mosby迁移到Butterknife 7并且发布了Mosby 1.2.0。
问题是使用Mosby的每个应用程序都必须将整个应用程序迁移到Butterknife 7，以便升级到Mosby 1.2.0以及将来可能包含错误修正和改进的Mosby版本。这在任何时候都可能发生任何第三方库上，例如retrofit 从1.9.0升级到2.0.0。这就是为什么我们要删除所有第三方库，以及虽然其他开发者发现很有用但是依赖于第三方库的Mosby模块（例如dagger1 的集成）。我们建议您（或您的团队）为每个应用程序构建这样的“基类”，以便根据应用程序决定要使用的第三方库以及何时将这些库升级到更新的可用版本。您可以检出 v1.x分支 并手动将这些需要的类复制到您的应用程序仓库中。对于这可能造成的任何不便，我们深表歉意，但我们确信这有助于我们避免将来出现的问题，并将重点放在Mosby是一个MVP库而不是一个臃肿的框架上。
