리액트 네이티브에서 알림을 트리거하고 아이폰과 안드로이드에서 테스트하고 완료된 것처럼 느껴집니다. 그런 다음 웹 빌드에 누군가가 열어보면 아무것도 나타나지 않습니다. 또는 안드로이드는 iOS에서 사용한 프롬프트 흐름을 무시합니다. 또는 앱의 두 부분이 동시에 알림을 발행하고 사용자는 대화 상자 스택에 갇힙니다. Alert.alert() 그것이 리액트 네이티브 알림의 형태입니다. 빠른, 네이티브 확인 흐름에 좋습니다. 또한 narrow, 플랫폼에 의존적이고, 생산에서 잘못 사용하기 쉽습니다. 좋은 뉴스는 행복한 경로가 간단하고, Rough Edge가 예측 가능합니다.
That’s the shape of the React Native Alert API. It’s great for fast, native confirmation flows. It’s also narrow, platform-bound, and easy to misuse in production. The good news is that the happy path is simple, and the rough edges are predictable once you know where they are.
목차
- Alert.alert을 사용하여 단순한 메시지 표시
- 사용자 입력 처리하기: 확인 버튼
- 플랫폼 특이점과 입력 프롬프트
- Alert 대신 Modal 사용할 때
- React Native Alert를 신뢰할 수 있는 생산 패턴
Alert.alert를 사용하여 단순한 메시지 표시
기본적인通知 UI를위한 Alert 리액트 네이티브 알림 리액트 네이티브 알림은 여전히 box 내에서 가장 빠른 도구입니다. import를 하시면 Alert, 호출 Alert.alert(), 그리고 플랫폼은 네이티브 다이얼로그를 렌더링합니다. 추가 의존성, 커스텀 모달 상태, 스타일링 작업이 필요하지 않습니다.
제일 단순한 버전은 제목과 메시지만 필요합니다:
import React from 'react';
import { View, Button, Alert } from 'react-native';
export default function ProfileScreen() {
const showSavedMessage = () => {
Alert.alert('Profile updated', 'Your changes were saved successfully.');
};
return (
<View style={{ padding: 24 }}>
<Button title="Save profile" onPress={showSavedMessage} />
</View>
);
}
이 패턴은 사용자가 의미 있는 선택을 해야 할 필요가 없는 경우 잘 작동합니다. '설정 저장', '세션 만료', '현재 unavailable'과 같은 경우입니다. 다이얼로그는 흐름을 끊기 때문에 사용자가 즉시 필요한 정보를 전달해야 합니다. 그러나 이는 사용자에게 중요한 정보가 아닙니다.
기본 호출이 제공하는 것은 무엇입니까
plain Alert.alert(title, message) 은 유용합니다. 이는 네이티브로 유지되기 때문입니다. 운영 체제는 시각적 표현, 버튼 역할, 표준 상호 작용 패턴을 처리합니다. 많은 팀에게 이는 정확히 올바른 트레이드 오프입니다.
몇 가지 실용적인 규칙이 유용한 것을 유지하는 데 도움이 됩니다:
- 직접적인 제목을 사용하십시오. “업로드 실패”는 “공지”보다 명확합니다.
- 메시지를 짧게 유지하세요.. 경고는 즉시적인 맥락에 대한 것이며, 장기적인 설명이 아닙니다.
- 경고는 차단 정보를 위한 것입니다.. 사용자가 중단 없이 계속할 수 있다면, 토스트가 더 적합한 경우가 많습니다.
경고는 작고 결정적인 것이어야 합니다. 사용자가 문단을 읽어야 한다면, 대화창이 올바른 UI가 아닙니다.
팀이 경고를 잘못 사용하는 경우
가장 일반적인 실수는 경고를 일반적인 메시징 시스템으로 사용하는 것입니다. 모든 성공적인 액션에 차단 대화창을 표시하면 앱이 빠르게 느려집니다. Native 경고는 사용자를 중단시키는 이유가 있는 경우에 가장 강력합니다.
다른 실수는 경고를 컴포넌트 내부의 내부에 너무 강하게 결합하는 것입니다. 작은 버튼 핸들러는 처음에는 괜찮지만, 흐름이 여러 화면과 비동기 액션을跨越하면 경고 호출이 여기저기 흩어져서 추론하기 어려워집니다. 그 이유로 팀은 종종 초기에 표준화된 UX 패턴을 정의합니다. React Native 앱의 스플래시 화면 동작과 마찬가지로. 간단한 경고의 좋은 사용 사례.
시나리오
| Scenario | 알림이 왜 작동하는가? |
|---|---|
| 중요한 설정 변경 후 확인을 저장하세요 | 사용자가 명확한 승인 필요합니다 |
| 세션 타임아웃 경고 | 메시지는 급박하고 행동을 취해야 하는 것입니다 |
| 지원되지 않는 기능 알림 | 앱이 중단되어 설명해야 합니다 |
사용자가 경로를 선택해야 하는 경우, 다음 단계는 buttons 배열입니다. 그곳에서 Alert.alert() 이해하기만 하면 더 단순한 메시지 박스입니다
사용자 입력을 처리하는 확인 버튼
대부분의 실제 알림 사용은 정보를 제공하는 것이 아닙니다. 결정이 필요합니다. 초안을 삭제하거나 변경을 취소하거나 로그아웃하거나 실패한 요청을 다시 시도하십시오. 그곳에서 buttons 배열은 중요합니다.
다음은 일반적인 확인 대화입니다.
import React from 'react';
import { View, Button, Alert } from 'react-native';
export default function DangerZone() {
const confirmDelete = () => {
Alert.alert(
'Delete item',
'This action cannot be undone.',
[
{
text: 'Cancel',
style: 'cancel',
},
{
text: 'Delete',
style: 'destructive',
onPress: () => {
console.log('Deleting item...');
},
},
]
);
};
return (
<View style={{ padding: 24 }}>
<Button title="Delete item" onPress={confirmDelete} />
</View>
);
}
각 버튼은 객체입니다. 실제로 사용할 때는 세 가지 속성을 가장 자주 사용합니다.
text사용자가 보는 레이블입니다.onPress버튼을 탭했을 때 실행되는 함수입니다.styleiOS에서 특히 중요합니다.
버튼 레이블을 잘 선택하여 오류를 줄이는 방법
API을 사용하여 'OK'를 입력하고 다음 단계로 넘어갈 수 있습니다. 일반적으로 이것만으로는 충분하지 않습니다. 레이블은 결과를 설명해야 하며, 특히 파괴적인 동작의 경우尤其 그렇습니다.
다음 두 가지 세트를 비교해 보세요.
- Weak labels: OK / Cancel
- 더 나은 레이블: 삭제 항목 / 항목 유지
두 번째 버전은 불확실성을 제거합니다. 이는 파괴적인 흐름에서 중요하고, 오류 또는 비동기 작업이 끝난 후 알림이 나타날 때 더 중요합니다. 버튼 텍스트는 "이 버튼을 탭하면 무슨 일이 일어날까요?"라고 대답해야 합니다.
사용자로부터 텍스트를 수집하는 흐름이 있다면, 사용자 입력을 명확하게 표현하는 패턴을 사용하는 것이 좋습니다. 예를 들어, 전용 React Native TextInput 구현 대화 상자에 너무 많은 것을 강요하는 대신.
버튼 스타일이 실제로 무슨 의미인지
The style field는 의미가 있는 것이고, 꾸미는 것이 아닙니다. 의도를 전달하기 위해 사용하세요.
| 스타일 | 사용할 때 | 주석 |
|---|---|---|
default |
일반적인 동작 | 중립적인 선택에 적합 |
cancel |
iOS에서 뒤로가기 | 안전한 취소에 중요 |
destructive |
돌이킬 수 없는 동작 | iOS에서 강조 표시 |
Gluestack의 기술 벤치마크에 따르면, 플랫폼의 규칙은 여기서 중요합니다. iOS는 왼쪽에 취소 버튼을, 오른쪽에 확인 버튼을 두고, Android는 그 반대입니다. 규칙을 어기면 사용자 혼란 지표가 전 세계적으로 취소 버튼 오른쪽 확인 25% 버튼 45% 생산 앱에서 중요 경로 알림이 취소 또는 종료 경로를 포함하지 않으면, 불변적 동작과 지원 양이 증가합니다. 동일한 분석은 또한 보조 기술을 위한 읽기 순서에서 사용자 정의 알림 구현이 실패하는 것을 지적합니다. 이에 대한 자세한 내용은 Gluestack 알림 가이드.
실용적인 규칙: 모든 파괴적인 알림은 명시적인 종료 방법을 포함해야 합니다.
버튼 구성 및 상호 작용 흐름에 대한 더 시각적인_walkthrough를 보려면 이 짧은 데모가 가치가 있습니다.
더 안전한 확인 패턴
동작이敏感할 때, 콜백을 얇게 유지하십시오:
Alert.alert(
'Sign out',
'You will need to log in again to continue.',
[
{ text: 'Stay signed in', style: 'cancel' },
{
text: 'Sign out',
style: 'destructive',
onPress: async () => {
try {
await signOut();
} catch (error) {
Alert.alert('Sign out failed', 'Please try again.');
}
},
},
]
);이 패턴은 재미없지만, 그 이유가 바로 좋은 것입니다. 알림은 예측 가능해야 합니다.
플랫폼 특이성과 입력 프롬프트를 탐색하는 방법
생산 중 오류는 다음과 같은 형태를 띕니다. 동일한 Alert.alert() 콜백은 iOS에서 작동하고 Android에서 작동하지만, 팀이 웹 빌드를 배포한 후에 작동하지 않는다. API는 code에서 일관적이지만, 플랫폼은 아니다.
iOS와 Android는 완벽하게 일치하지 않습니다.
버튼 순서는 팀이 가장 먼저 걸리는 장애물입니다. React Native는 알림을 운영 체제에 위임하므로 사용자는 React Native 추상화가 아닌 운영 체제의 전통을 보게 됩니다. 일반적으로 올바른 거래 오프셋이지만 버튼 레이블은 플랫폼 간에 명확해야 합니다.
prompt 지원은 더 큰 불일치입니다. iOS는 Alert.prompt for 가벼운 텍스트 입력을 지원합니다. Android는 그렇지 않습니다. 흐름이 알림 내부에서 암호를 입력하거나 항목을 이름을 바꾸거나 짧은 메모를 캡처하는 경우, 그 흐름은 iOS 전용이 될 때까지 별도의 경로를 구축해야 합니다.
플랫폼 체크를 일찍 사용하세요. 대신 API가 일치한다고 가정하지 마세요.
import { Alert, Platform } from 'react-native';
export function requestPassword() {
if (Platform.OS === 'ios') {
Alert.prompt(
'Enter password',
'Please confirm your password.',
[
{ text: 'Cancel', style: 'cancel' },
{
text: 'Continue',
onPress: (value) => {
console.log('Password entered:', value);
},
},
],
'secure-text'
);
return;
}
Alert.alert(
'Confirmation required',
'Please continue to the next screen to confirm this action.',
[{ text: 'OK' }]
);
}Android 대체는 더 불편합니다. 그러나 여전히 더 안전한 선택입니다. 프로덕션에서 리다이렉트를 사용하여 전용 화면이나 제어된 모달로 이동하는 것은 테스트, 지역화, 접근성 측면에서 가짜 프롬프트를 구축한 불완전한 동작보다 쉽습니다.
웹 지원은 전용 계획이 필요합니다.
React Native의 공식 Alert API 문서는 iOS와 Android에 대한 지원을 React Native Alert 참조 에 나열합니다. 앱이 React Native Web 또는 Expo Web도 실행된다면 알림을 wrapping하지 않으면 웹 빌드에서 해당 상호 작용 경로에 대한 완전한 실패를 발생시킵니다. (React Native Web 알림 지원에 대한 문제 토론 ).
그것은 일반적인 모서리 사례가 아닙니다. 팀은 모바일 QA가 먼저 통과되면서 브라우저 커버리지가 나중에 발견되는 경우가 많습니다.
모바일 전용으로 Alert를 다루려면 wrapper를 추가해야 합니다.
wrapper는 플랫폼 간의 하이브리드 런타임의 이점을 비교하는 팀이 특히 플랫폼 간의 하이브리드 런타임의 이점을 비교하는 경우에 도움이 됩니다. React Native vs. Capacitor 아키텍처 비교.
간단한 웹 폴리필 패턴
앱의 첫 번째 작동 가능한 해결책은 플랫폼 분할에 대한 작은 추상화입니다:
import { Alert, Platform } from 'react-native';
type ConfirmOptions = {
title: string;
message?: string;
onConfirm?: () => void;
onCancel?: () => void;
};
export function confirmDialog({
title,
message,
onConfirm,
onCancel,
}: ConfirmOptions) {
if (Platform.OS === 'web') {
const result = window.confirm(message ? `${title}\n\n${message}` : title);
if (result) onConfirm?.();
else onCancel?.();
return;
}
Alert.alert(title, message, [
{ text: 'Cancel', style: 'cancel', onPress: onCancel },
{ text: 'OK', onPress: onConfirm },
]);
}이 패턴은 즉시 지원 결함을 해결하지만 제한이 있습니다. window.confirm 이 패턴은 스타일링, 포커스 동작, 분석 훅에 대한 제어를 거의 제공하지 않습니다. 간단한 확인을 위한 합리적인 안전 장치지만, 액세스 가능성 검토, 알림 큐, 모바일 및 웹 간에 일관된 동작이 필요한 흐름에 대한 최종 해결책은 아닙니다.
커스텀 모달 대신 알림을 사용할 때
자연스럽게 Alert 다이얼로그가 강력한 이유는 제한된 때문입니다. 그 제한이 같은 이유로 Alert 다이얼로그가 곧 제대로 된 도구가되지 않습니다.
브랜딩, 레이아웃 제어, 아이콘, 양식 필드, 커스텀 스페이싱, 애니메이션 타이밍, 또는 크로스 플랫폼 시각적 일관성을 필요로 할 때 __CAPGO_KEEP_0__와 싸우지 마세요. 커스텀 모달을 사용하세요.API는 React Native의 아키텍처입니다.
Native alert은 code할 수 없습니다.
You can’t make Alert.alert() 디자인 시스템과 같은 모양을 만들 수 없습니다. 그건 의도한 것입니다. React Native는 rendering을 운영 체제에 맡기기 때문에 native appearance과 native constraints를 inherit합니다.
그것은 빠른 확인을 원할 때 좋지만 제품이 다음 중 하나를 요청할 때 나쁩니다:
- 브랜드 로고, helper text, 및 custom hierarchy를 가진 확인 대화상자 모달 내의 다중 필드 양식
- 체크박스 확인을 포함한 더 풍부한 파괴적 흐름 체크박스 확인을 포함한 더 풍부한 파괴적 흐름
- 평가 요청 또는 리뷰 요청 A branded confirmation dialog
- with logo, helper text, and custom hierarchy 별, minhwa, 및 사용자 지정 버튼과 함께
이러한 요구 사항이 나타나면, 네이티브 알림은 죽은 길이 됩니다.
간단한 결정 필터
사용하세요 리액트 네이티브 알림 대화가 다음과 같은 경우에 사용하세요:
| 네이티브 알림 사용 | 사용자 지정 모달 사용 |
|---|---|
| 짧은 메시지 | 복잡한 구조의 콘텐츠 |
| 기본적인 1~3개의 액션 | 폼 필드 또는 임베디드 컴포넌트 |
| 플랫폼-자체적인 외관은 받아 들여질 수 있습니다. | 시각적 일관성은 플랫폼 간에 중요합니다. |
| 가장 빠른 구현을 원합니다. | 레이아웃 및 애니메이션 제어가 필요합니다. |
모바일 및 웹 빌드가 동일한 동작을 필요로 할 때, 커스텀 모달도 도움이 됩니다. 대신에, 각 플랫폼에 대한 특별한 처리를 영원히 하지 않고, 하나의 대화 컴포넌트를 중앙화하여 상호 작용 모델을 일관되게 유지할 수 있습니다.
Alert가 "다음 하나의 속성을 가지고 싶다"고 생각할 때, 그때는 모달이 필요합니다.
커스텀 모달 라이브러리의 좋은 후보
내장된 Modal 컴포넌트는 작동하지만, 많은 팀이 react-native-modal 와 같은 wrapper를 선택하는 이유는 시각적 제어, 배경 처리, 애니메이션과 같은 실제적인 제어가 추가되기 때문입니다.
특히, 액션 시트, 하단 드로어, 또는 구성된 확인 대화판과 유사한 흐름이 있는 경우 유용합니다. 만약 디자인은 메뉴보다 엄격한 네이티브 알림과 더 가깝다면, 관련된 UI 패턴인 Ionic 액션 시트 시스템 알림을 재구성하는 것보다 종종 더 나은 정신 모델을 제공합니다.
주의해야 할 점이 하나 있습니다. 모든 알림을 커스텀 모달로 대체하지 마세요. 시스템 알림은 속도, 친숙성, 그리고 구현 위험이 낮은 점에서 여전히 우수합니다. 모달을 사용해야 하는 이유가 아니라 디자인 팀이 시스템 창을 싫어하기 때문입니다.
production 패턴을 사용하여 신뢰할 수 있는 React Native 알림
삭제 요청이 실패하고, 재시도 핸들러가 실행되고, 세션 만료 확인이 동시에 실행되면 사용자는 겹치는 대화상자, 잃어버린 포커스, 또는 웹에서 __CAPGO_KEEP_0__가 implement되지 않았기 때문에 무효화되는 문제를 겪게 됩니다. 일반적으로 이러한 버그는 아키텍처에서 오는 것이고, __CAPGO_KEEP_0__ 호출 자체에서 오는 것이 아닙니다. Alert.alert is not implemented there. Those bugs usually come from architecture, not from the API call itself.
직접
스크린에 걸쳐 있는 __CAPGO_KEEP_0__ 호출은 대규모 코드베이스에서 유지되지 않습니다. 하나의 컴포넌트는 __CAPGO_KEEP_0__ 실패를 처리하고, 다른 컴포넌트는 네비게이션 확인을 요청하고, 세 번째 컴포넌트는 인증 만료 경고를 표시합니다. 이러한 이벤트가 가까이 함께 발생하면, 하나의 위치에서 순서, 중복 제거, 플랫폼 fallback 로직이 필요합니다. Alert.alert(...) calls scattered across screens do not hold up in a larger codebase. One component handles an API failure, another asks for navigation confirmation, and a third warns about auth expiry. If those events happen close together, you need ordering, deduplication, and platform fallback logic in one place.
production 패턴을 사용하여 신뢰할 수 있는 React Native 알림
개발자들은 경고 추상화 패턴에 대한 논의에서 반복적으로 동일한 실패 모드를 지적했습니다: 구조가 좋지 않은 앱은 종종 사용자가 갇히거나 필요한 동작을 숨기거나, 때로는 약 10%의 구현에 영향을 미치는 스택된 대화상자를 갖게 됩니다. 30-40% 실제 구현에 대한 논의는 이 기사에서 이전에 언급된 바와 같이, 여기서 다시 링크하지 마십시오. 실제 해결책은 간단합니다. __CAPGO_KEEP_0__를 한번 wrapping하고, 전역적으로 요청을 큐에 넣고, 렌더러가 정확히 하나의 표시 대화상자를 관리하도록 하십시오.다음은 compact Zustand-style shape입니다: was noted earlier in the article, so do not repeat that link here). The practical fix is simple. Wrap the API once, queue requests globally, and make the renderer responsible for exactly one visible alert.
접근성은 implementation의 일부입니다.
type AlertRequest = {
title: string;
message?: string;
buttons?: { text: string; onPress?: () => void; style?: 'default' | 'cancel' | 'destructive' }[];
};
type AlertStore = {
queue: AlertRequest[];
push: (alert: AlertRequest) => void;
shift: () => void;
};iOS와 Android에서 Native alerts는 괜찮은 기본값을 제공합니다. 웹에서 커스텀 fallback, richer content, 또는 Android prompt replacement을 도입하는 순간, 시스템 대화상자가 무료로 처리한 동작을 소유하게 됩니다.
Gluestack의 React Native alert 옵션 비교는 custom modal implementation이 종종 예상되는 읽기 순서를 깨트리는 것을 지적합니다: 제목 → 메시지 → 버튼
이러한 문제는 screen reader 사용자가 대화상자의 구조를 예측할 수 있도록 하기 때문에 중요합니다. Gluestack의 React Native Alert vs Modal accessibility comparison에서 accessibility 처리에 대한 실패가 보고된 바와 같이, 해당 문제는 약 10%의 구현에서 발생합니다.
이러한 문제는 screen reader 사용자가 대화상자의 구조를 예측할 수 있도록 하기 때문에 중요합니다. Gluestack의 React Native Alert vs Modal accessibility comparison에서 accessibility 처리에 대한 실패가 보고된 바와 같이, 해당 문제는 약 10%의 구현에서 발생합니다. 이러한 문제는 screen reader 사용자가 대화상자의 구조를 예측할 수 있도록 하기 때문에 중요합니다. Gluestack의 React Native Alert vs Modal accessibility comparison에서 accessibility 처리에 대한 실패가 보고된 바와 같이, 해당 문제는 약 10%의 구현에서 발생합니다.이러한 문제는 screen reader 사용자가 대화상자의 구조를 예측할 수 있도록 하기 때문에 중요합니다. Gluestack의 React Native Alert vs Modal accessibility comparison에서 accessibility 처리에 대한 실패가 보고된 바와 같이, 해당 문제는 약 10%의 구현에서 발생합니다. 60% 이러한 문제는 screen reader 사용자가 대화상자의 구조를 예측할 수 있도록 하기 때문에 중요합니다. Gluestack의 React Native Alert vs Modal accessibility comparison에서 accessibility 처리에 대한 실패가 보고된 바와 같이, 해당 문제는 약 10%의 구현에서 발생합니다.
커스텀 알림 UI를 위해 이 체크리스트를 짧고 강제로 유지하세요:
- 대화상자가 열릴 때 포커스를 대화상자 안으로 이동하세요. 대화상자가 열릴 때:
- 대화상자가 닫힐 때 트리거로 포커스를 되돌려주세요. 읽기 순서를 유지하세요: 제목, 메시지, 그리고 액션.
- 취소 경로를 명확하게 제공하세요.특히 파괴적인 흐름에서.
- 액션을 정확하게 라벨링하세요.결과가 중요할 때 “삭제”보다는 “OK”보다 좋습니다.
- 알림 흐름의 접근성 버그는 일반 QA 중에 쉽게 놓치지만 키보드 사용자와 스크린 리더 사용자는 가장 먼저 발견합니다.접근성 버그는 알림 흐름에서 쉽게 놓치지만 키보드 사용자와 스크린 리더 사용자는 가장 먼저 발견합니다.
키보드 사용자와 스크린 리더 사용자는 알림 흐름의 접근성 버그를 가장 먼저 발견합니다.
플랫폼 대화 대신 트리거를 테스트하세요
단위 테스트는 code가 예상한 알림을 요청했는지 확인해야 합니다. 테스트 환경 외부의 대화 런타임에 의존하지 않도록 해야 합니다.
일반적인 Jest 패턴은 다음과 같습니다:
import { Alert } from 'react-native';
jest.spyOn(Alert, 'alert').mockImplementation(() => {});
it('asks for confirmation before deleting', () => {
triggerDeleteFlow();
expect(Alert.alert).toHaveBeenCalledWith(
'Delete item',
'This action cannot be undone.',
expect.any(Array)
);
});이 패턴은 테스트가 비즈니스 로직에 집중하고 대화 동작에 의한 hangs를 방지합니다. 또한 웹 및 Android의 알림 제한이 커스텀 fallback을 강요할 때 wrapper API를 사용하는 팀을 밀어줍니다.
클라이언트 측 모니터링도 도움이 됩니다. React Native 앱에서 Sentry를 사용하는 팀은 알림 트리거 경로를 명시적으로 오류 처리하고 충분한 컨텍스트와 함께 로깅하여 흐름을 재현할 수 있는 경로를 wrapping합니다. 프로덕션 기준선 usually catch more alert-related issues when alert-triggering code paths are wrapped in explicit error handling and logged with enough context to reproduce the flow.
Wrap
helper
- 웹 fallback logic은 한 곳에 살려둡니다.
Alert.alert__CAPGO_KEEP_0__ __CAPGO_KEEP_0__ - 전역으로 대기열 대화 요청을 큐합니다. 따라서 한 번에 하나의 알림만 표시됩니다.
- 안드로이드 프롬프트 지원을 없다고 간주합니다. 대신 모달 fallback을 계획하여 늦게 branch하지 않습니다.
- 취소 동작을 요구합니다. 파괴적이거나 irreversible한 작업에 대해.
- 테스트에서 알림을 모킹합니다. 레이블, 콜백, 순서를 확인합니다.
- 만약 필요할 때만 사용하십시오.웹 동등성, 프롬프트 입력, 또는 richer 콘텐츠와 같은 경우.
이것은 네이티브 알림이 잘 작동하는 곳에서는 빠르게 작동하고, 플랫폼 차이점이 나중에 나타날 때 코드베이스를 벽에 부딪히지 않도록 합니다.
