Protocols

Protocol used to define Hub Framework actions

Actions are independant pieces of code that can be executed in response to events, such as selection, other user interface events, timers, etc. They can be used to implement application-wide extensions to the Hub Framework and handle tasks like model mutations, user interface updates, etc. Actions are either performed automatically by the Hub Framework when a component was selected, or by a component conforming to the HUBComponentActionPerformer protocol.

Actions are created by an implementation of HUBActionFactory, which are registered for a certain namespace with HUBActionRegistry.

Protocol defining the public API of a contextual object used when executing an action

The Hub Framework automatically creates objects conforming to this protocol as part of handling an event which should cause an action to be performed. The context includes information that an action can use to make decisions on how to execute, and is always relative to the component for which the action will be performed.

Protocol used to define factories that create Hub Framework actions

You implement a factory to integrate actions with the framework. Each factory is registered for a certain namespace with HUBActionRegistry, and will be invoked when an action identifier with the matching namespace was encountered as part of the handling of an event.

Protocol used to define Hub Framework action handlers

An action handler is an object that optionally takes over the handling of an action, preventing that action from executing as it normally would. This enables you to customize what will happen for certain actions, including selection and other events.

Each feature can supply each own action handler when it’s being setup with HUBFeatureRegistry. A default action handler to be used system-wide can also be supplied when setting up this application’s HUBManager.

Protocol defining the public API of an object that performs Hub Framework actions

You use this API to manually perform actions from either a component (conforming to HUBComponentActionPerformer) or content operation (conforming to HUBContentOperationActionPerformer).

Actions are used to define custom behavior and/or to communicate between the parts that make up a Hub Framework-powered view.

You don’t conform to this protocol yourself. Instead, the Hub Framework will assign an object conforming to this protocol to the actionPerformer property of either a component or content operation.

Protocol defining the public API of a Hub Framework action registry

An action registry manages a series of registered HUBActionFactory implementations, that are used to create actions for handling events occuring in Hub Framework-powered views. To integrate actions with the framework - implement a HUBActionFactory and register it with the registry.

You don’t conform to this protocol yourself, instead the application’s HUBManager comes setup with a registry that you can use.

Delegate protocol used by HUBAsyncAction types to notify the Hub Framework when they finish

Extended action protocol used to define actions that are asynchronous

Asynchronous actions enable you to perform work even after the main performWithContext: method has returned. Once you’re done performing an async action, call its delegate. The Hub Framework will automatically retain any performed asynchronous actions until they have been completed.

Protocol implemented by objects that manage a Hub Framework component

A component acts as a controller between a HUBComponentModel and a UIView that should be added to the screen by the Hub Framework. Its responsibilities include model->view data binding, event handling and rendering.

You are free to implement your component in whatever way you desire, and register it for use with the Hub Framework using a HUBComponentFactory implementation registered with HUBComponentRegistry.

Ideally, components should hold as little state as possible, and instead react to any model changes through -configureViewWithModel:. Components of the same class are also reused as much as possible, so a component can never assume a 1:1 relationship with a certain model, rather it needs to be able to render any HUBComponentModel.

This is the base protocol that all components must conform to. For extensions that adds additional functionality see:

HUBComponentWithChildren: For components that can contain nested child components

HUBComponentWithImageHandling: For handling downloaded images.

HUBComponentWithRestorableUIState: For saving & restoring the UI state of a component.

HUBComponentWithSelectionState: For responding to highlight & selection events in a component.

HUBComponentContentOffsetObserver: For components that react to the view’s content offset.

HUBComponentViewObserver: For components that observe their view for various events.

HUBComponentActionPerformer: For components that can perform actions (see HUBAction).

HUBComponentActionObserver: For components that can observe actions (see HUBAction).

Extended component protocol that adds the ability to observe whenever an action was performed

You can use this protocol to be able to react to an action being performed in your component.

See HUBComponent and HUBAction for more information.

Extended Hub component protocol that adds the ability to perform actions

Use this protocol if you want your component to be able to perform actions based on custom user interactions or other events. By default The Hub Framework performs any actions associated with a component model’s target when the component is selected by the user, but this protocol makes it possible to perform any other action whenever the component wants. For example, you might want to trigger an action whenever the user swipes the component, or something similar.

See HUBComponent and HUBAction for more information.

Extended Hub component protocol that adds the ability to observe content offset changes

