App manager devtool

[Alexandre poirot]

Hi devtools!

In the process of thinking how we can integrate Firefox OS Simulator with
devtools and Firefox ecosystem, I've been seing the opportunity to start
with landing a remotable App management developer tool in Firefox.

For now, there is nothing to help debugging app installation, update and
removal:
- It is especially hard to play with app update mechanism and push apps to
a device.
- The Simulator has only limited support for FF OS devices.
- There is an about:apps page in Fennec, but that's for end user. And
debugging with UI on device isn't really handy.

I think we do want a developer tool here!
It is now not an option to build a non-remote, platform specific, devtool.
So here is what I'm suggesting:

1) Move /b2g/chrome/content/dbg-webapps-actors.js to /dom/apps/ or a place
reachable by all platforms.
http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/dbg-webapps-actors.js

2) This actor only support install for now. So we need to add various new
requests to list, install, uninstall, update, ... apps
The simulator already implement some in a custom actor only shipped in
simulator's xpi.

3) Land in desktop a UI to query this remote actor, so that we can play
with apps on all platforms!

This goal matches Milestone 4 "App manager" goal from the Firefox Simulator
Roadmap:

https://docs.google.com/document/d/1UpW31ypq-IpIbhRzREvrlujfLC7NQl4qzLtWyve7uXc/edit#
also respond to the request made by Panos during dbg-webapps-actors.js's
review:
https://bugzilla.mozilla.org/show_bug.cgi?id=828863#c2
and would streamline fabrice's effort directly into firefox:
https://github.com/fabricedesre/b2gremote

Steps 1 and 2 are obvious to me. Apps are already working on all platforms,
we shouldn't segregate Actor's code to b2g, nor the simulator addon.
We can collaborate and land our effort in a common place. Then put some
additional
work to make them work for Desktop and Fennec.

Step 3 is more at risk, as it will require more work and ask the question
about how we do integrate the Simulator in firefox.
We can stop at step 2 and just start sharing code.

The simulator has been made to mainly target b2g desktop. Some support has
been
added to also support b2g devices and eventually firefox desktop.
Many features of the simulator aren't b2g specific and are also usefull on
desktop and mobile:
managing apps, mocking device APIs, debugging new APIs (geoloc, alarms,
...)
I'm deeply convinced we should do generic tools that will work everywhere.
Otherwise it will defeat the new #devtools rule where any new devtool has
to be remotable.
Not doing that gives the feeling that the web is clustered and various
stuff only happens in b2g platform.

Having said that, it shouldn't be too hard to convert the simulator to a
generic
tool. I think that the main modification would be UX wise. For now, the
simulator UI
doesn't feel really integrated into firefox and devtools various UIs.
I have the feeling that the existing "Connect" menu action,
and the related connect page should be tweaked to better integrate the
simulator.
Also the app management interface displayed by the simulator
should be plugged into the remote connection, not the opposite.
We do want to "manage apps of a given remote" and not
"have a local/global app management that eventually connect to a remote".
My naive idea was to display the app management UI into the remote toolbox,
as a new regular devtool panel, but this particular tool isn't tab-specific
and it can be misleading.

Can we get some talented UX resources thinking about devtools connected to
a device and the simulator?
It feel like we are not there yet with the existing "Connect" menu.

There is interesting mockups here, made by Harald, but focusing on App
creation screen:

https://dl.dropboxusercontent.com/u/1864007/Mozilla/17-10-12%20-%20Simulator.pdf

My overall idea is that the simulator addon should be limited to setup'n
spawn
a FF OS instance, and then automatically connect tools to it.
With a nice UX that:
- does'nt require going to some menu for displaying tool,
- spawn FF OS with just a button,
- avoid having multiple windows (if technicaly possible).
Most of the other features should be in firefox and work for all platforms.

Last but not least, here is a tentative implementation of such tool as an
addon.
It gives a rough idea of what could go wrong with making the actor work on
all platforms.
Desktop addon:
https://github.com/ochameau/webapps-tool/blob/master/webapps.xpi
Necessary fennec addon to register the actor:

https://github.com/ochameau/webapps-tool/blob/master/apps-actor/webapp-actor%40mozilla.org.xpi

It worked without major issues on Desktop, but highlighted one on Mobile,
where the code registering the intent is executed in chrome browser UI code.
That ends up preventing the intent from being registered and prevent the
app from being launched correctly.

