1 of 72

Architecture, Development, Patterns

2 of 72

Window Manager

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

3 of 72

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.

4 of 72

5 of 72

Things inside..

6 of 72

Window Manager (v1.3-)

ModalDialog

TrusteUI

AuthDialog

transition control

create mozbrowser iframe

maintain app life cycle

gen screenshots

redirect mozbrowser events

orientation control

layout control

error handling

visibility control

web activities management

web app management

manage homescreen

manage ftu

7 of 72

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

8 of 72

The secret to build a large app ?

​

​

​

9 of 72

The secret to build a large app ?

​

Never build a large app

​

10 of 72

Solutions

Instances +

Manager +

Scalable Patterns

11 of 72

INSTANCES

Minimal operable unit

12 of 72

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.

13 of 72

14 of 72

Extra chrome UI

Real web content

15 of 72

AppWindow States

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

16 of 72

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.

17 of 72

App Orientation

  • Passive orientation requested in manifest
  • Active orientation requested by screen.lockOrientation()
    • System app does not being involed too much in this progress but is expected to.
    • What if lock orientation during transitioning?
  • Query by screen.mozOrientation

18 of 72

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)

19 of 72

Use small piece of codes doing limited tasks

AppWindow: Submodule

To avoid a giant AppWindow class..

20 of 72

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

M

HW

M

M

M

M

M

M

AtW

M

M

M

M

M

M

submodule

21 of 72

Current

Submodules

AppWindow

ModalDialog

AuthenticationDialog

TransitionController

Chrome

ContextMenu

childWindowFactory

window.alert

window.open

HTTP Auth

chrome property

<contextmenu>

Transition State Machine

<iframe mozBrowser>

22 of 72

Developing Submodules

​

​

var 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

23 of 72

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.

24 of 72

opened

closed

opening

closing

AppWindow

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

25 of 72

opened

closed

opening

closing

AppWindow

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

26 of 72

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!

27 of 72

MANAGERS

Managing multiple standalone instances

28 of 72

If all the subordinates are standalone

​

The job of a manager is easy!

​

29 of 72

Manager

  • Lifecycle Management
  • Hierarchy Management

30 of 72

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.

31 of 72

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.

32 of 72

AppWindowManager

#AppWindow

Gecko

webapps-launch

open-app

Factory

Factory

mozbrowseropenwindow

launchactivity

#AppWindow

Factory

#AppWindow

Factory

#AppWindow

Factory

#AppWindow

Factory

#PopupWindow

Factory

#ActivityWindow

Factory

#AttentionWindow

appopenwindow

33 of 72

Life cycle - kill

  • active kill
    • window.close()
    • ParentWindow is killed
    • 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.

34 of 72

appWindow

SuspendingWindowManager

suspended

appWindow

suspended

appWindow

suspended

mozbrowsererror

mozbrowsererror

mozbrowsererror

35 of 72

appWindow

timestamp: 1

SuspendingWindowManager

appWindow

timestamp: 0

appWindow

timestamp: 2

resumed

launch

36 of 72

appWindow

timestamp: 1

SuspendingWindowManager

appWindow

timestamp: 0

appWindow

timestamp: 9

appWindow

timestamp: 10

suspended

kill the oldest

37 of 72

*WindowManager

*Window

*Window (active)

Modules affecting transition

*Window

Transition

FSM

*Window

request to open

close the active instance

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

38 of 72

WindowManager

*Window

*Window

Modules affecting transition

*DialogManager

Transition

FSM

*Window

admit the request or ignore by

*Window.open();

39 of 72

MultiTasking - Nested Windows

Dialer App

Gallery App

Homescreen App

Contact App

Contact Activity

Gallery Activity

Camera Activity

Camera App

40 of 72

MultiTasking - Nested Windows

AppWindow

AppWindow

AppWindow

AppWindow

ActivityWindow

Activity

Window

ActivityWindow

AppWindow

FrontWindow is rendered inside BottomWindow’s container.

41 of 72

Nested Window

AppWindow#1

Activity

Window#A

Activity

