User:Alive/System Refactor Plan: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 17: Line 17:
** Package device specific modules in build time
** Package device specific modules in build time
** Load/start modules correspondingly in run 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 ===
=== Swappable functionality ===

Revision as of 05:33, 8 April 2015

System Refactor Plan

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 refinement
  • AppWindowManager dismantling
  • Statusbar dismantling
  • Shared transition controller
  • Notification refactor
  • LockScreen
  • SystemDialog


Startup logic

  • Tracking bug: bug 1094768
  • 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

AppWindowManager dismantling

  • 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

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

Notification Refactor

  • 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:
  • Owner: Greg?
  • 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

Retrieved from "https://wiki.mozilla.org/index.php?title=User:Alive/System_Refactor_Plan&oldid=1066950"