Currently, the panel picker only displayed panels that have been registered by installed add-ons. However, we want to be able to promote panels here, especially if the user doesn't have any panel add-ons installed. As a first pass, we should prototype pulling promoted panel data from a JSON file. This JSON file should store URLs for the add-ons that correspond to the panels, and if the add-on for a panel isn't already installed, we should download it and install it. This bug is not about changing our current model of registering/installing panels.

Here's a proof of concept that's actually working pretty well. The main problem I'm running into is that the onInstallEnded listener is called before the add-ons startup script runs, so the panels haven't been registered yet. Other than that, I need to factor out SuggestedPanels into something that reads the suggestions from a file that we can update. And I wonder if we should display these panels differently than the ones that come from add-ons that users have installed separately, so that they know where these are coming from.

This is updated to actually properly wait for the new panel to be registered after an add-on is installed. This has its own problem, since it's possible the register notification we want could never fire if the add-on doesn't install a panel with the expected id, but this at least moves us in the right direction.

Friendly feedback ping... I still need to work on the file-reading aspect of this, but it would be nice to get feedback on the rest :)

Comment on attachment 8401613 [details] [diff] [review] WIP v2 Review of attachment 8401613 [details] [diff] [review]: ----------------------------------------------------------------- Sorry this took so long D: but it looks great! I wonder if we should delineate the suggested panels as ones that FF is recommending - "Popular" or, if that's not exactly true, "Recommended". ::: mobile/android/base/home/HomePanelPicker.java @@ +132,5 @@ > final PickerAdapter adapter = (PickerAdapter) mListView.getAdapter(); > adapter.updateFromPanelInfos(availablePanels); > } > > + private void selectPanel(PanelInfo panelInfo) { I think selectPanel is a little general - maybe something like handlePanelSelection? Not sure if that is better, but something that implies that more actions will be happening. @@ +158,5 @@ > + if (panelInfos.size() > 0) { > + final PanelConfig newPanelConfig = panelInfos.get(0).toPanelConfig(); > + installNewPanelAndQuit(newPanelConfig); > + } else { > + // XXX: Panel still wasn't found after add-on was installed. Should definitely log, maybe show a toast. I wonder how we can keep this suggested add-ons list up to date with AMO. ::: mobile/android/base/home/PanelManager.java @@ +116,5 @@ > + try { > + message.put("requestId", requestId); > + message.put("id", id); > + } catch (JSONException e) { > + Log.e(LOGTAG, "Failed to build event to request panels by id", e); We should have a toast here, or throw so a caller can catch and show a toast. Should we also remove the callback here? ::: mobile/android/modules/Home.jsm @@ +160,5 @@ > } > }); > })(); > > +// XXX: Get this from a file that we can update over the network. Ok, this is the same question I was thinking earlier :)

Ian, can you help us think about what promoted panels in the panel picker should look like? I think we should find a way to indicate that these are panels that Fennec is suggesting, as opposed to panels that come from any add-ons you might have installed. Also, should we communicate to users that installing a suggested panel is actually installing an add-on under the hood? I wouldn't want users to be confused about how new things ended up in their about:addons, although if an add-on is named something like "XHZ Home Panel" with a description about adding that panel, it's pretty obvious how it ended up in there. And honestly, some users may never visit about:addons. It would also be nice to have some default promoted panels that we can land in Nightly. I wonder if I could hack together some panels that would appeal to Nightly users, like the mozilla-central changelog and the FennecNightly twitter stream, just so that we can land this and test it with something. Obviously we would restrict those to Nightly :) However, it would be nice to have some default panels we could promote across all channels, mostly so that we don't need to fix bug 989430 :)

I think we should set this bug aside for now, since we removed the "Add panel" item in bug 1009586.

We're getting rid of the panel picker in it's current incarnation, so we won't need this bug. Good to have the WIP on file though, in case we want to do something similar in the future.