Refactoring Push module to allow easier integration of new push providers other than FCM.
Implementation
Removed LeanplumPushServiceFcm and LeanplumPushRegistrationService as they were not necessary and was making the implementation confusing. Compare version 1 and version 2 of the architecture diagram, check what happens in onStart of LeanplumPushService (centered and green colored) in both diagrams. Also removed LeanplumManualProvider as it is not used anywhere.
PushProviderType - enumeration to differentiate the push providers.
IPushProvider - main interface to implement for a push provider. It contains several methods:
getType - Returns the type of this push provider
getRegistrationId - Returns the registration id saved in shared preferences
setRegistrationId - Saves the registration id to shared preferences and calls the backend
unregister - Mainly for testing purposes to reset the push token from the push provider's SDK
updateRegistrationId - Updates the current registration ID from the cloud messaging's API
LeanplumCloudMessagingProvider - abstract class implementing the IPushProvider. It adds functionality to save the registration id to shared preferences and sends it to the backend. Provides an abstract method getSharedPrefsPropertyName that its decedents need to implement.
PushProviders - container for all IPushProvider instances. Contains several methods:
setRegistrationId - Set registration id for a specific provider. When a push provider's SDK generates a registration token for the app, this method will get called. For example FirebaseMessagingService.onNewToken.
updateRegistrationIdsAndBackend - called from LeanplumPushService to tell the providers to initiate logic for getting the registration ids. It calls them one by one by using OperationQueue.addParallelOperation.
Background
Refactoring Push module to allow easier integration of new push providers other than FCM.
Implementation
Removed
LeanplumPushServiceFcmandLeanplumPushRegistrationServiceas they were not necessary and was making the implementation confusing. Compare version 1 and version 2 of the architecture diagram, check what happens inonStartofLeanplumPushService(centered and green colored) in both diagrams. Also removedLeanplumManualProvideras it is not used anywhere.PushProviderType- enumeration to differentiate the push providers.IPushProvider- main interface to implement for a push provider. It contains several methods:getType- Returns the type of this push providergetRegistrationId- Returns the registration id saved in shared preferencessetRegistrationId- Saves the registration id to shared preferences and calls the backendunregister- Mainly for testing purposes to reset the push token from the push provider's SDKupdateRegistrationId- Updates the current registration ID from the cloud messaging's APILeanplumCloudMessagingProvider- abstract class implementing theIPushProvider. It adds functionality to save the registration id to shared preferences and sends it to the backend. Provides an abstract methodgetSharedPrefsPropertyNamethat its decedents need to implement.PushProviders- container for allIPushProviderinstances. Contains several methods:setRegistrationId- Set registration id for a specific provider. When a push provider's SDK generates a registration token for the app, this method will get called. For exampleFirebaseMessagingService.onNewToken.updateRegistrationIdsAndBackend- called fromLeanplumPushServiceto tell the providers to initiate logic for getting the registration ids. It calls them one by one by usingOperationQueue.addParallelOperation.