地点布告和长途文告亚洲必赢app在哪下载

By admin in 亚洲必赢app在哪下载 on 2019年2月10日

正文主要描述了iOS的本土和长途通告的为主使用,以及一些不易注意的题材。

Note:小说有许多身旁同学提供了救助,多量引用或转发本文请宣示原文地址,多谢。

一:用户通报简介

用户通报是哪些

iOS中留存两种常见的风浪通报格局:NSNofiticationCenter、KVO Notification
和 User Notifications,其中 User
Notifications,就是本文将要商量的用户通报。

俺们都精通 iOS 系统不时的有一些与 App
相关的文告栏新闻,那些消息往往伴随着提醒音以及 App
的桌面图标右上角的未读信息提示,这几个公告就是 iOS 的用户通报。

用户通报的分类

用户通报分为两类:本地文告和远程通告,其中长途布告又称之为推送布告。

双面最重大的界别是:本地布告是由 App
发送到当前设备上,不要求互联网协理;而远程公告是由 App
的服务器发送到苹果的 APNs 服务器,并由 APNs 服务器转载到对应设施(由 App
服务器指定接收布告的装置)。

双面最重大的共同点是:本地布告和长距离布告对用户的表现方式是一致的,两者均可以动用通告栏音信、App
桌面图标右上角角标和提醒音的章程通报用户。

用户通报有如何用场

当即有效的(无论是在前台如故后台)向用户发送音讯(聊天音信、新闻、待办事项、天气变化等)是用户通报最大的优势。

其余,有效创制的施用用户通报,可以让我们的 App 有更好的体会,如:

  • 当待办事项将要过期时方可登时提示用户;
  • 当用户执行下载大文件职责时进入后台,当下载达成后得以通告用户;
  • 当用户满世界旅行时,能够根据用户的地理地点推送天气变化等音信;
  • 当用户订阅的某杂志或音讯主旨有立异时,文告用户;
  • ……

正文后续内容将以使用开发者的角度对用户通报举办深远的商讨,本文啄磨内容针对iOS7/8/9,有关
iOS10 系统的用户通报会另做教师。

那里可下载
本文demo
。其余,本文中的远程公告使用了
Simplepush.php
,内部代码很简短,可应用该脚本自定义远程公告的始末,当然可以采纳
本文demo
里我修改过的本子文件,提议花几分钟查看以下 Simplepush.php
的用法。其它,demo
不提供证书,如有远程文告必要,请自行报名证书,否则不可能正常使用
Simplepush。

本文主要参照了苹果官方的 Local and Remote Notification Programming
Guide

以及本文用到的接口的官方文档。

二:本地通告的选取

打开本地通知作用

  • 对于 iOS7,要是用户并未在系统装置里关闭该 App
    的通告效能,那么开发者无需做其余操作即可使用当地布告成效。

  • 对于 iOS8
    及其后的体系,若须求利用当地通知功用,则需求登记布告类型。
    布告类型有五种:角标(UIUserNotificationTypeBadge)、提醒音(UIUserNotificationTypeSound)、提示音信(UIUserNotificationTypeAlert)和无其余公告(UIUserNotificationTypeNone)。

    你可以注册上诉七种通告类型的任性组合,但结尾可用的通报格局必要依照用户对此
    App 公告的安装规定。比如:App
    内部注册了角标、提醒音和提示音信,可是用户关闭了动静公告,那么收到本地通告时是不会有提示音的。
    对于 iOS8 及其后的系统,注册本地布告的代码示例如下:

    - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
        // 只有 iOS8 and later 才需要
        if ([[UIApplication sharedApplication]  respondsToSelector:@selector(registerForRemoteNotifications)]) {
            // 这里 types 可以自定义,如果 types 为 0,那么所有的用户通知均会静默的接收,系统不会给用户任何提示(当然,App 可以自己处理并给出提示)
            UIUserNotificationType types = (UIUserNotificationType) (UIUserNotificationTypeBadge | UIUserNotificationTypeSound | UIUserNotificationTypeAlert);
            // 这里 categories 可暂不深入,本文后面会详细讲解。
            UIUserNotificationSettings *mySettings = [UIUserNotificationSettings settingsForTypes:types categories:nil];
            // 当应用安装后第一次调用该方法时,系统会弹窗提示用户是否允许接收通知
            [[UIApplication sharedApplication] registerUserNotificationSettings:mySettings];
        }
    
        // Your own other codes.
        return YES;
    }
    

