Firefox OS Window management 201

Architecture, Development, Patterns

Window Manager

A core module in an operating system, which is responsible to display and maintain the window based UI.

Window Mgmt. at FxOS

● A clustor of modules mainly serves to create web apps.

● A re-implementation of a browser.● Ability to handle WebAPI request between

apps.

Things inside..

Window Manager (v1.3-)

ModalDialog

TrusteUI

AuthDialog

transition control

create mozbrowser iframe maintain app life

cycle

gen screenshotsredirect mozbrowser events

orientation control

layout control

error handling

visibility control

web activities management

web app management

manage homescreen

manage ftu

It’s sad to have a such giant module to control everything :(

The secret to build a large app ?

The secret to build a large app ?

Never build a large app

Solutions

Instances +Manager +

Scalable Patterns

INSTANCESMinimal operable unit

AppWindow

● The basic unit which wraps the mozbrowser iframe.

● (Mostly) Standalone library to create a webapp instance.

● Each appWindow instance maintains its own states and display proper UI according to these states.

Extra chrome UI

Real web content

AppWindow States

● Visibility: |document.hidden|● Orientation: screen.orientation● Layout: window.innerHeight/innerWidth● Transition● Loading● Title, icon, ….

App Visibility

● Active app is basically foreground, but we are having some more complex rules; for instance, a chaining activities are all foreground.

● Page visibility is particially impacting the process priority.

● The timing of visibilitychange was bind to transition states.

App Orientation

● Passive orientation requested in manifest● Active orientation requested by

screen.lockOrientation()o System app does not being involed too

much in this progress but is expected to.o What if lock orientation during

transitioning?● Query by screen.mozOrientation

App has no knowledge about (x, y),but (w, h) is affecting app by window.innerHeight, window.innerWidth, and reflow/resize if that changed.

Layout = (x, y, w, h)

Use small piece of codes doing limited tasks

AppWindow: Submodule

To avoid a giant AppWindow class..

AppWindow Submodules

AppWindow

Each submodule is responsible to handle a specific request from the appWindow. Their only dependency is the appWindow who launches/instantiates them.

M

M

M

M

M

MHW

M

M

M

M

M M

AtW

M

M

M

M

MM

submodule

CurrentSubmodules

AppWindow

ModalDialog

AuthenticationDialog

TransitionController

Chrome

ContextMenu

childWindowFactory

window.alert

window.open

HTTP Auth

chrome property

<contextmenu>

Transition State Machine

<iframe mozBrowser>

Developing Submodulesvar MyModule = function(app) { this.app = app; this.app.element.addEventListener(‘_opened’, this);};MyModule.prototype = { handleEvent: function() { // ... }};

AppWindow.SUB_MODULES = { ‘myModule’: window.MyModule};

var a = new AppWindow();typeof(a.myModule) // === MyModule

Transition Finite State Machine

● A submodule to process transition related events to maintain the state and perform the transition.

● States: opened/opening/closed/closing● Transition state should be standalone from

other states.

openedclosed

opening

closing

AppWindow

AppWindow does not care the state maintainence, but only ask the finite state machine to process events

openedclosed

opening

closing

AppWindow

Whenever state is changed, transition FSM will publish events for the app.

Interactions between AppWindows..

We are living in a world of multiple apps. An appWindow should not do anything it wants to do.

Request before permitted!

MANAGERSManaging multiple standalone instances

If all the subordinates are standalone

The job of a manager is easy!

Manager

● Lifecycle Management● Hierarchy Management

LifeCycle Management

● Maintain a list of alive windows● Manage the interaction between window

instances● Events happens inside an appWindow is

delegated to the appWindow itself.● Interactions involved multiple appWindows

needs the manager to decide what to do.

Life cycle - launch

● AppWindowManager has an appWindow factory to deal with launch request from the gecko(system message) or the user.

● Each AppWindow instances has a child window factory to deal with launch request from the app.

AppWindowManager

#AppWindow

Gecko

webapps-launch open-app

Factory

Factory

mozbrowseropenwindow

launchactivity

#AppWindowFactory

#AppWindowFactory

#AppWindowFactory

#AppWindowFactory #PopupWindow

Factory

#ActivityWindowFactory

#AttentionWindow

appopenwindow

Life cycle - kill

● active killo window.close()o ParentWindow is killedo The user kills it from task manager.

● When an appWindow is killed inactively by gecko due to OOM or crash, it will enter suspend state.

appWindow

SuspendingWindowManager

suspended

appWindowsuspended

appWindowsuspended

mozbrowsererror

mozbrowsererror

mozbrowsererror

appWindowtimestamp: 1




resumedlaunch






suspended

kill the oldest

*WindowManager

*Window *Window (active)

Modules affecting transition

*Window

TransitionFSM

*Window

request to open

close the active instance

Basically only the same type window will be taken into account.

WindowManager

*Window *Window

Modules affecting transition

*DialogManager

TransitionFSM

*Window

admit the request or ignore by*Window.open();

MultiTasking - Nested Windows

Dialer App Gallery AppHomescreen App Contact App

Contact Activity

Gallery Activity

Camera Activity

Camera App

MultiTasking - Nested Windows

AppWindowAppWindowAppWindow

AppWindow

ActivityWindow

ActivityWindow

ActivityWindow

AppWindow

FrontWindow is rendered inside BottomWindow’s container.

AppWindow#1

ActivityWindow#A

Nested Window

ActivityWindow#B

● AppWindow#1 manages ActivityWindow#A● ActivityWindow#A manages ActivityWindow#B● Only parentWindow/childWindow refers each

other; the grandparentWindow(AppWindow#1) does not need to know the state of the grandchildWindow(ActivityWindow#B)

● However, kill a parentWindow will kill the childWindow which causes a chaining kill.

We are having a principal pattern now.

AppWindowManagerAppWindow AppWindow

Application Core

AppWindow AppWindowAppWindow

One Manager + Instances Pattern fits usual webapp management requirements.

Hierarchy

In an operation system, there would be some system level user interface which are not usual applications but has certain interaction with applications.

Lockscreen, Attention, SystemDialog, Rocketbar...

We are having a principal pattern now.

Scale this design.

One App =>Multiple App =>

Multiple Tasking =>Multiple Hierachy


Application Core

LockscreenWindowManager

LockscreenWindow

Ability to extend the manager


Application Core

LockscreenWindowManager

LockscreenWindow

Keep the interactions between new windows

AttentionWindowManager

AttentionWindow

AttentionWindow

Manager of ManagersHierarchy management

Hierarchy Management

● Visibility Management● Orientation Management● Layout Management

Lowlevel Windows

Highlevel Windows

Manager

1. Request

2. Detect

3.Perform/ Ignore

Operations across windows is controlled by specfic manager.

Hierarchy events

● resize● orientation● visibility● home

Hierarchy Management

● Visibility Management● Orientation Management● Layout Management

LayoutManager

*Window

KeyboardManager SoftwareHomeButton

*WindowManager

*Window *Window *Window

*WindowManager*WindowManager

dispatch resize command to highest priority manager

Modules affecting layout

execute resize to active window

resize

VisibilityManager

*Window

*Window *Window

*WindowManager*WindowManager*WindowManager

dispatch background command to lower priority manager

Modules affecting visibility

execute setVisible to active window

*DialogManager

*Window

VisibilityManager

*Window *Window


*DialogManager

TransitionFSM

request to foreground

*Window

Check no higher priority module is active

VisibilityManager

*Window *Window


*DialogManager

TransitionFSM

*Window

admit the request or ignoreby *Window.setVisible(true)

OrientationManager

*Window *Window

Modules affecting orientation

*DialogManager

TransitionFSM

*Window

request lock orientation

Check no higher priority module is active

OrientationManager

*Window *Window

Modules affecting orientation

*DialogManager

TransitionFSM

*Window

admit the request or ignore

This is not real now.screen.requestLockOrientation() is open to web content.System app should have the ability to manage orientation request from mozbrowser iframe.

Look at the Transition FSM closely

● statechange will trigger the inner handlero Enter closed state: send to backgroundo Enter opened state: request to foreground

Develop a window manager

● What windows to manage/create?● Reuse/Inherit AppWindow● Make HierachyManagement Modules know

your existence

Best Practice: Rocketbar

● Search app is different from a normal appWindow.

● Implement SearchWindow● Implement

SearchWindowManager(rocketbar.js)● Modify HierachyManagement Modules

PATTERNS USED

Patterns

● Manager Pattern● *Observer Pattern● Finite State Machine Pattern

Manager(Mediator) Pattern

● A manager is usually a singleton.● What to manage? Interactions between

instances.● A manager is expected to maintain a list

multiple instances coming from the same class.

InstanceA

Manager

InstanceB

InstanceC

Instances should issue a request which needs cross instance knowledge to manager.

request an operation across instances

InstanceA

Manager

InstanceB

InstanceC

InstanceA has no knowledge about instanceB.

check states

InstanceA

Manager

InstanceB

InstanceC

permit the request after checkingother instances

Patterns

● Manager Pattern● *Observer Pattern● Finite State Machine

Event Publisher/Broadcaster Inner Subscriber

Inner Subscriber

Inner Subscriber

Outer SubscriberOuter Subscriber

Outer Subscriber

Inside a module

The world

Patterns

● Manager Pattern● *Observer Pattern● Finite State Machine + Proxy

Finite State MachineEvents

FSM.processEvent(‘a’);FSM.processEvent(‘a’);FSM.processEvent(‘b’);FSM.processEvent(‘c’);

statechange

Firefox OS Window management 201

Engineering

Transcript of Firefox OS Window management 201