プッシュメッセージのカスタマイズ
プッシュメッセージのカスタマイズ プッシュメッセージを送信する際、APNs では制御用フィールドを使ってプッシュ通知の詳細動作をカスタマイズすることができます。 Kii Cloud でプッシュメッセージを送信する際は、ユーザープッシュ通知 (Push to User) と 管理者メッセージのプッシュ通知（Direct Push） で、ここに示す制御用フィールドを設定できます。サーバー上変更のプッシュ通知（Push to App） では Kii Cloud でのデフォルトの設定が使用され、設定できません。 APNs の通知メッセージに含まれるデータのうち、特に重要なものを以下に示します。これらの詳細な解説や、その他のタグは 公式ドキュメント をご覧ください。 下記の制御用フィールド以外にも、プッシュメッセージの内部にモバイルアプリで使用するカスタムデータを含めることができます。APNs では
Apple Push Notification Serviceのエラー処理について
iOSアプリにPush通知をするのに利用するApple Push Notification service(APNs)について。配信数がある程度の規模になると面倒事が増えるのでまとめた。 本稿では疎結合なサービスとして稼動させるPush通知配信サーバーを考える。 Push通知配信サーバーの機能要件 個々のアプリケーションから分離したPush通知配信サーバーを考える場合、要件は大きく分けて次の二つになるだろう。 A. デバイストークンを溜め込んでおき、配信日時を指定して一斉に配信する ゲームのイベントが始まった事を全ユーザーに通知したい ユーザーセグメントを指定してキャンペーンの通知をしたい B. 都度送信対象のデバイスをアプリケーションから受け取って即時配信をする チャットルームで発言がある度に、チャットルームのメンバーに通知をしたい ユーザー間のmentionを通知したい Bの場合は、ア
iOS8アップデートでアプリへのプッシュ通知でハマる点 - Qiita
iOS7対応で既に盛大に苦しんだ方はハマってないはずですが… iOS8でAPNsへデバイス登録する際のメソッドが変わった、とは別の話です。 ※予めお断りしておきますが、検証は各自でお願いします。 （自分はiOS Appのdeveloperでもなんでもないです） iOS8アップデートとプッシュ通知 アプリをインストールした状態でiOSをアップデートした場合にプッシュ通知でハマる場合がある こんなアプリがハマる アプリ内部にデバイストークンが無い場合のみAPNsにデバイス登録&トークン発行するアプリ （実質、初回起動時のみしかデバイス登録しないタイプのアプリ） なぜハマるか iOSアップデート後、再度APNsへのデバイス登録を行わなければプッシュ通知が行えない ※ちなみに再登録後のデバイストークンはiOSアップデート前と同じ なので、APNsへのデバイス登録が必要なのだが、上記のハマるタイプの
AWS SNSを使ってiOSへpush通知 - Qiita
#import <AWSCore/AWSCore.h> #import <AWSS3/AWSS3.h> #import <AWSDynamoDB/AWSDynamoDB.h> #import <AWSSQS/AWSSQS.h> #import <AWSSNS/AWSSNS.h> #import <AWSCognito/AWSCognito.h> APNsのための証明書&ProvisiongProfile発行 続いてMemberCenterにて証明書を発行します。 AppIDの作成 まずはAppIDの作成から行います。 App Nameは適当な名前でも大丈夫ですが、Explicit App IDにはXCodeのBundleIdentifierと同様の値を入力します。 App Servicesのpush Notificationにも忘れずにチェックを入れます。 あとは流れに沿って作成します。
Google Cloud MessagingでAndroidとiOSにプッシュ通知 後編
前回ご紹介した、Android・iOSの両方にプッシュ通知を送信できる新しいGCM。今回は、その国際化対応と、アプリ側の対応方法についてご紹介します。 GCMへのプッシュ通知要求は、必要な項目を詰め込んだJSONを、GCMコネクションサーバーへとPOSTすることで行えます。 そのJSONのフォーマットは公式リファレンスで触れられていますが、本来、AndroidとiOSのそれぞれの端末に届くプッシュ通知は、それぞれフォーマットが異なっています。それをきちんと両方に対応させる、すなわち 全く同じJSONを送信し、両OSそれぞれに適切な通知が受信される ようにするためにはどうすればよいでしょうか。 また、新しいGCMの大きな特徴である、 標準フォーマットの通知であれば、アプリ側が通知表示に関するコードを一切書く必要がない 両OSで統一したローカライズができる を満たすにはどうしたらよいでしょうか
Elixir+PhoenixでAPNsを利用したPush通知を送る簡単なAPIをつくってみる - Qiita
はじめに Advent Calendar童貞を捨てに来ました。 前提 以前"Elixir+PhoenixでGCMのAPIを叩いてPush通知を送る簡単なAPIをつくってみた"という記事で、ElixirでAndroidアプリにPush通知するWebAPIをつくったので、その続きとしてiOSアプリにPush通知するWebAPIをつくってみます。 ですので、環境構築などは前回の記事をご覧いただければと思います。 Apns4exインストール 最初張り切って自前で実装しようとした（無謀）のですが、Apns4exというよさげなライブラリがあったので、そちらを利用させていただきました。 ~mix.exsのdepsとapplicationの箇所にApns4exの設定を追加します。 defp deps do [{:phoenix, "~> 1.0.3"}, {:phoenix_ecto, "~> 1.1"}
iOSのPUSH通知(APNS)の特徴・ノウハウまとめ(iOS 9まで対応) - Qiita
今開発しているPlayer!で、チャット系のリアルタイム更新処理が必要となったので、色々調べながらまとめています。 分量が多いので、とりあえずまずは小出しにAppleのPUSH通知の特徴・ノウハウについてまとめたものを公開します。 → 「リアルタイム更新処理」全体にフォーカスした記事も書きましたヽ(・ω・｀） iOS - チャットなどリアルタイム更新が必要なスマフォアプリの構成について考えてみた - Qiita アプリが終了状態になっていてもサーバーから通知出来る唯一の手段 まず当たり前のことからですが、最大の特長だと思います。 この理由によって、双方向通信などを併用するにしてもPUSH通知対応は必須です。 (サーバー経由でなければ、位置情報トリガーなど他にもいくつか終了状態から起こす方法は存在します。) ユーザーにPUSH通知を不許可にされたら届かない さらに、初回の確認で不許可にされた
Remote Push からの Background Fetch を試してみた - griffin-stewieのブログ
前回は Background Fetch を試してみました。この方法ではアプリだけの実装でバックグラウンドで通信処理等を走らせる事ができますが、実行タイミングが OS 側の学習によるもので任意のタイミングでは発動させることができません。iOS 7 からは Background Fetch 以外にも Remote Push Notification をトリガーに Background Fetch を実行させる機能も追加されています。Remote Push Notification を送るためのサーバサイドの準備が必要ですが、任意のタイミングで実行できる（Rate Limit はあります）のは魅力的です。APNs 環境を作ったことがない僕が APNS 環境の構築から Remote Push Notification から Background Fetch を動かすまでのメモを残しておきます。
APNSの確認ダイアログを再表示する方法 - Qiita
Push通知の確認ダイアログの表示タイミングを色々テストするときに、再表示させるためのデバイスの操作を毎回忘れるのでメモ。 手順 アプリをアンインストールして1日以上経過した状態を作りだすのが重要みたい。再起動は面倒だけど省くと上手くいかないです。 デバイスの時刻を自動設定から手動に変更 アプリをアンインストール デバイスを再起動 iPhone の時刻を1日以上未来に手動で変更 デバイスを再起動 アプリを再インストール 参考 Troubleshooting Push Notifications The first time a push-enabled app registers for push notifications, iOS asks the user if they wish to receive notifications for that app. Once the use
25.Google App Engine/Java 1.7.7でiPhoneにPush通知してみた
◯Google App Engineは1.7.7から外向きのSocke通信をサポート Google App Engine 1.7.7から外向きのSocket通信がサポートされました。 それに伴い、 AppEngineから直接APNSサーバーと通信してiOSにPush通知を送信することもできるようになりました。 これまではAppEngineのアプリからAPNSサーバーにPush通知を送信するためには、 別の環境(EC2やElastic Beanstalkなど)に踏み台にするWebアプリを配置して、 以下のような構成にする必要がありました。 AppEngine → [httpsで通信] → 踏み台のWebアプリ →[Socket通信]→ APNSサーバー これはAppEngineから外部サーバーに対する接続が制限されていたためで、 AppEngineから外部のサーバーに対して許可されているht
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
