Petunjuk Master Pemberitahuan Push Expo 2026

Kamu mungkin sudah mencapai titik di mana aplikasi berjalan, pengguna telah masuk, dan produk sekarang ingin mengembangkan alur re-engagement yang terasa asli. Pengingat keranjang. Prompt ulasan. Peringatan pesan baru. Pengumuman rilis. Insting pertama seringkali adalah untuk "menghubungkan push" saja, kemudian setelah seminggu kamu sedang debugging mengapa perangkat tertentu menerima notifikasi, simulator terlihat terdaftar dengan baik, dan tidak ada yang bisa menjelaskan mengapa sentuhan tidak membuka layar yang benar.

itu di mana Expo push notifications adalah sederhana atau sangat rapuh.

Expo memberikan lapisan praktis atas APNs dan FCM untuk tim React Native, yang tepat mengapa banyak tim menggunakan itu. Namun, kesenjangan antara demo dan implementasi yang siap produksi nyata. Siklus token, waktu izin, pengaturan pendengar, desain payload, dan pembersihan backend semua berperan. Jika kamu juga mengirimkan perubahan logika aplikasi yang sering, kebutuhan disiplin operasional menjadi lebih tajam, terutama jika pekerjaan peningkatan penggunaan aplikasi kamu bergantung pada pesan yang dapat diandalkan dan kecepatan rilis. Itu adalah kekhawatiran yang sama di balik pekerjaan peningkatan penggunaan aplikasi mobile: pengiriman hanya berguna jika pengalaman pengguna di sekitarnya dapat diprediksi.

Isi Kandungan

• Dasar untuk Menghubungkan Pengguna dengan Notifikasi Expo
  • Apa yang sebenarnya diabstraksi oleh Expo
  • Apa yang sebenarnya berarti siap produksi
• Pengaturan Awal dan Konfigurasi Proyek
  • Install the notification packages
  • Tambahkan konfigurasi proyek
  • Atur handler notifikasi sebelumnya
  • Android memerlukan konfigurasi channel
• Mengajukan Izin dan Mengambil Token Push
  • Fungsi klien yang harus menjadi dasar Anda
  • Mengapa Device.isDevice tidak optional
  • Minta izin pada saat yang tepat
• Mengirim Notifikasi dari Server Anda
  • Setiap bidang payload harus melakukan apa
  • Pastikan payload kecil dan membosankan
  • Habits yang berguna di sisi server
• Menangani Notifikasi Masuk di Aplikasi Anda
  • Penerimaan latar depan dan respons pengguna adalah peristiwa yang berbeda
  • Read payload data dan navigasikan dengan sengaja
  • Perilaku latar depan harus sesuai dengan konteks pengguna
• Praktik Terbaik dan Kesalahan Umum di Produksi
  • Token-token adalah sementara, bukan catatan identitas
  • Strategi refresh lebih penting daripada yang sebagian besar tutorial katakan
  • Keamanan dan kinerja tidak boleh berada di akhir sprint
  • Apa yang biasanya berhasil dan apa yang biasanya gagal

Dasar untuk Menghubungi Pengguna dengan Notifikasi Expo Push

An Notifikasi Push Expo Pengaturan Expo push menarik karena satu alasan di atas semua. Ini menghilangkan banyak kompleksitas pesan native yang tim tidak ingin miliki pada hari pertama. Sebaliknya, Anda dapat bekerja dengan gateway Expo dan fokus pada perilaku produk, routing, UX izin, dan logika pesan backend.

Abstraksi ini tidak membuat push “kurang nyata.” Ini hanya mengubah tempat upaya insinyur Anda.

Juga, layanan ini cukup cepat sehingga kinerja biasanya bukan hal pertama yang perlu dikhawatirkan. Dari tanggal 14 Maret 2023 hingga 12 Juni 2023, API notifikasi push Expo menunjukkan 42 milisecond waktu respons median, 273 milisecond waktu p99 latency, dan sebuah tingkat kesalahan rata-rata harian sebesar 0,17% di seluruh Ratusan juta pesan harian, according to analisis benchmark API Expo push Knock. Hal ini seharusnya dapat menenangkan tim yang bertanya-tanya apakah Expo hanya cocok untuk prototipe.