I'd be very existed to drive this cross team project, if we can get at
least some efficient review cycles, and eventually some developement
resources from Apps and devtools teams to help:
- writing the actor and making it work on all platforms,
- integrate an App management UI in firefox.


++
Alex

[Dave Camp]

On Thu, Apr 18, 2013 at 7:46 AM, Alexandre poirot <poiro...@gmail.com>wrote:

> Hi devtools!
>
> In the process of thinking how we can integrate Firefox OS Simulator with
> devtools and Firefox ecosystem, I've been seing the opportunity to start
> with landing a remotable App management developer tool in Firefox.
>

Sounds good!

> 1) Move /b2g/chrome/content/dbg-webapps-actors.js to /dom/apps/ or a place
> reachable by all platforms.
>
> http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/dbg-webapps-actors.js
>

You could just put it in toolkit/devtools/ somewhere with the rest of the
actors.

The simulator has been made to mainly target b2g desktop. Some support has
> been
> added to also support b2g devices and eventually firefox desktop.
> Many features of the simulator aren't b2g specific and are also usefull on
> desktop and mobile:
> managing apps, mocking device APIs, debugging new APIs (geoloc, alarms,
> ...)
> I'm deeply convinced we should do generic tools that will work everywhere.
> Otherwise it will defeat the new #devtools rule where any new devtool has
> to be remotable.
> Not doing that gives the feeling that the web is clustered and various
> stuff only happens in b2g platform.
>

I agree. I would imagine shipping a bare firefox with an app manager that
can manage apps installed in firefox itself or on a connected phone. When
the simulator addon is installed, it could augment that manager with
support for the simulator.

Can we get some talented UX resources thinking about devtools connected to
> a device and the simulator?
> It feel like we are not there yet with the existing "Connect" menu.
>

Yeah, let's try to find someone.

Yeah, this sounds great. Looking forward to it.

-dave


>
>
> ++
> Alex
> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

[Jeff Griffiths]

On 2013-04-18 9:05 AM, Dave Camp wrote:
> On Thu, Apr 18, 2013 at 7:46 AM, Alexandre poirot
> <poiro...@gmail.com>wrote:

...

> The simulator has been made to mainly target b2g desktop. Some
> support has
>> been added to also support b2g devices and eventually firefox
>> desktop. Many features of the simulator aren't b2g specific and are
>> also usefull on desktop and mobile: managing apps, mocking device
>> APIs, debugging new APIs (geoloc, alarms, ...) I'm deeply convinced
>> we should do generic tools that will work everywhere. Otherwise it
>> will defeat the new #devtools rule where any new devtool has to be
>> remotable. Not doing that gives the feeling that the web is
>> clustered and various stuff only happens in b2g platform.
>>
>
> I agree. I would imagine shipping a bare firefox with an app manager
> that can manage apps installed in firefox itself or on a connected
> phone. When the simulator addon is installed, it could augment that
> manager with support for the simulator.

I can see eventually needing to support multiple versions or
combinations of Gaia and a B2G desktop build, so we may eventually need
to do something like:

1. produce a simulator add-on that provides 'current' mainline versions
of both B2G & Gaia

2. allow Gaia to be loaded from the filesystem, eg a Git repo checkout.

3. (eventually) distribute 'content packs' that contain specific
B2G/Gaia versions

This is all implied by the roadmap under "Multiple Versions of B2G/Gaia
".

[Matt Claypotch]

Presently the remote app management is done via a bundled copy of adb. I
can't imagine that's something we would want in the core browser.

> ______________________________**_________________
> dev-developer-tools mailing list
> dev-developer-tools@lists.**mozilla.org<dev-devel...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-developer-tools<https://lists.mozilla.org/listinfo/dev-developer-tools>
>



--
Matt "potch" Claypotch
"Neque porro quisquam est qui dolorem ipsum quia dolor sit amet,
consectetur, adipisci velit..."

[Myk Melez]

On 2013/04/18 07:46, Alexandre poirot wrote:
> 1) Move /b2g/chrome/content/dbg-webapps-actors.js to /dom/apps/ or a
> place reachable by all platforms.
> http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/dbg-webapps-actors.js
>

> 2) This actor only support install for now. So we need to add various
> new requests to list, install, uninstall, update, ... apps
> The simulator already implement some in a custom actor only shipped in
> simulator's xpi.
>
> 3) Land in desktop a UI to query this remote actor, so that we can
> play with apps on all platforms!

This all makes tons of sense!

> Many features of the simulator aren't b2g specific and are also
> usefull on desktop and mobile:
> managing apps, mocking device APIs, debugging new APIs (geoloc,
> alarms, ...)
> I'm deeply convinced we should do generic tools that will work everywhere.
> Otherwise it will defeat the new #devtools rule where any new devtool
> has to be remotable.
> Not doing that gives the feeling that the web is clustered and various
> stuff only happens in b2g platform.

Indeed! We recently added support for pushing apps to actual devices to
the Simulator for exactly this reason, and it's consistent with the
vision for the Simulator's Dashboard.

> Having said that, it shouldn't be too hard to convert the simulator to
> a generic
> tool. I think that the main modification would be UX wise. For now,
> the simulator UI
> doesn't feel really integrated into firefox and devtools various UIs.

That's true, but it isn't intentional; it's just a product of the
experimental origin of the Simulator and the limited resources we have
had available to develop it to date.

> I have the feeling that the existing "Connect" menu action,
> and the related connect page should be tweaked to better integrate the
> simulator.

Absolutely! The current UX isn't our intended endgame, just an
intermediate step to make things a little easier. Ideally, a developer
would be able to connect devtools to a given app on a given target
(simulator, device, Android app, desktop app) via an obvious single step
(at most!) instead of the three (or more) it currently takes.

> Also the app management interface displayed by the simulator
> should be plugged into the remote connection, not the opposite.
> We do want to "manage apps of a given remote" and not
> "have a local/global app management that eventually connect to a remote".

It would be useful to be able to manage the apps installed on a given
target. But it's absolutely essential that a developer be able to
register an app they intend to install (and develop), because that is
the key first step to installing the app so it can be managed in the
first place.

Without that ability, developers will have to resort to target-specific
flows to install apps, some of which are more cumbersome than others,
and all of which are more difficult than the single "push to device"
step in the Simulator's Dashboard.

And those install flows don't necessarily give the target enough
information (including in particular the location of the app's source
code) to make it easy for the developer to refresh the app on the target
in a single step, which is another key feature of the Dashboard (and the
basis for the Simulator's new "Ctrl/Command-R to refresh a packaged app"
feature).

App registration and installed app management could be provided by
separate interfaces, of course. But both interfaces would show
representations of the same targets and many of the same apps. And
developers will manage primarily registered apps. So it makes more sense
to provide a single view of apps that lets developers register them, see
their status on the various targets, and manage that status.

> My naive idea was to display the app management UI into the remote
> toolbox,
> as a new regular devtool panel, but this particular tool isn't
> tab-specific and it can be misleading.
>

> Can we get some talented UX resources thinking about devtools
> connected to a device and the simulator?
> It feel like we are not there yet with the existing "Connect" menu.

Maria Sandberg and Tony Santos have expressed availability to work on
this UX. And Stephen Horlander has done a bunch of work on the existing
devtools UX. I don't know how their team divvies up work, but I've cc:ed
them all and hope they can plug themselves in.

> There is interesting mockups here, made by Harald, but focusing on App
> creation screen:
> https://dl.dropboxusercontent.com/u/1864007/Mozilla/17-10-12%20-%20Simulator.pdf
>
> My overall idea is that the simulator addon should be limited to
> setup'n spawn
> a FF OS instance, and then automatically connect tools to it.
> With a nice UX that:
> - does'nt require going to some menu for displaying tool,
> - spawn FF OS with just a button,
> - avoid having multiple windows (if technicaly possible).
> Most of the other features should be in firefox and work for all
> platforms.

That makes plenty of sense!

-myk

[Myk Melez]

On 2013/04/18 10:54, Matt Claypotch wrote:
> Presently the remote app management is done via a bundled copy of adb.
> I can't imagine that's something we would want in the core browser.

Perhaps not, although it's worth exploring our options. There's a
footprint consideration, as adb is several hundred KB (at best). And
then there may be some quality considerations. But we may be able to
address those or reimplement adb's functionality in Firefox.

Either way, we could choose to bundle the functionality with Firefox or
make it available as an addon for developers who want to manage apps on
a physical device. It isn't essential that it ship with Firefox, since
the app manager is useful for managing apps installed in Firefox itself,
even without the Simulator nor access to a physical device.

-myk

