1069338 - Introduce a simulator to control the API the application needs and uses

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::SMS, defect)

Comment 1

[Julien Wajsberg [:julienw]]

Attachment: github PR

Comment 2

[Julien Wajsberg [:julienw]]

From Oleg in https://github.com/mozilla-b2g/gaia/pull/23766#discussion_r17623378:

* We have links to all shims in index.html (that are removed by build.js for device);
* All shims still responsible only for it's own matters;
* We have central desktop-only/simulator.js that has the following responsibilities:
  * Build and manage simulator UI in full. Currently I see that it's built by data from several "providers", not sure if need that level of abstraction;
  * Eg. listen for window.onKeyDown for some magic key combination to show Simulator panel as overlay. In that case we won't have iframe and can use responsive view (though value is arguable)
  * Somehow notifies mocks about relevant changes in Simulator UI (like Simulator UI (Settings) -> navigator_moz_settings -> call mozSettings observers). Shouldn't be difficult as we're in the same document.
  * Simulator UI changes can be saved via modifying query params or sessionStorage for example to persist between reloads..

I haven't analyzed code too much, maybe I'm missing the point of having it like this. It would be great to hear it from you!

Comment 3

[Julien Wajsberg [:julienw]]

(In reply to Julien Wajsberg [:julienw] from comment #2)
> From Oleg in
> https://github.com/mozilla-b2g/gaia/pull/23766#discussion_r17623378:
> 
> * We have links to all shims in index.html (that are removed by build.js for
> device);

done :) (except the fact that it's removed by build.js, waiting for bug 1050416 

> * All shims still responsible only for it's own matters;

done !

What I've put in "shims/" are really of 2 types:
* some are really shims for some API
* some are more high level (eg: DSDS)

I'd be open to separate them in 2 different directories. That would help making clear which are higher level, and avoid dependencies from low level to high level.

> * We have central desktop-only/simulator.js that has the following
> responsibilities:
>   * Build and manage simulator UI in full. Currently I see that it's built
> by data from several "providers", not sure if need that level of abstraction;

I really like the way I did it for now. Each provider gets a container where it can render stuff and react. This helps having a quite ordered UI, and keeps things organized without spaghetti code.

>   * Eg. listen for window.onKeyDown for some magic key combination to show
> Simulator panel as overlay. In that case we won't have iframe and can use
> responsive view (though value is arguable)

I don't see how this would work with the responsive view.
For sure I'd rather have all this inside Firefox Dev tools :)

>   * Somehow notifies mocks about relevant changes in Simulator UI (like
> Simulator UI (Settings) -> navigator_moz_settings -> call mozSettings
> observers). Shouldn't be difficult as we're in the same document.

That's what I do already (or that I want to do, not sure for the case of mozSettings actually ;) ).

>   * Simulator UI changes can be saved via modifying query params or
> sessionStorage for example to persist between reloads..

Even localStorage. Each shims could persist stuff locally, or have access to a global API.

> 
> I haven't analyzed code too much, maybe I'm missing the point of having it
> like this. It would be great to hear it from you!

So it's not really different to what you're saying, actually :)

Comment 4

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 5

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(