智能厨房重构-项目分包

最新推荐文章于 2024-06-06 18:01:27 发布

betterAndroider

最新推荐文章于 2024-06-06 18:01:27 发布

阅读量1.1k

点赞数 1

分类专栏：项目集中营文章标签：项目分包

本文链接：https://blog.csdn.net/u014316462/article/details/52132510

版权

项目集中营专栏收录该内容

7 篇文章 0 订阅

订阅专栏

1.前言

想想自己学习android也有一段时间了，一路自学既有自己的艰辛，也有自己的快乐。是时候用当前最火热的技术来重构一下自己以前刀耕火种的代码了，否定过去，就是肯定现在嘛！

2.环境的切换

以前刚开发的时候用的是ecplise，被时不时就断就断一下的adb折磨了好久，调试起来非常不方便，自从接触了google推出的Android Studio之后，加上genymotion简直爽到不行。还有编程环境更加Geek范，黑色的背景既酷又不伤眼睛。

3.分包对比

现在开始进入正题，首先看一下我之前的分包，正视一下自己的错误。

这里写图片描述

因为之前用的是ecplise开发的，环境我已经删了，就直接在原始代码文件夹里截个屏了。乍一看貌似还有点像样子，但是存在好多问题，对于my。。。的命名，我自己都不好意思了，看来我之前还是很有保护意识的，一直在说我的，我的。来看一下现在项目的分包。

这里写图片描述

重点要将一下现在的分包思路：

1、首先整体项目我采用MVP设计模式，这个模式网上已经有很多资料了，不清楚可以google，采用这种模式最主要的三个包就是：

（1）Model（数据的请求加载），包括获取数据库中的数据，获取网络中的数据，获取文件中的数据，反正只要的获取数据的，就定义在这个包里，也是任务最重的地方。
（2）View（加载视图，视图点击响应），View层通常对应着Activity，一般将Model将数据请求好之后，需要加载到界面展示给用户，而这展示的工作就由View来承担。
（3）Presenter（组织者），它就相当于工厂中的老大，负责调度，比如先让Model去网络上把数据请求下来，然后他就把这个数据交给View，让View去展示。

这里写图片描述

从类图中我们可以看出Presenter依赖于View和Model。View和Model也没有直接进行通信。

优点：MVP可以把Activity解放出来，避免了MVC中Activity既当View又当Control的尴尬，能够极大缩减Activity的代码。代码的复用性和可维护性更高。

缺点：一个功能界面需要定义一个接口View、Model、Presenter，可能会导致接口爆炸。

好，MVP先介绍到这里，后面我会写一篇博文详细介绍一下。我们先介绍完分包。

2.applicaton

有时候我们需要上下文context，但是有的地方不方便获取到Activity的context，我们就需要定义一个application，用来获取application的context，另外补充一点一个app的context总和是一个application的context，Activity的context，service的context的总和。

还有一点：使用Application的context有利于避免内存泄露。关于这一点可以看我的这篇博客Android内存泄露详解
看一下代码：

/**
 * 作者：GXL on 2016/8/3 0003
 * 博客: http://blog.csdn.net/u014316462
 * 作用：全局Application
 */
public class BaseApplication extends Application {
    public static Context getmContext() {
        return sContext;
    }


     static Context sContext;
    @Override
    public void onCreate() {
        super.onCreate();
        sContext=getApplicationContext();
    }


}