介绍说明 · ITME

介绍说明

全栈之路

用后端知识体系开发原生移动应用

介绍说明

UMC的全名是UI Model Command，意思是让界面响应服务端的模块指令来绘制界面,实现上就是设计了一套客户端与服务端交互的文本协议，此协议能让用户界面用定义好的标准请求服务端，然后服务端用UMC标准的JSON格式响应客户端。客户端分析出JSON端包含的事件、数据和UI组件，从而达到操控和绘制客户端的目的，服务端我们已经用java和.net实现了此标准协议，现在java后端工程师和.net后端工程师只要用此架构开发，就能快速实现了原生Android和原生IOS端和H5端和小程序，此协议用一套标准，统一实现PC和H5端，小程序端，安卓和苹果端的界面实现和后台逻辑。

这也意为着一个统一的后台就可以管理各个终端，用此实现的业务程序不但开发维护简单，业务维护也更简单，对公司而言，拥有后端工程师就有移动互联网开发团队，对于后端工程师更是赋能，现在他们能开发原生Android和IOS应用了，对于Android和IOS工程师，让他们告别杂乱UI绘制和UI跳转方式，进入终端的组件式开发，且只要对新组件实现就可以了，让终端开发更简单，对发布来说大大减少APP版本发布次数，我也相信每个后台工程师和Android和IOS工程师都愿意掌握此技能。

UMC是在数据通信上是采用标准的HTTP REST API方式请求，在文件交互时，则采用先把资源上传到文件服务器，再来由UMC处理，这样就简单高效了，还不用占用带宽，又起服务器分流等做用，此设计为我们分布式和API高性能网关提供了前期准备。

再来说交互路由吧，我们用Url参数QueryString来交互传参，我们保留jsonp参数做跨域使用，还有_model和_cmd就是我们的Model与Command，再除去_开头的参数就是这次有效请求的参数，就这样根据Model和Command带着参数去路由，跑一遍，把再结果返回给客户端，就这样完成这次请求了，它的原理就是这么回事。下面我用java讲解如何实现。

UMC的IWebFactory、WebFlow、WebActivity

请求路由路线是由model和cmd来确认，它对应的后台路由类分别为IWebFactory接口，WebFlow基类、WebActivity基类，其中由IWebFactory来确认接收那此model并返回接收WebFlow类，再由WebFlow类确认cmd,由那个WebActivity处理，整个处理路由就是这样，下面我们就来讲解此逻辑

IWebFactory

//IWebFactory
public class FlowFactory implements IWebFactory {
    @Override
    public void init(WebContext context) {

    }

    @Override
    public WebFlow flowHandler(String mode) {
        switch (mode) {
            case "Account":
                return new AccountFlow();
        }
        return WebFlow.Empty;
    }
}

WebFlow

上例代码展示，此IWebFactory只接收Account的model，此模块的cmd路由由AccountFlow处理，下面我们就查看AccountFlow代码

public class AccountFlow extends WebFlow {
    @Override
    public WebActivity firstActivity() {
        switch (this.context().request().cmd()) {
            case "Login":
                return new AccountLoginActivity();
            case "Register":
                return new AccountRegisterActivity();
            case "Forget":
                return new AccountForgetActivity();
            case "Password":
                return new AccountPasswordActivity();
        }

        return WebActivity.Empty;
    }
}

从上列代码可以就看到AccountFlow，可以路由指令Login，Register，Forget，Password,每个指令都有自己的WebActivity,WebActivity就是我们的业务实现了，处理业务业务方法在processActivity，下面我就用AccountLoginActivity来说明WebActivity的处理方式

WebActivity