Window#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.

42 of 72

We are having a principal pattern now.

AppWindowManager

AppWindow

AppWindow

Application Core

AppWindow

AppWindow

AppWindow

One Manager + Instances Pattern fits usual webapp management requirements.

43 of 72

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...

44 of 72

We are having a principal pattern now.

Scale this design.

45 of 72

One App =>

Multiple App =>

Multiple Tasking =>

Multiple Hierachy

​

46 of 72

AppWindowManager

AppWindow

AppWindow

Application Core

LockscreenWindow

Manager

LockscreenWindow

Ability to extend the manager

47 of 72

AppWindowManager

AppWindow

AppWindow

Application Core

LockscreenWindow

Manager

LockscreenWindow

Keep the interactions between new windows

AttentionWindow

Manager

Attention

Window

Attention

Window

48 of 72

Manager of Managers

Hierarchy management

49 of 72

Hierarchy Management

  • Visibility Management
  • Orientation Management
  • Layout Management

50 of 72

Lowlevel Windows

Highlevel Windows

Manager

1. Request

2. Detect

3.Perform/ Ignore

Operations across windows is controlled by specfic manager.

51 of 72

Hierarchy events

  • resize
  • orientation
  • visibility
  • home

52 of 72

Hierarchy Management

  • Visibility Management
  • Orientation Management
  • Layout Management

53 of 72

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

54 of 72

VisibilityManager

*Window

*Window

*Window

*WindowManager

*WindowManager

*WindowManager

dispatch background command to lower priority manager

Modules affecting visibility

execute setVisible to active window

*DialogManager

*Window

55 of 72

VisibilityManager

*Window

*Window

Modules affecting visibility

*DialogManager

Transition

FSM

request to foreground

*Window

Check no higher priority module is active

56 of 72

VisibilityManager

*Window

*Window

Modules affecting visibility

*DialogManager

Transition

FSM

*Window

admit the request or ignore

by *Window.setVisible(true)

57 of 72

OrientationManager

*Window

*Window

Modules affecting orientation

*DialogManager

Transition

FSM

*Window

request lock orientation

Check no higher priority module is active

58 of 72

OrientationManager

*Window

*Window

Modules affecting orientation

*DialogManager

Transition

FSM

*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.

59 of 72

Look at the Transition FSM closely

  • statechange will trigger the inner handler
    • Enter closed state: send to background
    • Enter opened state: request to foreground

60 of 72

Develop a window manager

  • What windows to manage/create?
  • Reuse/Inherit AppWindow
  • Make HierachyManagement Modules know your existence

61 of 72

Best Practice: Rocketbar

  • Search app is different from a normal appWindow.
  • Implement SearchWindow
  • Implement SearchWindowManager(rocketbar.js)
  • Modify HierachyManagement Modules

62 of 72

PATTERNS USED

63 of 72

Patterns

  • Manager Pattern
  • *Observer Pattern
  • Finite State Machine Pattern

64 of 72

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.

65 of 72

InstanceA

Manager

InstanceB

InstanceC

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

request an operation across instances

66 of 72

InstanceA

Manager

InstanceB

InstanceC

InstanceA has no knowledge about instanceB.

check states

67 of 72

InstanceA

Manager

InstanceB

InstanceC

permit the request after checking

other instances

68 of 72

Patterns

  • Manager Pattern
  • *Observer Pattern
  • Finite State Machine

69 of 72

Event Publisher/Broadcaster

Inner Subscriber

Inner Subscriber

Inner Subscriber

Outer Subscriber

Outer Subscriber

Outer Subscriber

Inside a module

The world

70 of 72

Event Publisher/Broadcaster

Inner Subscriber

Inner Subscriber

Inner Subscriber

Outer Subscriber

Outer Subscriber

Outer Subscriber

Inside a module

The world

71 of 72

Patterns

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

72 of 72

Finite State Machine

Events

FSM.processEvent(‘a’);

FSM.processEvent(‘a’);

FSM.processEvent(‘b’);

FSM.processEvent(‘c’);

statechange