Core Layer

The core layer is the micro-framework that lets developers write Screenlets in a structured and isolated way. All Screenlets share a common structure based on the core classes, but each Screenlet can have a unique purpose and communication API.

Figure 1: Heres the core layer of Liferay Screens for Android.

Figure 1: Here's the core layer of Liferay Screens for Android.

Here are the core’s main components:

Interactor: the base class for all Liferay Portal interactions and use cases that a Screenlet supports. Interactors call services through the Liferay Mobile SDK and receive responses asynchronously through the EventBus, eventually changing a View’s state. Their actions can vary in complexity, from performing simple algorithms to requesting data asynchronously from a server or database. A Screenlet can have multiple Interactors, each dedicated to supporting a specific operation.

BaseScreenlet: the base class for all Screenlet classes. It receives user events from a Screenlet’s View, instantiates and calls the Interactors, and then updates the View with operation results. Classes that extend it can override its template methods:

  • createScreenletView: typically inflates the Screenlet’s View and gets the attribute values from the XML definition.
  • createInteractor: instantiates an Interactor for the specified action. If a Screenlet only supports one Interactor type then that type of Interactor is always instantiated.
  • onUserAction: runs the Interactor associated with the specified action.

Screenlet View: implements the Screenlet’s UI. It’s instantiated by the Screenlet’s createScreenletView method. It renders a specific UI using standard layout files and updates the UI with data changes. When developing your own Views that extend a parent View, you can read the parent Screenlet’s properties or call its methods from this class.

EventBus: notifies the Interactor when asynchronous operations complete. It decouples the AsyncTask class instance from the activity life cycle, to avoid problems typically associated with AsyncTask instances.

Liferay Mobile SDK: calls a Liferay instance’s remote services in a type-safe and transparent way.

SessionContext: a singleton class that holds the logged in user’s session. Apps can use an implicit login, invisible to the user, or a login that relies on explicit user input to create the session. User logins can be implemented with the Login Screenlet. This is explained in detail here.

LiferayServerContext: a singleton object that holds server configuration parameters. It’s loaded from the server_context.xml file, or from any other XML file that overrides the keys defined in the server_context.xml.

server_context.xml: specifies the default server, companyId (Liferay instance ID) and groupId (site ID). You can also configure other Screens parameters in this file, such as the current Liferay version (with the attribute liferay_portal_version) or an alternative ServiceVersionFactory to access custom backends.

LiferayScreensContext: a singleton object that holds a reference to the application context. It’s used internally where necessary.

ServiceVersionFactory: an interface that defines all the server operations supported in Liferay Screens. This is created and accessed through a ServiceProvider that creates the Server Connectors needed to interact with a specific Liferay version. The ServiceVersionFactory is an implementation of an Abstract Factory pattern.

Now that you know what makes up the core layer, you’re ready to learn the Screenlet layer’s details.

High-Level Architecture

Screenlet Layer

View Layer

Screenlet Lifecycle

« High-Level ArchitectureScreenlet Layer »
この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています