885636 - [HereMap] Pre-installed application cannot be updated with latest version present in marketplace

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: Consumer Pages, defect, P5)

Description

[Leo]

STR:
  1. Have pre-installed HereMap application(Version 1.8.44)
  2. Open MarketPlace and search for HereMap application(Version 1.8.61)

Expected:
  User should be asked to update the application or used should have way to uninstall old version and install the new one.

Actual:
  "Launch" option will be displayed on MarketPlace and user cannot update to the latest version.

Comment 1

[Leo]

Please let know your comments for this.

Comment 2

[Jason Smith [:jsmith]]

Sounds like this is a feature request on the marketplace side to allow a user to update an app directly from marketplace by clicking a button.

Note - this is possible to do if you check for updates manually or automatically via periodic sync and apply the app updates.

Comment 3

[Jason Smith [:jsmith]]

Here's how I'd imagine something like this could be implemented:

After marketplace calls getInstalled to find a set of apps, you would want to call checkForUpdate to find out if there's updates available. If there are updates available, you would display "Update" on the button choice to allow a user to update the app. Otherwise, "Launch" is displayed if no update is available.

If the user selects "update," you would need to call the download function in the mozApps API for that particular app. From there, you would probably follow similar behavior the stub apps do with tracking download progress on the marketplace UI until the update is applied.

Comment 4

[David Bialer [:dbialer]]

Just to check, the app will update when opened though, correct?  This is only for update within marketplace?

Comment 5

[Jason Smith [:jsmith]]

