앱이 작동하고 사용자가 로그인했으며 제품이 재참여 흐름을 원한다면, 카트 알림, 리뷰提示, 새로운 메시지 알림, 릴리스 발표와 같은 네이티브 느낌의 흐름이 필요하다. 첫 번째 직관은 종종 '푸시를 연결'이라고만 말하는 것이다. 그러나 한 주 후에는 디버깅을 시작해야 하는데, 하나의 기기만이 알림을 받고 시뮬레이터는 정상적으로 등록되는 것처럼 보인다. 그러나 nobody도 왜 탭이 올바른 화면을 열지 못하는지 설명할 수 없다.
Expo 푸시 알림은 간단하게 느껴질 수도 있고 surprisngly 약한 경우도 있다.
Expo는 React Native 팀에게 APNs 및 FCM 위에 실용적인 층을 제공한다. 이는 많은 팀이 사용하는 이유이다. 그러나 데모와 실제 프로덕션 준비 구현 사이의 격차는 실제다. 토큰 라이프 사이클, 권한 타이밍, 리스너 설정, 페이로드 디자인, 백엔드 클린업 모두 중요하다. 또한 자주 앱 로직 변경을 하는 경우, 운영적 규율이 필요해지며, 특히 신뢰할 수 있는 메시징과 릴리스 속도에 의존하는 경우, 그 필요성이 더욱 뚜렷해진다. 사용자 유지율 작업: 사용자 경험을 예측할 수 있는 경우에만 전달이 유용하다.
목차
- 사용자와의 상호 작용을 위한 Expo 푸시 알림의 기초
- 초기 프로젝트 설정 및 구성
- 권한 요청 및 푸시 토큰 캡처
- 서버에서 알림을 보내는 방법
- 앱에서 들어오는 알림을 처리하는 방법
- 제작 최적화 및 일반적인 오류
Expo 푸시 알림과 사용자와의 상호 작용의 기초
An Expo 푸시 알림 설치는 주된 이유 하나 때문에 매력적입니다. 그것은 팀이 첫 번째 날에 소유하고 싶지 않은 원시 메시징 복잡성을 제거합니다. APNs 및 FCM 플러밍을 직접 구축하기 전에, Expo 게이트웨이와 함께 작업하고 제품 동작, 경로, 권한 UX, 백엔드 메시지 논리에 집중할 수 있습니다.
그 추상화는 푸시가 '진짜'가 아니라고 만드는 것이 아닙니다. 그것은 엔지니어링 노력의 위치를 바꾸는 것입니다.
서비스는 또한 성능이 빠르기 때문에 일반적으로 성능이 걱정되는 첫 번째 일은 아니야. 2023년 3월 14일부터 2023년 6월 12일까지 Expo의 푸시 알림 API은 42 밀리초의 중간 응답 시간 , 273 밀리초의 p99 지연 , 그리고 일 평균 오류율 0.17% 수십만 건의 일일 메시지 에 걸쳐 Knock의 Expo 푸시 __CAPGO_KEEP_0__ 벤치마크 분석 Knock의 Expo push API 성능 분석Expo가 추상화하는 실제 것
Expo는 실제로 추상화합니다
Expo 푸시를 말할 때 팀들은 종종 여러 개의 분리된 문제를 하나로 묶어서 말한다.
- 제공자 라우팅: Expo는 iOS와 Android용 APNs, FCM으로 메시지를 전달합니다. APNs iOS와 FCM Android용
- 토큰 형식: 서버에서는 Expo Push Token을 관리하는 대신 플랫폼별 토큰 처리를 먼저 관리하지 않습니다.
- 요청 계약: Expo의 푸시 API로 페이로드를 POST합니다.
그것은 도움이지만 실제로는 앱 code,陈舊한 토큰, 잘못된 페이로드, 또는 허용된 흐름이 많은 실패를 발생시킵니다.
실용적인 규칙: Expo를 신뢰할 수 있는 전송 계층으로 다루고, 좋은 클라이언트 및 백엔드 설계를 대신하는 것으로는 생각하지 마세요.
실제로 프로덕션 준비가 무엇인지
작동하는 데모는 단지 한 기기에서 한 페이로드를 한 번 받아들이는 것을 증명하는 것일 뿐입니다. 프로덕션 준비는 다른 것을 의미합니다:
| 관심사 | 데모 마음가짐 | 프로덕션 마음가짐 |
|---|---|---|
| 권한 | 바로 물어봐 | Capgo에서 질문하세요 |
| Tokens | Save once | 업데이트, 중복 제거, 만료, 일치시키기 |
| Payloads | 모든 것을 넣어 data |
작업을 수행할 수 있는 작은 데이터로 유지 |
| 앱 동작 | 경고 표시 | 전면 상태를 올바르게 처리하고 |
| 작업 | 수동 테스트 | 수령, 정리, 로그, 및 사고 처리 |
‘알림 전송’과 ‘실제 제품 워크플로우를 지원하는 알림’의 차이입니다.
초기 프로젝트 설정 및 구성
Expo 알림의 많은 고통은 첫 번째 권한 요청 전부터 시작됩니다. 프로젝트 구성이 엉망이라면, 클라이언트 code가 올바르게 보이더라도 빌드 간에 앱이 일관되지 않게 동작할 수 있습니다.
개발 환경을 맞추고 빌드 경로와 일치하는 개발 환경을 갖추세요. Expo Go를 넘어 작업 중이라면, 개발 환경을 맞추는 것이 도움이 됩니다. 개발 환경을 맞추면, 개발 환경이 실제 배포 환경과 더 가깝게 개발 환경을 맞추면, 알림 동작을 실제 배포 환경과 더 가깝게 테스트할 수 있습니다. 커스텀 Expo 개발 클라이언트 설정커스텀 Expo 개발 클라이언트 설정
알림 패키지를 설치하세요
알림 패키지를 설치하세요
expo-notifications권한 요청, 토큰 취득, 리스너, 알림 표시를 위한 패키지를 설치해야 합니다.expo-device권한 요청을 취득할 때는 토큰 취득을 보호해야 합니다.Device.isDevice.
버전을 맞추세요. Expo SDK와 일치하는 버전을 사용하세요. 임의의 패키지 버전을 사용하지 마세요. Expo가 호환되는 버전을 자동으로 해결하세요.
프로젝트 수준 설정을 추가하세요
설정은 명확하게 유지하세요. 최소한의 설정 app.json or 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"
}
}
}
}몇 가지 세부 사항이 여기서 중요합니다:
- 앱의 실제 배포에 맞춰야 하는 번들 식별자와 패키지 이름 알림 플러그인은 빌드 중에 네이티브 프로젝트에 필요한 설정을 제공합니다.
- EAS 프로젝트 ID는 토큰 취득이 앱이 올바른 Expo 프로젝트와 연관되어야 한다고 기대할 때 중요합니다. 알림 처리기를 일찍 설정하세요
- 기본적인 튜토리얼은 알림 동작을 너무 늦게 정의합니다. 하지 마세요. 앱 시작 시 근처에 두세요. 이면 동작이 예측 가능합니다. 팀은 전면 알림이 경고 표시, 소리 재생, 또는 배지 영향을 미치는지 결정합니다. 정확한 동작은 제품에 따라 다릅니다. 채팅 앱과 결제 앱은 같은 선택을 하지 않습니다.
알림 동작을 의도적으로 정의하지 않으면, 팀은 실제로 받은 알림이 표시되지 않았지만 제품이 예상한 대로 표시되지 않았기 때문에
알림이 누락된 것
import * as Notifications from 'expo-notifications';
Notifications.setNotificationHandler({
handleNotification: async () => ({
shouldShowAlert: true,
shouldPlaySound: false,
shouldSetBadge: true,
}),
});으로 디버깅해야 합니다.
If you don’t define foreground behavior intentionally, your team will end up debugging “missing” notifications that were actually received but never presented the way product expected.
Android는 채널 구성이 필요합니다.
실제로 Android 알림 채널은 선택사항이 아닙니다. 채널을 생략하면 알림이 불일치하거나 사용자 예상과 일치하지 않을 수 있습니다.
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,
});
}앱 초기화 중에 이 설정을 구성하세요. 그런 다음 채널 ID가 안정적이도록 유지하세요. 채널 ID를 자주 변경하면 알림 동작을 추론하기 어려워집니다.
권한 요청 및 푸시 토큰 캡처
이 부분은 많은 팀이 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 };
}순서는 중요합니다. 장치 유형을 확인한 후 Android 채널 동작을 설정하세요. 권한을 해결한 후 프로젝트 구성이 유효한지 확인한 후 Expo 토큰을 요청하세요.
왜 Device.isDevice 선택사항이 아닙니다
이것은 많은 잡음이 발생하는 몇 가지 실수 중 하나입니다. 전문 팀은 조건부로 허용을 요청할 때만 Device.isDevice true일 때, 그리고 일반적인 실수는 그 가드를 생략하는 것입니다. 이는 개발자들이 잘못된 시뮬레이터 토큰으로 알림을 보내고 Expo를 비난하는 결과를 낳습니다. 이 문제는 실제로 앱 구성에서 설명된 것과 같습니다. Eagerworks’ Expo 알림 구현 노트.
그것이 왜 위에 위치하는지 이유는 이것입니다. 그것을 도우미 뒤에 숨기지 마십시오. 그것이 명백해야 합니다.
시뮬레이터 결과는 UI 테스트에 유용합니다. push 토큰 등록을 확인하는 데 신뢰할 수 없습니다.
권한을 요청하는 올바른 순간에 물어보세요
컨텍스트: Capgo 마케팅 웹사이트. 역할: 호출을 위한 액션 버튼 또는 링크 레이블. 보이는 곳: 컴포넌트 AskAiSection.astro. 메시지 키 `ask_ai_button` (Ask Ai Button).
이 좋은 구현은 일반적으로 이 흐름을 따릅니다.
- 좋은 구현은 일반적으로 이 흐름을 따릅니다:
- 사용자가 의미 있는 기능 경계에 도달합니다.
- 앱은 알림의 가치를 사용자 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는 유용한 시각적 참조입니다:
릴리스가 많은 앱을 개발하는 팀에게는 토큰 등록을 앱의 운영 상태로 생각하는 것이 도움이 됩니다. 이는 broader Expo 앱 전달 워크플로우와 잘 맞습니다. 서버에서 알림을 보내는 방법백엔드에 유효한 Expo Push 토큰이 있는 경우 알림을 보내는 것은 간단합니다. 요청 자체가 어려운 부분이 아닙니다. 문제는 payload에 무엇이 포함되어야 하는지와 클라이언트 상태에 얼마나 신뢰할 수 있는지입니다.
Node-style 예제입니다:
payload 필드의 각 필드가 무엇을 해야 하는지
payload를 버스정류장으로 생각하지 마세요. 각 필드를 의도적으로 사용하세요. 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;
}Expo Push 토큰을 사용하여 알림을 보내는 방법
알림을 보내는 요청 자체가 어려운 부분이 아닙니다. 문제는 payload에 무엇이 포함되어야 하는지와 클라이언트 상태에 얼마나 신뢰할 수 있는지입니다.
| Field | 목적 | 실용적인 조언 |
|---|---|---|
to |
Target Expo Push Token | 현재 기기 기록에 속하는지 확인하세요 |
title |
알림 제목 | 간결하고 사용자 친화적이어야 합니다 |
body |
주요 표시 텍스트 | 액션을 명확하게 하세요 |
sound |
시스템 사운드 동작 | 중요한 알림에만 사용하세요 |
data |
앱 전용 메타데이터 | ID와 경로 힌트를富한 콘텐츠보다 선호하세요. |
그것은 data 객체는 제품 워크플로가 유용해지는 곳입니다. 사용자가 탭을 누를 때 최신 데이터를 가져오도록 허용할 수 있습니다. 사용자에게 보여주지 않는 대용량 또는 sensitive blob을 직접 패키지에 포함하는 것보다 안전합니다.
패키지 크기를 작게 유지하세요.
Courier의 Expo 알림에 대한 지침에 따르면 courier의 가이드: Expo 알림사용자를 라우팅하기 위해 필요한 데이터를 보내세요. 앱이 열릴 때 나머지 데이터를 가져오세요. 유용한 서버 측 습관 배포 { "type": "new_review", "id": 123 } 이것은
Expo Push 토큰을 사용하여 알림을 보내는 방법에 대한 가이드입니다.
Expo Push 토큰을 사용하여 알림을 보내는 방법에 대한 가이드입니다.
A 테스트에 적합한 기본적인 보내기 함수는 충분합니다. 그러나 실제 운영 환경에서는 몇 가지 더 많은 책임을 추가하는 보내기 함수가 일반적입니다.
- 보내기를 시도하는 기록을 유지하세요: 사용자 ID, 토큰, 페이로드 타입 및 타임스탬프와 함께 알림 의도 저장:
- 송신을 위한 내용 생성과 전송을 분리하세요: 메시지 복사본을 하나의 층에서 빌드하고 Expo API 요청을 다른 층에서 빌드하세요.
- 유효성 검사 피드백을 처리하세요: Expo가 나중에 보고하면
DeviceNotRegistered유효하지 않은 토큰을 표시하고 무작위로 다시 시도하지 마세요. - 웹후크 친화적인 디자인을 사용하세요: 시스템이 이미 이벤트를 내뿜고 있다면, 동일한 유형의 백엔드 웹후크 처리 패턴을 통해 알림 트리거를 라우팅하세요. 백엔드 웹후크 처리 패턴을 통해 알림 트리거를 라우팅하세요.
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.
앱에서 수신 알림 처리하기
배송은 기능의 반만입니다. 알림이 도착했을 때 앱이 무엇을 해야 하는지, 사용자가 알림을 탭했을 때 앱이 무엇을 해야 하는지 알 수 있어야 합니다.
알림을 처리하는 것은 두 가지 별개의 순간을 의미합니다:
- 앱이 열려 있는 동안 알림이 도착하는 경우
- 사용자가 시스템 트레이 또는 잠금 화면에서 알림을 탭하는 경우
앱이 전경 상태일 때 받은 알림과 사용자가 알림에 반응하는 것은 다른 이벤트입니다.
신뢰할 수 있는 설정은 두 가지 리스너를 포함하는 경우가 많습니다:
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 경로가 모호하면 사용자가 즉시 알 수 있습니다.
사용자 컨텍스트에 맞는 백그라운드 동작이 되어야 합니다.
foreground listener는 라우트와 알림 유형에 따라 branch해야 합니다. 예를 들어:
채팅 화면이 열려 있는 경우:
- 메시지를 추가하고 중복된 배너를 피하십시오. 대시보드가 열려 있는 경우:
- 가벼운 인앱 토스트를 표시하십시오. 중요한 계정 이벤트가 발생한 경우:
- 강한 UI 처리를 표출하십시오. Chat screen open: append the message and avoid a redundant banner
간단한 접근 방식은 다음과 같습니다:
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
- 플랫폼
- 설치 범위 메타데이터 설치
- 현재 토큰
- 최근으로 확인된 타임스탬프
- 상태 (활성,陈舊,취소)
사용자 테이블에 하나의 토큰 field만 저장하고 끝내지 마세요. 사용자는 여러 장치가 있고 장치의 상태가 바뀝니다.
Refresh 전략이 대부분의 튜토리얼에서 인정하지 못하는 것보다 더 중요합니다.
official ecosystem guidance는 실제 운영상의 빈틈을 남깁니다. 현재 Expo push notification content는 token의 유효성을 유지하는 방법을 설명하지 않습니다. App Store 리뷰 사이클과 OTA 업데이트와 같은 경우이는 특히 live 변경을 배포하는 팀에게 특히 중요합니다. push 신뢰도는 현재 토큰 상태와 백엔드 동기화에 의존하기 때문입니다. Expo notifications documentation에서 언급한 바와 같이.
이것은 refresh triggers를 디자인할 때 영향을 미칩니다. token 상태를 일치시키는 좋은 시간은 다음과 같습니다:
- 업데이트 후 앱 런치
- 사용자 로그인
- 권한 설정 변경
- 인증 정보 회전이 릴리스 프로세스에서 작동
- 푸시 관련 지원 티켓 후 회복 흐름
보안 및 규정 준수는 스프린트의 끝에 속하지 않습니다.
많은 Expo 튜토리얼은 기계적 측면에 초점을 맞추고 운영 위험을 생략합니다. 그것은 취미 앱에 괜찮습니다. 그것은 의료-관련, 금융 기술, 또는 규제 상업 제품에 괜찮지 않습니다.
Courier의 Expo 알림 간격에 대한 기업에 초점을 맞춘 토론은 consent 로깅, 감사 기록, 민감한 데이터 노출을 최소화하는 실제 지침에 대한 실질적인 지침 부족을 강조합니다. 직접적인 엔지니어링 취약점은 단순합니다:
- 알림 텍스트나 페이로드 메타데이터에敏感한 비즈니스 데이터를 넣지 마십시오.
- consent 변경을 서버 측에서 로깅하십시오.
- 알림 의도에 대한 토큰에 대한 기록을 남기십시오.
- 페이로드에 ID를 사용하고 앱이 열리면 보호된 콘텐츠를 가져오십시오.
팀이 출시 운영을 더 넓은 규정과 __CAPGO_KEEP_0__ 보안 관행과 일치시키는 경우 애플 스토어 준수성 및 API 보안 관행push는 동일한 검토 범위에 포함되어야 하는 auth, analytics, backend event logging과 함께
푸시 알림은 사용자에게 보이는 메시지이지만, auth 상태와 결제 이벤트와 마찬가지로 분산 시스템 문제로 다루어져야 합니다.
일반적으로 잘 작동하는 것과 일반적으로 깨지는 것
| 일반적으로 잘 작동하는 것 | 일반적으로 깨지는 것 |
|---|---|
| 사용자에게 명확한 가치 설명이 있는 후에 권한 요청 | 첫 번째 프레임에서 권고 |
| 실제 장치에서 테스트 | 심화자 등록에 신뢰 |
| 장치 컨텍스트와 함께 토큰 저장 | 한 사용자 기록당 하나의 토큰 |
| 작은 메타데이터 페이로드를 보내는 | 대형 또는敏感한 블록을 임베딩 |
| 전면과 탭 이벤트를 별도로 처리 | 모든 알림이 하나의 경로를 따르는 것으로 가정 |
| 더러워진 토큰을 적극적으로 만료 | 죽은 토큰을 영원히 재시도 |
튼튼한 Expo 푸시 설정은 복잡하지 않다. 그것은 discipline이다.
팀이 자주 앱 논리 변경을 배포하고 tighter 제어를 필요로하고 rollback, 배포 시각성, 그리고 배포 시각성에 대해 필요로하는 경우 Capgo 팀이 자주 앱 논리 변경을 배포하고 tighter 제어를 필요로하고 rollback, 배포 시각성, 그리고 배포 시각성에 대해 필요로하는 경우는 Capgo를 살펴보면 좋습니다. It helps mobile 팀이 빠르게 업데이트를 푸시하는 데 도움이 됩니다. Store 리뷰를 기다리지 않고, 알림 흐름, 라우팅 논리, 또는 클라이언트 사이드修정에 도움이 됩니다.
