Titanium JIRA Archive
Alloy (ALOY)

[ALOY-680] add compiler directives to distinguish between ad-hoc and app-store distribution

GitHub Issuen/a
TypeNew Feature
PriorityLow
StatusClosed
ResolutionFixed
Resolution Date2014-02-05T23:11:33.000+0000
Affected Version/sn/a
Fix Version/sAlloy 1.4.0, 2014 Sprint 03
Componentsn/a
Labelsnotable, qe-testadded
ReporterDaniel Sefton
AssigneeTony Lukasavage
Created2013-05-31T16:26:53.000+0000
Updated2014-05-19T09:14:48.000+0000

Description

It would be nice, if it would be possible to programmatically distinguish between ad-hoc and app-store distribution. So like the other environment compiler directives: ENV_DEV ENV_TEST ENV_PROD it would be nice to have something like: DIST_IOS_ADHOC DIST_IOS_APPSTORE also see Q&A: http://developer.appcelerator.com/question/152765/alloy-is-there-any-way-to-have-conditional-code-distinguishing-between-ad-hoc-distribution-and-app-store-distribution

Attachments

FileDateSize
app.zip2014-01-27T15:52:39.000+00003835821

Comments

  1. Fokke Zandbergen 2013-11-21

    Yes yes yes, want this! Also would like to have them available in config.json so I can set different API keys for stuff like TestFlight, push and backends.
  2. Malcolm Hollingsworth 2013-11-21

    This is one of those things that really hits a specific need - whilst it will not benefit everyone - the power users really need this sort of thing.
  3. Tim Poulsen 2014-01-27

    Goal is for an app like the attached to output ad-hoc values when built from Studio or CLI as an Ad-Hoc build. Proposal that the config.json value would be ENV_ADHOC because ad-hoc is a type of a production build -- you can do a production build for the App Store *or* Ad-Hoc, but not both. So, there's no need to have to set both ENV_PRODUCTION and DIST_TYPE=adhoc to identify an ad-hoc build.
  4. Fokke Zandbergen 2014-01-27

    As long as an adhoc build also has ENV_PRODUCTION true I'm fine with it.
  5. Tony Lukasavage 2014-01-27

    Yep, ENV_ADHOC will also set ENV_PRODUCTION and ENV_PROD
  6. Fokke Zandbergen 2014-01-27

    And then there should be ENV_STORE of course
  7. Tim Poulsen 2014-01-27

    Why? If the default of ENV_ADHOC is false (as it is for any of the values), simply testing for ENV_PROD should be sufficient. What am I missing?
  8. Tony Lukasavage 2014-01-27

    We were going to have that be implied with ENV_PROD is ENV_ADHOC was not true. This is making think that developers should have access to make compiler conditionals on any value from the CLI they choose. Unless you have a strong objection [~fokke] we will likely leave this ticket as defined and just account for ENV_ADHOC, but another ticket for giving access to the data in the alloy hook that comes straight from the CLI might be beneficial, heading this problem off before it occurs again.
  9. Fokke Zandbergen 2014-01-27

    So if I want to target code for App Store only I need this? 
       if (ENV_PRODUCTION && !ENV_ADHOC) {}
  10. Tim Poulsen 2014-01-28

    Your build target (app store or adhoc) is decided by the CLI and passed to Alloy as a parameter. ENV_ADHOC will be true only for ad-hoc builds. ENV_PROD will be true for both app store and ad-hoc builds. config.json: * settings in ENV_PROD will be applied in both types of builds * settings in ENV_ADHOC will be applied for only ad-hoc builds, and would override settings in ENV_PROD compiler directives in controllers: * if(ENV_PROD) {} // would run in both app store and ad-hoc builds, though obviously you'd do one or the other type build * if(ENV_ADHOC) {} // would run in only ad-hoc builds if build type is ad-hoc * if(ENV_PROD && !ENV_ADHOC) {} // would run for only an app-store build * if(ENV_ADHOC && !ENV_PROD) {} // wouldn't run
  11. Fokke Zandbergen 2014-01-28

    Well, I dont find that very logical, but I guess it will do
  12. Fokke Zandbergen 2014-01-28

    My final attempt to talk you out of (only) ENV_ADHOC: - Targeting App Store using ENV_PROD && !ENV_ADHOC is like using !OS_IOS to target Android. It requires people to know about all options and how they relate. - As it is now both OS_ and ENV_ have only one of them true at the same time. I would keep it that way. - I don't know of any other OS or language where two types of ENV (environment) can be true at the same time. - AdHoc and AppStore are no environments, they are two ways to distribute. I would strongly advice to go with both DIST_ADHOC and DIST_STORE and make the second one TRUE both both dist-appstore and dist-playstore targets.
  13. Tony Lukasavage 2014-02-05

    implementation

    * *DIST_ADHOC* - will be true when the iOS build target is "dist-adhoc" * *DIST_STORE* - will be true when the iOS build target is "dist-appstore", or the android build target is "dist-playstore"

    code

    PR: https://github.com/appcelerator/alloy/pull/329 test app: https://github.com/appcelerator/alloy/tree/master/test/apps/testing/ALOY-680

    functional test

    This should be executed for all of the following. The "deployType" for all will be "production", the "target" is shown in the parens next to each: * Android playstore distribution ("store") * iOS adhoc build ("adhoc") * iOS itunes store build ("store")

    Execute one of the build process mentioned above on the test app

    While you could do the entire packaging, and easier way to test would be to abort the build process after the alloy step completes and then inspect the generated code.

    Go to "Resources/PLATFORM/alloy/controllers/index.js"

    Check the end of the generated code where the "deployType" and "dist" variables are assigned.

    Confirm that the strings assigned to those variables match what you would expect, as noted in parens next to each build type above.

  14. Fokke Zandbergen 2014-05-19

  15. Malcolm Hollingsworth 2014-05-19

JSON Source