Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Firefox OS Window management 201

501 views

Published on

Mid level introduction to the Javascript based window management system of FxOS

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Firefox OS Window management 201

  1. 1. Architecture, Development, Patterns
  2. 2. Window Manager A core module in an operating system, which is responsible to display and maintain the window based UI.
  3. 3. 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. 4. Things inside..
  5. 5. Window Manager (v1.3-) Modal Dialog Truste UI AuthDi alog 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
  6. 6. It’s sad to have a such giant module to control everything :(
  7. 7. The secret to build a large app ?
  8. 8. The secret to build a large app ? Never build a large app
  9. 9. Solutions Instances + Manager + Scalable Patterns
  10. 10. INSTANCES Minimal operable unit
  11. 11. 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.
  12. 12. Extra chrome UI Real web content
  13. 13. AppWindow States ● Visibility: |document.hidden| ● Orientation: screen.orientation ● Layout: window.innerHeight/innerWidth ● Transition ● Loading ● Title, icon, ….
  14. 14. 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.
  15. 15. 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
  16. 16. 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)
  17. 17. Use small piece of codes doing limited tasks AppWindow: Submodule To avoid a giant AppWindow class..
  18. 18. 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 At W M M M M M M submodule
  19. 19. Current Submodules AppWindow ModalDialog AuthenticationDialog TransitionController Chrome ContextMenu childWindowFactory window.alert window.open HTTP Auth chrome property <contextmenu> Transition State Machine <iframe mozBrowser>
  20. 20. 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
  21. 21. 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.
  22. 22. openedclosed opening closing AppWindow AppWindow does not care the state maintainence, but only ask the finite state machine to process events
  23. 23. openedclosed opening closing AppWindow Whenever state is changed, transition FSM will publish events for the app.
  24. 24. 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!
  25. 25. MANAGERS Managing multiple standalone instances
  26. 26. If all the subordinates are standalone The job of a manager is easy!
  27. 27. Manager ● Lifecycle Management ● Hierarchy Management
  28. 28. 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.
  29. 29. 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.
  30. 30. AppWindowManager #AppWindow Gecko webapps-launch open-app Factory Factory mozbrowseropenwindow launchactivity #AppWindow Factor y #AppWindow Factor y #AppWindow Factor y #AppWindow Factor y #PopupWindow Factor y #ActivityWindow Factor y #AttentionWindow appopenwindow
  31. 31. Life cycle - kill ● active kill o window.close() o ParentWindow is killed o 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.
  32. 32. appWindow SuspendingWindowManager suspended appWindow suspended appWindow suspended mozbrowsererror mozbrowsererror mozbrowsererror
  33. 33. appWindow timestamp: 1 SuspendingWindowManager appWindow timestamp: 0 appWindow timestamp: 2 resumedlaunch
  34. 34. appWindow timestamp: 1 SuspendingWindowManager appWindow timestamp: 0 appWindow timestamp: 9 appWindow timestamp: 10 suspended kill the oldest
  35. 35. *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.
  36. 36. WindowManager *Window *Window Modules affecting transition *DialogManager Transition FSM *Window admit the request or ignore by *Window.open();
  37. 37. MultiTasking - Nested Windows Dialer App Gallery AppHomescreen App Contact App Contact Activity Gallery Activity Camera Activity Camera App
  38. 38. MultiTasking - Nested Windows AppWindow AppWindowAppWindow AppWindow ActivityWindow Activity Window ActivityWindow AppWindow FrontWindow is rendered inside BottomWindow’s container.
  39. 39. AppWindow#1 Activity Window#A Nested Window 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.
  40. 40. We are having a principal pattern now. AppWindowManagerAppWindow AppWindow Application Core AppWindow AppWindow AppWindow One Manager + Instances Pattern fits usual webapp management requirements.
  41. 41. 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...
  42. 42. We are having a principal pattern now. Scale this design.
  43. 43. One App => Multiple App => Multiple Tasking => Multiple Hierachy
  44. 44. AppWindowManagerAppWindow AppWindow Application Core LockscreenWindow Manager Lockscreen Window Ability to extend the manager
  45. 45. AppWindowManagerAppWindow AppWindow Application Core LockscreenWindow Manager Lockscreen Window Keep the interactions between new windows AttentionWindow Manager Attention Window Attention Window
  46. 46. Manager of Managers Hierarchy management
  47. 47. Hierarchy Management ● Visibility Management ● Orientation Management ● Layout Management
  48. 48. Lowlevel Windows Highlevel Windows Manager 1. Request 2. Detect 3.Perform/ Ignore Operations across windows is controlled by specfic manager.
  49. 49. Hierarchy events ● resize ● orientation ● visibility ● home
  50. 50. Hierarchy Management ● Visibility Management ● Orientation Management ● Layout Management
  51. 51. 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
  52. 52. VisibilityManager *Window *Window *Window *WindowManager*WindowManager*WindowManager dispatch background command to lower priority manager Modules affecting visibility execute setVisible to active window *DialogManager *Window
  53. 53. VisibilityManager *Window *Window Modules affecting visibility *DialogManager Transition FSM request to foreground *Window Check no higher priority module is active
  54. 54. VisibilityManager *Window *Window Modules affecting visibility *DialogManager Transition FSM *Window admit the request or ignore by *Window.setVisible(true)
  55. 55. OrientationManager *Window *Window Modules affecting orientation *DialogManager Transition FSM *Window request lock orientation Check no higher priority module is active
  56. 56. OrientationManager *Window *Window Modules affecting orientation *DialogManager Transition FSM *Window admit the request or ignore This is not real now. screen.requestLockOri entation() is open to web content. System app should have the ability to manage orientation request from mozbrowser iframe.
  57. 57. Look at the Transition FSM closely ● statechange will trigger the inner handler o Enter closed state: send to background o Enter opened state: request to foreground
  58. 58. Develop a window manager ● What windows to manage/create? ● Reuse/Inherit AppWindow ● Make HierachyManagement Modules know your existence
  59. 59. Best Practice: Rocketbar ● Search app is different from a normal appWindow. ● Implement SearchWindow ● Implement SearchWindowManager(rocketbar.js) ● Modify HierachyManagement Modules
  60. 60. PATTERNS USED
  61. 61. Patterns ● Manager Pattern ● *Observer Pattern ● Finite State Machine Pattern
  62. 62. 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.
  63. 63. InstanceA Manager InstanceB InstanceC Instances should issue a request which needs cross instance knowledge to manager. request an operation across instances
  64. 64. InstanceA Manager InstanceB InstanceC InstanceA has no knowledge about instanceB. check states
  65. 65. InstanceA Manager InstanceB InstanceC permit the request after checking other instances
  66. 66. Patterns ● Manager Pattern ● *Observer Pattern ● Finite State Machine
  67. 67. Event Publisher/Broadcaster Inner Subscriber Inner Subscriber Inner Subscriber Outer Subscriber Outer Subscriber Outer Subscriber Inside a module The world
  68. 68. Event Publisher/Broadcaster Inner Subscriber Inner Subscriber Inner Subscriber Outer Subscriber Outer Subscriber Outer Subscriber Inside a module The world
  69. 69. Patterns ● Manager Pattern ● *Observer Pattern ● Finite State Machine + Proxy
  70. 70. Finite State MachineEvents FSM.processEvent(‘a’); FSM.processEvent(‘a’); FSM.processEvent(‘b’); FSM.processEvent(‘c’); statechange

×