当系统弹窗提示用户是还是不是允许收取布告后,用户可能会拒绝;我们得以在
AppDelegate 的 application:didRegisterUserNotificationSettings:
方法中用来查看注册成功的关照类型,大家可以在获得注册结果后做自定义操作(比如败北时弹个窗提醒用户眼前不可以使用用户通报)。

苹果推荐在后来发送的当地文告时,要幸免使用没有注册成功的打招呼类型(并不是挟持需求)。

- (void)application: (UIApplication*)application didRegisterUserNotificationSettings:(UIUserNotificationSettings *)notificationSettings {
    if (notificationSettings.types & UIUserNotificationTypeBadge) {
        NSLog(@"Badge Nofitication type is allowed");
    }
    if (notificationSettings.types & UIUserNotificationTypeAlert) {
        NSLog(@"Alert Notfication type is allowed");
    }
    if (notificationSettings.types & UIUserNotificationTypeSound) {
        NSLog(@"Sound Notfication type is allowed");
    }
}

发送本地公告

出殡一个本地文告紧要有如下步骤:

  1. 先是要遵守上述 “开启本地布告作用” 步骤注册通知类型;

  2. 开创一个 UILocalNotification 对象;

  3. 设置 UILocalNotification 对象的 fireDate
    属性,该属性表示什么时间点发送这条地点公告;同时可以安装 timeZone
    属性表示时区,设置 timeZone 后,当用户超过时区时,fireDate
    会依照时区被调动(类似于钟表调整);其它,可以使用 repeatInterval 和
    repeatCalendar 来设置周期性的关照。

  4. 安装布告的提醒信息:

    • 安装 alertTitle 作为公告的少校,设置 alertBody
      作为布告的具体新闻;注意那里强烈提出使用本地化的字符串,即
      NSLocalizedString(@"This is alert body", nil);
      在意 alertTitle 属性只适用于 iOS8.2 及事后的种类
    • 设置 applicationIconBadgeNumber 用于显示 App
      桌面图标的右上角角标。
    • 安装 soundName, 大家一般设置为
      UILocalNotificationDefaultSoundName;使用自定义 sound
      在背后会进一步讲解。
    • 在安装提示格局的值时,对于 iOS8
      及今后的体系,可以检查下当前唤醒方式是不是已经登记成功(可以用
      [[UIApplication sharedApplication] currentUserNotificationSettings]
      获取注册成功的通报类型)。
  5. 可以挑选设置 userInfo 属性,该属性一般可以存放业务有关的消息(如 ID
    等),这样收到文告后可以方便处监护人务相关逻辑;

  6. 将方面创立的 UILocalnotification 放入公告队列中:使用方法
    scheduleLocalNotification: 会按照 UILocalnotification 中的
    fireDate 进行通报的发送,而接纳 presentLocalNotificationNow:
    会登时发送该地方布告。

上边给出一段示例代码:

- (void)scheduleLocalNotification {
    NSDate *itemDate = [NSDate date];

    UILocalNotification *localNotif = [[UILocalNotification alloc] init];
    if (localNotif == nil)
        return;
    localNotif.fireDate = [itemDate dateByAddingTimeInterval:10];
    localNotif.timeZone = [NSTimeZone defaultTimeZone];

    localNotif.alertBody = [NSString stringWithFormat:NSLocalizedString(@"%@ after %i seconds scheduled.", nil), @"本地通知", 10];

    localNotif.alertTitle = NSLocalizedString(@"Local Notification Title", nil);

    localNotif.soundName = UILocalNotificationDefaultSoundName;
    localNotif.applicationIconBadgeNumber = 1;

    NSDictionary *infoDict = [NSDictionary dictionaryWithObject:@"ID:10" forKey:@"LocalNotification"];
    localNotif.userInfo = infoDict;

    [[UIApplication sharedApplication] scheduleLocalNotification:localNotif];
}

拍卖收到的本地公告

那里分二种境况商量哪些处理地点通告:

行使处于前台

使用处于前台时,本地布告到达时,不会有提醒音、布告栏横幅提醒,然而 App
桌面图标的右上角角标是有数值突显的,所以固然在前台,大家也应该对角标数量做拍卖
此刻,大家得以在 application:didReceiveLocalNotification:
方法中获获得本地公告,示例代码如下:

