Allow a developer to submit demo/trial versions for apps

[Anthony Lenton]

When creating an application, a developer should be able to have an option to indicate that the application is a demo/trial version of another application already uploaded.

It's probably safe for the developer portal to expect trial/demo versions to be necessarily free (as in beer).

If the available for-purchase apps API call includes this information, USC can then present this information to the user in a friendly manner, displaying only the main application in the app list, but then providing an option to "Install demo/trial" when the user views the application's details.

[yman (s-y-schwarz)]

Rather, when creating an application, the developer should have the option, as part of the process of creating his app, to also add demo and trial versions, and perhaps alternative licensing options for the same products.

[manny (estelar57)]

should this bug also include "video demo" or "promotional videos" or it should be in a separate bug report?

[Anthony Lenton (elachuni)]

Pre-implementation discussion:

- ApplicationDemo would be a separate model, with just a ppaid, signing key, package name and a foreign key to Application "is_demo_of".
- Demos will always be free (gratis), and they should only be an option for paid (as in price > 0) apps.
- Apps with a demo shouldn't be allowed to update their price to 0 without deleting the demo first (doesn't sound like many devs would even try to do so, but still).
- Apps should be allowed to have at most one demo version.
- Demos should be a separate package that can be superseded by the full version.
- In the API, the demo can be included inlined within the application, in the available-apps-for-purchase call, as in { 'name': 'Foobar', demo: {'ppa_id': 'foo',...}, 'ppa_id': '...'}, and demo can be null.
- This stub api should be provided as early as possible, so that the client can start handling it.
- For the UI for creating a demo, you will have a "Create a demo for this app" button on paid apps details page, possibly in the calls to action on the right
- The creation workflow could probably be boiled down to a single screen for demos.

Looks like this bug should be split out into multiple bugs next

[Anthony Lenton (elachuni)]

@yman, yes, after another brief discussion we'll probably do as you suggest:

1. The first seven bullets of comment #3 still apply.
2. The UI for creating a demo will be part of the initial app submission workflow. On the first screen, where you upload the package, you'll have an option to provide a demo for the app.
3. The demo package should be mentioned on the details page in the "Your app" section, displaying just the uploaded demo package.
4. Reviewers will have to upload the demo and full versions of the app to separate ppas, so they'll need separate archive id, signing key and package name fields for each.
5. You should be able to submit an app for review even if it *only* has a demo version. This will allow devs that haven't yet completed the details for the full version of an app to still start generating a bit of hype around their app, by providing a demo.
6. If an app only has a demo version (no full version), once published the available-apps-for-purchase api call will include the details for the demo package and just leave the current package_name, archive_id and signing_key fields empty.
7. The client should be able to handle this case, by graying out the "Purchase" button, possibly giving an explanation (eg "Not available yet"), and providing a button to install the demo version.