892397 - Get rid of HIDDENAPPS in favor of manifest field

Status: RESOLVED FIXED

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

Description

[Jan Jongboom [:janjongboom] (inactive)]

At the moment the list of apps that aren't shown in the homescreen are hardcoded in the HIDDENAPPS field. However there might also be a requirement for installable applications to not be shown on the homescreen, f.e. an auth provider that only makes sense when being called from an activity. A user can always still uninstall an application by going into Settings.

Comment 1

[Jan Jongboom [:janjongboom] (inactive)]

Attachment: Patch

This moves the responsibility of hiding apps to the manifest files of the apps themselves.

We're adding a field to the manifest so that might be an undesired change. The code in settings/ that is removed is no longer necessary. If an application is not certified, it'll always show up in the settings, if it's certified, only when it has permissions that can be set.

Comment 2

[Cristian Rodriguez (:crdlc)]

AFAIK the grid component implemented your approach six months ago although for some reason related to security, authors cannot decide if an app belongs to the layout or not. Actually, I don't remember why it because I didn't attend the discussion. I am sure that Vivien has more info about it. I guess that for this reason it will be r- but I want to wait for his opinion

Comment 3

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 773856 [details] [review]
Patch

I don't believe apps should be able to hide themselves with a manifest field. It seems to me that the common use cases for an application is to be launched by the user. 

The problem you are trying to resolved needs to be thinked the same way than themes or keyboards. How are we going to install those without having them on the homescreen?

For example I would be more open about using the 'category' field in the manifest and said that |category: [keyboard|theme|service]| should not be displayed.

Then marketplace would put those in a specific category and will be able to display the right warning to the user.

Let's see what Fabrice thinks about it.

Comment 4

[Jan Jongboom [:janjongboom] (inactive)]

For keyboard we're currently not going for an extra field (at least that's the idea) but rather rely on the keyboard permission being set. Might need to rethink this in broader perspective.

Comment 5

[Jason Smith [:jsmith]]

Note - we do have a categories property implemented as an attribute in the mozApps DOM API.

http://hg.mozilla.org/mozilla-central/file/5e191a26d909/dom/apps/src/Webapps.js#l137

Marketplace right now provides a second parameter on every install of an app that indicates the respective marketplace category the app was installed from.

That said, it might make more sense to put this in the app manifest rather than a secondary parameter in the options dictionary during install of an app.

Comment 6

[[:fabrice] Fabrice Desré]

The 'categories' field's purpose is not really a good fit there. It's an installation parameter, and once the application is installed, it's not exposed by the api - at least for now. And the semantic is to use the category as a user filtering/grouping mechanism, not some technical switch.

I feel that using a a manifest field would be better, but we would have to name it differently (yay for bike-shedding). Maybe something like "kind" or "role"...

Comment 7

[Jan Jongboom [:janjongboom] (inactive)]

+1 for `role`. "role": "service", "role": "keyboard", etc.

Comment 9

[Evelyn Hung]

(In reply to Jan Jongboom [:janjongboom] from comment #7)
> +1 for `role`. "role": "service", "role": "keyboard", etc.

So Fabrice agrees using 'role' is okay for now.
:janjongboom, will you have a follow-up patch here? Thanks.

Comment 10

[Jan Jongboom [:janjongboom] (inactive)]

I have added three roles here, 'service', 'keyboard' and 'homescreen'. Homescreen isn't really needed yet, we can use service there as well.

Comment 11

[Jan Jongboom [:janjongboom] (inactive)]

Renamed service -> system. Will rebase when r+'ed.

Comment 12

[Jan Jongboom [:janjongboom] (inactive)]

Landed in https://github.com/mozilla-b2g/gaia/commit/92d85bffa14c2334be8008ab0232e101f9033e06

Thanks Fabrice for the insanely quick feedback loop :-)

Comment 13

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Jan Jongboom [:janjongboom] (PTO until 7/28) from comment #10)
> I have added three roles here, 'service', 'keyboard' and 'homescreen'.
> Homescreen isn't really needed yet, we can use service there as well.

I'm a bit worried about having 'role' as a new 'field' in the manifest without talking to the standardization guy :( 

This is why I suggested 'category' at first but let get others opinion on this.

Comment 14

[[:fabrice] Fabrice Desré]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #13)

> This is why I suggested 'category' at first but let get others opinion on
> this.

Since there is no 'category' field in the manifests currently, I don't understand how this is better. Did you read comment 6?

Comment 15

[Marcos Caceres [:marcosc]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #13)
> (In reply to Jan Jongboom [:janjongboom] (PTO until 7/28) from comment #10)
> > I have added three roles here, 'service', 'keyboard' and 'homescreen'.
> > Homescreen isn't really needed yet, we can use service there as well.
> 
> I'm a bit worried about having 'role' as a new 'field' in the manifest
> without talking to the standardization guy :( 

Standardization guy here: `role` makes sense to me.
 
> This is why I suggested 'category' at first but let get others opinion on
> this.

I agree that `category` is not the best match here.

Comment 16

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Fabrice Desré [:fabrice] from comment #14)
> (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #13)
> 
> > This is why I suggested 'category' at first but let get others opinion on
> > this.
> 
> Since there is no 'category' field in the manifests currently, I don't
> understand how this is better. Did you read comment 6?

My bad, I'm pretty sure category was part of the initial manifest draft back in 2011, isn't it? I think I'm becoming too old...