Apple Push Notification (APN) 使用時の delegate の挙動について、 iOS 7以降 / iOS 6以前の差をまとめた iOS 7以降とiOS 6以前で、俗にいうリモートPush通知の受け取り方と受け取った際の挙動がまるで違っているので、最近リモートPush通知を実装した時につまづいた箇所をまとめてみました。 使用するdelegate methodの違い いかなる種類のPush通知においてもapplication:didReceiveRemoteNotification:fetchCompletionHandler:を使用します。 application:didReceiveRemoteNotification:fetchCompletionHandler:とapplication:didReceiveRemoteNotification:が両方実装され
連載目次 プッシュ通知とは？ なぜ開発者はアプリにプッシュ通知機能を搭載するのか スマートデバイスにおける「プッシュ通知」はアプリにとって欠かせない機能の一つであり、メールマガジンと同様に重要な集客ツールです（図1）。スマートフォンをお使いの方でしたら、一度はプッシュ通知を受け取ったことがあるのではないでしょうか。 プッシュ通知はユーザーがスマートデバイスを起動していなくても通知を送ることができる仕組みであり、以下の特徴があります。 開くと直接アプリを起動するためアクションにつながりやすい アプリをインストールしているユーザーのみに届くため開封率が高い 上記のような特徴から、プッシュ通知は以下の用途で使うことが多くなります。 リアルタイムな情報配信 直接アプリ起動につながるため、ニュースなどリアルタイム性の高い情報の配信に向く ユーザーのアクティブ率向上 開封率が高いため、定期的にアプリを
もしかしたらよく知られていることなのかもしれないけど、割とハマったのでメモ。 iOSアプリでプッシュ通知機能のテストは結構面倒である。特に面倒なのが、アプリ初回起動時の挙動のテスト（以下の画像参照）。 iOSのプッシュ機能は以下のような流れで設定される。 アプリ起動時にregisterForRemoteNotificationTypesメソッドを呼ぶ 端末はアップルのサーバー(APNs)と通信して、プッシュのためのデバイストークンを取得 アプリの初回起動時にのみiOSが「＜アプリ名＞はあなたにプッシュ通知を送信します。よろしいですか？」というアラートを表示する 「はい」ボタンを押すと、APNsに端末が登録されプッシュを受信できるようになる で面倒なのが、初回起動時のみに表示されるアラートのテスト。このアラートは本当に初回起動時にしか表示されず、アプリを一度削除して、再度インストールしても、
プッシュ通知を実装するときに、「バックグラウンドで通知受けたときはapplication:didFinishLaunchingWithOptions:とapplication:didReceiveRemoteNotification:、どっちが呼ばれるんだっけ？」とかなんだかいつも自信なくなってきてドキュメントを見返したりしてしまうので、ドキュメントと、実際の動作を確認した内容をまとめておきます。 （参考ドキュメント） Local Notification および Push Notification プログラミングガイド（日本語） （英語・最新版） アプリがバックグラウンドで動作中に通知が配信された場合の挙動 この場合、システムは、警告の表示、アイコンのバッジの表示、また、サウンドの再生を行う ことで通知を提示します。 アクションボタンがタップされると、システムはアプリケーションを起動しま
本連載「Apple Geeks」は、Apple製ハードウェア／ソフトウェア、またこれらの中核をなすOS X／iOSに関する解説を、余すことなくお贈りする連載です（連載目次はこちら）。 UNIX使い向けを始め、Apple関連テクノロジー情報を知りつくしたいユーザーに役立つ情報を提供します。 プッシュ通知とローカル通知、ここが違う 「プッシュ通知」とひと括りにされがちなiOSの通知機能だが、正確には「リモート通知」と「ローカル通知」の2種類がある。前者はメールの到着を知らせるなどの目的のためiOS 3で登場し、後者は前者と同等の機能を端末内部で実現するためにiOS 4で追加された。ユーザーの目には同じ「プッシュ」に映るが、使用するクラス（UIRemoteNotification／UILocalNotification）は分かれている。 このふたつの機能には、動作に関して決定的な違いがある。リモ
http://keima.herokuapp.com/ 「えーpolling!? pollingが許されるのは小学生までだよねー、キャハハハ」というわけでpush通知にWebSocketをお使いのみなさま、こんにちは。 しかし、毎回、WebSocketを扱う機能を実装するのは、いくつかの理由で面倒ですよね! WebSocketは様々なバージョンがあるので、すべてに対応するのは面倒。 同様の理由で、個別のアプリで作り込んでしまうと、WebSocketのバージョンアップに追従するのが面倒。 WebSocketは大抵別サーバになっているので、設定が面倒。 Heroku等のPaaSではWebSocketを使えないことが多い。 (2015/1/23追記: HerokuはWebSocketをサポートするようになりました) そこで、WebSocketによるpush通知に特化したWebサービス Keima
はじめに 初めまして。NTTアドバンステクノロジの金城と申します。幸運にも記事を執筆させていただけることになりました。WebSocketという新しいウェブの規格についての連載を、全4回の予定でお届けします。 用語統一について WebSocketは「WebSocket」「WebSockets」、単語を切り離した「Web Socket」等、表記に揺れがあります。2009年12月22日のワーキングドラフトのタイトルは「The Web Sockets API」となっていますが、2010年4月26日のエディターズドラフトでは「The WebSocket API」となっています。この連載では、最新の仕様書に則り、用語を「WebSocket」で統一します。 HTML5とWebSocketの関係 WebSocketは、もともとHTML5の一機能として仕様の策定が進められていました。しかし、Web S
▼1 IPポート待ち受け 通信量 A 消費電力 B 即時性 A ▽実装方法 ポートを開いて待つ。 ▽実装例 ・各種サーバー。 ▽メリット ・IP通信ができれば何でも実装できる。 ・パケットが飛んでこなければそれほど電力を消費しない。 ▽デメリット ・Public IPでないと無理。 ▼2 ポーリング(フェッチ) 通信量 B 消費電力 A 即時性 C ▽実装方法 定期的にクライアントからサーバーに接続を行い、状態の変化を問い合わせる。 ▽実装例 ・POP, IMAP 等Client色々。 ▽メリット ・IP通信ができれば何でも実装できる。 ・ポーリング間隔によるがそれほど電力を消費しない。 ・ポーリングしていない時間は通信部の電源を落とせる。 ▽デメリット ・そもそもプッシュじゃない。ポーリングが行われるまで状態の変更がわからない。 ・定期的に通信を行う必要がある。 ▼3 コネクション張りっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く