User:Alive/System Refactor Plan

From MozillaWiki
Jump to: navigation, search

System Refactor Plan

This plan is in draft and subject to change. More detail to be updated.

High level goals

  • Modularization
    • Concentrated module responsibility
  • One system app for multiple devices
    • Swappable functionality
    • One business logic, different UI logic
  • Maintenance
    • Code readability
    • Test coverage
  • Performance
    • Reduce startup time

Multiple device support

  • Hardware feature detector - done in Core
  • In the long term, we will have all what we need in the code base
    • Package device specific modules in build time
    • Load/start modules correspondingly in run time
    • Split business logic and UI logic
 // Possible pattern
 var MyCoreLogic = function() {};
 MyCoreLogic.prototype = {
   start: function() {
     switch (Service.query('getDeviceType')) {
       case 'phone':
         BaseModule.load(['phoneUI']).then(() => {
           this.ui = new PhoneUI(this);
         });
         break;
       case 'tv':
         BaseModule.load(['tvUI']).then(() => {
           this.ui = new TvUI(this);
         });
         break;
     }
   },
   handleEvent: function(evt) {
     this.ui.handleEvent(evt);
   },
   // called by UI
   writeDataBase: function() {},
   readDataBase: function() {}
 };

Swappable functionality

  • Each HW specific functionality should be easily removed/disabled from the current code base.
  • Less module dependency - try not touch global variable.

If you need to ask someone else to work, ask the mediator instead of asking it directly. 

 var MyModule = {
   show: function() {
     UtilityTray.hide(); // Sad
     Service.request('UtilityTray:hide'); // Better
   }
 };

Concentrated Module Responsibility

  • A module is always used to accomplish a specific task
  • If an module has too many tasks to do - stop and think about it
    • What's the core task of this module?
    • Could we use a shared logic between modules?
    • Could we have a submodule to help on certain tasks?

Special Topics

Startup logic

  • Tracking bug: bug 1094759
  • Owner: Alive
  • Build a reasonable dependency tree
 Launcher -> Core -> Subsystem Launcher -> ...
  • Determine the critical launch path: Lockscreen, FTU or Homescreen
  • Lazy load non-critial modules by the tree order
  • Now is fixing integration test failures due to lazily loaded features
    • Maybe an event queue system in service

Clean DOM elements

  • Tracking Bug: NaN, and there won't be.
  • Clean system app DOM elements - only <windows> is necessary on startup
  • All other DOM elements are appended to the document when render() function is called in the UI module.
  • This is a long term change.

AppWindowManager dismantling

  • Tracking Bug: NaN
  • Owner: NaN
  • AppWindowManager is still heavy now.
  • Current direction is to look into TV's AWM requirements and see how we could split it.
  • Idea: shared WindowManager interface + shared app switch interface.
    • We have many WindowManager right now, maybe we should have a baseWindowManager
    • Window switch feature is complex and it is phone(Single window device) specific.

Statusbar dismantling

  • Tracking Bug: NaN
  • Owner: NaN
  • Icon operation is already dismantled in bug 1098168
  • Todo: Instantiation, take UtilityTray as submodule

Notification Refactor

  • Tracking Bug: NaN
  • Owner: NaN
  • Ideally we shall have a simple NotificationManager singleton and several NotificationUI instances
  • NotificationManager is responsible to create NotificationUI instances due to events from gecko
  • The behavior of the NotificationUI is dependent from the NotificationManager
  • NotificationUI is device specific - it may change due to UX design

LockScreen Decoupling

  • Tracking Bug:bug 1152198
  • Owner: John/Chens
  • LockScreen is going to be a new app at certain timing. However we should make it less dependent from other modules in the system before that really happens
 Core -> AppCore -> LockScreenWindowManager -> LockScreenWindow -> (LockScreenLoader) -> LockScreen specific modules

System Dialog-lize

  • Tracking Bug: NaN
  • Owner: NaN
  • All non appWindow specific dialog should be refactored into SystemDialog and managed by SystemDialogManager
    • CustomDialog/ModalDialog/AppInstallDialog/UpdateDialog/...

AppInstallDialog

RoamingWarningDialog

  • Tracking Bug: bug 1121356
  • Owner: Alive
  • (Welcome to steal!)

ActionMenuDialog

  • Tracking Bug: bug 1121316
  • Owner: NaN
  • It's not finalized this one should be a new system dialog or a new app window sub component.

STK decoupling from system

Shared transition state controller in BaseUI

  • Tracking Bug: NaN
  • Owner: Alive
  • Now all AppWindow family is using AppTransitionController as its transition state machine
  • Some UI modules inside system app is having their own transition controller
    • Listen to transitionend event with a timer
    • Dispatch internal events when transition starts/ends
    • Do certain things when transition starts/ends

Transition Pattern

  • I believe all transitions could be mapped to 'opened/shown', 'closing/hiding', 'closed/hidden', 'opening/showing'.
  • If we could make a customisable transition state machine, we don't need to re-implement it everywhere.
  • Another pros: We could have a AnimationManager to control all animation/transition in system app.
  • One more pros: We could switch to Web animation (TBD)

Move More Window Specific UI into AppWindow

Permission Dialog

Screen element cleanup

  • Tracking Bug: bug 1110659
  • Owner: NaN
  • Read the bug comment :)

Deprecate VisibilityManager and enhance HierarchyManager

  • Tracking Bug: NaN
  • Owner: NaN
  • HierarchyManager had already covered the functionality of the current VisibilityManager.
 1. Do setVisible stuff in each UI manager's setHierarchy function
 2. Call setVisible/setVisibleForScreenReader to the active instance
 3. Deal with exception (audio channel)

Window Management Related Cleanup

Rework WrapperFactory into ChildWindowFactory

Input Management Isolation

  • Tracking Bug: NaN, but maybe John Lu had opened it.
  • Owner: NaN
  • We need to group Input Management related modules and clean the coupling between KeyboardManager and InputWindowManager.
Retrieved from "https://wiki.mozilla.org/index.php?title=User:Alive/System_Refactor_Plan&oldid=1067287"