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
0
170
俺が考える最強のPush Receiver
FCMとReproを共存させるためにちょっと考えてみた
hayashi hirotake
August 28, 2018
Tweet
Share
More Decks by hayashi hirotake
See All by hayashi hirotake
第2回カスタマー系エンジニア座談会
hiroxy
0
340
Monaca UG Conference 2019
hiroxy
0
25
Career Kaigi 2019
hiroxy
0
44
Repro Tech Meetup #CRE
hiroxy
2
740
Intercom Kickoff
hiroxy
0
340
Other Decks in Technology
See All in Technology
非同期推論システムによるコスト削減と信頼性向上
koki_nishihara
1
360
LLM開発・活用の舞台裏@2024.04.25
yushin_n
3
1.2k
Rustで「プリズモイダル法」を利用して「土量計算」をガチでやる
nokonoko1203
1
290
How to do well in consulting–Balkan Ruby 2024
irinanazarova
0
140
Max out Local LLM in Challenging Environments
sashimimochi
1
110
今年のRubyKaigiはProfiler Year🤘
osyoyu
0
360
【SORACOM UG 東海】あらゆるモノがつながる社会へ、IoT と SORACOM
soracom
PRO
1
140
JAWS-UG Bedrock Claude Night
yamahiro
3
700
生成AIの変革の時代に、直近1年で直面した課題とその解決策
ktc_wada
0
590
自己改善からチームを動かす! 「セルフエンジニアリングマネージャー」のすゝめ
shoota
6
1k
DMM.com アルファ室採用案内資料
hsugita
1
220
VSCodeの拡張機能を作っている話
ebarakazuhiro
1
800
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
20
1.6k
Art, The Web, and Tiny UX
lynnandtonic
290
19k
Bash Introduction
62gerente
605
210k
Designing Experiences People Love
moore
136
23k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
501
140k
Atom: Resistance is Futile
akmur
260
25k
The MySQL Ecosystem @ GitHub 2015
samlambert
244
12k
Producing Creativity
orderedlist
PRO
338
39k
Designing for humans not robots
tammielis
248
25k
10 Git Anti Patterns You Should be Aware of
lemiorhan
649
58k
Reflections from 52 weeks, 52 projects
jeffersonlam
345
19k
Product Roadmaps are Hard
iamctodd
45
9.7k
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