Apa yang sebenarnya diabstraksi Expo

Ketika tim mengatakan "push notifikasi Expo," mereka sering kali berarti beberapa kekhawatiran yang terkait yang dibundel bersama:

• Rute penyedia: Expo mengalihkan pesan ke APNs untuk iOS dan FCM untuk Android.
• Format token: Pelayanan server Anda menyimpan dan mengirimkan Token Push Expo daripada mengelola token spesifik platform terlebih dahulu.
• Kontrak permintaan: Anda mengirimkan payload POST ke API Expo Push daripada mengintegrasi langsung API penyedia native.

Itu membantu, tetapi juga menciptakan kesalahpahaman umum. Tim kadang-kadang asumsi Expo menguasai setiap masalah pengiriman. Dalam prakteknya, banyak gagal datang dari aplikasi code, token yang kadaluarsa, payload yang rusak, atau aliran izin yang buruk.

Aturan praktis: Gunakan Expo sebagai lapisan transportasi yang dapat diandalkan, bukan sebagai pengganti desain klien dan backend yang baik.

Tentang kesiapan produksi yang sebenarnya

Demo yang berfungsi hanya membuktikan bahwa satu perangkat telah menerima satu payload sekali. Kesiapan produksi berarti sesuatu yang lain:

Perbedaan itu antara “pengiriman notifikasi” dan “notifikasi mendukung alur kerja produk nyata.”

Pengaturan Awal dan Konfigurasi Proyek

Banyak rasa sakit Expo push dimulai sebelum prompt izin pertama. Jika konfigurasi proyek Anda longgar, klien code mungkin terlihat benar sementara aplikasi masih berperilaku tidak konsisten di antara build.

Mulai dengan library yang terinstal dan lingkungan pengembangan yang sesuai dengan jalur pembangunan Anda. Jika Anda bekerja di luar Expo Go, membantu untuk menyelaraskan alur kerja lokal dengan pengaturan klien pengembangan Expo yang disesuaikan. pengaturan klien pengembangan Expo yang disesuaikankarena perilaku notifikasi sering perlu diverifikasi dalam build yang lebih dekat dengan produksi daripada menjalankan sandbox yang cepat.

Install the notification packages

Setidaknya, Anda biasanya memerlukan:

• expo-notifications untuk permintaan izin, pengambilan token, pemantauan, dan presentasi notifikasi.
• expo-device karena Anda harus melindungi pengambilan token dengan Device.isDevice.

Perintah instalasi biasanya tergantung pada manajer paket Anda, tetapi kunci adalah sinkronisasi versi dengan Expo SDK. Jangan campuradukkan versi paket yang sembarangan. Biarkan Expo menyelesaikan yang kompatibel.

Tambahkan pengaturan proyek

Tetapkan konfigurasi Anda secara eksplisit. Minimal app.json atau app.config.js harus mencerminkan fakta bahwa notifikasi adalah bagian dari kontrak aplikasi Anda, bukan sesuatu yang dilupakan.

{
  "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"
      }
    }
  }
}

Apa yang penting di sini:

• Identifikasi paket dan nama paket perlu sesuai dengan aplikasi yang Anda kirim.
• Plugin notifikasi menyediakan pengaturan native project selama proses build.
• ID EAS project penting ketika Anda mengharapkan token untuk diambil dari aplikasi yang terkait dengan project Expo yang benar.

Setel handler notifikasi awal

Banyak tutorial dasar menunda terlalu lama untuk mendefinisikan perilaku notifikasi. Jangan. Letakkan di dekat startup aplikasi agar perilaku latar depan dapat diprediksi.

import * as Notifications from 'expo-notifications';

Notifications.setNotificationHandler({
  handleNotification: async () => ({
    shouldShowAlert: true,
    shouldPlaySound: false,
    shouldSetBadge: true,
  }),
});

Tim Anda memutuskan apakah notifikasi latar depan harus menampilkan peringatan, memainkan suara, atau mempengaruhi tombol. Perilaku yang tepat tergantung pada produk Anda. Aplikasi obrolan dan aplikasi pembayaran tidak akan membuat pilihan yang sama.

