App 组件化/模块化之路——如何封装网络请求框架 在 App 开发中网络请求是每个开发者必备的开发库,也出现了许多优秀开源的网络请求库.例如 okhttp retrofit android-async-http 这些网络请求库很大程度上提高程序猿的编码效率.但是随着业务的发展,App 变得越来越大,我们将这些网络请求库加入到项目中直接使用,对我们业务类的入侵是非常强的.如果要进行业务分离时,这些网络请求代码将是一个阻止我们进一步工作的绊脚石.对开发者来说是非常痛苦的. 因此我们构建的网络请求框…

在不久之前分享一篇<App 组件化/模块化之路——如何封装网络请求框架>文章介绍了我在项目中封装网络请求框架的思路.开发一个 App 会涉及到很多网络请求 API ,例如登录注册接口.用户信息接口.业务列表请求接口等等.而本文介绍的是如何模块化设计这些接口,使得项目中更好地复用代码.当然这仅仅是一家之言,欢迎留言拍砖. 问题 网络请求中最常见的莫过于用户授权登录模块了.现在以此模块为例,大概有以下接口 登录 sign_in 注册 sign_up 找回密码 find_password 获取短信验…

面对越来越复杂的 App 需求,Google 官方发布了Android 框架组件库(Android Architecture Components ).为开发者更好的开发 App 提供了非常好的样本.这个框架里的组件是配合 Android 组件生命周期的,所以它能够很好的规避组件生命周期管理的问题.今天我们就来看看这个库的使用. 通用的框架准则 官方建议在架构 App 的时候遵循以下两个准则: 关注分离 其中早期开发 App 最常见的做法是在 Activity 或者 Fragment 中写了大量…

App 组件化/模块化开发架构思路 随着业务的发展 App 开发技术也越来越成熟,对开发者来说 App 代码量也迅速地增长到一个数量级.对于如何架构 App 已经每个开发者面临的实际问题.好的架构可以提高开发者的效率,降低维护成本. 由于业务增长引起项目中代码量激增,以及历史遗留问题和结构混乱,作为一个有代码洁癖的程序员,很早就开始思考如何组织 App 架构的问题了.目前遇到的主要有以下几点问题: 代码量激增引起结构混乱 各个模块相互引用且耦合度高 无法独立开发或者调试组件代码 无法应对组件插拔…

什么是 Repository 模式 Repository 这个词直译过来仓库.仓储的意思.这个意思其实也能反应出 Repository 模式作用.App 开发中少不了对数据的操作,数据的来源可能有很多种:网络.数据库.文件以及内存中的缓存.而 Repository 就相当于一个仓库管理员,管理这些数据的存储.当业务层想要获取或者存储数据时,只需要通过 Repository 的管理员进行操作.这样的好处就是:屏蔽数据来源的操作接口.对于业务层来说不必关心数据存在哪里,以及如何存储的.而且也符合我们…

Android 组件化/模块化之路——在展示层搭建MVP结构 什么是MVP Model–View–Presenter (MVP) 源于 Model–View–Controller (MVC) 的结构设计模式,它是用于展示层(Presentation)的结构. MVP 中的 Presenter 是 “中间人”角色,它的功能是在 Model–View–Presenter 三者中起到连接和协作的作用.程序中的大部分的逻辑都应该在 Presenter 中实现. Model 定义了数据的访问接口.例如之前…

1.网络请求 第一种实现方式: 功能:GET POST 请求 缓存逻辑: 1.是否要刷新本地缓存,不需要就直接发起无缓存的网络请求,否则直接读取本地数据 2.需要刷新本地缓存,先读取本地数据,有就返回,没有就发起缓存的网络请求 3.无网络时直接读取本地缓存 #import "AFHTTPSessionManager.h" /** *该类默认只要导入头文件就会自动检测网络状态,且会在没有网络和未知网络的时候,自动从本地数据库中读取缓存. *数据库网络缓存是基于猿题库公司对FMDB进行封装…

一.背景 随着项目逐渐扩展,业务功能越来越多,代码量越来越多,开发人员数量也越来越多.此过程中,你是否有过以下烦恼? 项目模块多且复杂,编译一次要5分钟甚至10分钟?太慢不能忍? 改了一行代码 或只调了一点UI,就要run整个项目,再忍受一次10分钟? 合代码经常发生冲突?很烦? 被人偷偷改了自己模块的代码?很不爽? 做一个需求,发现还要去改动很多别人模块的代码? 别的模块已实现的类似功能,自己要用只能去复制一份代码再改改? "这个不是我负责的,我不管",代码责任范围不明确? 只做了一…

在前面已经初步封装了一个MVP的网络请求框架,那只是个雏形,还有很多功能不完善,现在进一步进行封装.添加了网络请求时的等待框,retrofit中添加了日志打印拦截器,添加了token拦截器,并且对DataManager类进行了扩展,真正体现它的作用,并且对大量的重复代码做了一定封装,减少代码的冗余. 下面结合上篇文章,进行下一步的封装. 1.首先完善Result.java这个类. 通常在我们写API接口文档的时候,后端返回的数据格式都是 "code":1    //1:成功 //-1:…

在现在的app,网络请求是一个很重要的部分,app中很多部分都有或多或少的网络请求,所以在一个项目重构时,我会选择网络请求框架作为我重构的起点.在这篇文章中我所提出的架构,并不是所谓的 最好 的网络请求架构,因为我只基于我这个app原有架构进行改善,更多的情况下我是以app为出发点,让这个网络架构能够在原app的环境下给我一个完美的结果,当然如果有更好的改进意见,我会很乐于尝试. 关于网络请求框架 一个好的网络请求框架对于一个团队来说是十分重要的.如果一个网络请求框架没有封装好,或者是在设计上存…