User:Alive/System Refactor Plan: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 77: | Line 77: | ||
* All non appWindow specific dialog should be refactored into SystemDialog and managed by SystemDialogManager | * All non appWindow specific dialog should be refactored into SystemDialog and managed by SystemDialogManager | ||
** CustomDialog/ModalDialog/AppInstallDialog/UpdateDialog/... | ** CustomDialog/ModalDialog/AppInstallDialog/UpdateDialog/... | ||
* '''AppInstallDialog''': {{bug|1111975}} Pending | |||
Revision as of 04:39, 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
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?
Performance
Tracking bug: bug 1094768
- Setup dependency tree
Launcher -> Core -> Subsystem Launcher -> ...
- Determine the critical launch path: Lockscreen, FTU or Homescreen
- Lazy load non-critial modules by the tree order
Special Topics
- AppWindowManager dismantling
- Statusbar dismantling
- Shared transition controller
- Notification refactor
- LockScreen
- SystemDialog
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
Tracking Bug:
- 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:
- All non appWindow specific dialog should be refactored into SystemDialog and managed by SystemDialogManager
- CustomDialog/ModalDialog/AppInstallDialog/UpdateDialog/...
- AppInstallDialog: bug 1111975 Pending