Jika Anda tidak mendefinisikan perilaku latar depan secara sengaja, tim Anda akan menghabiskan waktu untuk meng-debug notifikasi yang hilang yang sebenarnya diterima tapi tidak pernah ditampilkan seperti yang diharapkan oleh produk.

Android memerlukan pengaturan saluran

Saluran notifikasi Android tidak boleh diabaikan dalam prakteknya. Jika Anda melewatinya, peringatan Anda mungkin terlihat tidak konsisten atau gagal memenuhi harapan pengguna.

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,
  });
}

Pasang ini selama inisialisasi aplikasi. Kemudian, jaga ID saluran tetap stabil. Mengubahnya secara sembarangan membuat perilaku notifikasi lebih sulit untuk dipahami nanti.

Mengajukan Izin dan Mengambil Token Push

Ini adalah bagian yang banyak tim salin dari snippet, lalu kemudian menyesalinya.

Pengajuan izin memerlukan waktu, kesadaran platform, dan penanganan async yang disiplin. Pengambilan token harus terjadi hanya pada perangkat fisik, hanya setelah izin diselesaikan, dan hanya jika Anda siap untuk menyimpan hasilnya di backend Anda segera.

Fungsi Klien yang Harus Jadi Acuan Anda

Gunakan fungsi seperti ini sebagai titik awal:

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 };
}

Urutan penting. Anda memeriksa jenis perangkat terlebih dahulu, mengatur perilaku saluran Android, menyelesaikan izin, memvalidasi konfigurasi proyek, lalu meminta token Expo.

Mengapa Device.isDevice tidak boleh diabaikan

Berikut adalah salah satu kesalahan yang menciptakan banyak kebisingan sementara terlihat tidak berbahaya. Tim ahli hanya meminta izin kondisional ketika Device.isDevice Benar, dan kesalahan umum adalah melewatkan pengaman tersebut, yang menyebabkan pengembang mengirimkan notifikasi ke token simulator yang tidak valid dan menyalahkan Expo ketika masalah sebenarnya adalah konfigurasi aplikasi, seperti yang dijelaskan dalam Eagerworks’ Catatan Implementasi Notifikasi Expo.

Itulah mengapa periksaan ditempatkan di atas fungsi. Jangan sembunyikannya di balik helper. Biarkan jelas.

Hasil simulator berguna untuk tes UI. Namun, tidak dapat dipercaya untuk memvalidasi pendaftaran token push.

Berikan izin pada saat yang tepat

Don’t ask on the splash screen. Don’t ask before the user understands the value. The best time is usually after a user action that makes notification benefits concrete, such as enabling delivery updates, joining a conversation, or saving a watched item.

Implementasi yang baik biasanya mengikuti alur ini:

1. Pengguna mencapai batasan fitur yang bermakna.
2. Implementasi yang baik biasanya mengikuti alur seperti ini:
3. Pengguna mencapai batasan fitur yang bermakna.
4. Aplikasi menyimpan token di backend segera jika izin diberikan.

Langkah terakhir itu adalah di mana banyak aplikasi gagal. Mereka mengambil token, merekamnya secara lokal, dan menunda registrasi backend. Kemudian, dukungan tidak bisa mengetahui perangkat mana yang memiliki token mana pada saat tertentu.

Contoh sederhana penyimpanan token setelah registrasi:

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;
}

Di bagian akhir alur kerja, panduan ini adalah referensi visual yang membantu:

Untuk tim yang membangun aplikasi dengan perilisan berat, juga membantu untuk berpikir tentang registrasi token sebagai bagian dari keadaan operasional aplikasi, bukan hanya bagian dari proses onboarding. Sikap itu cocok dengan alur kerja pengiriman aplikasi Expo yang lebih luas, Pengiriman Aplikasi Expodi mana perilaku aplikasi dapat berubah sering dan status backend perlu tetap sinkron.

Mengirim Notifikasi dari Server Anda

Once your backend has a valid Expo Push Token, sending a notification is straightforward. The hard part isn’t the request itself. It’s deciding what belongs in the payload and how much trust you place in client state.

Apa yang harus dilakukan oleh setiap bidang 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;
}

What each payload field should do

Jangan gunakan payload sebagai tempat sampah. Pastikan setiap field memiliki tujuan yang jelas.

