一款基于Kotlin+MVP+组件化的麻雀App

3,004 阅读6分钟

为什么叫麻雀

麻雀虽小,五脏俱全。

其实本app并不叫做麻雀,只是本人认为它比较符合麻雀的特点:小而全。

小,即轻量级,一是指app只专注于实现常见app基础的逻辑业务功能,并没有在某个功能点或者UI上做更为细节的实现;二是指app使用了简洁的的Kotlin语言作为实现语言,使用了相对简单的一种MVP实现方式,使用了一种比较轻量级的组件化方案。

全,当然是相对的,一是指app的后端也是本人开发,这能让整个业务逻辑更为全面,也能让感兴趣读者能更为全面的了解此app;二是指app涉及了当前技术趋势下安卓开发的多个技术点,包括kotlin,mvp,组件化,rxjava,retrofit等;三是指本app实际上可以作为一个快速开发框架,这主要得益于组件化的实现,具体怎么使用,后续会提到。

此app名字不叫麻雀,而是叫做KtDevBox。

仓库地址:

App实现-KtDevBox

后端实现-KtDevBox-backend

为什么要写这个app

诚然,网上关于Kotlin,MVP,组件化的研究、分享已经有很多,但是多数博客仅仅是泛泛而谈,代码库没有提供不说,博客中的代码甚至都有问题,有些更是抄来抄去。虽然有些好资源的确有挺好的借鉴意义,比如KotlinMvpReading等【本文仅着眼于项目级别实现,一些好的library并不在此讨论中】,但以下几点还是让我觉得有些不足:

  • 这些项目的接口,基本都是爬来的,大多数都是get方式实现,很难形成比较完整的一个功能逻辑,也很难从更全的角度去来展示某些技术点的实现;
  • Kotlin的使用,Java的味道较重,特别是网络请求的封装部分;
  • 组件化几乎没有涉及,项目是个app,并不能方便的转为另一项目的实现框架;
  • 文档等介绍略少

KtDevBox当然也存在的一些不足,但该项目的初衷,也仅做学习交流之用,以期对该方面技术的发展,起到一点点帮助。

为什么用Kotlin

仅说自己体会,至少有这几个原因吧:

  • 语言切换,对老手真不是问题,况且kotlin与java的兼容性很好,所以学习成本不应作为不使用kotlin的理由;
  • 真正摆脱了控件从布局到使用的查找问题,简洁明了;
  • 函数地位的提升,带来的编程思想的改变,对开发者开发思维是有提升的,当然,代码的灵活、更好的扩展是可视的效果;
  • 闭包、扩展函数、命名参数等语法糖带来的诸多便利。

为什么用MVP

有关MVP的讨论真是太多了,不过正如本人之前的博客提到,MVX不管怎么叫,核心在于分层,至于是C、P或是VM,要看项目自身情况来,甚至可以在同一项目中出现。本项目使用的是MVP的一种简化些的实现方式,至于好不好用,仁者见仁,这里只谈使用,不谈优劣,手动滑稽。再简略叨叨下MVP的发展吧,以表原因。

  • MVC中C重,于是功能转移,出现来了xxModel、xxLogic党,主要分担数据获取的职责;
  • C和xxModel的强依赖、空指针问题和内存泄露问题,促进了Presenter的出现,其主要处理业务逻辑,并绑定View的生命周期,面向接口,更为松耦合;此时C转为P。
  • 完全面向接口之后,难以避免的V和P接口爆炸,也过于分散,出现了Contract,人工约束,首见于github上谷歌的MVP官方示例。

个人认为,M结构相对很稳定,View并无太大必要通过持有P的接口引用去使用P,再者通过Contract的维护并不能真正降低接口太多造成的注意力分散问题。本项目app的MVP实现较为简单些,也是一种比较常见的方式,具体可阅读项目代码。

为什么用组件化

组件化是近两年才较为突出的一种项目管理实现方案,本人认为其符合基本的分而治之的思想,是同MVX一样,应该出现在任何一个打算长期维护的项目中的技术方案。其实,不仅在安卓端,在ios端、前端(Vue)、后端(Java、Python)都有组件化的使用。至于什么是组件化,组件化有什么好处以及如何实现,我想网上有太多优秀博客和开源库提及,这里就不再赘述。

本app虽然小,但也涉及了组件化,选择的是一种很轻量级、侵入性小的方案--Appjoint,方案虽然轻量级,但是本人认为:组件化思维,入侵性小、能在最初的时候将业务进行组件化管理是组件化的核心,而这个库很好的符合了要求。

主要功能点

  • 用户注册、登录以及资料管理功能;
  • 博客创建、更新、删除和查看等功能;
  • 博客的收藏、评论、点赞功能;
  • 爬了网易新闻和一些电台的接口以展示,主要做组件化演示。

项目架构

项目核心架构如图所示:

在这里插入图片描述

项目中的shell只含有MyApplication这一个类文件,目前app涉及的业务也仅usercenter和media这两个module,其中usercenter和module并无依赖关系。因此,此项目完全可以作为一个快速开发框架。简单做法:新建几个module编写自身的业务,仅需要被shell依赖,它们并不会受到原业务usercenter和module的影响。然后更改入口Activity之后,就是一个新项目,也不会被打包进apk中。更多组件化的使用可见Appjoint的介绍。

目录结构

每个组件和一般app的目录结构基本一致,主要多出了一个package,用来盛放与其它组件通信用到的类,项目中media组件有实例展示。

在这里插入图片描述

router库的结构如下图,其中每个组件都单独拥有一个package,里面分别盛放组件间通信的服务接口和共享的数据(组件通信数据实体类,或者面向json编程,手动哈哈,另一个话题)。

在这里插入图片描述

主要使用的第三方库

感谢:

本项目仅做学习交流之用。

仓库地址:

App实现-KtDevBox

后端实现-KtDevBox-backend

喜欢请记得Star一下。

后续还有更为详细的项目介绍。

最后,可能有些童鞋还对下面这张图感兴趣。不过,本文只谈技术,不谈“风月”,微笑。

在这里插入图片描述