Closed Bug 965105 (lockscreen-widgets) Opened 6 years ago Closed 2 years ago

[LockScreen] Implement the architecture of new LockScreen and its helpers


(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Gonk (Firefox OS)
Not set


(Not tracked)



(Reporter: gweng, Unassigned)




(2 files, 3 obsolete files)

I'm trying to design the new lockscreen architecture to deprecate current monolithic way to present multiple heterogeneous components on the same screen. This bug would be a demo and discussion place to evaluate the new architecture, and a WIP patch would be done. I'll also share my ideas on this bug later.
Assignee: nobody → gweng
And the 'helpers' is not a precise word to describe these components. I may name them 'widget', but I'm not sure if this word is suitable enough.
Alias: lockscreen-widgets
Attached file Patch (obsolete) —
This WIP patch demos:

1. How LockScreen become a mediator, to receive requests from widgets.
2. How a widget organize itself, including how to get resources and communicate with LockScreen.
3. How to generate and register new widget.

I'll keep working on this. So the current designation may be changed.

The demo widget would be removed recently, and replaced with a useful and refactored widget.
Attachment #8371486 - Flags: feedback?(timdream)
Updated the PR:

1. The LockScreenSlide now has a widget adapter, so it now use the widget way to unlock and activate the camera.
2. Now there is a new Bootstrap widget, which would invoke other listed widgets to do the initialization. In the long term this widget should be able to load different preset lists from external resources to provide different lockscreen widgets on different builds.
Comment on attachment 8371486 [details] [review]

Updated the PR:

1. Add bootstrap widget to bootstrap other widgets automatically.
2. Add unlocking and slide widgets to pull out some functions from the original lockscreen.
3. Disable the new functions so we can land this new architecture first, and start to solve other relevant bugs.
Attachment #8371486 - Attachment description: WIP Patch → Patch
Attachment #8371486 - Flags: feedback?(timdream) → review?(timdream)
Comment on attachment 8371486 [details] [review]

Since I'm do some adjustments, I now cancel the review.
Attachment #8371486 - Flags: review?(timdream)
Attached file Patch (obsolete) —
New PR to bubble-tea because of the new landing policy of the v1.4.
Attachment #8371486 - Attachment is obsolete: true
Attachment #8380440 - Flags: review?(timdream)
Whiteboard: [in-bubble-tea]
Attached image LockScreen_widgets.png
My thoughts on the new architecture.
Whiteboard: [in-bubble-tea]
Blocks: 980936
Comment on attachment 8380440 [details] [review]

Cancel review because Tim and I has a offline discussion, which is about:

1. Should use references and methods instead of events to let widgets communicate with the mediator

2. Bootstrap function should be a part of the factory, to reduce the complex

3. Using iframe to isolate widgets' canvas is a idea with some pros and cons we need to evaluate, so it would not happen before we complete this refactoring

4. The LockScreen launch path would be:

a. LockScreen app or component entry create the mediator
b. The mediator create the factory with its own reference
c. The factory create widgets to complete the bootstrap, and each widget would receive a mediator reference to communicate

5. The widget may receive a smaller inner-controller interface instead of the whole mediator, to avoid widget abuse it. This change would be done before we complete the refactoring

6. The mediator would manage outer and inner interface that handle requests from the outside world (through IAC or WebAPIs) and inner world (from widgets)
Attachment #8380440 - Flags: review?(timdream)
7. Documentation is necessary to let others know the whole designation.
8. The LockScreen should be a privileged app and clean all obstacles on the road (ex: the use of certified APIs), or no 3rd-party LockScreen can be placed on the market.
Any update? Thanks.
Flags: needinfo?(gweng)
Yes, I've refactored the refactoring patch to migrate the communication mechanism from the event to the function call.

Beside that, I created the MDN page to explain the designation of the new LockScreen at:

And today I just commented lots of methods to provide more information, and start to write unit tests.
Flags: needinfo?(gweng)
Hmm... the URL missing the last ')'. So it need a copying and pasting to direct to the right page.
The patch now is almost done. I'll send the patch and run tests tomorrow.
There is a question.
Should this architecture be adopted when making a third party lock screen application?
It depends on whether the 3rd-party LockScreen would adopt this architecture or not. If so, we may put some code as shared libraries to help developers to reuse them in their own LockScreen. But this would only happen after this architecture has been completed in our own LockScreen app.
(Even so, the 3rd-party developers still can write their own LockScreen in other ways).
Attached file Patch (obsolete) —
Patch to master, not bubble-tea.
Attachment #8380440 - Attachment is obsolete: true
Attached file Patch
Correct the wrong link.
Attachment #8402490 - Attachment is obsolete: true
Comment on attachment 8402493 [details] [review]

Travis is green. So I set the flag.
Attachment #8402493 - Flags: review?(timdream)
And I'll concurrently try the patch on the real device. If any problem occurs, I'll update it here.
After discussed with Tim, this patch should be landed after I firstly isolate the LockScreen as an app, to reduce the duplicated work and solve possible regressions. I'll re-schedule the whole plan of refactoring later.
Attachment #8402493 - Flags: review?(timdream)
Assignee: gweng → nobody
Firefox OS is not being worked on
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.