- (void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification {
    NSString *itemName = [notification.userInfo objectForKey:@"LocalNotification"];
    [self.windowRootController displayNotification:[NSString stringWithFormat:@"%@ receive from didReceiveLocalNotificaition", itemName]];
    // 这里将角标数量减一,注意系统不会帮助我们处理角标数量
    application.applicationIconBadgeNumber -= 1;
}

选择处于后台

当使用处于后台时,本地公告到达时,会基于地面通告设置的关照类型以及用户安装的文告类型进行提示,例如锁屏界面布告、公告栏布告、声音、角标。

那会儿只要滑动锁屏界面通告或点击布告栏公告,则会切换应用到前台,我们可以动用与行使处于前台时一样的得到文告的点子。

而是一旦大家点击 App
桌面图标,则不可以获取到用户通报,此时文告栏音信照旧会存在。此外,角标也不会扭转,倘使指望修改角标,则要求App 进入前台后将其修改。

采纳尚未运行

假若使用尚未运行,当本地布告到达时,会根据当地文告设置的通报类型以及用户设置的打招呼类型举行提醒,例如锁屏界面文告、文告栏通告、声音、角标。此时只要滑动锁屏界面公告或点击文告栏文告,则会打开应用,但此时我们得到通告的法门与眼前有所分歧,通过application:didReceiveLocalNotification:
是心有余而力不足赢得通知的。 那种场合大家需求经过
application:didFinishLaunchingWithOptions: 中的 LaunchOptions
获取文告,示例代码如下:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    UILocalNotification *localNotif = [launchOptions objectForKey:UIApplicationLaunchOptionsLocalNotificationKey];
    if (localNotif) {
        NSString *itemName = [localNotif.userInfo objectForKey:@"LocalNotification"];
        [self.windowRootController displayNotification:[NSString stringWithFormat:@"%@ receive from didFinishLaunch", itemName]];  // custom method
        [UIApplication sharedApplication].applicationIconBadgeNumber = localNotif.applicationIconBadgeNumber-1;
    }

    // Your own other codes.
    return YES;
}

一致的,不过假设我们点击 App
桌面图标,则不能获获得用户通报,此时文告栏新闻如故会存在。其余,角标也不会生成,如若愿意修改角标,则须要App 进入前台后将其修改。

地理地点相关的地点公告

在 iOS8
及将来系统中,我们得以定义一个与地理地方有关的当地文告,那样当大家跨过设定的地理区域时,系统会发送本地通告。

挂号地方相关的本地公告

  1. 内需创设一个 CLLocationManager 对象,并为其设置一个 delegate;

  2. 恳请用户同意行使固定服务:调用 CLLocationManager 的
    requestWhenInUseAuthorization,注意工程的 plist 中须求布署NSLocationWhenInUseUsageDescription
    选项,否则一定服务不可以正常启用;示例代码如下:

    - (void)registerLocationBasedNotification {
        CLLocationManager *locationManager = [[CLLocationManager alloc] init];
        locationManager.delegate = self;
        // 申请定位权限
        [locationManager requestWhenInUseAuthorization];
    }
    
  3. 因而 CLLocationManagerDelegate
    回调检查用户是或不是允许使用固定服务,若是同意了劳务,那么可以发送一个岗位相关的本地布告。

    - (void)locationManager:(CLLocationManager *)manager didChangeAuthorizationStatus:(CLAuthorizationStatus)status {
        // 因为上面我们是使用了 requestWhenInUseAuthorization,所以这里检查的是 kCLAuthorizationStatusAuthorizedWhenInUse
        if (status == kCLAuthorizationStatusAuthorizedWhenInUse) {
        [self scheduleLocalBasedNotification];
        }
    }
    
  4. 创立一个地方相关的地点公告,并将其交由系统处理。

    - (void)scheduleLocalBasedNotification {
        UILocalNotification *locationNotification = [[UILocalNotification alloc] init];
        locationNotification.alertBody = @"到达xxx";
        locationNotification.regionTriggersOnce = NO; // 表示每次跨越指定区域就会发送通知
        locationNotification.region = [[CLCircularRegion alloc] initWithCenter:LOC_COORDINATE radius:LOC_RADIUS identifier:LOC_IDENTIFIER];
    
        [[UIApplication sharedApplication] scheduleLocalNotification:locNotification];
    }
    