[Matt Claypotch]

> Completely agreed.

[Luca Greco]

Hi all
I agree completely with the vision described by Myk and,
as a volunteer contributor on the simulator project, I want to share
a couple of bits (in the same direction) as my modest contribution
to this preliminary discussion.

In the last hacking months I think we've achieved on the simulator
a good (even if not perfect) app development workflow, and now we've
the chance to use all this experiments (and related knowledge) to get the
other
openwebapp platforms on the same level (e.g. connect remote devtools
to a firefoxos app in the simulator is now simpler than connect to
an installed desktop/android app, or we can now reinstall an update
version of a registered app using a keyboard shortcut) and fix what is
eventually wrong in our current app devtool prototype.

I helped on the app management workflow currently implemented in the
simulator,
so to better visualize how it currently works, I would try to summarize
current components and their responsibilities into an informal diagram:

http://ubik.cc/DRAFTS/simulator_diagram.png

As described by Myk (if I'm not wrong) we can think to evolve the simulator
into a generic app manager devtool (implemented as an extensions during
prototyping
and then integrated into firefox) which manage registered apps (which are
app the user is
currently developing) and use a number of "platform providers" to
connect/manage:
- b2g-desktop releases
- firefoxos devices
- firefox desktop installed apps
- firefox android devices

in future dbg-webapps-actors:
include the commands needed to fully manage registered apps,
e.g. porting some of the commands we added to the simulator actor
(run app, uninstall app, validate app manifest) and add what is missing
(e.g. list app installed through dbg-webapps-actor could be useful):

http://ubik.cc/DRAFTS/app_manager_diagram.png

I think this could be a really interesting evolution of our current
experiments on the
FirefoxOS Simulator into a tool to develop openWebApps across the various
available
platforms.

My apologies if I got something wrong or if my english is completely
ununderstandable :-)

Best,
Luca

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

--
Luca Greco @ Alca Società Cooperativa
Follow me on http://twitter.com/lucagreco

[Luca Greco]

oh my...
informal diagram is good... but it supposed to be correct :-)

I mean "TCP" and "TCP over ADB" instead of HTTP (damn cut & paste)

and probably "adapters" is a better name than "providers"

[Luca Greco]

and the debugger actor prototyped in
https://github.com/ochameau/webapps-tool
is mostly in the direction I tried to describe in the previous email.

I'll try to use it in a simulator experimental branch instead of our
current actors
(dbg-webapps-actors.js and dbg-simulator-actors.js),
I'm curious to see how it will look.

Best,
Luca

[Alexandre poirot]

Thanks everyone for your feedback!

Next week, I'll start filling bugs and submit patches for steps 1 and 2:
tune webapps-actor to implement all necessary methods to build an App
manager tool and ideally make it work on other platforms (desktop and
mobile).

Luca, I'd suggest you to wait for these bugs to be reviewed before tuning
the simulator to use it, as it may change during the review process. I
already expect some changes to launch request as it may land seperately
here from a different patch that already exists:
https://bugzilla.mozilla.org/show_bug.cgi?id=844227
As you may have seen, I droped the adb requirement for install request, but
I've been having various questions while implementing it, so I'm also
expecting some modifications here.
I'll CC you on bugs and keep you updated of any progress.


2013/4/19 Luca Greco <luca....@alcacoop.it>

[bfra...@mozilla.com]

On Thursday, April 18, 2013 3:46:42 PM UTC+1, Alexandre poirot wrote:
> In the process of thinking how we can integrate Firefox OS Simulator with
> devtools and Firefox ecosystem, I've been seing the opportunity to start
> with landing a remotable App management developer tool in Firefox.

Hi, I just wanted to express my strong support for this work and also share some feedback after talking with Gaia developers at the Firefox OS work week and 50+ local app developers at the app workshop in Madrid last week.

At the beginning of the app workshop we demonstrated the Firefox OS Simulator and the Firefox developer tools. We had some positive feedback and those that persevered were able to demo some impressive apps at the end of the day. Sadly there was also a lot of frustration expressed about developer tools and I think this was one of the main reasons over half of the developers left before the demos at the end of the day.