public class AccountLoginActivity extends WebActivity {
    @Override
    public void processActivity(WebRequest request, WebResponse response) {

        WebMeta user = this.asyncDialog(d ->
        {
            UIFormDialog dialog = new UIFormDialog();
            dialog.title("账户登录");
            dialog.addText("用户名", "Username", "").put("placeholder", "手机/邮箱");
            dialog.addPassword("用户密码", "Password", "");
            dialog.submit("登录", request, "User");//事件对话框
            dialog.addUIIcon('\uf1c6', "忘记密码").put("Model", request.model()).put("Command", "Forget");
            dialog.addUIIcon('\uf234', "注册新用户").put("Model", request.model()).put("Command", "Register");
            return dialog;
        }, "Login");
        String username = user.get("Username");

        Membership userManager = WebADNuke.Security.Membership.Instance();
        int times = userManager.Password(username, passwork, maxTimes);
        switch (times) {
            case 0:
                Identity iden = userManager.Identity(username);

                AccessToken.login(iden, AccessToken.token(), request.isApp() ? "App" : "Client", true);

                this.context().send("User", true);

                break;
            case -2:
                this.prompt("您的用户已经锁定，请过后登录");
                break;
            case -1:
                this.prompt("您的用户不存在，请确定用户名");

                break;
            default:
                this.prompt(String.format("您的用户和密码不正确，您还有%d次机会", maxTimes - times));

                break;
        }
    }
}

我这里先说说processActivity方法的两个参数吧，request,response其中request是请求的所有参数信息都这里，包含客户端环境，是不是APP中，是不是微信中，客户的IP是多少，和QueryString参数，但request把QueryString和DataForm规整化了，把它们除了model和cmd都规整化到request.sendValues()，把“_”,“__”,“Path”，分解成先进先出的队列头部值以request.sendValue()获取，以方便对话框的获取交互的值；response客户端响应对象，它可以完成数据输出或跳转。一句话就是request是获取客户端信息，response是响应客户端内容的；

从上面讲解中，我们知道QueryString会规整到request请求参数中去，这里讲一讲请求参数与箭头函数的之间的关系。箭头函数在什么样的情况下执行呢，只有在请求参数或会话中找到这对话框的参数值，则执行箭头函数获得一个对话框给并返回到客户端；先声明一个对话框，对话框分为单值对话框和表单对话框，先说单值对话框与请求参数对应的关系吧，每个请求的对话框都有一个asyncId，也就是asyncDialog传入进去asyncId，确认asyncId是不是有值，先从会话参数中找，如果没有，从对话框参数池中找，如何不存在对话框参数，检测request.sendValue()有值则出列返回，如果没有值再用asyncId作为key来检测request.sendValues()，如果都没值的情况下，再去执行箭头函数获取对话框。这就是单值对话框获取值的逻辑，下面我们再说说表单对话框获取值的方式，第一步也是从会话参数中找，没有找到，再看request.sendValues()是不是能与此次表单asyncId对应，（它的对应关系架构会自行处理）如果不是或没有，再去执行箭头函数获取表单对话框。这就是表单对话框获取值的逻辑；整个对话框都是为了让对话框的asyncId配对提交的表单值，这也说明只要做准备好WebActivity所要的的参数，就能执行完processActivity逻辑，中途就不会去执行箭头函数。

说明这么多，实事上是希望大家理解此模式，这也就UMC架构的业务处理层的核心思想，其它的解说都是丰富这模式下的应用场景。

回头我们再看看AccountLoginActivity的processActivity方法，可从代码中可以看出，此Activity有绘出一个用户登录的UIFormDialog，还关联到忘记密码和用户注册，这就是我们登录功能的全部代码，是不是简单，掌握它就能开发出高性能的Andord、IOS和H5和小程序，因为它们的对应的客户端都是用原生程序写的，是不是比其它任何内嵌引擎的都要快，对应后端工程师来说，掌握它不并跨出后端的知识体系。它用的是后端架构思维，驱动各前端应用，是不是掌握它是不是更有价值呢。

 管理员 | 阅读(1043) | 评论(0)

赞

已读

 暂无点赞

介绍说明

UMC的IWebFactory、WebFlow、WebActivity

IWebFactory

WebFlow

WebActivity