On 6/19/12 4:10 PM, Jonas Sicking wrote:
I'd like to avoid having .getInstalled()/.mgmt.getAll()/.getSelf()
return App objects representing an app instance which can't be launched.
The fact that Firefox will have App objects which can't be launched
seems like an implementation quirk and not something that we should
expose to the web or expect other parties to want to standardize.

In the proposal discussed, getInstalled and getSelf do not return app objects that can't be launched.

getAll() does. It doesn't have to, but there has to be *some* function that returns app object that can't be launched.

I'm even hoping that Firefox will get to the point where we don't have
such apps either. For example by automatically starting to install apps
when they are synced (in which case the App object would indicate the
installation status). That's not something we need to figure out for now
though. My point is that I think that our non-native-installed apps is
an implementation quirk that we should keep out best we can for now.

I challenge that assumption.

Let's back up here. There are two sets of apps:

- Apps I own
- Apps I have installed on my current device

I don't think we can ever merge these two sets into one. I may have installed AutoCAD on my desktop, but I do not want it on my phone. However, I would like to to be able to see the fact that I own AutoCAD and have it installed on my desktop, from my phone.

Automatically installing all apps I purchase on all my devices does not make for a great user experience, IMO. Think of getAll() as mapping to my purchase history, across all marketplaces.

I'm happy to use some other name than getAllSynced() though. Like
getAllNonInstalled() or getAllInstallPending().

I'm pretty agnostic about naming too. The main point is we need *two* functions, one that returns all the apps I have acquired across all marketplaces, and the other function that returns all the apps that I have installed on my existing device (or, alternatively a list of apps that I *don't* have installed on my current device).

I do not think this is an implementation quirk at all. This information needs to be exposed, one way or another.

    I think the UA can optimize this step, since it knows which apps the
    user has previously acquired, a call to install() for any of those
    apps can bypass the doorhanger (we can decide whether to restrict to
    privileged domains only), but no change to the API is necessary.


Ok, so we are expecting user's to go to the store an installed the app
from there? We'd just make that flow nicer by being able to link them
directly to the relevant page in the store, and not having to prompt the
user again?

Yes, I think the act of installing an app on a new device, even if it was already installed on another device, should be an explicit opt-in by the user. We can bypass the prompt, but we should not automatically install the app on the new device just by virtue of sync.

    Also, the dashboard is expected not to display the app icons for
    apps that are not installed in the same manner as those which are.
    In our dashboard, at-least, there will be a clear demarcation and
    such apps will displayed in a "not on this device" tab much like the
    iOS store. The user can choose to install any of them on their
    current device if necessary, but there were no plans to allow
    seamless launching of these apps.


Sounds like having a separate functions for returning just the set of
apps which have been fully installed (in my proposal mgmt.getAll()) and
returning just the set of apps which are not natively installed (in my
proposal mgmt.getAllSynced/getAllNonInstalled/getAllInstallPending)
would work great for such a UI.

Agreed, returning the set of "installed" apps or returning the set of "not-installed" apps achieves exactly the same thing. We can either:

apps-installed = all-apps - apps-not-installed
or
apps-not-installed = all-apps - apps-installed

:)

-Anant
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps

Reply via email to