Как согласовать входящие сообщения FCM с форматом CNP $ AndroidPendingNotifications? - PullRequest
Новая
       5

Как согласовать входящие сообщения FCM с форматом CNP $ AndroidPendingNotifications?

1 голос
/ 10 марта 2020

Я пытался реализовать FCM в приложении CN1. Это может быть сделано до некоторой степени, но затем оно нарушает Google SignIn CN1 и, возможно, другие com.google.android.gms зависимости, поскольку FireBase зависит от этого сам, и, похоже, существует несовместимость версий (это я понял из чтения журналов сборки и из тестирования )

Затем я решил подать сообщения FCM в CN1 (напрямую с Firebase, а не с серверов CN1) и позволить собственной службе CN1 обрабатывать их.

Это работает, но мне не удалось правильно отформатировать мои сообщения FCM, которые будут приняты CN1. В результате уведомления отображаются правильно, но push(String value) дает значение null. Однако мне удалось сделать это в APN, пример принятого сообщения APN (CN1 Type 4) можно увидеть ниже. Все хорошо, когда дело доходит до внедрения CN1 APN Pu sh с Apple (удивительно). Все функции клиентского приложения CN1 могут быть повторно использованы, если вы просто адаптируете свою полезную нагрузку к требованиям 

{
"aps": {
    "alert": {
        "title": "Visible Title",
        "body": "Visible Body"
    },
    "badge" : 1,
    "sound" : "bingbong.aiff"
},
"meta":"Hidden message (can be JSON)",
}

Глядя на собственную реализацию Android pu sh CN1, я могу обратите внимание, что входящие уведомления pu sh хранятся в файле с именем CN1$AndroidPendingNotifications. Где они go в файле, неясно, я подозреваю, что это должно быть из ad-ho c службы, но до сих пор я не нашел точное место в общедоступном репозитории GitHub CN1

Формат содержимого этого файла, похоже, очень конкретный c. Например, его первый байт, кажется, обозначает целое число с ожидающим счетом pu sh, следующий байт содержит логическое значение, которое сообщает вам, имеет ли он тип, et c. Это можно увидеть здесь

Сообщение FCM о том, что полуработы (с нулевым значением pu sh ()) можно увидеть ниже 

        "{"+
            "'message':{" +
                "'token':'" +deviceId+"',"+
                "'notification':{"+
                    "'title':'"+title+"',"+
                    "'body':'"+msgBody+"'"+
                "}"+
            "}"+
        "}";

Выше приводит к уведомлению типа CN1 типа 1 с пустым сообщением (хотя уведомление в ОС по-прежнему отображается правильно).

Мой вопрос: есть ли место в CN1, где фактическое сообщение FCM используется и массируется в * 1025? * формат файла? Это было бы полезно знать, так как это помогло бы мне понять формат, который я должен адаптировать для своих входящих уведомлений FCM, учитывая, что реализация FCM отдельно не подходит для существующих зависимостей FCM / GMS CN1

Спасибо!

кстати: прежде чем кто-то это скажет, Parse4CN1 реализует только iOS pu sh, а не FCM:)

...