拍卖地方相关的本地通告

与地点讲过的 “处理收到的地面文告” 比较,那里可以在通报里获得到
region,然后可以做自定义操作,其他具备操作均与 “处理收到的当地布告”
一致。

专注若是用户并未同意接纳一定权限,则无法吸收地方相关的本土文告。

三:远程通告的拔取

APNs 简介

APNs 是苹果提供的远距离通告的服务器,当 App 处于后台或者尚未运行时,即使App 的服务器(之后我们誉为
Provider)须要发送通告音信给客户端,则要求器重 APNs 服务器。

应用 APNs 服务时,远程文告的路由路径为: Provider –> 苹果的 APNs
服务器 –> 手机设备 –> App。在这么些途径中,Provider 与 APNs
服务器之间有一个 TLS 连接,Provider 通过那个三番五次将长途文告推送到苹果的
APNs 服务器;手机设备与 APNs 服务器之间也会有一个 TLS
连接,所有发往手机设备的 APNs 远程公告都是运用那一个TLS连接,然后由装备区分远程通告所属的
App,进而文告给用户某使用有长途布告。

上边简单介绍下那些流程:

设备 与 APNs

配备与 APNs 建立连接的经过如图:

Device-APNs.png

内需分明的中央思想:

  1. 此一连由系统创制并保持,无需开发人员管理;
  2. 上图中的证书是苹果设备本身的注脚,与开发者账号中申请的注明无关;
  3. 每个设备与 APNs 服务器只需维持一条连接。

Provider 与 APNs

Provider 与 APNs 建立连接的经过如图:

Provider-APNs.png

亟待肯定的大旨思想:

  1. 此一连由 App 的 bundle ID 唯一确定;
  2. 上图中 Provider certificate 须求通过开发者账号申请变更,其中蕴蓄 App
    的 bundle ID。

APNs 工作的流程

Provider-App.png

  1. 先是客户端须要向 APNs 服务器注册当前 App,APNs
    会再次回到一个Token(注意这么些历程须求 App
    有合法的证书,有关讲明那里不做详细描述);注意分歧拔取在同样设备上得到的
    Token 不一致,同一应用在不一致装备上赢得的 Token也不比,所以 Token
    是跟设备与 App 唯一绑定的;

  2. App 得到 Token 后必要将其发送给 Provider;

  3. Provider 发送推送公告时,指定 Token 和通知内容,并发送给 APNs
    服务器;

  4. APNs 服务器会将通报发送给 Token 对应的装备上;

  5. 设施收到公告后,根据 APNs 发过来的公告中包含的 bundleID
    音信分别是哪位App的长途文告(那里应该是按照 Token 来赢得 bundleID)。

Feedback 机制

Feedback 是 APNs
服务器提供的用来减少服务器压力以及优化互联网的劳务,基本的行事流程如下图:

APNs-Feedback.png

  1. Provider 发送一个远距离文告给 APNs 服务器,APNs
    服务器会检测目的设备是还是不是在线,如若不在线,那么 APNs
    服务器会暂存该新闻;

  2. 当目的设施上线后,APNs
    会发送暂存的信息给目标设备(根据苹果官方说法暂存新闻只会暂存最后一条新闻,从前的音信会被裁撤);

  3. 如果目标设备很久都未曾上线,那么 APNs 新闻会把该装置进入 feedback
    名单。Provider 可以定期去 APNs 拉新 feedback 名单;

  4. 当 Provider 再次给前边的配备发送远程布告时,必要检查一下 feedback
    名单,如果设备在那么些名单,则不再发送给 APNs 了;

  5. 当设备再次上线后,Provider 可以再将此设施移除 feedback 名单,当
    Provider 更新 feedback list
    后,就可以再度给该设备发送远程通告了。当然,feedback list
    的翻新可能会有周期,要是必要马上有效的换代 feedback list,那么需要App 打开后,及时公告 Provider;

  6. 那种体制的功利就是幸免发送多余无用的长途通告信息,一方面能够舒缓
    APNs 服务器的下压力,另一方面也足以削减网络流量;

开启远程文告功效

