Dans Article précédent, j'ai confirmé que la notification push peut être envoyée du serveur vers Android, alors j'ai finalement confirmé comment exécuter le processus du côté Android en utilisant cela comme déclencheur. Faire.
Comme résumé dans ici, lorsque l'application est au premier plan et lorsqu'elle est en arrière-plan Et, le traitement change légèrement. Chacun est illustré ci-dessous.
Si votre application est au premier plan, vous pouvez recevoir des messages en étendant la classe FirebaseMessagingService
du package com.google.firebase.messaging.FirebaseMessagingService
. Deux articles précédents correspond à MyFirebaseMessagingService.kt
. Dans ce qui suit, cela s'appellera Iji.
Les spécifications de la classe FirebaseMessagingService
sont résumées dans ici. Plusieurs méthodes de rappel sont fournies et la classe d'extension les remplacera.
--ʻOnDeletedMessages () : Lorsqu'un message est supprimé en raison du message laissé pendant une longue période pour une raison quelconque, telle que le terminal n'accède pas au serveur pendant une longue période. --ʻOnDestroy ()
: Inconnu car rien n'est écrit. S'exécute probablement lors de la suppression de l'application.
--ʻOnMessageReceived (RemoteMessage message) : Lorsqu'un message est reçu. --ʻOnMessageSent (String msgId)
: Lorsque le message est envoyé avec succès au serveur de connexion de GCM.
--ʻOnNewToken (String token) : Lorsqu'un nouveau token est généré. --ʻOnSendError (String msgId, Exception exception)
: Lorsque l'envoi d'un message au serveur de connexion GCM échoue.
Lorsque l'application est en arrière-plan, la notification est envoyée dans la barre d'état système de l'appareil et la charge de données est fournie à la partie supplémentaire de l'intention d'activité du lanceur. Il s'écrit «. Après avoir vérifié diverses choses, il semble qu'il devrait être retiré de ʻintent.getExtras ()
.
Le message envoyé par le serveur est presque le même que celui de Article précédent. Cependant, seule la partie données est modifiée comme suit.
data={
'date': '20200628',
'message': 'Ceci est un message test'
}
Du côté client, MyFirebaseMessagingService.kt
ressemble à ceci.
class MyFirebaseMessagingService: FirebaseMessagingService() {
override fun onNewToken(token: String) {
Log.d(TAG, "Refreshed token: $token")
}
override fun onMessageReceived(p0: RemoteMessage) {
super.onMessageReceived(p0)
val date = p0.data["date"]!!.toInt()
val message = p0.data["message"]!!
val dao = NotificationsDAO(this)
dao.createNotification(MyNotification(-1, date, message)) //Les données sont stockées dans MySQL (explication omise)
}
}
Et «MainActivity.kt» est comme suit.
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
}
override fun onStart() {
super.onStart()
val dao = NotificationsDAO(this)
if (intent.getExtras() != null) {
val date = intent.getExtras().getString("date").toInt()
val message = intent.getExtras().getString("message")
dao.createNotification(MyNotification(-1, date, message)) //Les données sont stockées dans SQLite (explication omise)
}
val messageList = dao.getAll() //Toutes les données ont été acquises à partir de SQLite (explication omise)
val listView: ListView = findViewById(R.id.listView)
listView.adapter = MessageListAdapter(this, android.R.layout.simple_list_item_1, messageList.take(10))
}
}
Lorsqu'une demande a été émise par le serveur dans cet état, il a été confirmé que la notification volait comme prévu et que les données étaient stockées dans SQLite du côté Android, comme indiqué sur la figure 1. (L'affichage de ListView
est formaté par la classe MessageListAdapter
. L'explication est omise cette fois.)
Figure 1 Affichage de l'application après réception des données.
J'ai pu confirmer ce que je voulais faire, donc cette enquête est terminée.