更新时间:2019-09-25 10:26
source 'git@gitlab-ce.emas-poc.com:EMAS-iOS/emas-specs.git'
pod 'TBAccsSDK', '10.0.7'
pod 'NetworkSDK', '10.0.4.4'
pod 'tnet', '10.3.0'
#import <TBAccsSDK/TBAccsManager.h>
// 初始化参数
TBAccsConfiguration *config = [[TBAccsConfiguration alloc] initWithHost:@"accs.domain.com"];
// App唯一标识,必填
config.appkey = @"12345";
// 请求加密加签使用,必填
config.appsecret = @"abcdefghijklmnopqrst";
// 连接指定IP
config.defaultIP = @"10.10.10.10";
// 连接指定端口
config.defaultPort = 443;
// 设置EMAS专用公钥
config.slightSSLPublickeyIndex = ACCS_PUBKEY_PSEQ_EMAS;
// 根据config构建ACCS实例,并启动
TBAccsManager *accsManager = [TBAccsManager createAccsWithConfiguration:config];
[accsManager startAccs];
// 初始化参数
TBAccsConfiguration *config = [[TBAccsConfiguration alloc] initWithHost:@"accs.domain.com"];
// App唯一标识,必填
config.appkey = @“12345”;
// 请求加密加签使用,必填
config.appsecret = @“abcdefghijklmnopqrst”;
// 指定使用local dns
config.supportLocalDnsWhenNoPolicy = YES;
// 设置EMAS专用公钥
config.slightSSLPublickeyIndex = ACCS_PUBKEY_PSEQ_EMAS;
// 根据config构建ACCS实例,并启动
TBAccsManager *accsManager = [TBAccsManager createAccsWithConfiguration:config];
[accsManager startAccs];
相关概念解释:
上行
客户端向服务单主动发送数据,我们称之为上行数据
- REQ/RES模式
客户端每次向服务端请求后,服务端响应一个数据应答包,这种方式与传统的http请求类似。
- Data模式:
客户端向服务端发送数据,没有应答数据包,只有ACK,且业务层无须接收ACK。
- ACK:
accs的每条下行数据都会返回服务端ack, ack可以透传给业务, 业务可以选择接收或不接收。
下行
服务端主动向客户端推送数据,我们称之为下行数据。
[_accsManager bindAppWithAppleToken: appleDeviceToken
callBack:^(NSError *error, NSDictionary *resultsDict) {
if (error) {
AccsLog(@"\n\n绑定App出错了 %@\n\n", error);
}
else {
AccsLog(@"\n\n绑定App成功了\n\n");
}
}];
只有绑定APP成功,ACCS 实例才能正常接收下行消息,否则只能发送上行消息。
[_accsManager bindAppWithAppleToken: appleDeviceToken
force: YES
callBack:^(NSError *error, NSDictionary *resultsDict) {
if (error) {
AccsLog(@"\n\n绑定App出错了 %@\n\n", error);
}
else {
AccsLog(@"\n\n绑定App成功了\n\n");
}
}];
绑定用户动作在ACCS中不是必须的,ACCS设备检索是依赖deviceid (就是utdid)。端上通过bind user之后,业务端可以使用业务自己的userid来检索设备, 实现用户维度运维发送消息。注意同一个userId最多只能绑定20个设备,超出该限制后,绑定会失败。
[_accsManager bindUserWithUserId: _userId.text
callBack:^(NSError *error, NSDictionary *resultsDict) {
if (error) {
AccsLog(@"\n\n绑定用户出错了 %@\n\n", error);
}
else {
AccsLog(@"\n\n绑定用户成功了\n\n");
}
}];
[_accsManager unbindUserWithUserId:_userId.text callBack:^(NSError *error, NSDictionary *resultsDict) {
if (error) {
AccsLog(@"解绑用户出错: %@", error);
} else {
AccsLog(@"解绑用户成功");
}
}];
参数说明:
[_accsManager sendRequestWithData: [_message.text dataUsingEncoding: NSUTF8StringEncoding]
serviceId: @“your_service_id”
userId: @"your_user_id"
otherParameters: nil
callBack:^(NSError *error, NSDictionary *resultsDict) {
if (error) {
AccsLog(@"发送数据失败sendRequest: %@", error);
}
else{
AccsLog(@"发送数据成功sendRequest");
}
}];
订阅下行消息通过API: Bind Service 来完成:
参数说明:
emas-test
)
[_accsManager bindServiceWithServiceId: _serviceId.text
callBack:^(NSError *error, NSDictionary *resultsDict) {
if (error){
AccsLog(@"绑定Service出错了");
}
else{
AccsLog(@"绑定Service成功了");
}
}
receviceDataBlock:^(NSError *error, NSDictionary *resultsDict){
if (error){
AccsLog(@"接收 Accs 数据出错 %@", error.description);
}
else{
AccsLog(@"接收 Accs 数据成功 %@", resultsDict[@"jsonString"]);
}
}];
返回的数据在 resultDict 中,解析如下:
// message id
NSString *dataId = [resultsDict objectForKey:@"dataId"];
// from which service
NSString *serviceId = [resultsDict objectForKey:@"serviceId"];
// message payload, binary data
NSData *payload = [resultsDict objectForKey:@"resultData"];
// 例如业务端发送payload 是一个字符串,则解析成字串
NSString *text = [[NSString alloc] initWithData:payload encoding:NSUTF8StringEncoding];
“离线消息”概念:
当ACCS连接在线时,服务端通过ACCS推送下来的消息称之为“在线消息”;当ACCS连接离线时,服务端把需要的下行消息缓存起来,当设备再次上线时,再推下去,这些消息称之为“离线消息”
因连接一旦建立成功,服务端即会立即推送缓存的离线消息,因为业务使用SDK时的时序不可控,有可能数据到达SDK时,业务尚未bind service, 导致消息被丢弃。为解决此问题,业务可在AccsReceiverTable.plist中注册下行消息接收handler, ACCS在初始化时,通过反射创建注册的handler, 把收到的消息投递出去,避免业务bind service过晚而导致的消息丢失。注意:大小写敏感!
AccsReceiverTable.plist文件路径无特殊需求,添加到主客工程中即可。
注册格式如下:
{
"im": {
"class": "TBIMAccsAdapter"
}
}
im表示自己申请的serviceID,class表示需要实现以下协议的类,accs会根据类名和协议方法动态调用此类,其中 TBIMAccsAdapter 需要实现以下接口:
@protocol TBAccsCallbackProtocol <NSObject>
@required
+ (TBAccsManagerResponseBlock)callBack;
+ (NSString *)serviceID;
@optional
+ (NSString *)accsHost; // ACCS Host, 可以不写
@end
在接入调试的时候,若出现异常&错误不便排查,可以打开SDK日志,通过日志排查问题原因:
// 先声明日志开关函数
void tbAccsSDKSwitchLog(BOOL logCtr);
// 打开日志
tbAccsSDKSwitchLog(YES);
因为TBAccsSDK中连接的建连、保活等基础逻辑是在网络库中实现,所以有时我们需要进一步查看网络库的日志:
#import "NWLog.h"
[NWLog setLogLevel:NW_LOG_DEBUG];
所有上行接口的回调参数中的NSError* 若为nil, 则表示无错误;若非空,其解释如下:
错误码 | 解释 | 场景场景 |
---|---|---|
7001 | 请求超时 | timeout 设置过短,或服务端阻塞 |
7002 | 请求构建失败 | 依赖无线保镖时,appkey 在安全文件中无配置 |
7003 | 无通道 | 连接断开 |
7004 | 上行帧发送错误 | 发送失败 |
7005 | ACCS flag错误 | 下行数据服务端报文格式错误 |
7006 | 无网络 | |
7007 | 多次重试无响应 | 对应ACCS服务端宕机 |
70019 | 上行数据为空 | |
70020 | 服务端低级别限流 | 客户端在一段时间,不发起任何请求 |
70021 | 服务端高级别限流 | 客户端会每隔几毫秒发一个请求,给服务端减轻压力 |
70022 | 防刷限流 | 客户端QPS过高,用户需要输入验证码,客户端才可以继续发请求 |
在文档使用中是否遇到以下问题
更多建议
匿名提交