InvalidationHandler - is a client of InvalidationService (see below). Everyone who wants to use InvalidationService to receive Invalidation (notification of change in some object) needs to implement InvalidationHandler to receive those messages. InvalidationHandler has the following methods (the list is not full):
At the end of documentation, one can find the additional material for adding InvalidationHandler.
Class InvalidationService is just an interface which provides the following methods (the list is not exhaustive).
RegisterInvalidationHandler - allows InvalidationHandler to register itself as a observer for Invalidations. InvalidationService will only dispatch messages to registered handlers.
UpdateRegisteredInvalidationIds - allows InvalidationHandler to change the ids of Objects it is interested in receiving Invalidations for.
UnregisterInvalidationHandler - when InvalidationHandler unregisters it stops receiving Invalidations.
FCMInvalidationService - is the implementation of InvalidationService that uses Fandango as its publish/subscribe service.
FCMInvalidationService is the main entry point for InvalidationHandler. This is where InvalidationHandler registers/unregisters itself in InvalidationService, and registers Objects to invalidate. When a message comes, FCMInvalidationService calls OnIncomingInvalidation for the receiving InvalidationHandler.
Actually FCMInvalidationService just provides the abstraction above for InvalidationHandler, while in fact it just manages InvalidatorRegistrarWithMemory and FCMInvalidationListener, who do the actual work.
InvalidatorRegistrarWithMemory stores registered InvalidationHandlers, stores objects to invalidate and stores mapping between objects and InvalidationHandlers to know which InvalidationHandlers are interested in which objects. When a message comes from FCMInvalidationListener, InvalidatorRegistrarWithMemory dispatches that message (Invalidation) to the receiving InvalidationHandler.
FCMInvalidationListener just gets the list of topics to subscribe from FCMInvalidationService, and when FCMInvalidationListener receives Invalidations on those topics, it just passes them up to FCMInvalidationService.
And again the description above is just a good abstraction of FCMInvalidationListener for FCMInvalidationService, while in fact FCMInvalidationListener manages PerUserTopicRegistrationManager and FCMNetworkHandler who do the actual work.
PerUserTopicRegistrationManager manages subscriptions to topics. Topics in this case are objects we are interested in invalidating.
FCMNetworkHandler is the class responsible for communication via GCM channel. Provides the following functionality:
Retrieves the auth token required for the subscription. When this token is received, it is passed to PerUserTopicRegistrationManager which subscribes to topics with the given auth token.
Receives messages from GCM driver and passes them up to FCMInvalidationListener, where they are converted to Invalidations.
TiclInvalidationService - is the implementation of InvalidationService that uses Tango as its publish/subscribe service.
FCMInvalidationService has a different registration process for public and private topics. When registering with a public topic, publish/subscribe service will fan out all outgoing messages to all devices subscribed to this topic. For example: If a device subscribes to “DeviceGuestModeEnabled” public topic all instances subscribed to this topic will receive all outgoing messages addressed to topic “DeviceGuestModeEnabled”. But if 2 devices with different InstanceID subscribe to private topic “BOOKMARK”, they will receive different set of messages addressed to pair (“BOOKMARK”, InstanceID) respectively.
In the UML diagram above there are 3 classes that inherit from InvalidationHandler:
There is a notion of SenderId which is different for every InvalidationHandler. SenderId is used when registering to topics, to receive a topic of a particular sender. So for example server side logic of CloudPolicy posts messages using SenderId of “1013309121859”, and client side logic which is CloudPolicyInvalidator should register to topics using the SenderId “1013309121859”.
Usually InvalidationService is bound to a profile which can be spinned up using ProfileInvalidationProviderFactory, but sometimes there is no profile as in the special case of CloudPolicyInvalidator. CloudPolicyInvalidator is interested in receiving Invalidations on policies. Chrome OS team defines 2 types of policies - User and Device. Device policies should be received even when there is no one signed in to a Chrome OS device, thus there is no profile. For this reason there is a special class AffiliatedInvalidationServiceProvider which spawns InvalidationService even when there is no profile.