3 seems like something that's appropriate for the release build type. 1 and 2 seem like they could be differentiated by configuration. I don't know what the "demo" use case is (it could be anything from "showing around the office" to "unattended demo at a trade show kiosk"), but it could be a preference, or a menu command that lets you flip between modes, or you could prepare the device after installation by issuing an ADB command to change a value in the Sqlite database, or by dropping a configuration file somewhere in the filesystem.
If that seems like it may work, see if you can use the same mechanism to collapse 1/2 and 3 -- in the absence of the file or Sqlite value it defaults to behavior 3, and can be configured to 1 or 2 on the device. You'll have some amount of security by obscurity if users don't know how to get to 1 or 2, and it depends on whether it's a problem if they find out. Ultimately it's up to you, and it wouldn't be hard to set up a 2-3 build types for your use cases here, but I'd encourage you to find answers outside the build system first -- don't use a crowbar if all you need is a screwdriver. If you have two flavors and three build types there are six combinations to build, test (there will be *some* manual testing), and distribute. That's a lot more opportunities for things to go wrong. On Fri, Feb 28, 2014 at 9:43 AM, Diego Costantini < [email protected]> wrote: > Thanks Scott, > I know I can run the specific task (it was my second bullet point). > And I see your point in combination explosion. I actually first considered > these settings differences as flavors, but I noticed that it would be just > a small bunch of xml files on top of a lot of common code, so they were > orthogonal to the flavors, also because they "could" be used across > different flavors. > > However, as you said, I am creating complexity and I am not going to test > all of them because such settings don't require tests in my opinion. > As a simplified example, flavor1 might be assembled: > 1 - with autoUpdate setting visible and disabled (dev) > 2 - with autoUpdate setting visible and enabled (demo) > 3 - with autoUpdate setting invisible and enabled (customer) > > In this case I planned to use debug, debugDemo, release buildTypes. > But debugDemo does not apply to Flavor2. > > Would you have any pointer to achieve this with runtime configuration? > > > > On Fri, Feb 28, 2014 at 6:29 PM, Scott Barta <[email protected]> wrote: > >> The use case that was in mind when developing the "build type" concept >> was debug vs. release: debug may have extra runtime checking code, it won't >> use Proguard, it will be debuggable in the IDE, and it will be signed with >> the debug key, but it's usually functionally equivalent to the other build >> types (e.g. Release). >> >> With flavors, the intent was different versions of the app which are >> functionally different even in release versions: free vs. paid, perhaps >> something like an enterprise version vs. consumer version, etc. >> >> Having said that, you can of course do what makes sense to you, and in >> practice build types and flavors are similar concepts and allow similar >> types of configuration. But if you find yourself wanting to have >> sub-flavors inside flavors, it might help to take a step back and look at >> what you're doing to see if there's an easier way. You talk about a >> "predefined set of preferences" that differ in some of your sub-flavors; >> perhaps you could differentiate these via runtime configuration instead of >> making separate variants. If you have too many build variants, it will make >> your development and testing really tough as the number of combinations >> explodes. You'll help yourself out by restricting flavors to cases where >> the code or resources really need to be different, and making the decision >> at runtime just really doesn't work. >> >> When you're running the Gradle commands from the command line, you can >> specify which variant they act on. Instead of: >> >> ./gradlew assemble >> >> you can use: >> >> ./gradlew assembleFlavor1Debug >> >> etc. You can see the possibilities via: >> >> ./gradlew tasks >> >> >> On Fri, Feb 28, 2014 at 9:14 AM, Diego Costantini < >> [email protected]> wrote: >> >>> The question seems very generic but I have a concrete (corner?) case in >>> mind. >>> >>> I have 3 flavors and I test them in Jenkins with some default settings >>> which are good for us developers. >>> However, when I want to release them, I want different preferences for >>> the user, sometimes even more than one kind per flavor. >>> For this, I created different buildTypes, let's say for example that I >>> want Flavor1-ReleaseFlavor1 where I use a predefined set of preferences. >>> In this case, the build type ReleaseFlavor1 is specific to Flavor1, and >>> when generating the tasks, I would have many meaningless combinations like >>> Flavor2-ReleaseFlavor1. >>> >>> Now, related to the topic question: >>> - is it ok and I should just ignore those builds when running assemble? >>> -> big waste of time waiting for the extra meaningless builds >>> - should I avoid running assemble? -> I lose a quick way to build all >>> the variants I might need >>> - is there a way to filter out undesired combinations? -> this would >>> make sense >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "adt-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "adt-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/adt-dev/Z26wxPc7OKs/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "adt-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