The data object is where product workflows become useful. You can pass a type and record ID, then let the app fetch the latest data when the user taps. That’s safer than embedding large or sensitive blobs directly in the payload.

Tahan beban payload kecil dan sederhana

Petunjuk Courier untuk pemberitahuan Expo Petunjuk Pengantar Courier untuk Pemberitahuan ExpoPush Token Expo harus dianggap sebagai sementara, payload yang melebihi batasan ukuran sekitar 4 KB Dapat diabaikan, dan pola yang dapat diandalkan adalah mengirimkan metadata payload kecil seperti { "type": "new_review", "id": 123 } rather than large JSON or inline media. That advice matches what works in real systems. Small payloads fail less often and age better when app logic changes.

Kirimkan cukup data untuk menentukan jalur pengguna. Ambil sisa data setelah aplikasi dibuka.

Habits berguna di sisi server

Fungsi kirim dasar sudah cukup untuk tes. Fungsi produksi biasanya menambahkan beberapa tanggung jawab lainnya:

• Simpan upaya kirim: Simpan niat notifikasi dengan ID pengguna, token, jenis payload, dan waktu timestamp.
• Jangan campur aduk antara pembuatan konten dengan transportasi: Buat salinan pesan di satu lapisan dan permintaan Expo API di lapisan lain.
• Proses feedback invalidasi: Jika Expo kemudian melaporkan DeviceNotRegistered, tandai token tidak aktif dan berhenti mencoba ulang secara acak.
• Gunakan desain yang ramah webhook: Jika sistem Anda sudah mengeluarkan event, arahkan trigger notifikasi melalui jenis yang sama Polanya Webhook Pengolahan Backend Anda gunakan di tempat lain.

Sebelum memulai debugging pengguna, kirimlah push manual terlebih dahulu. Jika token menerima notifikasi sederhana dengan payload kecil, jalur transportasi Anda mungkin sehat. Jika tidak, jangan mulai dengan mengubah navigasi code. Mulai dengan memvalidasi token, bentuk payload, dan status izin.

Menangani Notifikasi Masuk di Aplikasi Anda

Kirimnya hanya setengah fitur. Aplikasi harus melakukan sesuatu yang konsisten ketika notifikasi datang dan ketika pengguna mengetuknya.

Artinya menangani dua momen terpisah:

• notifikasi datang ketika aplikasi terbuka
• pengguna berinteraksi dengan notifikasi dari tray sistem atau layar kunci

Penerimaan dan respons pengguna adalah dua event yang berbeda.

Konfigurasi yang dapat diandalkan biasanya mencakup kedua listener:

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 berjalan ketika aplikasi aktif. addNotificationResponseReceivedListener berjalan ketika pengguna mengetuk notifikasi yang telah dikirimkan. Jangan kombinasikan mereka secara mental. Mereka melayani jalur UX yang berbeda.

Baca payload data dan navigasikan dengan sengaja

Berikut adalah pola yang efektif untuk menghandle sentuhan tombol:

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');
}

Pola ini tetap stabil karena payload berisi petunjuk routing, bukan dokumen lengkap. Jika urutan telah berubah sejak notifikasi dikirim, aplikasi dapat mengambil status server saat ini setelah navigasi.

Notifikasi yang disentuh harus mengarah ke satu tujuan yang jelas. Jika jalur cadangan Anda tidak jelas, pengguna akan menyadari segera.

Perilaku latar depan harus sesuai dengan konteks pengguna

Ketika aplikasi sudah terbuka, menampilkan peringatan sistem secara acak dapat terasa tidak nyaman. Terkadang langkah yang tepat adalah menampilkan banner aplikasi, memperbarui badge, atau memperbarui secara diam. Layar inbox dukungan mungkin tidak memerlukan peringatan yang terlihat ketika pengguna sedang membaca percakapan tersebut.

Itulah mengapa listener latar depan Anda harus membagi berdasarkan jalur dan jenis notifikasi. Misalnya:

• Layar chat terbuka: Tambahkan pesan dan hindari menampilkan banner yang tidak perlu
• Layar dashboard terbuka: Tampilkan notifikasi ringan dalam aplikasi
• Event akun kritis: Tampilkan perawatan UI yang lebih kuat