Use this protocol if your component needs to react to content offset changes in the view that it is being displayed in. See HUBComponent for more info.

Protocol implemented by objects that create Hub Framework components

You implement a component factory to be able to integrate your component(s) with the framework. Each factory is registered with HUBComponentRegistry for a certain namespace, and will be used whenever a component model declares that namespace as part of its component identifier.

Extended HUBComponentFactory protocol that adds the ability to provide component names to a showcase

Use this protocol when you want to provide an array of supported component names to be included when showcaseableComponentIdentifiers is requested from the application’s HUBComponentRegistry.

The Hub Framework does not provide any built-in functionality for showcases, besides providing the component identifiers that have been declared as showcasable. Instead, it’s up to each API user to build showcase functionality on top of this API.

For more information about component factories, see HUBComponentFactory.

Protocol implemented by an object that handles fallback behavior for Hub Framework components

You implement this protocol in a single custom object and inject it when setting up the application’s HUBManager. The fallback handler helps the Hub Framework assure that a component is always created, even if a component model’s namespace/name combination couldn’t be resolved to a component. The information provided by a fallback handler is used to set up all component model builders with default values, and the fallback handler also acts as a last line of defence for backwards compatibility.

Protocol defining the public API of an object that describes image data for a Component in the Hub Framework

You don’t conform to this protocol yourself, instead the Hub Framework will create implementations of it for you based on the data supplied to a HUBComponentImageDataBuilder or through JSON data.

Protocol defining the public API for a builder that builds image data objects

This builder acts like a mutable model counterpart for HUBComponentImageData, with the key difference that they are not related by inheritance.

All properties are briefly documented as part of this protocol, but for more extensive documentation and use case examples, see the full documentation in the HUBComponentImageData protocol definition.

In order to successfully build an image data object (and not return nil), the builder must have either have a non-nil URL, placeholderIconIdentifier or localImage property.

Protocol defining the public API of a JSON schema for HUBComponentImageData

You don’t conform to this protocol yourself, instead an object matching the default Hub Framework schema will come attached to a HUBJSONSchema. You are free to customize a schema in whatever way you want, but you must do so before registering it with the HUBJSONSchemaRegistry.

The Hub Framework uses a path-based approach to JSON parsing, that enables you to describe how to retrieve data from a JSON structure using paths - sequences of operations that each perform a JSON parsing task, such as going to a key in a dictionary, or iterating over an array. For more information about how to construct paths, see the documentation for HUBJSONPath and HUBMutableJSONPath.

All paths in this schema are relative to a dictionary containing image data for a component.

Protocol implemented by an object that acts as a layout manager for components in an instance of the Hub Framework

You implement this protocol in a single custom object and inject it when setting up the application’s HUBManager. The responsibility of a component layout manager is to compute margins between various components and content edges.

A layout manager is always given a set of layout traits for the component(s) in question, to be able to make good decisions on what margins to use. For more information about layout traits; see HUBComponentLayoutTrait.

Protocol defining the public API of a model object that is used for a Component in the Hub Framework

You don’t conform to this protocol yourself, instead the Hub Framework will create implementations of it for you based on the data supplied to a HUBComponentModelBuilder or through JSON data.

See also HUBComponent that acts as the controller for a view that renders the data from a HUBComponentModel.

What pieces of data each individual component supports is up to them. It’s also up to the components themselves to control their own rendering of the data contained in a model like this. However, it’s always safe to assign any of the properties in this model, regardless of component implementation. Components that don’t support a certain piece of data (like subtitle or descriptionText for example), will simply choose to ignore those properties.

This protocol defines an immutable component model, for its mutable counterpart; see HUBComponentModelBuilder.

Protocol defining the public API for a builder that builds component model objects

This builder acts like a mutable model counterpart for HUBComponentModel, with the key difference that they are not related by inheritance.

All properties are briefly documented as part of this protocol, but for more extensive documentation and use case examples, see the full documentation in the HUBComponentModel protocol definition.

Protocol defining the public API of a JSON schema used to extract data for a HUBComponentModel

You don’t conform to this protocol yourself, instead an object conforming to it will come attached when you create a HUBJSONSchema (see its documentation for more info). The implementation of this protocol will come setup according to the default Hub Framework JSON schema, but you’re free to change & extend it to fit any schema that you expect your JSON data to conform to.

