Classes

An proxy that sets itself as an observer of a loadable object and then forwards “did change” notifications to a block or a target/selector pair. This way your custom objects don’t have to conform to MMMLoadableObserver protocol exposing it in their public interfaces.

When initialized it adds itself as an observer of the given loadable and removes itself automatically when deallocated or when its remove method is called.

Both initializers return nil when the passed loadable is nil. This is handy when resubscribing to (possibile) different loadables many times and storing an instance of the observer in the same variable over and over: there is no need to check the target loadable and/or nullify the previous observer to unsubscribe.

An implementation of a loadable that might be used as a base. Subclasses must override ‘isContentsAvailable’ and ‘doSync’, the latter being called from implementation of sync/syncIfNeeded, see MMMLoadable+Subclasses.h. (Only the general declaration is open here so you can inherit it in the classes exposed to the end user, but still keep implementation details out of sight.)

A basic implementation of MMMPureLoadable that does not require to override anything. Typically you would have an object that instead of vending these objects directly would vend them as id<MMMPureLoadable>, so the state controls are visible to your main object only and don’t distract the end user.

MMMLoadable with simple auto-refresh logic. Again, see MMMLoadable+Subclasses.h if you want to see how to override things.

Allows to treat several “pure” loadables as one.

The group supports 2 different modes:

• “all” (this is the default), where the group is considered ‘synced successfully’ when all of its children are ‘synced successfully’;
• “at least one”, where the group is considered ‘synced successfully’ when at least one of its child loadables is ‘synced successfully’.

This can be used standalone or subclassed (see MMMLoadable+Subclasses.h in this case.)

The ‘did change’ event of the group is triggered when its loadableState changes or, if all objects are loaded, then every time any of the them emits ‘did change’.

Similar to MMMPureLoadableGroup allows to treat a bunch of loadables as one.

Can be used standalone or subclassed (see MMMLoadable+Subclasses.h in this case.)

In addition to the behavior of MMMPureLoadableGroup:

• needsSync is YES, if the same property is YES for at least one object in the group;
• sync and syncIfNeeded methods call the corresponding methods of every object in the group supporting them (note that some time before we required all objects in a “non-pure” group to support syncing, but it’s not the case anymore).

Sometimes an API expects a promise but you don’t have a reference to it until some time later, i.e. you need a promise for a promise.

This proxy pretends its contents is unavailable and the state is idle until the actual promise is set. After this all the properties are taken and the calls are forwarded from/to the actual object.

You can inherit this and forward “contents” properties for your kind of loadable.

Same as MMMPureLoadableProxy but for MMMLoadable protocol.

In case the user asks the proxy to sync before the actual object is set, then it actually enters ‘syncing’ state and when the actual object is set, then a sync is triggered for it too.

Can be used as a base for unit test (view) models conforming to MMMLoadable. Basically allows to override properties of MMMLoadable from the outside (i.e. from a unit test).

An image from the app’s bundle (accessible via +imageNamed: method of UIImage) wrapped into MMMLoadableImage and loaded asynchronously.

MMMLoadableImage-compatible wrapper for images that are immediately available.

Implementation of MMMLoadableImage for images that are publicly accessible via a URL. This is very basic, using the shared instance of NSURLSession, so any caching will happen there.

This is used in unit tests when we want to manipulate the state of a MMMLoadableImage to verify it produces the needed effects on the views being tested.

Sometimes an object implementing MMMLoadableImage is created much later than when it would be convenient to have one.

A proxy can be used in this case, so the users still have a reference to MMMLoadableImage and can begin observing it or request a sync asap. Later when the actual reference is finally available it is supplied to the proxy which begins mirroring its state.

As always, this is meant to be used only in the implementation, with only id visible publicly.