登记布告类型

  • 对于 iOS7,无需此步骤;
  • 对于 iOS8
    及其后的种类,若要求选拔远程布告功效,则要求注册布告类型。步骤与
    “本地公告的施用” 中 “开启本地布告功用” 是完全相同的,此处不再另行。

注册远程布告

着力流程为:

  1. 注册布告类型,上一小节已经做了介绍;
  2. 使用 registerForRemoteNotifications 注册远程布告(对于 iOS7 使用
    registerForRemoteNotificationTypes:);
  3. 使用 application:didRegisterForRemoteNotificationsWithDeviceToken:
    接收 APNs 返回的 Token,使用
    application:didFailToRegisterForRemoteNotificationsWithError:
    处理登记错误;
  4. 要是上一步骤中登记成功了,那么将获得的 Token 发送给 Provider。

注意:

  1. 此时此刻总的来说,对于 iOS9,每便重新安装应用后收获的 Token
    是不均等的,而且每便重装系统也会改变,所以
    老是应用启动时都急需按上边的手续注册一次

  2. 决不将事先的 Token 缓存,当要求将 Token 传送到 Provider
    时,一定要利用 registerForRemoteNotifications
    获取,并运用回调处理登记结果;当使用注册过通报,而且 Token
    没有改变时,系统会应声赶回结果,不会去 APNs 请求。那里揣度系统援助将
    Token
    缓存下来,且与利用的情形进行了事关,借使选择当前情状没有更改,那么会即时将系统存下的
    Token 重返。为了证实那一点,可以将互联网关闭举行测试,即便 App
    没有卸载,也是足以获取到 Token 的;

  3. 必然要有打开了 Push 功用的讲明,才能健康使用远程推送。

登记远程文告的示范代码如下:

- (void)registerRemoteNotifications {
    // 区分是否是 iOS8 or later
    if ([[UIApplication sharedApplication] respondsToSelector:@selector(registerForRemoteNotifications)]) {
        // 这里 types 可以自定义,如果 types 为 0,那么所有的用户通知均会静默的接收,系统不会给用户任何提示(当然,App 可以自己处理并给出提示)
        UIUserNotificationType types = (UIUserNotificationType) (UIUserNotificationTypeBadge | UIUserNotificationTypeSound | UIUserNotificationTypeAlert);
        // 这里 categories 可暂不深入,本文后面会详细讲解。
        UIUserNotificationSettings *mySettings = [UIUserNotificationSettings settingsForTypes:types categories:nil];
        // 当应用安装后第一次调用该方法时,系统会弹窗提示用户是否允许接收通知
        [[UIApplication sharedApplication] registerUserNotificationSettings:mySettings];
    } else {
        UIRemoteNotificationType types = UIRemoteNotificationTypeAlert | UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound;
        [[UIApplication sharedApplication] registerForRemoteNotificationTypes:types];
    }
}

- (void)application:(UIApplication *)application didRegisterUserNotificationSettings:(nonnull UIUserNotificationSettings *)notificationSettings {
    // Register for remote notifications.
    [[UIApplication sharedApplication] registerForRemoteNotifications];
}

// Handle register result.
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
    //获得 device token,这一步处理为字符串的操作很重要
    NSString *token = [[[deviceToken description]
                        stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"<>"]]
                        stringByReplacingOccurrencesOfString:@" "
                        withString:@""];
    NSLog(@"DeviceToken string, %@", token);
    [UIApplication sharedApplication].applicationIconBadgeNumber = 0;
    // 将 token 发送给 Provider
}

- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error {
    NSLog(@"Error in registration for apns service. Error: %@", error);
}

出殡远程通告

长途公告的情节

Provider 发送给 APNs 服务器的内容格式如下:

{
   // aps key 是必须要有的
   "aps" : {
      "alert" : {
         "title" : "通知的概要,对 8.2 以前的系统本选项无效"
         "body" : "通知的具体内容",
         "loc-key" : "GAME_PLAY_REQUEST_FORMAT",
         "loc-args" : [ "Jenna", "Frank"]
      },
      "badge" : 3, // 角标数值
      "sound" : “chime.aiff" // 可以自定义提示音
   },

   "userName" : "username", // aps key 之外可以有自定义内容,需要符合 json 格式
   "message" : ["hello", "world", "programmer"]
}

下面只是简单介绍了宽广的情节,如必要更进一步深度定制推送文告,提出查看:
苹果官方payload文档

长距离通告的本地化处理