A schema is defined as a collection of paths, that each describe the operations required to extract a certain piece of data from a JSON structure. For a more in-depth description on how paths work, see the documentation for HUBJSONPath and HUBMutableJSONPath. For more information about the properties that the data extractd using this schema will be used for, see HUBComponentModel.

To change a path - either create a mutableCopy of it, change it, and re-assign it back to its property, or create a new path from scratch using HUBJSONSchema.

All paths in this schema are relative to a JSON dictionary defining component model data.

Protocol defining the public API of a Hub component registry

A component registry manages a series of registered HUBComponentFactory implementations, that are used to create components for Hub Framework-powered views. To integrate a component with the framework - implement a HUBComponentFactory and register it with the registry.

You don’t conform to this protocol yourself, instead the application’s HUBManager comes setup with a registry that you can use.

Protocol defining the public API of a Hub Framework component showcase manager

You interact with this API to build showcase functionality for available components in this instance of the Hub Framework. Normally, you don’t call it from production code (although there is no harm in doing so), but rather use it to build tooling on top of the framework.

The Hub Framework does not provide any built-in functionality for showcases, besides providing the component identifiers that have been declared as showcasable, and the ability to create snapshot images of a component instance, for showcase purposes.

You don’t conform to this protocol yourself, instead the application’s HUBManager comes setup with a showcase manager that you can use.

Protocol defining the public API of an object that can generate showcase snapshots

Use this API to generate snapshot images of components, that can be used in showcases or tooling associated with the Hub Framework. Normally, you don’t interact with it in production code.

You don’t conform to this protocol yourself, instead request an instance conforming to it from the application’s HUBComponentShowcaseManager.

Protocol defining the public API of an object that describes a target of a user interaction with a Hub Framework component.

You create targets using HUBComponentTargetBuilder, available on HUBComponentModelBuilder.

Protocol defining the public API for a builder that builds component target objects

This builder acts like a mutable model counterpart for HUBComponentTarget, with the key difference that they are not related by inheritance.

All properties are briefly documented as part of this protocol, but for more extensive documentation and use case examples, see the full documentation in the HUBComponentTarget protocol definition.

Protocol defining the public API of a JSON schema for HUBComponentTarget

You don’t conform to this protocol yourself, instead an object matching the default Hub Framework schema will come attached to a HUBJSONSchema. You are free to customize a schema in whatever way you want, but you must do so before registering it with the HUBJSONSchemaRegistry.

The Hub Framework uses a path-based approach to JSON parsing, that enables you to describe how to retrieve data from a JSON structure using paths - sequences of operations that each perform a JSON parsing task, such as going to a key in a dictionary, or iterating over an array. For more information about how to construct paths, see the documentation for HUBJSONPath and HUBMutableJSONPath.

All paths in this schema are relative to a dictionary containing target data for a component.

Extended Hub component protocol that adds the ability for a component to observe its view

Use this protocol when you want to customize the behavior of your component’s view, such as starting animations when the component appears on the screen, or reacting to resizes.

See HUBComponent for more information.

Delegate protocol used to send events related to a component’s children back to the Hub Framework

You don’t implement this protocol yourself. Instead, you \@synthesize your component’s childDelegate property, and may choose to send any of these methods to it to notify it of events, as well as creating child component instances.

It’s definitely recommended to use this protocol as much as possible when using child components, since you can leverage the framework’s built-in capabilities for selection, image loading & other events.

Extended Hub component protocol that adds the ability to handle child components

Use this protocol if your component supports nesting other components within it. Use the assigned childDelegate to let the Hub Framework perform tasks for nested components for you. See HUBComponent for more info.

Extended Hub component protocol that adds the ability to handle images

Use this protocol if your component will display images, either for itself or for any child components that it could potentially be managing. See HUBComponent for more info.

Extended Hub component protocol that adds the ability to save & restore UI state

Use this protocol if your component has some UI state that should be persisted between reuses. Examples of this might be selection state, internal scrolling positions, etc.

The Hub Framework automatically manages the state for you, and will ask the component to provide its current UI state, and to restore a previously saved state whenever appropriate. UI states are always stored based on HUBComponentModel identifiers, so the same UI state will never be reused for different models, although it might be reused for different component implementations

UI state is never shared across different views, and it’s not persisted across multiple launches of the application.

For more information, see HUBComponent.

Extended Hub component protocol that adds the ability to scroll between child components.

Use this protocol if your component supports scrolling between components within it. See HUBComponent for more info.

