User:Alive/System Refactor Plan

From MozillaWiki
Jump to navigation Jump to 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"