Aplikasi sederhana seperti ini:

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
}

Jika aplikasi Anda tidak dapat membedakan konteks ini, pengguna akan merasa lelah dengan notifikasi lebih cepat, bahkan jika pengiriman teknisnya benar.

Praktik Terbaik dan Kesalahan Umum di Produksi

Sebagian besar pengaturan notifikasi push Expo yang rusak tidak gagal karena Expo terlalu terbatas. Mereka gagal karena tim asumsi token adalah permanen, payload dapat membawa apa saja, dan pembaruan aplikasi tidak akan mempengaruhi logika notifikasi.

Asumsi tersebut tidak bertahan di produksi.

Token adalah sementara, bukan catatan identitas

Token Push Expo yang baik harus dianggap seperti sewa, bukan identitas perangkat seumur hidup. Token dapat berputar setelah reinstall, perubahan OS, atau kejadian siklus lainnya. Jika token akhirnya kembali DeviceNotRegistered, backend Anda harus berhenti menganggapnya sebagai aktif.

Model backend yang praktis menyimpan:

• ID pengguna
• platform
• install-metadata ter-scope
• token saat ini
• timestamp terakhir dilihat
• status seperti aktif, ketinggalan, atau dibatalkan

Tidak menyimpan satu lapangan token pada tabel pengguna dan selesai. Pengguna memiliki perangkat yang berbeda, dan perangkat berubah status.

Strategi refresh lebih penting daripada tutorial yang paling banyak.

Guidançe ekosistem resmi meninggalkan celah operasional yang nyata di sini. Konten pemberitahuan push Expo yang ada sering tidak menjelaskan cara menjaga keabsahan token di seluruh Siklus ulasan App Store dan pembaruan OTAyang sangat penting bagi tim yang mengirimkan perubahan hidup karena keandalan push tergantung pada status token saat ini dan sinkronisasi backend, seperti yang disebutkan di Meluncurkan aplikasi setelah pembaruan.

refresh trigger Anda akan terpengaruh. Waktu yang tepat untuk menyinkronkan keadaan token termasuk:

• Aplikasi diluncurkan setelah pembaruan
• Masuk pengguna
• Pengaturan izin berubah
• Rotasi kredit bekerja pada proses rilis Anda
• Aliran pemulihan setelah tiket dukungan terkait push

Keamanan dan kinerja tidak boleh berada di akhir sprint

Banyak tutorial Expo fokus pada mekanika dan melewatkan risiko operasional. Itu baik untuk aplikasi hobi. Tidak baik untuk produk perawatan kesehatan, fintech, atau perdagangan yang diatur.

Diskusi fokus bisnis Courier tentang kekurangan notifikasi Expo menunjukkan kekurangan panduan praktis seputar pencatatan persetujuan, jejak audit, dan mengurangi paparan payload sensitif. Ambilalih insinyur langsung adalah sederhana:

• Tidak masukkan data bisnis sensitif ke dalam teks atau metadata notifikasi.
• Catat perubahan persetujuan di server.
• Rekam mana notifikasi intent yang dikirim ke mana token.
• Pakai ID di payload dan ambil konten yang dilindungi setelah aplikasi dibuka.

Untuk tim yang mengatur operasi rilis dengan lebih luas Kepatuhan Toko Aplikasi dan Praktik-Praktik Keamanan APIpush harus dimasukkan dalam disiplin tinjauan yang sama seperti auth, analytics, dan logging event backend.

Push notifications are user-facing messages, but they’re also a distributed systems problem. Treat them with the same care you apply to auth state and payment events.

Apa yang biasanya berfungsi dan apa yang biasanya gagal

Konfigurasi push Expo yang solid bukanlah rumit. Itu disiplin.

Jika tim Anda mengirimkan perubahan logika aplikasi yang sering dan membutuhkan kontrol yang lebih ketat atas perilaku rilis, pengembalian, dan visibilitas pengiriman, Capgo mungkin layak dilihat. Ini membantu tim mobile mengirimkan update dengan cepat tanpa menunggu tinjauan toko, yang sangat berguna ketika aliran pemberitahuan, logika routing, atau perbaikan sisi klien perlu mencapai pengguna dengan cepat.