有二种格局:

  • 在 Provider 端进行本地化
    App 可以将近日拔取的语言发送给 Provider,Provider
    在发送远程文告前,检查当前装备使用的语言,并抓实本地化后发送给 APNs
    服务器。App 发送当前利用的言语给 Provider 的示范代码:

    NSString *preferredLang = [[NSLocale preferredLanguages] objectAtIndex:0];
    const char *langStr = [preferredLang UTF8String];
    [self sendProviderCurrentLanguage:langStr]; // custom method
    

    诚如的话,将眼前系统语言音信发送给 Provider 时,也会将 Token
    一起发送,那样 Provider
    才可以在发送远程公告时根据差异目的设备开展本地化处理。
    别的,当使用启动后,用户可能会修改系统语言,那时,App 须要监听
    NSCurrentLocaleDidChangeNotification
    通告,并在处理通报的章程中重新向 Provider 发送当前利用的言语。

  • 在客户端本地化
    那种形式下,Provider 在发送远程文告时,要求设置 Payload -> alert
    中的本地化相关属性,如下:

    {
        // aps key 是必须要有的
        "aps" : {
            "alert" : {
                      "title" : "通知的概要,对 8.2 以前的系统本选项无效",
                      "loc-key" : "Remote Notification",
                      "loc-args" : [ "hello", "world"]
            },
            "badge" : 3, // 角标数值
            "sound" : “chime.aiff" // 可以自定义提示音
        }
    }
    

上面 loc-key 以及 loc-args 就是本地化相关的习性,用于地点化 alert 中的
body。
当 App 收到此信息时,会基于系统当下的语言设置去相应的本地化文件中查找与
loc-key 对应的 value,借使 loc-key 对应的 value
是一个格式化的字符串,那么可以用 loc-args 传递参数。

比方本地化文件中: “Remote Notification” = “大家程序员经常钟爱:%@ %@”
,那么提醒信息就是: “大家程序员钟爱:hello world”;

除此以外在本地化文件中大家也可以用 %n$@ 代替 %@ 用来表示使用 loc-args
的第多少个参数。例如:”Remote Notification” = “我们程序员经常钟爱:%2$@
%1$@”,那么提醒音讯是:”大家程序员钟爱:world hello”。

同等的,title-loc-key 和 title-loc-args 是对 alert 中的 title
做本地化的。

拍卖收到的中远距离布告

那里分二种情况钻探怎么样处理远程文告:

利用处于前台

动用处于前台时,本地公告到达时,不会有提醒音、布告栏横幅提醒。可是 App
桌面图标的右上角角标是有数值突显的,所以就是在前台,大家也应有对角标数量做拍卖;
此时,大家可以在
application:didReceiveRemoteNotification:fetchCompletionHandler:
方法中拿走到长途公告,示例代码如下:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(nonnull NSDictionary *)userInfo fetchCompletionHandler:(nonnull void (^)(UIBackgroundFetchResult))completionHandler {
    NSData *infoData = [NSJSONSerialization dataWithJSONObject:userInfo options:0 error:nil];
    NSString *info = [[NSString alloc] initWithData:infoData encoding:NSUTF8StringEncoding];
    [self.windowRootController displayNotification:[NSString stringWithFormat:@"From didReceiveRemoteNotification: %@", info]];
    // 这里将角标数量减一,注意系统不会帮助我们处理角标数量
    application.applicationIconBadgeNumber = notification.applicationIconBadgeNumber - 1;
}

使用处于后台

当使用处于后台时,远程文告到达时,会依照登记布告是设置的关照类型以及用户设置的公告类型举行提示,例如锁屏界面文告、通告栏通告、声音、角标。

那儿一经滑动锁屏界面布告或点击公告栏文告,则会切换应用到前台,大家可以运用与运用处于前台时一样的得到通告的措施。

不过一旦我们点击 App
桌面图标,则无法获取到用户通报,此时公告栏音信依然会设有。其它,角标也不会变卦,如若期望修改角标,则要求App 进入前台后将其修改。

使用尚未运行

