Di pihak pengguna, klien email adalah aplikasi sederhana. Pengembang Yandex.Mail bahkan bercanda bahwa hanya ada tiga layar dalam aplikasi: daftar surat; mengirim surat; tentang layar.
Tetapi banyak hal menarik terjadi di bawah tenda. Seperti banyak aplikasi seluler, Mail menggunakan pemberitahuan push untuk berinteraksi dengan pengguna. Seperti banyak aplikasi iOS, Mail kehilangan beberapa pemberitahuan karena sifat dari Layanan Pemberitahuan Dorong Apple.
Asya Sviridenko , kepala kelompok iOS Yandex.Mail, akan membuktikan bahwa meskipun dengan keterbatasan sistem, hilangnya pemberitahuan push dapat dan harus diperjuangkan jika mereka penting untuk aplikasi Anda. Ini berlaku untuk Mail, karena pemberitahuan push surat baru adalah tujuan pengguna menginstal aplikasi. Jika, untuk aplikasi Anda, pengiriman pemberitahuan push tidak terlalu penting, masih menarik untuk mencari tahu sepeda mana yang dipasangi Yandex.Mail seluler.
Ini tentang notifikasi jarak jauh, yaitu notifikasi yang datang dari server melalui APN (Apple Push Notification Service). Kami tidak akan menyentuh notifikasi lokal dan membicarakan:
- Seperti apa tampilan API untuk bekerja dengan pemberitahuan push. Pertimbangkan skema pengiriman pemberitahuan push dan di mana kerugian dapat terjadi dalam skema ini.
- Bagaimana Anda memutuskan untuk menangani kerugian di Yandex.Mail - antrian pemberitahuan push.
- Bagaimana cara log dan kesulitan apa yang bisa ditemui.
Apa yang kita miliki dan di mana kita kehilangan
Sekarang API untuk bekerja dengan pemberitahuan push adalah hal yang cukup kuat yang memungkinkan Anda melakukan banyak hal menarik. Tapi itu tidak selalu terjadi.
Sebelumnya, pemberitahuan push tampak persis seperti ini - itu adalah dasbor biru yang muncul di layar, diblokir bekerja dengan aplikasi saat ini, tidak mengizinkan apa pun dilakukan, dan kemudian menghilang selamanya, dan tidak ada lagi pengingat tentang hal itu.
Sudah cukup waktu sejak itu.
Bagi kami, sebagai pengembang,
semuanya dimulai di iOS 3 ketika pemberitahuan push tersedia untuk perpustakaan pihak ketiga.
Pusat Pemberitahuan muncul di iOS 5 , dan pemberitahuan push berhenti ke mana-mana, sekarang mereka tetap berada di Pusat Pemberitahuan, tempat mereka dapat dilihat lagi.
IOS 6 memperkenalkan Do Not Disturb . Pengguna memiliki kesempatan untuk mengatur periode waktu di mana ia tidak ingin menerima pemberitahuan.
Perubahan ini terutama menyangkut bagaimana pengguna dapat bekerja dengan pemberitahuan push, bagaimana mereka bisa membuat hidupnya lebih nyaman, dan bukan bagaimana pengembang dapat memengaruhi pemberitahuan.
Untuk pengembang, tonggak penting adalah
iOS 8 dan munculnya Tindakan Pemberitahuan , yang memungkinkan untuk melakukan tindakan khusus untuk aplikasi tertentu dengan pemberitahuan push.
IOS 10 memperkenalkan Perpanjangan Layanan Pemberitahuan dan Perpanjangan Konten Pemberitahuan . Yang pertama memungkinkan Anda untuk memodifikasi pemberitahuan push sebelum ditampilkan kepada pengguna. Yang kedua adalah menampilkan beberapa UI dengan pemberitahuan push pada Push notification, di mana, misalnya, Anda dapat menampilkan informasi yang lebih detail. Di iOS 10, UI ini tidak dapat diklik - Anda dapat menonton, Anda tidak dapat menyentuhnya.
IOS 11 memperkenalkan Pengaturan Privasi Pemberitahuan . Sekarang pengguna dapat masuk ke pengaturan dan menunjukkan apakah ia ingin konten pemberitahuan yang masuk ditampilkan. Ini adalah langkah besar menuju keamanan. Hanya perlu 8 versi iOS untuk memahami bahwa tidak semua pengguna ingin informasi pribadi tiba-tiba muncul di iPhone yang tergeletak di atas meja.
Di iOS 12, menjadi mungkin untuk mengelompokkan pemberitahuan push berdasarkan thread-id, dan UI yang kami terima di iOS 10 menggunakan Pemberitahuan Konten Ekstensi telah menjadi dapat diklik. Sekarang Anda dapat menambahkan tombol dan kontrol gerakan di sana - semua yang membantu pengguna berinteraksi dengan UI.
Pemberitahuan push hari ini
Seperti yang dapat Anda lihat, pemberitahuan push telah lama, dan hari ini dengan bantuan mereka Anda benar-benar dapat melakukan banyak hal.
Pesan teks dan lokalisasi
Seperti sebelumnya, kami dapat mengirim pesan teks dalam pemberitahuan push, tetapi sekarang Anda juga dapat menentukan kunci untuk pelokalan.
"aps" : { "alert" : { "title" : "New Mail", "subtitle-loc-key" : "alert_subtitle_localization_key", "loc-key" : "alert_body_localization_key", } }
Jika Anda menentukan
subtitle-loc-key dan
loc-key dalam notifikasi payload, maka ketika notifikasi push tiba di perangkat, nilai-nilai yang diperlukan akan ditemukan dalam file Localizable.string aplikasi dan pengguna akan melihat pesan yang dilokalkan.
Suara dan peringatan kritis
Seperti sebelumnya, Anda dapat menambahkan suara ke notifikasi payload.
"aps" : { "sound" : { "critical" : 1, "name" : "bingbong.aiff", "volume" : 1.0, } }
IOS 12 memiliki peringatan kritis. Ini adalah suara yang akan diputar bahkan jika pengguna dalam mode Do Not Disturb.
Biasanya, pengguna tidak perlu, misalnya, aplikasi dengan berlangganan majalah di malam hari untuk melaporkan bahwa nomor baru telah dirilis. Karena itu, Apple membatasi aplikasi yang dapat menggunakan peringatan kritis. Jika aplikasi Anda bekerja dengan kesehatan, keselamatan, atau Anda berpikir bahwa peringatan kritis adalah sesuatu yang benar-benar dapat membantu pengguna berinteraksi dengan aplikasi Anda, tulis ke Apple. Mungkin mereka akan memungkinkan Anda untuk menggunakan fungsi ini.
Notifikasi diam
Pengguna tidak melihat pemberitahuan diam. Mereka datang langsung ke aplikasi, membangunkannya dan memungkinkan Anda untuk melakukan beberapa tindakan untuk memperbarui aplikasi: mengirim permintaan ke server, meminta data di latar belakang, memperbarui data dari database, memperbarui UI sehingga ketika pengguna memasukkan aplikasi, ia melihat data yang diperbarui.
"aps" : { "content-available" : 1
Agar pemberitahuan push menjadi senyap, Anda harus menentukan di payload:
"content-available" : 1 . Dan jangan tentukan tanda peringatan, suara dan kunci lencana dalam payload - mereka sama sekali tidak berguna untuk pemberitahuan push yang tidak akan ditampilkan kepada pengguna.
Pengelompokan Pemberitahuan
Untuk mengelompokkan pesan, Anda harus menentukan “thread-id” dalam payload. Ini dapat memiliki beberapa nilai dalam aplikasi yang sama, jika Anda ingin mengelompokkan dalam berbagai cara: berdasarkan akun, oleh penerima, berdasarkan topik.
"aps" : { "thread-id" : "any_thread_identifier" }
Ini sangat mudah, karena sekarang pemberitahuan push tidak mengambil semua ruang di layar yang terkunci, tetapi dikelompokkan bersama. Jika Anda belum menggunakan fungsi ini, sekarang saatnya untuk memulai.
Ubah pemberitahuan sebelum menampilkannya
Pemberitahuan push dapat diubah sebelum ditampilkan. Untuk melakukan ini, Anda perlu menambahkan Ekstensi Konten Pemberitahuan ke aplikasi dan mengganti metode
didReceive . Dalam metode ini, Anda bisa mendapatkan konten notifikasi dan memodifikasinya.
"aps" : { "mutable-content" : 1 } override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) { guard let mutableContent = request.content.mutableCopy() as? UNMutableNotificationContent else { contentHandler(request.content); return } mutableContent.subtitle = "Got it!" contentHandler(mutableContent) }
Misalnya, Anda dapat mengirim tautan ke konten media dalam pemberitahuan, mengunduh konten dalam Ekstensi, dan melampirkan unduhan ke pemberitahuan. Setelah itu, panggil penyelesaian dengan konteks baru, dan tunjukkan kepada pengguna pemberitahuan push yang diperpanjang. Anda dapat mengubah judul, subtitle, dll.
Kasus menarik lainnya adalah Anda dapat mengirim pemberitahuan push dengan konteks terenkripsi, jika Anda ingin data dilindungi tambahan, dan Apple tidak melihatnya. Di Ekstensi Konten Pemberitahuan, Anda dapat mendekripsi dan menunjukkan data yang sudah didekripsi kepada pengguna.
Konten Pemberitahuan Tersembunyi
Di iOS 11, menjadi mungkin untuk menyembunyikan konten pemberitahuan push, dan kami, sebagai pengembang, tidak dapat memengaruhi ini dengan cara apa pun. Jika pengguna mencentang "Sembunyikan konten pemberitahuan", satu atau lain cara itu akan disembunyikan. Yang bisa kita lakukan adalah melalui UNNotificationCategory untuk menentukan placeholder yang akan ditampilkan alih-alih konten (secara default ini adalah notifikasi), dan untuk mengatur apakah akan menampilkan judul atau subtitle.
let commentCategory = UNNotificationCategory(identifier: "comment-category", actions: [], intentIdentifiers: [], hiddenPreviewsBodyPlaceholder: NSString.localizedUserNotificationString(forKey:"COMMENT_KEY",arguments: nil), options: [.hiddenPreviewsShowTitle])
Langkah-langkah pemberitahuan tanpa meluncurkan aplikasi
Untuk melakukan tindakan pemberitahuan push tanpa meluncurkan aplikasi itu sendiri, Anda perlu membuat kategori dan menambahkan tindakan ke sana. Pengidentifikasi kategori diteruskan ke bidang kategori pemberitahuan muatan. Anda dapat menghubungkan berbagai tindakan ke berbagai jenis notifikasi.
"aps" : { "category" : "message" } let action = UNNotificationAction(identifier:"reply", title:"Reply", options:[]) let category = UNNotificationCategory(identifier: "message", actions: [action], minimalActions: [action], intentIdentifiers: [], options: []) UNUserNotificationCenter.current().setNotificationCategories([category])
Notifikasi kaya
Dalam ekstensi ini, Anda dapat memproses tindakan tambahan yang Anda tambahkan ke pemberitahuan push dan menampilkan UI khusus.
Untuk melakukan ini, Anda perlu menambahkan Ekstensi Konten Pemberitahuan ke aplikasi, menentukan kelas di dalamnya yang mewarisi dari UNNotificationContentExtension, dan kemudian bekerja dengannya seperti dengan UIViewController biasa.
class NotificationViewController: UIViewController, UNNotificationContentExtension { @IBOutlet var userLabel: UILabel? func didReceive(_ notification: UNNotification) { let content = notification.request.content self.title = content.title let userInfo = content.userInfo self.userLabel?.text = userInfo["video-user"] as? String } }
Jika Anda memproses tindakan kustom, penting untuk diingat bahwa tindakan ini layak memperbarui UI yang Anda tampilkan kepada pengguna. Tidak perlu mencoba menerapkan logika bisnis dalam ekstensi ini. Kirim permintaan ke server melalui tindakan dengan pemberitahuan push di aplikasi utama, dan tidak di sini. Tempat ini hanya untuk UI.
Skema Pengiriman Pemberitahuan Push
Lihat seberapa banyak yang dapat Anda lakukan dengan pemberitahuan push di iOS. Dari versi ke versi, kami memiliki lebih banyak fungsi baru, tetapi skema pengiriman pemberitahuan push sekarang persis sama seperti di iOS 3.
Orang akan berpikir bahwa skema pengiriman pemberitahuan push baik-baik saja dari awal, tetapi tidak.
Ada tiga node utama dalam skema pengiriman pemberitahuan push:
- penyedia yang menghasilkan pemberitahuan push payload;
- APNs - Layanan Pemberitahuan Push Apple, yang memberikan pemberitahuan;
- perangkat iOS dan aplikasi Anda.
Saya akan melewatkan bagian tentang cara mendaftar, menerima token, ke mana harus mengirimkannya. Misalkan kita memiliki semua ini. Apa yang terjadi selanjutnya?
- Penyedia menghasilkan payload dan mengirimkannya ke APN.
- APN mengirimkannya ke perangkat.
- Pengguna melihat pesan push di perangkatnya.
Mail dan banyak aplikasi lain menggunakan skema pengiriman pemberitahuan push tingkat lanjut. Ekstensi Layanan Pemberitahuan ditambahkan, yang menerima pemberitahuan push dengan
"mutable-content" : 1 . Penyedia dibagi menjadi server yang berurusan dengan logika backend aplikasi, dan penyedia itu sendiri, yang menghasilkan muatan dan berurusan dengan langganan.
Di Yandex, penyedia yang membentuk payload disebut XIVA. XIVA adalah basis data berlangganan. Mail menggunakan XIVA untuk bekerja dengan pemberitahuan push sebagai perpustakaan pihak ketiga.
Di Mail, pekerjaan dengan langganan diatur secara non-sepele. Kami tidak hanya menandatangani aplikasi untuk notifikasi, kami memiliki multi-akun. Kami dapat menandatangani akun yang berbeda, atau dalam satu akun memilih folder mana pengguna ingin menerima notifikasi dan mana yang tidak mereka inginkan. XIVA menangani semua ini. Beberapa layanan Yandex lainnya juga bekerja melalui XIVA: semua informasi tentang aplikasi, pemberitahuan, langganan, token disimpan dalam XIVA.
Dimana kerugiannya?
Ada empat panah dalam skema pengiriman pemberitahuan push, kerugian dapat terjadi pada tiga transisi ini.
Antara server dan XIVA, kerugian dapat terjadi dalam kasus berikut. Pengguna menerima surat, server tahu tentang hal itu, menghasilkan pemberitahuan dan mengirimkannya ke XIVA. Tetapi XIVA dapat kehilangan informasi ini, misalnya, jika pengguna dalam aplikasi memilih "Berlangganan" ke folder tertentu saat ia offline. Kemudian XIVA tidak akan menerima informasi tentang berlangganan ke folder, dan ketika payload tiba, itu hanya akan menghapusnya dan pengguna tidak akan melihat notifikasi.
Antara XIVA dan APN , kehilangan jaringan dapat terjadi. Kami hampir tidak dapat mempengaruhi jaringan, jadi kami tidak akan membahas hal ini.
Antara APNs dan Extension, atau APNS dan iOS jika Anda tidak menggunakan Extension. Ini adalah jenis kehilangan yang paling umum. Kerugian tersebut terjadi karena APN tidak menyimpan lebih dari satu dorongan per aplikasi pada perangkat. Jika, saat pengguna offline, ia menerima beberapa notifikasi, ketika ia online, ia hanya akan melihat pesan terakhir.
Ini adalah kerugian yang sama yang tidak memungkinkan kami untuk menjamin pengiriman dan bergantung pada pemberitahuan push. Apple dengan jelas menulis bahwa pengiriman tidak dijamin.
Antara aplikasi Ekstensi dan iOS, kerugian tidak dapat terjadi , dan Apple menjamin ini. Jika Anda menggunakan Extension dan mengganti didReceiveContent dengan metode penyelesaian, bahkan jika Anda tidak memanggil penyelesaian ini, notifikasi akan tetap ditampilkan. Ini penting untuk diingat. Anda mungkin tidak menyebutnya atau tidak punya waktu untuk memanggilnya, tetapi kemudian pemberitahuan akan ditampilkan tanpa perubahan apa pun, dalam bentuk di mana ia berasal dari APN.
Kami akan melihat bagaimana kami menangani kerugian antara APN dan Perpanjangan. Tetapi jika Anda perlu meningkatkan kemampuan pengiriman pemberitahuan push, lihat keseluruhan skema. Periksa apakah ada kerugian di sisi layanan, apakah penyedia Anda berinteraksi secara normal dengan APN dan sebagainya. Periksa dan ukur keseluruhan rantai, dan kemudian buat kesimpulan di mana kerugian paling banyak terjadi dan bagian mana dari sirkuit ini yang harus dimodifikasi.
Tekan Notifikasi Antrian
Cara kami menangani kerugian dalam bundel APN dan Ekstensi yang kami sebut antrian pemberitahuan push.
Jika Anda mengompres keseluruhan cerita menjadi satu frasa, maka itu akan menjadi:
Jika Anda melewatkan pemberitahuan push, Anda dapat memintanya lagi.
Dalam skema pengiriman pemberitahuan kami, semua peserta yang sama adalah: XIVA, APNs, Extension. Skema yang disederhanakan bekerja seperti ini:
- XIVA memberi nomor pada notifikasi push yang ingin dikirim ke APN, dan baru kemudian mengirim informasi.
- Ekstensi menerima pemberitahuan push nomor 1 dan, setelah beberapa waktu, nomor 3. Ini memahami bahwa beberapa data hilang.
- Mengirim ke XIVA permintaan dengan posisi terakhir diterima, berbeda dan meminta untuk mengirim data yang hilang lagi.
- XIVA mengirim ulang pemberitahuan push karena menyimpan database payload dan database berlangganan. Semua langganan disimpan selama beberapa waktu dan dapat diminta kembali.
- Kami kembali bertanya, kami menerima pemberitahuan push, dan kami memiliki semua pesan yang seharusnya diterima klien.
Masalah yang diharapkan pertama adalah pemberitahuan rangkap. Ketika kami meminta kembali pesan dari XIVA, kami tidak tahu apa yang ada dalam antrian untuk dikirim, karena kami berkomunikasi dengannya tidak secara langsung, tetapi melalui APN. Misalkan kita melihat bahwa beberapa pemberitahuan hilang, dan mengirim permintaan ke XIVA. XIVA dikirim melalui APN payload dengan pemberitahuan yang terlewat. Tetapi sebelum kami menerimanya, kami menerima muatan lain dan juga dengan izin. Mereka bertanya lagi - XIVA mengirim lagi.
Agar notifikasi tidak digandakan, kami menggunakan
apns-collapse-id . Pengaturan ini memungkinkan sisi iOS untuk membatalkan pemberitahuan push dengan ID yang sama. Jika beberapa notifikasi push dengan apns-collapse-id yang sama telah tiba di perangkat, iOS akan menutupnya dan pengguna hanya akan melihat satu notifikasi.
XIVA
Saya akan memberi tahu Anda cara kerjanya di XIVA, karena selalu ingin tahu apa yang terjadi di backend.
XIVA ada sebelum antrian pemberitahuan push dan merupakan basis data berlangganan. Penting bahwa dalam basis data semua disimpan oleh pengguna:
- Kuncinya adalah
<service, user> . - Payload disimpan sebagai nilai (data tentang surat dalam kasus Mail).
XIVA mengambil data dari database dan dikirim ke APNs atau layanan lain, karena ia bekerja tidak hanya dengan iOS. Kami memutuskan untuk menggunakannya kembali.
Kami datang ke tim pengembangan XIVA dan benar-benar meminta antrian pemberitahuan push. Pada prinsipnya, XIVA sudah memiliki segalanya untuk ini: database, TTL untuk payload, yaitu, mereka tidak segera dihapus, mereka dapat diteruskan. Satu-satunya hal yang hilang adalah bahwa itu mungkin untuk mengkonfigurasi antrian pemberitahuan push sebagai bagian dari implementasi XIVA saat ini - itu penomoran ujung-ke-ujung.
Untuk penomoran pass-through, notifikasi push harus diberi nomor oleh perangkat dan app_name. Artinya, penomoran ujung-ke-ujung diperlukan untuk perangkat tertentu dan untuk aplikasi tertentu agar dapat mengandalkannya di sisi klien. Kami melakukan ini sebagai berikut: menggunakan kembali basis data XIVA, tetapi mulai menulis payload ke sana menggunakan kunci yang berbeda. Sekarang apns_queue bertindak sebagai layanan,
device_id + app_name sebagai pengguna - data yang perlu diberi nomor pada klien, yaitu,
key: <apns_queue, device_id + app_name> .
Sekarang XIVA mengambil data dari database utama dan memasukkannya ke dalam antrian ketika perlu dikirim. Pada titik ini, payload menerima penomoran baru, karena sekarang mereka berada di database yang sama, tetapi dengan kunci yang berbeda. Sudah dari sana XIVA mengeluarkannya dan mengirimkannya melalui APN. Secara total, klien menerima penomoran payload yang diperlukan.
Klien menggunakan Ekstensi Layanan Pemberitahuan.
public override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) {
Kami mendefinisikan kembali metode
didReceive di
didReceive dan melihat apa yang datang dari server. Kami menambahkan
"mutable-content" : 1 ke semua pemberitahuan push sehingga masuk ke dalam Ekstensi, karena jika tidak, kami tidak dapat memperhitungkannya dalam perhitungan.
Lebih lanjut dalam kode di dalam metode ada pemeriksaan berkelanjutan: apakah muatan yang diperlukan datang, apakah mereka dapat menguraikannya. Jika tidak diuraikan, maka pesan ini bukan dari XIVA. Jika pesan itu bukan dari XIVA, kami tidak dapat terus bekerja dengannya dan cukup memanggil penyelesaian dengan pemberitahuan yang datang dari APN, kami tidak melakukan perhitungan apa pun.
guard let payload = try? self.payloadParser.parsePayload(from: request.content.userInfo) else {
Kami masuk, periksa apakah deviceId telah berubah, karena kami tahu bahwa di iOS itu mungkin. Jujur, kami belum menemukan perubahan pada deviceId, tapi kalau-kalau kami sedang memprosesnya, karena jika itu berubah, kami tidak akan bisa mempercayai angka-angka dari XIVA.
self.logger.logNotificationReceived(with: payload) if lastPositionDeviceId != deviceId {
Lebih jauh kita melihat, apakah kita dapat menerima data XIVA dalam muatan ini, apakah mereka atau tidak. Jika tidak, panggil contentHandler lagi.
guard let xivaInfo = payload.xivaInfo else { contentHandler(request.content); return }
Jika ada data, periksa untuk melihat apakah deviceId telah menerima data. XIVA mengirimkan hash perangkat ke payload, jika diverifikasi dan cocok, kami melanjutkan, tidak, kami sebut contentHandler.
guard isHashCompatible(deviceId: deviceId, deviceIdHash: xivaInfo.deviceIdHash) else {
Blok selanjutnya adalah untuk melihat apakah ada posisi yang disimpan:
- Jika kami tidak memiliki posisi yang disimpan terakhir, maka kami belum menerima pemberitahuan dan belum memasukkan Ekstensi, atau karena alasan tertentu keluar. Lalu tidak ada yang perlu dilakukan untuk menemukan perbedaan yang terlewat, dan kami kembali memanggil penyelesaian.
- Jika ada, lanjutkan.
guard let lastPos = lastNotificationPosition else {
Kami menghitung jumlah pemberitahuan yang terlewat. Jika kehilangan nol baik-baik saja, kami tidak melewatkan apa pun.
let missedMessages = xivaInfo.notificationPosition - lastPos - 1 guard missedMessages > 0 else {
Jika tidak, kami mengambil dari XIVA data posisi - dari penomoran berkelanjutan yang sama. Lebih jauh kita melihat, apakah jumlah yang terlewat tidak melebihi nilai yang ditentukan.
lastNotificationPosition = xivaInfo.notificationPosition guard missedMessages <= repeatMaxCount else {
Mengapa ini dibutuhkan? Misalkan pengguna telah offline untuk waktu yang lama, dan selama waktu ini seratus pesan telah terakumulasi. Kami akan meminta seluruh seratus (mudah bagi kami), XIVA akan mengirim seluruh seratus, dan pengguna akan menerima semua pemberitahuan. Bahkan jika kita mengelompokkannya berdasarkan thread-id (dan kita mengelompokkannya), semua sama, untuk setiap notifikasi, ekstensi ini akan dipanggil, semua cek akan berlalu. Tampaknya tidak mungkin bahwa pengguna membutuhkan semua seratus notifikasi. Karena itu, kami membuat pemberitahuan di mana kami menulis bahwa Anda memiliki 100 pesan yang tidak terjawab, buka aplikasi dan lihat. Dan kami menunjukkan pesan ini kepada pengguna, karena kami dapat mengganti pemberitahuan push.
Ketika semua cek telah lulus, kami mengirim permintaan ke XIVA: posisi terakhir yang datang kepada kami, dan jumlah pesan yang terlewat. Dan lihat:
- Jika XIVA berhasil merespons: “Semuanya baik-baik saja, saya akan mengirim data”, kami menunjukkan kepada pengguna pemberitahuan saat ini dan menunggu hingga XIVA mengirim semua yang lain dan pengguna melihat semua pesan yang terlewat.
- Jika XIVA menjawab dengan kesalahan, maka kami menunjukkan kepada pengguna pemberitahuan khusus bahwa ia telah melewatkan pesan yang dapat dilihat dalam aplikasi.
self.requestMissedNotifications(lastPosition: xivaInfo.notificationPosition, gap: missedMessages) { result in result.onValue { _ in self.logger.logNotificationProcessed(with: .success) contentHandler(request.content) }.onError { error in self.logger.logNotificationProcessed(with: .failure(error)) contentHandler(buildNewNotification()) } }
Dengan demikian, implementasi pada klien datang ke sejumlah besar pemeriksaan di mana kami mengetahui apakah kami dapat bekerja dengan data yang diterima.
Penebangan dan kesulitan lainnya
Seperti yang Anda ketahui, untuk memastikan pendekatan tersebut berfungsi dengan baik, Anda harus login. Kami mulai mengumpulkan statistik tentang metode baru untuk mengirimkan pemberitahuan dan membandingkan bagaimana kemampuan pengiriman telah berubah.
Keterbatasan ekstensi push
Hal pertama yang kami temui adalah pembatasan push-extension.
Tidak selalu dipanggil . Jika Anda mematikan gambar pemberitahuan di pengaturan aplikasi (kemampuan untuk menerima pemberitahuan tetap menyala, tetapi semua kemungkinan render dimatikan), Ekstensi tidak akan dipanggil - semua logika dengan penghitungan ulang dan, yang paling penting, pencatatan tidak akan dipanggil. Kami tidak akan dapat menemukan apa yang paling penting bagi kami - apakah pengguna telah menerima pemberitahuan.
Ekstensi dorong memiliki batas waktu . Dokumentasi Apple mengatakan bahwa dalam waktu sekitar 30 detik Anda harus memanggil penyelesaian dengan notifikasi yang dimodifikasi, jika tidak, notifikasi awal akan ditampilkan.
Saya bertanya-tanya bagaimana kita menemukan jawabannya. Kami menerapkan fitur yang kami sebut notifikasi push "cantik", elemen media terlampir pada notifikasi, mengubah judul, subtitle. Selama pengujian, ternyata beberapa notifikasi push menjadi indah, sementara sisanya seperti bebek jelek tetap.
Kami mulai melihat perbedaan antara pemberitahuan push ini dan menemukan bahwa tidak ada perbedaan, hanya untuk beberapa yang berhasil kami selesaikan, tetapi untuk yang lain tidak. , , push- , APNs.
— . Apple , , push-extension, , , . , 12 .
Apple Developer Forum , , . , — 10 .
, . AppMetrica. , AppMetrica , Extension . , - .
: Extension .
push-extension UserDefaults. , , AppMetrica.
. . , , . , . , XIVA ( ), , .
, Notification Extension iOS 10 , Extension, , .
AppMetrica : , push-extension . AppMetrica push-, , . ,
AppMetrica Push SDK .
, . — , . , .
— , , .
, push-, , — .
, , . , …
: , , . , ? - , push-? , ? user experience ?
, 2–3–20 ?
, , , , , , , . , push-. , .
Ringkasan
Push- iOS . , .. , .
push- ( ) . . XIVA. , , . , , . !
push-extension. , . , .
, . , , , , - . , push- . , , , App Store, , !
AppsConf , 21 22 , .. 50 , . 1 , — .