Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
俺が考える最強のPush Receiver
Search
hayashi hirotake
August 28, 2018
Technology
230
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
俺が考える最強のPush Receiver
FCMとReproを共存させるためにちょっと考えてみた
hayashi hirotake
August 28, 2018
More Decks by hayashi hirotake
See All by hayashi hirotake
第2回カスタマー系エンジニア座談会
hiroxy
0
440
Monaca UG Conference 2019
hiroxy
0
45
Career Kaigi 2019
hiroxy
0
76
Repro Tech Meetup #CRE
hiroxy
2
870
Intercom Kickoff
hiroxy
0
430
Other Decks in Technology
See All in Technology
非定型なドキュメントを効率よくリファクタする 〜えぇ!?仕様書27本の移行が1日で終わったって!?〜
subroh0508
2
570
SREとQA 二人三脚で進めるSLO運用/sre-qa-slo
sugitak
0
990
Terraform共通モジュールをチーム横断で“変えられる”運用へ ― リリースと適用の分離
kekke_n
1
3.4k
タスクの複雑さでモデルを選ぶ ── Thompson Samplingで動かす“トークン/コスト最適化
satohy0323
0
570
LLM/Agent評価:トップ営業の発言を「正解」にする 〜暗黙的正解による評価を営業資産に変える〜
takkuhiro
1
230
AIレビューはどこまで任せられるのか?自動化と人が背負うレビューの境界
sansantech
PRO
3
1.1k
穢れた技術選定について
watany
17
5.6k
生成AI×AWS CDK×AWS FISで"振り返れる"ミニGameDayをつくろう
yoshimi0227
1
420
カードゲーム作りが教えてくれた プロダクトオーナーシップ
moritamasami
0
110
インシデント事例と パッケージの全量解析に学ぶ ソフトウェアサプライチェーンの守り方 / supply-chain-attack-defense
flatt_security
0
120
AI、CDK と協働する Full TypeScript アプリケーション開発 / Full TypeScript Application with AI and CDK
geekplus_tech
2
400
ゴールデンパスは敷いただけでは道にならない ─ 企画部門のエンジニアが技術標準を事業価値に変えるまで
mhrtech
1
230
Featured
See All Featured
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.6k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
180
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
Everyday Curiosity
cassininazir
0
260
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.5k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
190
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.6k
Un-Boring Meetings
codingconduct
0
350
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
1
2k
Heart Work Chapter 1 - Part 1
lfama
PRO
8
36k
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
400
Transcript
REPRO TECH MEETUP #2 Navigate : Space / Arrow Keys
| - Menu | - Fullscreen | - Overview | - Blackout | - Speaker | - Help M F O B S ? 1 / 37
INTRO @hiroxyy_ hiroxyy Repro CRE Team Leader 3名 Technical
Support Main: Android(半年ちょい) [ GitPitch @ github/hiroxyy/slides ] 2 / 37
最近こんな問い合わせが ありました [ GitPitch @ github/hiroxyy/slides ] 3 /
37
FCMを既に使っていて ReproのPushを受信するためには どうしたらいいですか? [ GitPitch @ github/hiroxyy/slides ]
4 / 37
よしなに実装して まじで ほんとに 頼むから [ GitPitch @ github/hiroxyy/slides ]
5 / 37
そんなCREイケてないよね [ GitPitch @ github/hiroxyy/slides ] 6 /
37
イケてるCREに僕はなりたい [ GitPitch @ github/hiroxyy/slides ] 7 /
37
作っちゃおう [ GitPitch @ github/hiroxyy/slides ] 8 /
37
俺が考える最強の Push Receiver [ GitPitch @ github/hiroxyy/slides ] 9
/ 37
余談なんですがPUSHのサービス [ GitPitch @ github/hiroxyy/slides ] 10 / 37
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Repro Amazon Simple Notification Service mobile backend Appvisor push CORE PUSH Growth Push Kii Cloud Urban Airship PushWoosh MAJIN [ GitPitch @ github/hiroxyy/slides ] 11 / 37
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
OneSignal pushnate push7 LOGBASE batch Braze kumulos SWRVE Upsight Accengage [ GitPitch @ github/hiroxyy/slides ] 12 / 37
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Catapush Mapp Leanplum OneSignal Intercom Pusher Carnival.io PushBots Localytics Kahuna [ GitPitch @ github/hiroxyy/slides ] 13 / 37
1. 2. 3. Taplytics Mixpanel StreetHawk [ GitPitch @ github/hiroxyy/slides
] 14 / 37
めっちゃある [ GitPitch @ github/hiroxyy/slides ] 15 /
37
自分好みのサービス探すのも 面白そう [ GitPitch @ github/hiroxyy/slides ] 16 /
37
余談終わり [ GitPitch @ github/hiroxyy/slides ] 17 / 37
れっつら最強RECEIVER! [ GitPitch @ github/hiroxyy/slides ] 18 / 37
の前に AndroidのPushについて 簡単におさらい [ GitPitch @ github/hiroxyy/slides ] 19
/ 37
ANDROIDのPUSH表示処理 1. ブロードキャストされたintentを BroadcastReceiverで受信 intentに含むキーによって、Data Messageと Notification Messageの2つに分類される 2. 受信したintentをReceiverでハンドリングし、
端末上に表示 [ GitPitch @ github/hiroxyy/slides ] 20 / 37
AndroidManifest.xml 01 // Firebase Push Service 02 <service 03 android:name=".MyFirebaseMessagingService">
04 <intent-filter> 05 <action android:name="com.google.firebase.MESS 06 </intent-filter> 07 </service> 08 09 // Repro Push Receiver 10 <receiver 11 android:name="com.hiroxy.multipushapp.MyGCMReceive [ GitPitch @ github/hiroxyy/slides ] 21 / 37
FCM Repro Notification Message FG:◯ BG:✕ FG:◯ BG:◦ Data Message
FG:◯ BG:◦ FG:◯ BG:◦ FCM Serviceと Repro Receiverの比較 [ GitPitch @ github/hiroxyy/slides ] 22 / 37
いい感じにハンドリングしないと、 FCMとREPRO両方に処理されて端末上 で同じPUSHが2通とか出ちゃう! [ GitPitch @ github/hiroxyy/slides ]
23 / 37
たまにそういうアプリあ、、、 [ GitPitch @ github/hiroxyy/slides ] 24 / 37
どうしたら良さそうか? [ GitPitch @ github/hiroxyy/slides ] 25 /
37
FirebaseMessagingServiceでは ハンドリングできないmessageがある Repro Receiverを使うのが良さそう [ GitPitch @ github/hiroxyy/slides ]
26 / 37
MyGCMReceiver.java 01 package com.hiroxy.multipushapp; 02 03 … 04 05 public
class MyGCMReceiver extends BroadcastReceiver { 06 07 private static final String TAG = "GCMReceiver"; 08 09 @Override 10 public void onReceive(Context context, Intent inte 11 中身を確認 [ GitPitch @ github/hiroxyy/slides ] 27 / 37
INTENT比較 FCMからのPush(notification message)のintent 01 google.c.a.udt:0 02 google.sent_time:1535343208004 03 google.ttl:2419200 04
gcm.notification.e:1 05 google.c.a.c_id:5316713855114895493 06 google.c.a.ts:1535343208 07 gcm.notification.title:From FCM //titleっぽい 08 gcm.n.e:1 09 from:918839616658 10 google.message_id:0:1535343208043592%c3f2cc90c3f2cc90 11 gcm.notification.body:fcm notification message from hi [ GitPitch @ github/hiroxyy/slides ] 28 / 37
ReproからのPush(data message)のintent 01 google.sent_time:1535339920264 02 google.ttl:2419200 03 body:data message from
hiroxyy // 定義したkey 04 from:918839616658 05 repro:n3ylk7yd // repro独自のkey 06 title:From Repro // 定義したkey 07 google.message_id:0:1535339920272127%c3f2cc90f9fd7ecd 08 google.priority:normal [ GitPitch @ github/hiroxyy/slides ] 29 / 37
MyGCMReceiver.java 01 package com.hiroxy.multipushapp; 02 03 … 04 05 public
class MyGCMReceiver extends BroadcastReceiver { 06 07 private static final String TAG = "GCMReceiver"; 08 09 @Override 10 public void onReceive(Context context, Intent inte 11 中身を確認 [ GitPitch @ github/hiroxyy/slides ] 30 / 37
全部のメッセージをハンドリングする RECEIVERを作るとなかなかカオス [ GitPitch @ github/hiroxyy/slides ] 31
/ 37
notificationもdataもやることは一緒 カスタマイズ性の高いdata messageだけを 利用するようにした方がReceiverの処理を スッキリ書けそう となると、FirebaseMessagingServiceを 利用するのもあり [ GitPitch @
github/hiroxyy/slides ] 32 / 37
利用するMESSAGEやサービス毎に RECEIVERを作ったほうが良さそう? [ GitPitch @ github/hiroxyy/slides ] 33 /
37
FIREBASEのようにSERVICEで ハンドリングするようにするのは どうだろう? [ GitPitch @ github/hiroxyy/slides ] 34
/ 37
最強にはまだまだ遠かった! [ GitPitch @ github/hiroxyy/slides ] 35 /
37
これからも良いアプリ設計を 提案できるように頑張ってこう! [ GitPitch @ github/hiroxyy/slides ] 36
/ 37
おわり ありがとうございました! [ GitPitch @ github/hiroxyy/slides ] 37 /
37