The push to device feature proved unreliable for a number of reasons. There was a bug where apps were not displayed until after a reboot (bug #9322), some people couldn't get it to work at all and it was particularly difficult to get working on Windows because of issues with device drivers. Another common problem was with installing hosted apps where the Simulator was too picky about content types (bug #221).

A big frustration was not being able to use all the developer tools against privileged apps which made debugging even simple CSS issues challenging. We tried to encourage people to develop their apps as hosted apps in Firefox for as long as possible before switching to the simulator to mitigate this, but most developers wanted to use privileged APIs, particularly System XHR.

We had several questions about editing source code from inside the developer tools and I did mention this was something that has been experimented with.

I think a huge win would be if developers could grant privileged API access to hosted apps during development. We used to have a pref for this which got removed and the Gaia build system currently has a hack which does the same thing, this is a huge productivity boost.

At the Firefox OS work week there was a tech talk about the tools Kevin and Vivien have been working on to enable Gaia development inside Firefox and I spent some time talking to them and other Gaia developers over the course of the week. The feeling is that right now we have two different solutions (Firefox OS Simulator vs. a collection of addons in the Gaia build system) which are aimed at different audiences, but over time we'd like to see these converge. The ultimate goal should be a single development environment which can work for all targets - the Firefox browser and app runtimes on both desktop and mobile - for both Gaia and third party developers.

For a long time at the beginning of the B2G project it was possible to run the whole of Gaia in Firefox. But as we added new APIs, a new permissions system and moved from appcache to packaged apps the Firefox runtime and the B2G runtime diverged enough to make this impossible and we had to create B2G Desktop to continue working. The Simulator then built on that tool. I'd really like to see these two diverging runtimes start to come back together again. A big part of this will be adding support for more APIs in the Firefox runtime but starting to migrate the tools from the Simulator into Firefox developer tools would also be great, even if they're packaged as an addon.

The last thing I want to mention is that it seems kind of odd that a web browser needs to "simulate" a web runtime and that we package an entirely separate gecko build inside a Firefox addon. I notice that one of the items on the simulator roadmap is to try to get the simulator using XULRunner from Firefox. This seems like a desirable thing but given the number of differences in the way the B2G gecko is built and configured I'm curious to know how feasible you think this is?

Sorry for the long email and thanks for the work you're all doing to make developer tools more awesome.

Ben

[Myk Melez]

On 2013/04/22 09:36, bfra...@mozilla.com wrote:
> The push to device feature proved unreliable for a number of reasons. There was a bug where apps were not displayed until after a reboot (bug #9322)

Do you perhaps mean Simulator issue 452
<https://github.com/mozilla/r2d2b2g/issues/452>, which is probably B2G
bug 842725 <https://bugzilla.mozilla.org/show_bug.cgi?id=842725>? It's
been fixed in B2G since early March, but perhaps Geeksphones are using
an old ROM.

> , some people couldn't get it to work at all

I'm sorry to hear this! And happy to troubleshoot given any additional
information ((OSes, device software versions, etc.).

> and it was particularly difficult to get working on Windows because of issues with device drivers.

Indeed, both Windows and Linux are cumbersome to configure. There may be
ways to improve the experience (up to and including rewriting adb), but
unfortunately I don't know of any quick wins.

> Another common problem was with installing hosted apps where the Simulator was too picky about content types (bug #221).

Roger that, and thanks for the input. Now that I know it's a common
problem, I've prioritized fixing it for the next release. For those
following along at home, this is
<https://github.com/mozilla/r2d2b2g/issues/221>.

> The ultimate goal should be a single development environment which can work for all targets - the Firefox browser and app runtimes on both desktop and mobile - for both Gaia and third party developers.

This puts the cart before the horse. A better goal is a great app
development experience for both Gaia and third-party developers, which
may well be (but isn't necessarily) a single development environment.

> The last thing I want to mention is that it seems kind of odd that a web browser needs to "simulate" a web runtime

Note that the Simulator is actually intended to simulate a physical
device, including, but not limited to, its runtime. That's important for
both tangible reasons (it encompasses important hardware simulations
like a Home button) and intangible ones (at past events, evangelists
found that developers responded better to a more device-like environment).

> and that we package an entirely separate gecko build inside a Firefox addon. I notice that one of the items on the simulator roadmap is to try to get the simulator using XULRunner from Firefox. This seems like a desirable thing but given the number of differences in the way the B2G gecko is built and configured I'm curious to know how feasible you think this is?

I think it's feasible, but it needs further investigation. In
conversations with Fabrice (cc:ed), he highlighted two issues:

1. lack of support for a variety of WebAPIs;
2. differences in the mozApps API implementation (a special case of #1).


#1 is a war of attrition: implementing or mocking APIs one by one in
Firefox's build. There are some unknowns around exposing these
selectively to the Simulator, where they don't make sense for web sites
and desktop apps; so it might be harder than I think; but it seems
tractable with enough effort.

#2 is more complicated. mozApps is nominally implemented as an XPCOM
component (Webapps.js), which is overridable; but much of the
implementation is in a JavaScript module (Webapps.jsm), which isn't (to
my knowledge). And some consumers access the module directly. So we may
have to introduce some runtime configuration or make all consumers
access the API through a component. Nevertheless, it seems doable.

However, note that running the Simulator on top of Firefox doesn't mean
running it in the same process as the developer's regular browsing
session. That might be ideal from a UX perspective, but Gaia requires
its own profile, as will presumably many of the platform modifications
we selectively enable for it. So we'll need to continue running it in a
separate process, whether its app shell is B2G, as with the Simulator,
or a Firefox browser window, as with kgrandon's Firefox OS Runtime.

-myk

[Myk Melez]

On 2013/04/19 07:17, Luca Greco wrote:
> http://ubik.cc/DRAFTS/simulator_diagram.png
>
> As described by Myk (if I'm not wrong) we can think to evolve the
> simulator
> into a generic app manager devtool

...

> http://ubik.cc/DRAFTS/app_manager_diagram.png
>
> I think this could be a really interesting evolution of our current
> experiments on the
> FirefoxOS Simulator into a tool to develop openWebApps across the
> various available
> platforms.

Nice diagrams! And yes, this is pretty much how I'm thinking, with the
App Manager becoming a core Firefox devtool, while additional app
development features (push to device, the Simulator) continue to be
delivered as addons.

The only change I would make is mostly semantic:

The box in the diagram called B2G Desktop, which simulates a Firefox OS
device, is what I generally describe as "the Simulator" nowadays, since
it provides the actual simulation, and because it is significantly
different from B2G Desktop due to all the changes we've made to better
simulate a device (even though, at Fabrice's request, we made them all
in an addon, so technically we haven't forked).

That can be confusing, since it means that the Simulator and the addon
have the same name. But it's still less misleading than saying that the
Simulator delivers B2G Desktop, which is by now quite inaccurate. And
when the distinction is important, I say that "the Simulator addon"
delivers "the Simulator", which folks seem to understand well enough.

-myk

[Myk Melez]

On 2013/04/22 14:55, Myk Melez wrote:
>> , some people couldn't get it to work at all

> I'm sorry to hear this! And happy to troubleshoot given any additional
> information ((OSes, device software versions, etc.).

Update: some of this may have been bug 831107
<https://bugzilla.mozilla.org/show_bug.cgi?id=831107>, a breaking change
to nsIDOMTCPSocket that landed on mozilla-central last Friday just in
time to bust the Simulator on Saturday morning's Nightly builds of Firefox.

Another potential cause of problems is issue 460
<https://github.com/mozilla/r2d2b2g/issues/460>, a regression in the
Simulator that prevents the Dashboard from seeing a connected device the
first time you open the Dashboard in a given browser session.

Both problems are on our radar, and I expect to resolve them in time for
the next preview build tomorrow.

-myk

[Ben Francis]

Thanks for the information.

I was just trying the push to device feature at home and came across the
problem that I needed to add udev rules for Geeksphone devices in order for
adb devices to work.

On Linux I did:

add the following line to /etc/udev/rules.d/android.rules (need to edit as
root):

SUBSYSTEM=="usb", ATTRS{idVendor}=="05c6", MODE="0666"

Then restart udev:

$ sudo service udev restart

Then it worked. Is this documented anywhere? How about the fact that you
need adb installed at all? Do we have some getting started documentation
explaining dependencies and setup?

Ben

[Jeff Griffiths]

Currently the relevant page on the developer hub doesn't address using
devices in any way:

https://marketplace.firefox.com/developers/docs/firefox_os_simulator

I'll try and find out how to log bugs for that content.

Jeff

[Jeff Griffiths]

Ben, I've logged this bug and cc'd you:

https://bugzilla.mozilla.org/show_bug.cgi?id=864897

[Myk Melez]

On 2013/04/23 11:04, Ben Francis wrote:
> I was just trying the push to device feature at home and came across
> the problem that I needed to add udev rules for Geeksphone devices in
> order for adb devices to work.
>
> On Linux I did:
>
> add the following line to /etc/udev/rules.d/android.rules (need to
> edit as root):
>
> SUBSYSTEM=="usb", ATTRS{idVendor}=="05c6", MODE="0666"
>
> Then restart udev:
>
> $ sudo service udev restart
>
> Then it worked. Is this documented anywhere?

Not yet. wbamberg (cc:ed) is working on Simulator documentation for the
next release, which will be the first to feature "push to device".

Will: in case you aren't already aware of this, the requirement to which
Ben refers is documented for Android on the following page (which also
describes a driver requirement for Windows; Mac "just works"):

https://developer.android.com/tools/device.html

> How about the fact that you need adb installed at all? Do we have some
> getting started documentation explaining dependencies and setup?

You don't need adb installed at all, as it comes bundled with the Simulator.

-myk

[Will Bamberg]

The (very new and unreviewed) Simulator guide, current for the 3.0pre6
builds, is here:
https://developer.mozilla.org/en-US/docs/Tools/Firefox_OS_Simulator, and
it includes some stuff on setting up a device, heavily based on Ben's
bug report and Myk's comment. But because I don't yet have a Geeksphone,
I haven't actually walked through this myself, nor do I have any
screenshots for it.

Cheers

Will

[Luca Greco]

On Fri, Apr 19, 2013 at 6:40 PM, Alexandre poirot <poiro...@gmail.com>wrote:

> Thanks everyone for your feedback!
>
> Next week, I'll start filling bugs and submit patches for steps 1 and 2:
> tune webapps-actor to implement all necessary methods to build an App
> manager tool and ideally make it work on other platforms (desktop and
> mobile).
>
> Luca, I'd suggest you to wait for these bugs to be reviewed before tuning
> the simulator to use it, as it may change during the review process. I
> already expect some changes to launch request as it may land seperately
> here from a different patch that already exists:
> https://bugzilla.mozilla.org/show_bug.cgi?id=844227
> As you may have seen, I droped the adb requirement for install request,
> but I've been having various questions while implementing it, so I'm also
> expecting some modifications here.
> I'll CC you on bugs and keep you updated of any progress.
>
>

Absolutely, please CC me on the new bugs related to the app manager (just
done on the 844227)
I will do a test only to check if we'll be able to remove our extensions to
the webapps actor (e.g. run and uninstall commands from our custom
simulator actor)
once it will finally land (or if we need some more tweaks)

[Luca Greco]

On Tue, Apr 23, 2013 at 6:08 PM, Myk Melez <m...@mozilla.org> wrote:

> On 2013/04/19 07:17, Luca Greco wrote:
>

>> http://ubik.cc/DRAFTS/**simulator_diagram.png<http://ubik.cc/DRAFTS/simulator_diagram.png>

>>
>> As described by Myk (if I'm not wrong) we can think to evolve the
>> simulator
>> into a generic app manager devtool
>>
> ...
>

> http://ubik.cc/DRAFTS/app_**manager_diagram.png<http://ubik.cc/DRAFTS/app_manager_diagram.png>

>>
>> I think this could be a really interesting evolution of our current
>> experiments on the
>> FirefoxOS Simulator into a tool to develop openWebApps across the various
>> available
>> platforms.
>>
> Nice diagrams! And yes, this is pretty much how I'm thinking, with the App
> Manager becoming a core Firefox devtool, while additional app development
> features (push to device, the Simulator) continue to be delivered as addons.
>
> The only change I would make is mostly semantic:
>
> The box in the diagram called B2G Desktop, which simulates a Firefox OS
> device, is what I generally describe as "the Simulator" nowadays, since it
> provides the actual simulation, and because it is significantly different
> from B2G Desktop due to all the changes we've made to better simulate a
> device (even though, at Fabrice's request, we made them all in an addon, so
> technically we haven't forked).
>
> That can be confusing, since it means that the Simulator and the addon
> have the same name. But it's still less misleading than saying that the
> Simulator delivers B2G Desktop, which is by now quite inaccurate. And when
> the distinction is important, I say that "the Simulator addon" delivers
> "the Simulator", which folks seem to understand well enough.
>
> -myk
>
>

Indeed! and in the second diagram they we could be named "Simulator" and
"Simulator Adapter".

I'll update the graph to present the correct semantic.