Extended Hub component protocol that adds the ability to respond to selection events

Use this protocol if your component adjusts its appearance when the user interacts with it, such as when the user highlights it through a touch down, or selects it through a tap. A normal use case for this protocol is when a component is implemented using a table- or collection view cell, and you wish to update the cell’s highlighted/selected status.

For more information, see HUBComponent and HUBComponentSelectionState.

Protocol used to observe a connectivity state resolver for changes in connectivity state

Protocol implemented by objects that can resolve an application’s current connectivity state

By default, the Hub Framework provides an implementation of this protocol that uses Apple’s SystemConfiguration framework. However, you can choose to supply a custom connectivity state resolver by conforming to this protocol in a custom object and passing it when setting up your application’s HUBManager.

The Hub Framework passes the information provided by its connectivity state resolver to content operations when they are performed, enabling them to make decisions on whether to attempt to load remote content or not.

The resolver should also support observations; to enable the Hub Framework to react to changes in connectivity state. Whenever the resolver detected a change, it should call its observers.

Delegate protocol for objects conforming to HUBContentOperation

You don’t conform to this protocol yourself. Instead, you synthesize your content operation’s delegate property, which the Hub Framework will assign. You may then use the methods defined in this protocol to communicate content operation events back to the framework.

Protocol used to define objects that load content that will make up a Hub Framework view model

To define a content operation, conform to this protocol in a custom object - and return it from a matching HUBContentOperationFactory that is passed when configuring your feature with the Hub Framework. A content operation is free to do its work in whatever way it desires, online or offline - manipulating a view’s content either in code or through JSON (or another data format) - synchronously or asynchronously.

When a new view is about to be displayed by the Hub Framework, the framework will call the content operations associated with that view. The content that these content operations add to the used HUBViewModelBuilder will then be used to create a view model for the view.

If your content operation also has some initial content that can be synchronously added to the view, before the main content loading chain is started - it can conform to HUBContentOperationWithInitialContent to be able to do so.

Extended content operation protocol that adds the ability to observe whenever an action was performed

You can use this protocol to be able to react to an action being performed in your content operation.

See HUBContentOperation and HUBAction for more information.

Extended content operation protocol that adds the ability to perform actions

Use this protocol whenever you want one of your content operations to be able to perform actions. Actions can be used to perform small, atomic tasks and provide a lightweight way to extend the Hub Framework with additional functionality.

For more information about actions, see HUBAction, as well as the Action programming guide available at https://spotify.github.io/HubFramework/action-programming-guide.html.

For more information about content operations, see HUBContentOperation.

Protocol defining the public API of a content operation context

This API is currently only used with HUBBlockContentOperation. For more information about the properties that are part of this API, refer to HUBContentOperation, or to the Content programming guide.

Protocol that objects that create Hub Framework content operations conform to

You conform to this protocol in a custom object and pass that object when configuring your feature with the Hub Framework. Multiple content operation factories can be used for a feature, and they can also be reused in between features.

For more information, see HUBContentOperation.

Extended Hub content operation protocol that adds the ability to add initial content to a view

Use this protocol whenever your content operation is able to add pre-loaded content to a view, that is rendered before the main content loading chain is started.

See HUBContentOperation for more information.

Extended content operation protocol that adds the ability to append paginated content to a view

Use this protocol in case you want to handle large datasets in your feature, which are not practical to load up front. Content operations conforming to this protocol will be called and asked to append content to an existing view model builder in either of 3 scenarios:

• If the loadNextPageForCurrentViewModel method was called on a HUBViewModelLoader.
• If the user is about to reach the bottom of the view’s content when scrolling.

Protocol used to define objects that represent a policy for when the content for a view should be reloaded

To define a reload policy, conform to this protocol in a custom object and pass it when registering your feature with HUBFeatureRegistry. A reload policy can be used to implement custom rules around when to reload a given view.

Each application using the Hub Framework also has a default content reload policy used for features that do not declare their own. This reload policy is passed when setting up HUBManager.

Protocol defining the public API of an object that contains information about a Hub Framework feature

You don’t conform to this protocol yourself, instead the Hub Framework will create instances conforming to this protocol based on the information a feature provided when it was registered with the framework.

Protocol defining the public API of a Hub feature registry

A feature is the top-level entity in the Hub Framework, that is used to ecapsulate related views into a logical group. Views that belong to the same feature share the same setup, such as a view URI predicate, content operation factories, etc.

