This topic has graduated to mailing lists so we don't have a bunch of
independent discussions about it and we're all in agreement. :)  Andrew
can answer the last question I hope so CCing him as well.

On 01/09/2013 04:45 PM, Jonas Sicking wrote:
> On Thu, Jan 10, 2013 at 12:31 AM, Wil Clouser <[email protected]> wrote:
>> As I understand it, in bug 826555 the platform is going to disallow app
>> renames.
>>
>> For hosted apps:
>> 1) This means if a hosted app changes their name, we change it in the
>> Marketplace (after a re-review) but due to #1 their app won't get
>> renamed on the phone ever
> 
> Actually, I was planning on rejecting renames from the app, which
> would mean that the app not only doesn't get renamed, it also won't
> get updated. But maybe we can add code to accept the update but change
> it such that we maintain the old name. That should be doable, but as
> we are so close to the deadline I don't want to give promises until
> the code is in the tree.
> 
>> 2) If the user wants the new name on the phone, they can reinstall the
>> app from the marketplace.  At that point, ____________.  (Where
>> __________ is either it installs alongside the current one on the phone
>> or it replaces the current one on the phone.  A question for Jonas, I
>> think).
> 
> If the user uninstalls and reinstalls the app, it will definitely
> change name. But the user will also lose all data stored by the app.
> 
> If the user reinstalls the app on top of the existing app then we
> might be able to make sure it changes name. But again, I don't want to
> give promises until we have the code in the tree. But supporting
> re-installs would require marketplace support too, right? Since
> normally we don't enable a "install" button if the user already has
> the app installed?
> 
>> 3) Regardless of whether the App on the phone gets a new name, the
>> contents of the app will change, since it is a hosted app
> 
> The contents of the app indeed will. But see above. We might not
> update the manifest which would mean that things like the icon and the
> list of permissions would not update.


>> For packaged apps:
>> 1) The phone will see the update for a new packaged app but, I assume,
>> will error somewhere along the way and never update.
> 
> Yes, that was the planned behavior. But if we change things to allow
> the update without the name-change for hosted apps, we would probably
> do so for signed apps as well.
> 
>> 2) If the user wants to ever get an update they will need to go to the
>> marketplace and install the newly named app.  This will mean they lose
>> any local data and the app _______________ (where _____________ is
>> installing alongside the existing app or replacing it.  If they share a
>> UUID, I expect it would replace it?  Again, a question for Jonas)
> 
> Same answer as for hosted apps above.
> 
>> The scenarios above sound like critically broken flows, even for a v1
>> product.  Are they incorrect or do we have alternative solutions?
> 
> I'm really not convinced that application renames is common enough
> that it's a must-have feature for v1. Do we have any data indicating
> that renames are common enough that it's must-have? Do we know how
> often add-ons change names?
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps

Reply via email to