那边有二种处理格局:

  • 与地方文告的处理格局相同,在
    application:didFinishLaunchingWithOptions: 的 LaunchOptions
    中赢得文告,不过里面代码会略有差别,示例如下:

    - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
        NSDictionary *remoteNotif = [launchOptions objectForKey:UIApplicationLaunchOptionsRemoteNotificationKey];
        if (remoteNotif) {
            NSData *infoData = [NSJSONSerialization dataWithJSONObject:remoteNotif options:0 error:nil];
            NSString *info = [[NSString alloc] initWithData:infoData encoding:NSUTF8StringEncoding];
            [self.windowRootController displayNotification:[NSString stringWithFormat:@"From didFinishLaunch: %@", info]];
            [UIApplication sharedApplication].applicationIconBadgeNumber -= 1;
        }
        // Your own other codes.
        return YES;
    }
    
  • 与行使处于前后台时处理格局相同,使用application:didReceiveRemoteNotification:fetchCompletionHandler:
    方法,示例代码见 “应用处于前台”
    时的处理。对于远程公告,推荐使用此种方式处理。

    其余,对于远程通告,若是大家点击 App
    桌面图标,则无从获取到用户通报,此时通告栏信息如故会设有。其它,角标也不会扭转,假如指望修改角标,则需求App 进入前台后将其修改。

长途文告-静默推送

沉默推送是指利用在前台或后台状态下,收到远程通告时,没有弹窗或横幅提醒,即便处在后台也得以处理远程文告。具体应用流程如下:

  1. 开拓应用工程 Target 的 Capacities,将 Background Modes
    选项打开,并且勾选 Remote Notifications;

  2. 在 Provider 发送远程通告时,需要将远程公告 Payload 中的 aps 内的
    content-available 设置为 1,如下:

     aps {  
         content-available: 1
         alert: {...}
     }
    
  3. 应用需要贯彻
    application:didReceiveRemoteNotification:fetchCompletionHandler:亚洲必赢app在哪下载,
    方法接收静默推送。

有几点需求留意:

  1. 采纳静默推送时,alert 字段不该其余新闻,但足以设置 aps
    内的自定义字段;
  2. sound 和 badge 字段可以安装,但最好不安装,否则会有提醒音;
  3. 敦默寡言推送唯有当使用处于前台或后台时才能处理,当使用尚未启动时是收不到静默推送的;
  4. 拍卖静默推送时,无法做耗时操作,因为系统只为那种处理作为分配少量小时,如下载文件之类的操作请使用后台下载服务。

可操作文告

先是须求专注的是,可操作布告只适用于 iOS8 及随后的连串。

可操作公告其实并不是一种新的通报形式,它只是在那地点通告和远程公告的根底上加了有些可操作的一言一动而已。为了直观表达怎么样是可操作文告,可以参见下图:

Actionable-Notification.png

可操作通告为用户提供了在通告提示中有益执行操作的主意,在行使横幅提醒布告信息时,最多可以有八个操作,在选择弹窗提醒布告音讯是,最多可以有八个操作。上边讲解怎么样接纳:

四:定义可操作文告的行事

大旨使用办法:

  1. 创办一个 UIMutableUserNotificationAction
    对象,并按须要布署该对象的属性,示例代码:

    UIMutableUserNotificationAction *acceptAction = [[UIMutableUserNotificationAction alloc] init];
    // 为该操作设置一个 id
    acceptAction.identifier = @"accept";
    // 设置该操作对应的 button 显示的字符串
    acceptAction.title = @"Accept";
    // 指定是否需要应用处于运行状态
    acceptAction.activationMode = UIUserNotificationActivationModeBackground;
    // 表示该操作是否有害,若设置为 YES,则对应的button会有高亮
    acceptAction.destructive = NO;
    // 当锁屏时收到可操作通知,该属性表示是否必须解锁才能执行该操作
    acceptAction.authenticationRequired = YES;
    
  2. 创造一个 UIMutableUserNotificationCategory
    对象,并将自定义的操作通过 setActions: 的格局设置给 category
    对象。代码如下:

    // 这里为了测试,又新建了两个 action,declineAction 和 maybeAction ,代码可见 demo
    UIMutableUserNotificationCategory *inviteCategory = [[UIMutableUserNotificationCategory alloc] init];
    // 设置一个 ID,用于本地通知或远程通知时指定该通知可执行的操作group
    inviteCategory.identifier = @"Action";
    // 为弹窗模式设置 actions
    [inviteCategory setActions:@[acceptAction, maybeAction, declineAction] forContext:UIUserNotificationActionContextDefault];
    // 为横幅模式设置 actions
    [inviteCategory setActions:@[acceptAction, declineAction] forContext:UIUserNotificationActionContextMinimal];
    
  3. 登记通告类型以及可操作的actions

    看似于地面通告和远程通告,调用 registerUserNotificationSettings:
    注册公告,只是这里的 setting 插手了大家地点定义的 category。

    NSSet *categories = [NSSet setWithObjects:inviteCategory, nil];
    // 这里 types 可以自定义,如果 types 为 0,那么所有的用户通知均会静默的接收,系统不会给用户任何提示(当然,App 可以自己处理并给出提示)
    UIUserNotificationType types = (UIUserNotificationType) (UIUserNotificationTypeBadge | UIUserNotificationTypeSound | UIUserNotificationTypeAlert);
    // 这里 categories 可暂不深入,本文后面会详细讲解。
    UIUserNotificationSettings *mySettings = [UIUserNotificationSettings settingsForTypes:types categories:categories];
    // 当应用安装后第一次调用该方法时,系统会弹窗提示用户是否允许接收通知
    [[UIApplication sharedApplication] registerUserNotificationSettings:mySettings];
    