Protocol defining the public API of an icon object

An icon is not renderable in of itself, but rather acts as a container for icon information, which can be materialized into an image of any size. Images are resolved using the HUBIconImageResolver passed when setting up HUBManager.

Protocol implemented by objects that can resolve images from icon identifiers

You conform to this protocol in a custom object and supply it when setting up your application’s HUBManager. The Hub Framework uses this object whenever an image needs to be resolved from a HUBIcon instance.

Delegate protocol for HUBImageLoader

You don’t conform to this protocol yourself. Instead, the Hub Framework will assign an internal object that conforms to this protocol as the delegate of any image loader. You use the methods defined in this protocol to communicate an image loader’s outcomes back to the framework.

Protocol that objects that load images on behalf of the Hub Framework conform to

The Hub Framework uses an image loader to load images for components which models contain image data, when the component is about to be displayed on the screen. The framework itself does not employ any caching on images, so it’s up to each implementation of this protocol to handle that.

In case you don’t supply your own image loader implementation, the default HUBDefaultImageLoader is used.

See also HUBImageLoaderFactory which is used to create instances conforming to this protocol.

Protocol that objects that create image loaders for use with the Hub Framework conform to

You conform to this protocol in a custom object and pass that object when setting up HUBManager. The Hub Framework will then use the factory to create an image loader for each view controller that it creates.

In case you don’t supply your own image loader factory, the default HUBDefaultImageLoaderFactory is used.

See HUBImageLoader for more information.

Protocol defining the public API for adding JSON data to a Hub Framework model builder

Builders that support JSON data will conform to this protocol. Most builders only support Dictionary-based JSON, except for HUBViewModelBuilder that supports Array-based JSON for defining an array of body component models.

Protocol defining the basic API of an object describing a path to a piece of data within a JSON structure

The Hub Framework uses a path-based approach to JSON parsing, that enables the API user to describe how to retrieve data from a JSON structure using paths - sequences of operations that each perform a JSON parsing task, such as going to a key in a dictionary, or iterating over an array.

You normally don’t have to interact with the APIs defined in this file yourself. Instead, the Hub Framework uses them to retrieve data internally. You might want to construct paths yourself, though, and for that you use the mutable version of this API; HUBMutableJSONPath.

Protocol defining the API of a JSON path that points to a BOOL value

See HUBJSONPath and HUBMutableJSONPath for more information on how JSON paths work.

Protocol defining the API of a JSON path that points to an NSInteger value

See HUBJSONPath and HUBMutableJSONPath for more information on how JSON paths work.

Protocol defining the API of a JSON path that points to an NSString value

See HUBJSONPath and HUBMutableJSONPath for more information on how JSON paths work.

Protocol defining the API of a JSON path that points to an NSURL value

See HUBJSONPath and HUBMutableJSONPath for more information on how JSON paths work.

Protocol defining the API for a JSON path that points to an NSDictionary value

See HUBJSONPath and HUBMutableJSONPath for more information on how JSON paths work.

Protocol defining the public API of an object describing a JSON schema for use in the Hub Framework

You don’t conform to this protocol yourself, instead you retrieve an instance conforming to it from the HUBJSONSchemaRegistry used by the application’s HUBManager. A HUBJSONSchema comes setup according to the default Hub Framework JSON schema, but you’re free to change & extend it to fit any schema that you expect your JSON data to conform to.

A HUBJSONSchema consists of several sub-schemas, one for each model. The schemas may be individually customized. See their respective documentation for more info on how to customize them.

The Hub Framework uses a path-based approach to JSON parsing, that enables the API user to describe how to retrieve data from a JSON structure using paths - sequences of operations that each perform a JSON parsing task, such as going to a key in a dictionary, or iterating over an array. To customize a path, you can either change it directly, or replace it with a new one created from this schema’s -createNewPath method.

For a more in-depth description on how paths work, see the documentation for HUBJSONPath and HUBMutableJSONPath.

Protocol defining the public API of a Hub JSON schema registry

You don’t conform to this protocol yourself, instead the application’s HUBManager has an object conforming to this protocol attached to it, that enables you to create and register custom JSON schemas for use in the Hub Framework.

To customize a schema, create one using -createNewSchema, then set up the returned schema to match the JSON format that you are expecting, and finally register it with the registry.

For more information on how Hub Framework JSON schemas work; see HUBJSONSchema.

