Mstar之Service

注：以下来自Mstar官方培训文档。

 

    Service不具有使用者接口，透过API提供服务给多个不同的APP或Service；

    Service大多于手机开机时并启动。生命周期比Applet来的长，这种类型的Service定义于static const MAEClsId_t _xmmi_StaticObjectClsIds[];

    在MMI Task上，多个Service可以同时运行，Applet被使用者关闭后，配置的内存被释放，而Service通常还会存在。

 

在XMMI中，Applet需明确自行创建与释放Service实例；Service使用CB/Event两种方式响应Applet的请求；Applet向Service注册特定Event，Service主动在特定时刻向Applet发送Event；开发者需明确的写程序代码去处理由Service发送的Event。

以蓝牙搜索为例：

1)    创建实例

Ret = SH_CreateInstance(CLSID_BTSRV, (void**)&pThis->pBTSrv, (Ibase*)pThis);

2)    发送请求

nRetVal = IBTSRV_InquiryReq(pThis->pBTSrv, BTSRV_INQUIRY_START);

 

光看此API，开发者并不知道接收这个API的响应，只能自己苦苦追寻，才发现原来是函数Void BTSRV_mode_Active_Searching_act_2431(...),多么痛苦啊！

在XMMI中，使用Service的时候，要在BT Applet中要先注册此Event，接着去实现一个Event Handler函数mmi_BTAPP_HandleEvent(...)。由Event传递的参数，无法透过prototype来得知真实的参数形态，必须深入的到Service内部的逻辑才能得知。

因此EMMI为了减少开发者的复杂度，引入了Service Wrapper API, Service实例在Wrapper API中自动被创建，并在适当的时机被释放，回调函数成为唯一Service被动的响应与主动发送指示的方式。

 

(如果你看过XMMI的代码，你真的会为它的状态机(State Machine)为之一震，写代码真的是半自动，对于维护的人来说还是有些头疼的)。

 

Service Wrapper API内部设计

    Service回传结果给Applet的方式依然是事件，只是在EMMI平台被隐藏了起来，这样开发者并无需处理Service Event的代码。为了达到这个目的，平台必须有一角色来提供下面的功能：

1)自动为Applet建立Service实例，并存放起来

2)存放Event与CB函数的响应

3)处理传送给Applet的Event，并转为正确的CB函数

   

BaseApplet便是扮演这个角色的数据结构。

BaseApplet_t是每个EMMI平台Applet创建时都会自动分配的一块数据结构，每个Applet皆有其独立的BaseApplet_t。

 

限制：Service Wrapper API只能被Applet使用，因为只有Applet才有BaseApplet来为Applet处理Event及转换为对应的CB函数