UMC面向Serverless的全栈开发架构,用后端体系开发原生移动应用

UMC介绍

UMC的全名是UI Model Command,意思是让UI响应服务端的模块指令,实现上就是设计了一套客户端与服务端交互的文本协议,此协议能让就是客户端用标准请求服务端、服务端用标准JSON格式响应客户端。客户端分析出JSON端包含的事件,数据和UI组件,达到操控和绘制客户端目的,现在服务端我们已经用java.net实现了此标准协议(后期我们会实现其他计算机语言),现在java后端工程师和.net后端工程师只要用此架构开发,就能快速实现了原生Android和原生IOS端和H5端和小程序(嵌套H5,后期会用原生小程序实现),H5都已经开源,此协议用一套标准,统一实现PC和H5端,小程序端,安卓和苹果端的界面实现和后台逻辑。
这也意为做,一个统一的后台就可以管理各个终端,用此实现的业务不但开发维护简单,业务维护也更简单,对公司而言,有后端工程师就有各IOS和Android的团队班子,对于后端工程师更是赋能,现在他们能开发Android和IOS应用了,对于Android和IOS工程师,让他们告别杂乱UI绘制和UI跳转方式,进入终端的组件式开发,且只要对新组件实现就可以了,让终端开发更简单,对发布来太太减少APP版本发布次数,我也相信每个后台工程师和Android和IOS工程师都愿意掌握此技能。
UMC是在数据通信上是采用Http GET方式请求,为什么采用GET方式呢,客户端与服务端做为非文件交互,整体来说交互所要的数据是相当少,GET方式足可满足我们应用需要,如果需要文件交互,则采用先把资源上传到文件服务器,再来由UMC处理,这样就简单高效了,还不用占用带宽,又起服务器分流等做用,此设计为我分布式和API高性能网关提供了前期基础。
再来说交互路由吧,我们用GETQueryString来交互传参,我们保留jsonp参数做跨域使用,还有_model_cmd就是我们的ModelCommand,再除去_开头的参数就是这次有效请求的参数,就这样根据ModelCommand带着参数去路由,跑一遍,把再结果返回给客户端,就这样完成这次请求了,他的原理就是这样回事。下面我用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只接收Accountmodel,此模块的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,可以路由指令LoginRegisterForgetPassword,每个指令都有自己的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参数,但requestQueryString规整化了,当请求中有modelcmd的时间,QueryString单值可以request.sendValue()获取,多值可以用request.sendValues()得到;当请求无modelcmd的时,则会把请求把QueryString规整化到了对话框中,以对话框的方式获取交互的值;response客户端响应对象,他可以完成数据输出或跳转。一句话就是request是获取客户端信息,response是操作响应内容的;
从上面讲解中,我们知道QueryString会规整到request请求参数中去,这里讲一讲请求参数与箭头函数的之间的关系。箭头函数在什么样的情况下执行呢,只有在请求参数或会话中找到这对话框的参数值,则执行箭头函数获得一个对话框给并返回到客户端;先声明一个对话框,对话框分为单值对话框和表单对话框,先说单值对话框与请求参数对应的关系吧,每个请求的对话框都有一个asyncId,也就是asyncDialog传入进去asyncId,确认asyncId是不是有值,先从会话参数中找,如果没有,从对话框参数池中找,如何不存在对话框参数,检测request.sendValue()还没有值,再用asyncId作为key来检测request.sendValues(),如果都没值的情况下,再去执行箭头函数获取对话框。这就是单值对话框获取值的逻辑,下面我们再说说表单对话框获取值的方式,第一步也是一样从会话参数中找,没有找到,再看对话框参数池是不是表单值,如果不是或没有,再看request.sendValues()是不是能与此次表单asyncId对应,(他的对应关系架构会自行处理)如果不是或没有,再去执行箭头函数获取表单对话框。这就是表单对话框获取值的逻辑;整个对话框都是为了让对话框的asyncId配对QueryString,这也说明只要做准备好WebActivity所要的的参数,就能执行完processActivity逻辑,中途就不会去执行箭头函数。
在对话框中从获取值的方式上,可分为两种,会话对话框和事件对话框,会话对话框前端提交之后就关闭,事件对话框是根据服务端返回的事件,进行关闭或者刷新。在我们的UIGridDialogUIFormDialog都支持这两种模式

现在我们讲解一下上面的AccountLoginActivityprocessActivity,此processActivity有登录表单对话框,此对话框并启用了事件对话框,看dialog.submit("登录", request, "User")这块表示启用了事件对话框模式,
说明这么多,实事上是希望大家理解此模式,这也就UMC架构的业务处理层的核心思想,其他的解译都是丰富这模式下的应用场景。
回头我们再看看AccountLoginActivityprocessActivity方法,可从代码中可以看出,此Activity有绘出一个用户登录的UIFormDialog,还关联到忘记密码和用户注册,这就是我们登录功能的全部代码,是不是简单,掌握他就能开发出高性能的Andord,IOS和H5和小程序,因为他们的对应的客户端都是用原生程序写的,不是比其他任何内嵌引擎的都要快,对应后端工程师来说,掌握他不并跨出后端的知识体系。他用的是后端架构思维,驱动各前端应用,是不是掌握他是不是更有价值呢。

上一篇:iOS_18_控制器切换_NavigationController_push方式_传递数据


下一篇:android UI开源库