Protocols

The interface definition for a PureMVC Command.

`@see org.puremvc.swift.multicore.interfaces INotification

See more

public protocol ICommand : INotifier

The interface definition for a PureMVC Controller.

In PureMVC, an IController implementor follows the ‘Command and Controller’ strategy, and assumes these responsibilities:

• Remembering which ICommands are intended to handle which INotifications.
• Registering itself as an IObserver with the View for each INotification that it has an ICommand mapping for.
• Creating a new instance of the proper ICommand to handle a given INotification when notified by the View.
• Calling the ICommand‘s execute method, passing in the INotification.

@see org.puremvc.swift.multicore.interfaces INotification

@see org.puremvc.swift.multicore.interfaces ICommand

See more

public protocol IController

The interface definition for a PureMVC Facade.

The Facade Pattern suggests providing a single class to act as a central point of communication for a subsystem.

In PureMVC, the Facade acts as an interface between the core MVC actors (Model, View, Controller) and the rest of your application.

@see org.puremvc.swift.multicore.interfaces.IModel IModel

@see org.puremvc.swift.multicore.interfaces.IView IView

@see org.puremvc.swift.multicore.interfaces.IController IController

@see org.puremvc.swift.multicore.interfaces.ICommand ICommand

@see org.puremvc.swift.multicore.interfaces.INotification INotification

See more

public protocol IFacade : INotifier

The interface definition for a PureMVC Mediator.

In PureMVC, IMediator implementors assume these responsibilities:

• Implement a common method which returns a list of all INotifications the IMediator has interest in.
• Implement a notification callback method.
• Implement methods that are called when the IMediator is registered or removed from the View.

Additionally, IMediators typically:

• Act as an intermediary between one or more view components such as text boxes or list controls, maintaining references and coordinating their behavior.
• In Flash-based apps, this is often the place where event listeners are added to view components, and their handlers implemented.
• Respond to and generate INotifications, interacting with of the rest of the PureMVC app.

When an IMediator is registered with the IView, the IView will call the IMediator‘s listNotificationInterests method. The IMediator will return an Array of INotification names which it wishes to be notified about.

The IView will then create an Observer object encapsulating that IMediator’s (handleNotification) method and register it as an Observer for each INotification name returned by listNotificationInterests.

@see org.puremvc.swift.multicore.interfaces.INotification INotification

See more

public protocol IMediator : INotifier

The interface definition for a PureMVC Model.

In PureMVC, IModel implementors provide access to IProxy objects by named lookup.

An IModel assumes these responsibilities:

• Maintain a cache of IProxy instances
• Provide methods for registering, retrieving, and removing IProxy instances

See more

public protocol IModel

The interface definition for a PureMVC Notification.

PureMVC does not rely upon underlying event models such as the one provided with Flash, and ActionScript 3 does not have an inherent event model.

The Observer Pattern as implemented within PureMVC exists to support event-driven communication between the application and the actors of the MVC triad.

Notifications are not meant to be a replacement for Events in Flex/Flash/AIR. Generally, IMediator implementors place event listeners on their view components, which they then handle in the usual way. This may lead to the broadcast of Notifications to trigger ICommands or to communicate with other IMediators. IProxy and ICommand instances communicate with each other and IMediators by broadcasting INotifications.

A key difference between Flash Events and PureMVC Notifications is that Events follow the ‘Chain of Responsibility’ pattern, ‘bubbling’ up the display hierarchy until some parent component handles the Event, while PureMVC Notifications follow a ‘Publish/Subscribe’ pattern. PureMVC classes need not be related to each other in a parent/child relationship in order to communicate with one another using Notifications.

@see org.puremvc.swift.multicore.interfaces.IView IView

@see org.puremvc.swift.multicore.interfaces.IObserver IObserver

See more

public protocol INotification

The interface definition for a PureMVC Notifier.

MacroCommand, Command, Mediator and Proxy all have a need to send Notifications.

The INotifier interface provides a common method called sendNotification that relieves implementation code of the necessity to actually construct Notifications.

The Notifier class, which all of the above mentioned classes extend, also provides an initialized reference to the Facade Singleton, which is required for the convienience method for sending Notifications, but also eases implementation as these classes have frequent Facade interactions and usually require access to the facade anyway.

@see org.puremvc.swift.multicore.interfaces.IFacade IFacade

@see org.puremvc.swift.multicore.interfaces.INotification INotification

See more

public protocol INotifier

The interface definition for a PureMVC Observer.

In PureMVC, IObserver implementors assume these responsibilities:

• Encapsulate the notification (callback) method of the interested object.
• Encapsulate the notification context (self) of the interested object.
• Provide methods for setting the interested object’ notification method and context.
• Provide a method for notifying the interested object.

PureMVC does not rely upon underlying event models such as the one provided with Flash, and ActionScript 3 does not have an inherent event model.

The Observer Pattern as implemented within PureMVC exists to support event driven communication between the application and the actors of the MVC triad.

An Observer is an object that encapsulates information about an interested object with a notification method that should be called when an INotification is broadcast. The Observer then acts as a proxy for notifying the interested object.

Observers can receive Notifications by having their notifyObserver method invoked, passing in an object implementing the INotification interface, such as a subclass of Notification.

@see org.puremvc.swift.multicore.interfaces.IView IView

@see org.puremvc.swift.multicore.interfaces.INotification INotification

See more

public protocol IObserver

The interface definition for a PureMVC Proxy.

In PureMVC, IProxy implementors assume these responsibilities:

• Implement a common method which returns the name of the Proxy.
• Provide methods for setting and getting the data object.

Additionally, IProxys typically:

• Maintain references to one or more pieces of model data.
• Provide methods for manipulating that data.
• Generate INotifications when their model data changes.
• Expose their name as a public static const called NAME, if they are not instantiated multiple times.
• Encapsulate interaction with local or remote services used to fetch and persist model data.

See more

public protocol IProxy : INotifier

The interface definition for a PureMVC View.

In PureMVC, IView implementors assume these responsibilities:

In PureMVC, the View class assumes these responsibilities:

• Maintain a cache of IMediator instances.
• Provide methods for registering, retrieving, and removing IMediators.
• Managing the observer lists for each INotification in the application.
• Providing a method for attaching IObservers to an INotification‘s observer list.
• Providing a method for broadcasting an INotification.
• Notifying the IObservers of a given INotification when it broadcast.

@see org.puremvc.swift.multicore.interfaces.IMediator IMediator

@see org.puremvc.swift.multicore.interfaces.IObserver IObserver

@see org.puremvc.swift.multicore.interfaces.INotification INotification

See more

public protocol IView