894352 - [app manager] Connection footer and Device Inspector

Status: RESOLVED DUPLICATE of bug 912447

(DevTools Graveyard :: WebIDE, defect)

Description

[Paul Rouget [:paul]]

Attachment: Content to show in the inspector

The Connection Footer is where the user can connect a device and start a simulator. The Connection Footer includes a Device Inspector that shows various useful data about the connected device.

Comment 1

[Paul Rouget [:paul]]

Attachment: WIP mockup footer (design)

Comment 2

[Paul Rouget [:paul]]

Attachment: WIP mockup (interaction) - PART 1

Comment 3

[Paul Rouget [:paul]]

Attachment: WIP mockup (interaction) - PART 2

Comment 4

[Paul Rouget [:paul]]

Attachment: WIP mockup (interaction) - PART 3

Comment 5

[Paul Rouget [:paul]]

Attachment: WIP mockup (interaction) - PART 4

Comment 6

[Paul Rouget [:paul]]

Front-end WIP code can be found here:

https://github.com/paulrouget/mozilla-central/compare/mozilla:fx-team...app-manager

Comment 7

[Paul Rouget [:paul]]

Panos, can I ask you to take a quick look at these commits:

> actor: url-resolver
> actor: permissionsTable
> actor: device-info
> start actors
> connections-manager

(see https://github.com/paulrouget/mozilla-central/compare/mozilla:fx-team...app-manager)

I'm not asking for a formal review, but for a quick feedback.

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

I took a rather brief look, mostly in the parts I'm familiar with, and here are a few comments I have:

- the device-info and permissionsTable actors should probably be unified to a DeviceActor or a MainProcess actor as discussed on IRC

- the connections-manager module API does not seem sufficiently encapsulated and gives clients access to stuff that should be private. I would expect a ConnectionManager object to encapsulate the connection list and provide createConnection/destroyConnection methods to add/remove connections, instead of handing out the connection list to the clients.

- the Connection object is described as a wrapper around a debugger client object, but it looks more like a RemoteInstance or RemoteTarget object to me. It contains both connection-related data like host and port, but also a generically-named "store" that contains device-related information. In pure remote protocol terms, it looks more like a DeviceActor front combined with a debugger client. This weird layering is partly the fault of dbg-client.jsm, which needs to be refactored to split the various actor fronts from the connection management parts.

- the object hierarchy inside the store reflects the parent-child relationship I mentioned on IRC between the DeviceActor and the Webapps actor (a device contains a webapp manager instance).

Comment 10

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Filter on 86b7095e-2bd0-499e-a704-d00f2524aeef / PAUL STOP SETTING QA CONTACT TO THE DEVTOOLS COMPONENT'S WATCHERS EMAIL FOR BUGS YOU FILE :)