一旦将可进行布告用于远程通告,那么须求依据长途公告的挂号形式得到token,可参考远程公告的登记。

发送可操作公告

前边说过,可操作文告只是在当地公告和长途文告的根底上加了自定义的操作,所以发送可操作文告就是殡葬本地公告或远程公告。然而,倘使指望我们自定义的
action 有效,在殡葬本地通告或远程通告时索要进行部分改变:

  • 本土文告的可操作文告
    为 UILocalNotification 对象设置大家自定义的 category。如下:

    UILocalNotification *notification = [[UILocalNotification alloc] init];
    // Other configurations
    notification.category = @"Action";
    [[UIApplication sharedApplication] scheduleLocalNotification:notification];
    
  • 长途文告的可操作布告
    在远距离布告的 Payload 中装置大家自定义的 category,如下:

    {
        "aps" :  {
            "alert" : "You’re invited!",
            "category" : "Action"
        }
    }
    

处理可操作公告

拍卖可操作通知与处理位置布告和长途通知一致,唯一的不一样点就是当用户执行了某个操作后,应用可以在后台运行application:handleActionWithIdentifier:forRemoteNotification:completionHandler:
处理通报(例如后台更新数据等操作),我们可以在这一个回调里快速的履行操作:

- (void)application:(UIApplication *) application
              handleActionWithIdentifier: (NSString *) identifier
          // either forLocalNotification: (NSDictionary *) notification or
                   forRemoteNotification: (NSDictionary *) notification
                       completionHandler: (void (^)()) completionHandler {

    if ([identifier isEqualToString: @"accept"]) {
        [self handleAcceptActionWithNotification:notification];
    }

    // 执行自定义代码完成后必须调用
    completionHandler();
}

对于当地通告大家得以采纳
application:handleActionWithIdentifier:forLocalNotification:completionHandler:

可操作文告到底有啥利益?

此处举个例证表达:
要是A向B发出了一个列席揭橥会特邀,并且 App
是以长途布告的章程接受到该音讯,那么当不接纳可操作通告的时候,大家需求做的业务要害概括:

  1. 用户要求开拓应用;
  2. App 查看远程通告的内容是一个诚邀,那么 App
    应该弹窗提醒用户是不是接受该诚邀;
  3. 用户挑选后,App 通过 Http(也可以应用别的通讯协议)
    将结果重临给服务器;
  4. 约请公告处理达成。

那么,假诺大家利用可操作文告,可以很不难的成功那件业务:

  1. 用户挑选接受或拒绝约请(用户无需打开 App);

  2. App 通过可操作文告的回调处理用户操作结果,将结果发送给服务器;

  3. 特约布告处理落成。

    可以看到,不论是从用户角度依旧开发者角度,可操作布告都大幅度的便民了拍卖具有可操作动作的那类通告。

五:总结

到这边曾经讲解落成了用户通报的情节,作品包涵了苹果给出的用户通报的骨干具备用法,倘诺想要确认文档是或不是有误可自动参考
Local and Remote Notification Programming
Guide

,如果本文中情节有误,欢迎提出与研讨。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图
Copyright @ 2010-2019 亚洲必赢app官方下载 版权所有