애플리케이션은 이제 작동하고 사용자는 로그인했으며 제품은 재참여 흐름이 원生的 느낌을 원합니다. 장바구니 알림. 리뷰 제안. 새로운 메시지 알림. 출시 발표. 첫 번째 직관은 종종 "푸시를 단순히 연결"이라고 생각하지만, 한 주 후에는 한 기기에서 알림이 오는 이유를 debug하는 중일 때 simulator는 정상적으로 등록되는 것처럼 보이면서 nobody도 왜 탭이 올바른 화면을 열지 않는지 설명할 수 없을 때가 있습니다.
이것은 Expo 푸시 알림이 EITHER 즐겁게 간단하거나 놀랍게도 약한 경우입니다.
Expo는 React Native 팀에게 APNs와 FCM에 대한 실용적인 층을 제공한다. 이는 많은 팀이 사용하는 이유이기도 하다. 하지만 데모와 실제 배포 준비 구현 사이의 격차는 실제로 존재한다. 토큰 생명 주기, 권한 타이밍, 리스너 설정, 페이로드 디자인, 백엔드 청소 등 모든 것이 중요하다. 또한 빈번한 앱 로직 변경을 통해 배송하는 경우, 운영 절차의 엄격함이 더욱 필요해지며, 신뢰할 수 있는 메시징과 릴리즈 속도에 의존하는 유지율 작업이 더욱 중요해진다. 이는 더 넓은 우려의 바탕이기도 하다. 모바일 앱 사용자 유지 관리 작업: 사용자 경험을 예측할 수 있는 환경에서만 배달이 유용합니다.
목차
- Expo Push Notification을 사용하여 사용자와 상호 작용하는 데 필요한 기초
- 초기 프로젝트 설정 및 구성
- 권한 요청 및 푸시 토큰 캡처
- 서버에서 알림을 보내는 방법
- 앱에서 들어오는 알림을 처리하는 방법
- 프로덕션 최적화 및 일반적인 오류
Expo Push Notification과 사용자 참여를 위한 기초
An Expo Push Notification 설정은 주로 한 가지 이유로 매력적이다. native messaging 복잡성을 제거하여 팀이 첫날부터 소유하고 싶지 않기 때문이다. APNs 및 FCM 플러밍을 직접 구축하기 전에, Expo의 게이트웨이와 함께 작업하여 제품 동작, 경로, 권한 UX, 백엔드 메시지 논리에 집중할 수 있다.
추상화는 푸시가 '진짜'가 아니라는 것을 의미하지 않는다. 단지 엔지니어링 노력을 어디에 사용할 것인지를 바꾸는 것 뿐이다.
서비스도 빠르기 때문에 성능이 일반적으로 걱정되는 것은 아니다. 2023년 3월 14일부터 2023년 6월 12일까지 Expo의 푸시 알림 API는 42 밀리초의 중간 응답 시간, 273 밀리초의 p99 지연 시간, 그리고 일일 평균 오류율은 0.17% 수십만 건의 일일 메시지에 걸쳐 Knock의 Expo 푸시 __CAPGO_KEEP_0__ 벤치마크 분석에 따르면 이것이 프로토타입에만 적합한 Expo라는 의심을 품고 있는 팀에게는 충분한 보장이 될 것입니다.Expo가 실제로 추상화하는 것은 Knock’s Expo push API benchmark analysisExpo 푸시
라고 말할 때, 종종 여러 개의 별개의 문제를 함께 묶어 말하는 것입니다:
Provider 라우팅:
- Expo는 메시지를 APNs 으로 전달합니다. iOS와 Android용 FCM Android용.
- 토큰 형식: 서버는 플랫폼별 토큰 처리를 관리하는 대신 Expo Push Token을 저장하고 전송합니다.
- 요청 계약: Expo의 푸시 API로 페이로드를 POST하는 대신 원시 제공자 API에 직접 통합하지 않습니다.
그것은 유용하지만 실제로는 앱 code,陈舊 토큰, 잘못된 페이로드, 또는 허용되지 않은 권한 흐름으로 인한 많은 실패가 발생합니다.
실용적인 규칙: Expo를 신뢰할 수 있는 전송層로 간주하고, 클라이언트 및 백엔드 설계에 대한 대안으로는 사용하지 마십시오.
실제로 프로덕션 준비가 무엇을 의미하는지
작동하는 데모는 단지 한 기기에서 한 페이로드를 한 번 수락했을 뿐입니다. 프로덕션 준비는 다른 것을 의미합니다:
| 관심 | 데모 마음가짐 | 생산 마음가짐 |
|---|---|---|
| 권한 | 즉시 묻기 | 사용자 값이 명확한 후에 문맥에 맞게 묻기 |
| 토큰 | 한 번 저장 | 갱신, 중복 제거, 만료, 일치시키기 |
| 페이로드 | 모든 것을 포함시키기 data |
페이로드를 작고 동작에 집중된 것으로 유지하기 |
| 앱 동작 | 알림 표시 | 정상적으로 이동하고 전면 상태를 처리하십시오 |
| 작업 | 수동 테스트 | 수령증, 정리, 로그 및 사고 처리 |
That’s the difference between “notifications send” and “notifications support a real product workflow.”
초기 프로젝트 설정 및 구성
Expo 푸시의 많은 고통은 첫 번째 허가 요청 전부터 시작됩니다. 프로젝트 구성이 엉망이라면 클라이언트 code가 올바르게 보일 수 있지만 빌드 간에 앱이 일관되지 않게 동작할 수 있습니다.
적절한 라이브러리가 설치되어 개발 환경이 빌드 경로와 일치하는 경우 시작하십시오. Expo Go를 넘어서 작업하는 경우, 개발 클라이언트 설정을 맞춰주는 것이 도움이 됩니다. 개발 환경과 빌드 경로를 맞추면 도움이 됩니다., because notification behavior often needs to be validated in a build that mirrors production more closely than a quick sandbox run.
알림 패키지를 설치하세요
최소한, 다음을 설치해야 합니다:
expo-notifications권한 요청, 토큰 취득, 리스너, 알림 표시를 위해expo-device권한 요청을 위한 토큰 취득을 보호해야 합니다Device.isDevice.
Typical install commands depend on your package manager, but the key is version alignment with your Expo SDK. Don’t mix arbitrary package versions. Let Expo resolve compatible ones.
프로젝트 수준의 구성 추가
알림은 앱 계약의 일부이므로, 후thought가 아닌 명시적인 구성이 필요합니다. app.json 다음 몇 가지 세부 사항이 중요합니다: app.config.js 번들 식별자 및 패키지 이름
{
"expo": {
"name": "MyApp",
"slug": "my-app",
"plugins": ["expo-notifications"],
"ios": {
"bundleIdentifier": "com.example.myapp"
},
"android": {
"package": "com.example.myapp"
},
"extra": {
"eas": {
"projectId": "your-project-id"
}
}
}
}because you should guard token retrieval with
- for permission requests, token retrieval, listeners, and notification presentation. __CAPGO_KEEP_0__
- __CAPGO_KEEP_1__ __CAPGO_KEEP_2__
- __CAPGO_KEEP_3__ __CAPGO_KEEP_4__
__CAPGO_KEEP_5__
__CAPGO_KEEP_6__
import * as Notifications from 'expo-notifications';
Notifications.setNotificationHandler({
handleNotification: async () => ({
shouldShowAlert: true,
shouldPlaySound: false,
shouldSetBadge: true,
}),
});__CAPGO_KEEP_7__
__CAPGO_KEEP_8__
__CAPGO_KEEP_9__
__CAPGO_KEEP_10__
import { Platform } from 'react-native';
import * as Notifications from 'expo-notifications';
export async function configureAndroidNotifications() {
if (Platform.OS !== 'android') return;
await Notifications.setNotificationChannelAsync('default', {
name: 'Default',
importance: Notifications.AndroidImportance.MAX,
});
}__CAPGO_KEEP_11__
권한 요청 및 푸시 토큰 캡처
많은 팀이 Snippet에서 복사하고 나중에 후회하는 부분입니다.
권한 요청에는 타이밍, 플랫폼 인식, 그리고 비동기 처리를 엄격하게 관리하는 것이 필요합니다. 토큰 캡처는 물리적 장치에서만, 권한이 해결된 후에만, 그리고 백엔드에 결과를 저장할 준비가 되었을 때만 발생해야 합니다.
클라이언트 함수가 기본값이어야 하는 함수
이 함수를 시작점으로 사용하세요:
import * as Device from 'expo-device';
import * as Notifications from 'expo-notifications';
import Constants from 'expo-constants';
import { Platform } from 'react-native';
type RegisterResult =
| { ok: true; token: string }
| { ok: false; reason: string };
export async function registerForExpoPushNotificationsAsync(): Promise<RegisterResult> {
if (!Device.isDevice) {
return { ok: false, reason: 'Push notifications require a physical device.' };
}
if (Platform.OS === 'android') {
await Notifications.setNotificationChannelAsync('default', {
name: 'Default',
importance: Notifications.AndroidImportance.MAX,
});
}
const permissions = await Notifications.getPermissionsAsync();
let finalStatus = permissions.status;
if (finalStatus !== 'granted') {
const request = await Notifications.requestPermissionsAsync();
finalStatus = request.status;
}
if (finalStatus !== 'granted') {
return { ok: false, reason: 'Notification permission was not granted.' };
}
const projectId =
Constants.expoConfig?.extra?.eas?.projectId ??
Constants.easConfig?.projectId;
if (!projectId) {
return { ok: false, reason: 'Missing EAS project ID configuration.' };
}
const tokenResponse = await Notifications.getExpoPushTokenAsync({ projectId });
return { ok: true, token: tokenResponse.data };
}순서는 중요합니다. 장치 유형을 확인한 후 안드로이드 채널 동작을 설정하고 권한을 해결한 후 프로젝트 구성이 유효한지 확인한 후 Expo 토큰을 요청합니다.
왜 Device.isDevice 필수입니다
이것은 많은 잡음이 발생하는 것처럼 보이지만 해가 없는 실수 중 하나입니다. 전문 팀만 권한을 조건부적으로 요청할 때 Device.isDevice true이 조건을 생략하는 것은 개발자가 잘못된 시뮬레이터 토큰으로 알림을 보내고 Expo를 비난하는 일반적인 실수입니다. 실제로는 앱 구성에 대한 설명과 관련된 문제입니다. Eagerworks’ Expo 알림 구현 노트.
그것이 왜 함수의 맨 위에 위치하는지 이유는 간단합니다. 그것을 도우미 함수 뒤에 숨기지 마세요. 그것이 명확해야 합니다.
시뮬레이터 결과는 UI 테스트에 유용합니다. 푸시 토큰 등록을 확인하는 데는 신뢰할 수 없습니다.
권한을 요청하는 시점을 올바르게 선택하세요.
스플래시 화면에서 권한을 요청하지 마세요. 사용자가 알림의 가치를 이해하기 전에 권한을 요청하지 마세요. 일반적으로 알림의 이점을 구체화하는 사용자 동작이후에 권한을 요청하는 것이 좋습니다. 예를 들어, 배송 업데이트 수신, 대화에 참여, 또는 감시 중인 항목을 저장하는 경우입니다.
좋은 구현은 일반적으로 이 흐름을 따릅니다:
- 사용자가 의미 있는 기능 경계에 도달합니다.
- 앱은 알림의 가치를 사용자 UI에서 설명합니다.
- 앱은 시스템 권한을 요청합니다.
- 권한이 승인되면 앱은 백엔드에 토큰을 즉시 저장합니다.
그 마지막 단계에서 많은 앱이 실패합니다. 그들은 토큰을 로컬로 로깅하고 백엔드 등록을 미루어 버립니다. 나중에 지원 팀은 어느 기기에서 어느 토큰을 어느 시점에 사용했는지 알 수 없습니다.
토큰을 등록한 후 저장하는 간단한 예제입니다.
export async function enablePushForCurrentUser(userId: string) {
const result = await registerForExpoPushNotificationsAsync();
if (!result.ok) {
return result;
}
await fetch('https://api.example.com/push-tokens', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
Authorization: 'Bearer user-session-token',
},
body: JSON.stringify({
userId,
token: result.token,
platform: Platform.OS,
}),
});
return result;
}워크플로우의 나중에 이 walkthrough은 유용한 시각적 참조입니다:
릴리즈-heavy 앱을 빌드하는 팀에게도 토큰 등록을 앱의 운영 상태로 생각하는 것이 도움이 됩니다. 이는 온보딩의 일부만으로 생각하는 것과는 다릅니다. 이러한 마음가짐은 더 넓은 Expo 앱 전송 워크플로우에서 앱의 동작이 자주 바뀌고 백엔드 상태가 동기화되어야 할 때 잘 맞습니다.
서버에서 알림을 보내는 방법
백엔드가 유효한 Expo Push 토큰을 가지고 있는 경우 알림을 보내는 것은 직관적입니다. 요청 자체가 어려운 것은 아닙니다. 알림을 보내는 hardest 부분은 payload에 무엇을 넣고 클라이언트 상태에 얼마나 신뢰할 것인지 결정하는 것입니다.
Node-style 예제 fetch:
type ExpoPushMessage = {
to: string;
title: string;
body: string;
sound?: 'default' | null;
data?: Record<string, unknown>;
};
export async function sendExpoPushNotification(token: string) {
const message: ExpoPushMessage = {
to: token,
title: 'New review received',
body: 'Tap to open the order details.',
sound: 'default',
data: {
type: 'new_review',
orderId: 'ord_123',
screen: 'OrderDetails',
},
};
const response = await fetch('https://exp.host/--/api/v2/push/send', {
method: 'POST',
headers: {
Accept: 'application/json',
'Accept-encoding': 'gzip, deflate',
'Content-Type': 'application/json',
},
body: JSON.stringify(message),
});
const result = await response.json();
return result;
}payload 필드의 각 필드가 해야 할 일
payload를 버스정류장으로 생각하지 마세요. 각 필드를 의도적으로 사용하세요.
| 필드 | 목적 | 실용적인 조언 |
|---|---|---|
to |
대상 Expo Push Token | 현재 기기 기록에 속하는지 확인하세요. |
title |
알림 제목 | 짧고 인간적인 읽기 |
body |
메인 표시 텍스트 | 액션을 명확하게 하세요 |
sound |
시스템 소리 동작 | 중요한 알림에만 사용하세요 |
data |
앱 전용 메타데이터 | ID와 경로 힌트를 선호하세요. 대신에 rich content를 사용하지 마세요. |
그것 data 객체는 제품 워크플로우에서 유용합니다. 타입과 레코드 ID를 전달하고 사용자가 탭할 때 최신 데이터를 가져올 수 있습니다. 그게 안전한 방법입니다. 대량이나 sensitive blob을 직접 payload에 포함하지 마세요.
__CAPGO_KEEP_0__
에 따르면 courier의 Expo 알림에 대한 안내서, Expo Push 토큰은 임시로 처리되어야 하며, 약 4 KB 를 초과하는 페이로드는 삭제될 수 있으며, 신뢰할 수 있는 패턴은 작은 메타데이터 페이로드를 보낼 때입니다. 예를 들어, { "type": "new_review", "id": 123 } 대신
를 보낼 때입니다. 이 조언은 실제 시스템에서 작동하는 방식과 일치합니다. 작은 페이로드는 더 자주 실패하지 않고 앱 로직이 변경될 때 더 오래 살아남습니다.
사용자에게 경로를 설정하기 위한 데이터를 보내면 충분합니다. 앱이 열릴 때 나머지 데이터를 가져옵니다.
유용한 서버 측 습관
- 테스트를 위해 기본적인 보내기 함수가 충분합니다. 실제 프로덕션에서는 보내기 함수에 몇 가지 추가 책임이 있습니다: 보내기를 시도한 횟수를 저장합니다:
- 콘텐츠 생성과 전송을 분리하십시오: 한 층에서 메시지 복사본을 빌드하고 Expo API 요청을 다른 층에서 처리하십시오.
- invalidation feedback를 처리하십시오: Expo가 나중에 __CAPGO_KEEP_0__를 보고한다면, 그 토큰을 무효로 표시하고 무의식적으로 다시 시도하지 마십시오.
DeviceNotRegistered웹 훅 디자인을 사용하십시오: - 이미 시스템이 이벤트를 내뱉고 있다면, 같은 종류의 백엔드 웹 훅 처리 패턴을 사용하십시오. 클라이언트 리스너를 디버깅하기 전에 수동 테스트 푸시를 먼저 보내십시오. 토큰이 평범한 알림에 작은 페이로드를 받았다면, 전송 경로는 건강한 것입니다. 그렇지 않다면, 네비게이션 __CAPGO_KEEP_0__를 변경하기 전에 토큰, 페이로드 형태, 권한 상태를 확인하십시오. 알림을 받은 앱이 사용자가 알림을 탭했을 때도 일관된 동작을 하도록 하십시오. 알림을 받은 앱이 사용자가 알림을 탭했을 때도 일관된 동작을 하도록 하십시오.
Before debugging client listeners, send a manual test push first. If a token receives a plain notification with a tiny payload, your transport path is probably healthy. If not, don’t start by changing navigation code. Start by validating the token, payload shape, and permission state.
알림을 받은 앱이 사용자가 알림을 탭했을 때도 일관된 동작을 하도록 하십시오.
알림을 받은 앱이 사용자가 알림을 탭했을 때도 일관된 동작을 하도록 하십시오.
That means handling two separate moments:
- 앱이 열려 있는 동안 알림이 도착하는 경우
- 시스템 트레이 또는 잠금 화면에서 알림에 상호 작용하는 경우
앱이 전면 상태일 때 받은 알림과 사용자가 알림에 반응하는 것은 다른 이벤트입니다.
신뢰할 수 있는 설정은 두 개의 리스너를 모두 포함하는 경우가 많습니다.
import { useEffect } from 'react';
import * as Notifications from 'expo-notifications';
export function useNotificationObservers(
onForegroundMessage: (notification: Notifications.Notification) => void,
onNotificationTap: (response: Notifications.NotificationResponse) => void
) {
useEffect(() => {
const receivedSub = Notifications.addNotificationReceivedListener(
(notification) => {
onForegroundMessage(notification);
}
);
const responseSub = Notifications.addNotificationResponseReceivedListener(
(response) => {
onNotificationTap(response);
}
);
return () => {
receivedSub.remove();
responseSub.remove();
};
}, [onForegroundMessage, onNotificationTap]);
}addNotificationReceivedListener 앱이 활성화된 상태일 때 실행됩니다. addNotificationResponseReceivedListener 사용자가 전달된 알림을 탭했을 때 실행됩니다. 그들을 혼합하지 마십시오. 그들은 다른 UX 경로를 제공합니다.
데이터 페이로드를 읽고 의도적으로 이동하십시오.
이벤트 처리 패턴을 읽으십시오.
type NotificationData = {
type?: string;
orderId?: string;
screen?: string;
};
export function handleNotificationTap(
response: Notifications.NotificationResponse,
navigation: any
) {
const data =
response.notification.request.content.data as NotificationData;
if (data.screen === 'OrderDetails' && data.orderId) {
navigation.navigate('OrderDetails', { orderId: data.orderId });
return;
}
if (data.type === 'new_review') {
navigation.navigate('Inbox');
return;
}
navigation.navigate('Home');
}이 패턴은 데이터 페이로드가 라우팅 힌트를 포함하기 때문에 안정적입니다. 알림이 전송된 후에 주문이 변경된 경우 앱은 현재 서버 상태를 가져와 이동할 수 있습니다.
탭된 알림은 하나의 명확한 목적지를 향해야 합니다. 만약 fallback 경로가 모호하다면 사용자는 즉시 이를 알아차립니다.
사용자 환경에 맞는 전면 동작이 되어야 합니다.
앱이 이미 열려 있는 경우, 시스템 스타일 알림을 무작위로 표시하는 것은 불편할 수 있습니다. 때로는 올바른 움직임은 앱 내 배너, 배지 업데이트, 또는 무음 리프레시입니다. 사용자가 이미 해당 대화 읽고 있는 경우, 지원 인박스 화면에는 보이지 않는 알림이 필요하지 않을 수 있습니다.
이러한 이유로, 전면 리스너는 경로와 알림 유형에 따라 branch해야 합니다. 예를 들어:
- 채팅 화면 열기: 메시지를 추가하고 중복된 배너를 피하십시오.
- 대시보드 열기: 가벼운 앱 내 토스트를 표시하십시오.
- 중요 계정 이벤트: 강한 UI 처리를 표면화하십시오.
간단한 방법은 다음과 같습니다:
export function handleForegroundNotification(
notification: Notifications.Notification,
currentRouteName: string
) {
const data = notification.request.content.data as { type?: string };
if (currentRouteName === 'ChatThread' && data.type === 'new_message') {
// refresh local thread state
return;
}
// otherwise show your own in-app UI or update badges
}앱이 이러한 컨텍스트를 구분하지 않는 경우, 사용자는 기술적으로 정확한 배달에도 알림 피로를 더 빠르게 느끼게 됩니다.
생산 환경에서最佳 관행과 일반적인 함정
대부분의 Expo 푸시 알림 설정이 실패하는 이유는 Expo가 너무 제한적이라는 것이 아니다. 실패하는 이유는 팀이 토큰이 영구적이라는 것을 가정하고, 패킷이 아무것이나 포함할 수 있고, 앱 업데이트가 알림 로직에 영향을 주지 않는다고 가정하기 때문이다.
이런 가정은 실제 운영 환경에서 살아남지 못한다.
토큰은 임시적이며, 사용자 식별 정보가 아니다.
Expo Push Token은 임차권과 같이 영구적인 장치 식별자로 다루지 말고, 임차권으로 다루어야 한다. 토큰은 재설치, OS 변경, 또는 라이프 사이클 이벤트 이후에 회전할 수 있다. 만약 토큰이 결국 돌아오면, 백엔드에서는 이를 활성 토큰으로 다루지 않아야 한다. DeviceNotRegistered실용적인 백엔드 모델은 다음과 같은 정보를 저장한다.
사용자 ID
- 플랫폼
- 설치 범위의 메타데이터
- 현재 토큰
- 최근으로 확인된 타임스탬프
- __CAPGO_KEEP_0__
- 활성, 만료, 또는 취소된 상태와 같은 상태
사용자 테이블에 하나의 토큰 field만 저장하고 끝내지 마세요. 사용자는 여러 장치가 있고 장치 상태가 변합니다.
리프레시 전략은 대부분의 튜토리얼에서 인정하지 못하는 것보다 더 중요합니다.
official ecosystem 지침은 실제 운영상의 빈틈을 남깁니다. 기존 Expo push notification content는 일반적으로 App Store 리뷰 주기와 OTA 업데이트를 포함하여 토큰 유효성을 유지하는 방법을 설명하지 않습니다. 앱 스토어 리뷰 주기와 OTA 업데이트를 포함하여 토큰 유효성을 유지하는 방법을 설명하지 않습니다.이것은 특히 push 신뢰도가 현재 토큰 상태와 백엔드 동기화에 의존하는 팀에게 라이브 변경을 배포하는 경우 특히 중요합니다. Expo notifications 문서에서 언급한 바와 같이.
이것은 토큰 유효성을 유지하는 방법을 설명하지 않습니다.
- 이것은 토큰 유효성을 유지하는 방법을 설명하지 않습니다.
- 이것은 토큰 유효성을 유지하는 방법을 설명하지 않습니다.
- 이것은 토큰 유효성을 유지하는 방법을 설명하지 않습니다.
- 토큰 상태를 일치시키는 좋은 시간은 다음과 같습니다. : 앱 업데이트 후 앱 런치, 사용자 로그인, 권한 설정 변경, 자격 증명 회전 작업
- Recovery flows after push-related support tickets
보안 및 규정 준수는 스프린트의 마지막에 속하지 않습니다.
Expo 튜토리얼의 많은 것들은 기계적 측면에 초점을 맞추고 운영 위험을 생략합니다. 그것은 취미 앱에 괜찮은 것입니다. 그것은 의료-관련, 금융 기술, 또는 규제 상업 제품에 괜찮지 않습니다.
Courier의 Enterprise-focused Expo 알림 간격에 대한 토론 Enterprise-focused Expo 알림 간격에 대한 Courier의 토론
- Expo 알림 간격에 대한 Courier의 Enterprise-focused 토론
- Expo 알림 간격에 대한 Courier의 Enterprise-focused 토론
- Expo 알림 간격에 대한 Courier의 Enterprise-focused 토론
- Expo 알림 간격에 대한 Courier의 Enterprise-focused 토론
Expo 알림 간격에 대한 Courier의 Enterprise-focused 토론 app store compliance and API security practicesFor 팀이 broader 앱 스토어 규정 준수와 __CAPGO_KEEP_0__ 보안 관행에 맞춰 릴리스 운영을 조정할 때, push는 auth, analytics, 및 백엔드 이벤트 로깅과 같은 동일한 검토-discipline에 포함되어야 합니다.
__CAPGO_KEEP_0__는 사용자에게 보이는 메시지이지만 분산 시스템 문제이기도 하다. 인증 상태와 결제 이벤트와 같은 주의를 기울여야 한다.
__CAPGO_KEEP_0__는 일반적으로 작동하고 일반적으로 실패하는 것
| 일반적으로 작동한다 | 일반적으로 실패한다 |
|---|---|
| 허용 권한을 요청하기 전에 명확한 값 설명을 제공하는 경우 | 첫 번째 프레임에서 프롬프트하는 경우 |
| 실제 장치에서 테스트하는 경우 | 시뮬레이터 등록에 신뢰하는 경우 |
| 장치 컨텍스트와 함께 토큰을 저장하는 경우 | 사용자 레코드당 하나의 토큰을 보관하는 경우 |
| 작은 메타데이터 페이로드를 보내는 경우 | 대형 또는敏感한 블롭을 임베딩하는 경우 |
| 배경과 터치 이벤트를 별도로 처리합니다. | 모든 알림이 한 경로를 따르는 것으로 가정합니다. |
| 고갈된 토큰을 적극적으로 만료합니다. | 죽은 토큰을 영원히 다시 시도합니다. |
__CAPGO_KEEP_0__
solid Expo push 설정은 복잡하지 않습니다. 그것은 discipline입니다. Capgo 그것은 가치가 있습니다. 그것은 모바일 팀이 업데이트를 빠르게 푸시할 수 있도록 스토어 리뷰를 기다리지 않고, 특히 알림 흐름, 라우팅 논리, 또는 클라이언트 사이드 수정이 사용자에게 빨리 도달해야 하는 경우에 유용합니다.