Delegate protocol for HUBLiveService

Implement this to recieve view controllers created by the service (using JSON passed from the hublive command line application).

Protocol defining the public API for the Hub Framework Live service

The live service enables live editing of Hub Framework-powered view controllers, using the hublive command line application (you can find it in the /live folder of the Hub Framework repo).

To start the service, simply call startOnPort: with a port number that you wish to enable the hublive application to connect on (the same port should then be supplied when starting hublive). The service will then call its delegate once it has created a view controller for any JSON data that was passed from hublive.

You don’t implement this protocol yourself, instead the Hub Framework contains an implementation of it. Note though that this implementation is only compiled when the application hosting the framework is compiled for DEBUG.

Protocol defining the API of a mutable JSON path, that is used to describe operations to perform to retrieve a certain piece of data from a JSON structure.

You use this API to customize how the Hub Framework should parse a downloaded JSON structure for a feature, by either extending an existing HUBJSONPath or creating a new one through HUBJSONSchema.

A path consists of a sequence of operations that each perform a JSON parsing task, such as going to a key in a dictionary, or iterating over an array. You append operations to a path by calling any of the methods listed under Operations, and finally convert it into an immutable, destination path by calling any of the methods listed under Destinations.

For example; if you wish to express the string Sunday from this JSON dictionary:

@code { date: { weekday: Sunday } } @endcode

You would construct a path accordingly:

@code [[[path goTo:@date] goTo:@weekday] stringPath]; @endcode

Protocol that Hub Framework objects that may be serialized conform to

Delegate protocol for HUBViewController

Conform to this protocol in a custom object to get notified of events occuring in a Hub Framework view controller

Protocol defining the public API of a factory that creates view controllers

You don’t conform to this protocol yourself. Instead, access this API through the application’s HUBManager. You use this API to create view controllers that are powered by the Hub Framework, somewhere in your navigation code, where new view controllers should be pushed. Since the Hub Framework uses URL-based navigation (per default), a recommended place to create view controllers using this factory, would be when you are responding to opening URLs, for example in your App Delegate.

Protocol used to define custom scroll handlers for Hub Framework view controllers

Each feature can supply a scroll handler when it’s being registered with the Hub Framework (through HUBFeatureRegistry). This enables a feature to customize how scrolling is handled for all view controllers that will be created on its behalf.

Protocol defining the public API of a model that is used for a View in the Hub Framework

You don’t conform to this protocol yourself, instead the Hub Framework will create implementations of it for you based on the data supplied to a HUBViewModelBuilder or through JSON data.

See also HUBViewController that acts as the controller for a view that renders the data from a HUBViewModel.

Protocol defining the public API of a builder that builds view model objects

This builder acts like a mutable model counterpart for HUBViewModel, with the key difference that they are not related by inheritance.

For more information regarding the properties that this builder enables you to set, see the documentation for HUBViewModel.

Protocol defining the public API of a JSON schema for HUBViewModel

You don’t conform to this protocol yourself, instead an object conforming to it will come attached when you create a HUBJSONSchema (see its documentation for more info). The implementation of this protocol will come setup according to the default Hub Framework JSON schema, but you’re free to change & extend it to fit any schema that you expect your JSON data to conform to.

A schema is defined as a collection of paths, that each describe the operations required to extract a certain piece of data from a JSON structure. For a more in-depth description on how paths work, see the documentation for HUBJSONPath and HUBMutableJSONPath. For more information about the properties that the data extracted using this schema will be used for, see HUBViewModel.

To change a path - either create a mutableCopy of it, change it, and re-assign it back to its property, or create a new path from scratch using HUBJSONSchema.

All paths in this schema are relative to a JSON dictionary defining view model data.

Delegate protocol for HUBViewModelLoader

Conform to this protocol in a custom object to get notified when a view model was loaded, or if an error occured in the loading process.

Protocol defining the public API of a view model loader

You don’t conform to this protocol yourself, instead the Hub Framework will create objects conforming to this protocol internally. This API is currently not accessible from outside of the Hub Framework, but will be soon as part of the external data API.

Protocol defining the public API of a factory that creates view model loaders

You don’t conform to this protocol yourself. Instead, access this API through the application’s HUBManager. You can use this API to create view model loaders for use outside of the Hub Framework, in case you want to use data from a Hub Framework-powered feature in a part of the app that does not use the framework.