(In reply to David Bialer [:dbialer] from comment #4)
> Just to check, the app will update when opened though, correct?  This is
> only for update within marketplace?

Not opened - we don't update in that case. The current workflow for updating would be:

1. User checks for an update manually or from periodic checks
2. User finds the update
3. User selects to apply update

This use case being described here is using marketplace directly to apply the update. That should be possible to do - you just need to use the app object for the particular app already installed and allow the user to download and apply the update via the mozApps API.

Comment 6

[Wayne Chang [:wchang]]

Leo displayed this bug for me, so the update checker finds an update for here map, but after downloading, the here map version on the device remains as the old one.

Jason, are you seeing this also? or do you not get the update option prompt at all.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Wayne Chang [:wchang] from comment #6)
> Leo displayed this bug for me, so the update checker finds an update for
> here map, but after downloading, the here map version on the device remains
> as the old one.
> 
> Jason, are you seeing this also? or do you not get the update option prompt
> at all.

Yup, I'm seeing that as well. That is different than the original bug filed. Let me file a different bug for this.

Comment 8

[Jason Smith [:jsmith]]

Filed bug 886814 for the issue cited in comment 6.

Comment 9

[Matt Basta [:basta]]

The Marketplace doesn't have access to any sort of function to check for updates. Why can't the system just automatically check for updates?

Comment 10

[Jason Smith [:jsmith]]

(In reply to Matt Basta [:basta] from comment #9)
> The Marketplace doesn't have access to any sort of function to check for
> updates. Why can't the system just automatically check for updates?

As long as you can get the app object from getInstalled() (which you guys already do), you should be able to do this. See the idl below for various functions involved here that you can take advantage of on the app object:

http://hg.mozilla.org/mozilla-central/file/e681476216e6/dom/interfaces/apps/nsIDOMApplicationRegistry.idl

Such functions I'd expect you guys would use includes:

* checkForUpdate - allows you to determine if an update is available
* download - download the update if the update is found
* ondownloadsuccess - fired when the download was successful

The system can already do this, but the whole intention of this bug was to be a feature request to allow Marketplace to do this as well.

Myk and Nick built a stub app that demonstrated use of these functions here (https://github.com/mozilla-b2g/gaia/tree/master/test_external_apps/packstubtest) as a point of reference.

Fabrice would have more information on this if need be (he's out though right now until 6/29).

Comment 11

[Matt Basta [:basta]]

Checking whether every installed app has an update available when you launch the marketplace is a huge hit on bandwidth and conceivably performance for low-end devices. Plus you'll end up with a delay between when we determine that an app is installed and when we know that there's an update available.

Until we can reliably determine when the user is on wifi, I think the return from this feature isn't worth the cost (in users' bandwidth, in qa and dev time, and ux/performance), especially if the feature (i.e.: updating) is already implemented by the platform today.

Comment 12

[Jason Smith [:jsmith]]

There are ways you can reduce the network consumption here easily. If allowing an "update" button on all apps causes too much network consumption, an easy way to work around this is to do something like this instead:

* Don't check for updates by default
* On an app details page, to check and apply updates if available
* In this case, you would then consume network resources to check for updates & apply them if they are available

Note that the platform supports it (as in gecko), but only consumers of the API manage the checking and applying the update (Gaia in this case right now). Google Play does support this use case even though the system updater does check for updates as well, so I don't see why Marketplace couldn't support this use case so long as we're mindful of network consumption (there are options available to get around this).

Comment 13

[Matt Basta [:basta]]

(In reply to Jason Smith [:jsmith] from comment #12)
> * Don't check for updates by default
> * On an app details page, to check and apply updates if available
> * In this case, you would then consume network resources to check for
> updates & apply them if they are available

In order to get to the detail page, you would have seen the app in a listing with a Launch button. It's confusing to see a Launch button, then know that clicking through to the following page would produce a button that says Update.

> Google Play does support this use case even though the system updater
> does check for updates as well, so I don't see why Marketplace couldn't
> support this use case so long as we're mindful of network consumption (there
> are options available to get around this).

Google Play doesn't have to make separate network requests to check to see if there's a new version available. They also don't rely on the system to perform those checks for them and subsequently trigger the update to install. It's not an apples to apples comparison.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Matt Basta [:basta] from comment #13)
> (In reply to Jason Smith [:jsmith] from comment #12)
> > * Don't check for updates by default
> > * On an app details page, to check and apply updates if available
> > * In this case, you would then consume network resources to check for
> > updates & apply them if they are available
> 
> In order to get to the detail page, you would have seen the app in a listing
> with a Launch button. It's confusing to see a Launch button, then know that
> clicking through to the following page would produce a button that says
> Update.

Then that would mean you would include a different button on the app details page for checking for updates. Ask UX what to do here.

> 
> > Google Play does support this use case even though the system updater
> > does check for updates as well, so I don't see why Marketplace couldn't
> > support this use case so long as we're mindful of network consumption (there
> > are options available to get around this).
> 
> Google Play doesn't have to make separate network requests to check to see
> if there's a new version available. They also don't rely on the system to
> perform those checks for them and subsequently trigger the update to
> install. It's not an apples to apples comparison.

I don't agree with this analysis. downloadAvailable exposed on an app object allows you to figure out if the app has an update available. If the value is true because the system found out about, you wouldn't need to do the additional networking request to check for updates. Once you know the update available, the app update can be applied via the download API function, whether done by the system or via the app object.

On another note - I really think the technical merit of possibility of doing this isn't being analyzed effectively here, nor is the product perspective of the value of doing this. This is straight forward to implement with controlled networking resources and is alignment with what Android's Google Play store does. There really isn't any reason for not implementing this. I'd imagine a product argument that could be made for doing this is that we should be pushing users to have up to date apps as much as possible and not be running outdated apps.

Comment 16

[Wil Clouser [:clouserw]]

I'll mark this as uiwanted and we can discuss with UX and figure out the right way to do this.  In the mean time, let's focus on blockers.

Comment 18

[Matt Basta [:basta]]

This, as it turns out, is a platform bug.

getInstalled only returns apps that were installed by the origin calling getInstalled. So when the marketplace calls getInstalled, we only see apps that were installed by the Marketplace. We have no idea if HereMaps is installed on the device because the API doesn't tell us. Thus we have no way of offering the user updates.

The platform should offer a privileged API which gives access to the full list of installed apps.

Comment 19

[[:fabrice] Fabrice Desré]

(In reply to Matt Basta [:basta] from comment #18)
> This, as it turns out, is a platform bug.
> 
> getInstalled only returns apps that were installed by the origin calling
> getInstalled. So when the marketplace calls getInstalled, we only see apps
> that were installed by the Marketplace. We have no idea if HereMaps is
> installed on the device because the API doesn't tell us. Thus we have no way
> of offering the user updates.
> 
> The platform should offer a privileged API which gives access to the full
> list of installed apps.

This api is getAll(), and will be privileged soon, because we need that for 3rd party homescreens. But your issue could also be solved if HereMaps was preloaded with the appropriate installOrigin.

Comment 20

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #19)
> (In reply to Matt Basta [:basta] from comment #18)
> > This, as it turns out, is a platform bug.
> > 
> > getInstalled only returns apps that were installed by the origin calling
> > getInstalled. So when the marketplace calls getInstalled, we only see apps
> > that were installed by the Marketplace. We have no idea if HereMaps is
> > installed on the device because the API doesn't tell us. Thus we have no way
> > of offering the user updates.
> > 
> > The platform should offer a privileged API which gives access to the full
> > list of installed apps.
> 
> This api is getAll(), and will be privileged soon, because we need that for
> 3rd party homescreens. But your issue could also be solved if HereMaps was
> preloaded with the appropriate installOrigin.

It should have the correct installOrigin. We already resolved that problem with Leo, so I'm inclined to believe that Matt's argument isn't right. Back over to marketplace.

Comment 21

[Christopher Van Wiemeersch [:cvan]]

(In reply to Jason Smith [:jsmith] from comment #20)
> (In reply to Fabrice Desré [:fabrice] from comment #19)
> > (In reply to Matt Basta [:basta] from comment #18)
> > > This, as it turns out, is a platform bug.
> > > 
> > > getInstalled only returns apps that were installed by the origin calling
> > > getInstalled. So when the marketplace calls getInstalled, we only see apps
> > > that were installed by the Marketplace. We have no idea if HereMaps is
> > > installed on the device because the API doesn't tell us. Thus we have no way
> > > of offering the user updates.
> > > 
> > > The platform should offer a privileged API which gives access to the full
> > > list of installed apps.
> > 
> > This api is getAll(), and will be privileged soon, because we need that for
> > 3rd party homescreens. But your issue could also be solved if HereMaps was
> > preloaded with the appropriate installOrigin.
> 
> It should have the correct installOrigin. We already resolved that problem
> with Leo, so I'm inclined to believe that Matt's argument isn't right. Back
> over to marketplace.

If the installOrigin is correct, what else could be causing it? Can we verify on the device that that's the case. I tried adb pull'ing on a ZTE Open, but I didn't have proper read permissions.

Comment 22

[Jason Smith [:jsmith]]

(In reply to Christopher Van Wiemeersch [:cvan] from comment #21)
> (In reply to Jason Smith [:jsmith] from comment #20)
> > (In reply to Fabrice Desré [:fabrice] from comment #19)
> > > (In reply to Matt Basta [:basta] from comment #18)
> > > > This, as it turns out, is a platform bug.
> > > > 
> > > > getInstalled only returns apps that were installed by the origin calling
> > > > getInstalled. So when the marketplace calls getInstalled, we only see apps
> > > > that were installed by the Marketplace. We have no idea if HereMaps is
> > > > installed on the device because the API doesn't tell us. Thus we have no way
> > > > of offering the user updates.
> > > > 
> > > > The platform should offer a privileged API which gives access to the full
> > > > list of installed apps.
> > > 
> > > This api is getAll(), and will be privileged soon, because we need that for
> > > 3rd party homescreens. But your issue could also be solved if HereMaps was
> > > preloaded with the appropriate installOrigin.
> > 
> > It should have the correct installOrigin. We already resolved that problem
> > with Leo, so I'm inclined to believe that Matt's argument isn't right. Back
> > over to marketplace.
> 
> If the installOrigin is correct, what else could be causing it? Can we
> verify on the device that that's the case. I tried adb pull'ing on a ZTE
> Open, but I didn't have proper read permissions.

If the installOrigin is correct, then you should be able to get the apps directly via getInstalled. If you read comment 0, it indicates a "launch" button, which means that you did find the app via getInstalled. The bug here to my understanding was indicating the word "update" instead of "launch" when an update was available and then, allowing the user to update the app if they press the button.

Comment 23

[Matt Basta [:basta]]

I think the build that I've been experimenting against is wrong. I don't get a Launch button in my build; that's a different bug. Sorry for the noise!

Comment 24

[David Bialer [:dbialer]]

Getting bug 964068 in motion.  Candidate for repoman once UI is designed?