So I have an interesting question more or less to the high level design of using Android Libraries vs product flavors vs product variants etc.
Right now my problem is that I am trying to build a second Android application (after building my first) one where in many cases I can reuse a majority of my non UI code (IE activities, styles etc.) and reuse a small portion of the UI code.
Right now I see two different strategies, one being make a new application + Android library for the shared code (resulting in basically my POV two new GIT repos along with two corresponding projects) or take my original application and write a few productFlavor / productVariants and sort of tweak things as needed (this would allow me not to have to make two new GIT repos + project setups).
What do folks usually do in this situation?
Update:
Maybe a project with each submodule would work best as separate apps while moving the central library (shared code) to a library module.
Related
I'm searching for differences between modules and flavor.
I've read those posts:
Android difference between module vs flavor
When to use android flavours vs separate projects
But it's still a bit blur about the differences and how to choose between one and another.
So far the only differences, I manage to get out of it is:
Different structure
Modules can do everything that a Flavor does.
My first question is, what's the difference and what's so good about flavor that you don't use modules ?
Also, is flavor adapted for 2 applications where Application-1 and Application-2 share same code base (i.e. API, models, utils, service), but deviate from each other in terms of features and UI?
When to use modules:
When your project can be separated into smaller independent parts.
I've don'e this to my project, and my compile time went from 50+ seconds per iteration to less than 10 per iteration.
Because when I change code in 1 module, the others dont change and that's why the compile time is faster.
When to use flavours:
When you want to publish apps to different stores, and they need to have different applicationId
for example you want to publish to google play, and amazon store, and some other store that no one has heard of.
When you want to have part of your app available under certain build time conditions
When you want to whitelabel your app - basically it has the same logic but different UI, so in practice it is a completely different app, only... it's not.
I'm reading the source code of Android : Clean Architecture, mostly to learn how to properly organize an application into layers, and for the MVP pattern, and also to match it with what I've been reading on MVP here.
However, as pretty as I find the structure, I don't really understand the benefit of order a single application into multiple sub-projects or modules. Considering they (data, presentation, domain) depend on one another, and eventually will be part of the same executable, it looks more like configuration hell.
dependencies {
...
compile project(':domain')
compile project(':data')
What are the benefits of compartmentalizing an Android application into multiple subprojects (modules), rather than keep them in one project but separate them merely by packages?
Actually this question is not Android-specific but more software architecture related as it applies to almost any software you develop (e.g. why does any app consists of several modules and not all in one package).
Splitting the code into modules would provide you at least the following benefits (these are the first 3 that comes to my mind):
Clear isolation between the modules. The whole goal of the MVP pattern is to make sure your business logic and presentations layer are not tightly coupled together. By defining these in different modules it makes this separation more clear and encourages you to stick to this pattern.
Code reuse - consider the case where you have one application that you'd to sell for several customers, but each of these customers would like to get a different look and feel. If you'll have all of your code in one monolithic project you'll have to either have many forks of your project, one for each customer or otherwise bloat the provided app code with the customization options. Now, if on the other hand you had separated your modules, then you could just prepare a different presentation layer for each customer and bundle it with the other common modules.
Splitting your project into sub-project allows more efficient build and testing as you can rebuild and test only the modules that changed rather than recompiling the whole project whenever there's a change in one of the files.
I hope that this makes sense to you.
The main benefit of using multi-module projects, instead of just packages, is that the code usage between modules goes in one direction only.
Any code inside the module can have a back-and-forth relationship:
A -> uses classes from -> B
and
B -> uses classes from -> A
If A and B are in separate modules, this only goes one-way:
A -> (uses classes from) -> B...
But B can't see anything in A.
This splits up your thinking into smaller, bite-sized chunks. If you need to understand how a class in module B works, you only need to look at the other classes in B.
But in the first scenario, you have to look at the all the classes in both A and B.
As an added bonus, if you do want to reuse any code, you can copy that module right over to the next project.
I usually put the bulk of my code in modules, with a thin app layer connecting them all together. I recommend using dependency inversion to make any connections between modules.
Another Android specific advantage of splitting into modules apart from faster build time is that the update size of your app will be less.
I have an application A that consists of feature 1 , feature 2, feature 3. Now I want to create an application B that consists of only feature 1 and application C that consists only of feature 3.
Things I have tried
I have organized the packages according to features. Now maintaining Application A, B and C as separated projects will lead to duplication of efforts.
Android Studio
Using Android Studio I have created "Variants". I am able to get Application A, B and C as apks but size of all the apk is same i.e they contain all the code of complete project. I want Application A, B and C such that it only consists code relevant to there feature. Excluding packages while building is not supported as can be seen from this link. Am I missing something or is there any other way to customize build script for the applicatoin
Your best approach would be to separate your features (1-3) into standalone libraries that can be Java or Android library modules. In your Android Studio project, you can have more modules for applications A-C, and have them depend on the feature modules they need.
Maintaining the features as standalone libraries and keeping the different apps separated from them will probably make your code more modular and easier to maintain, so it should help you in that regard as well.
Using flavors in Android Studio to differentiate the application types would make sense if the applications are very similar and will share the majority of their code. Examples would be a free vs. paid version of the same app. If the apps are conceptually different, you'll probably find it better to make them separate app modules.
I'm working with Android Studio 0.5.8.
I have a Working project, and I want to reuse all its contents to make an almost identical app with only another name and different colors.
Basically I want to make a library from the original app and reuse it in various identical apps, but I don't want to copy & paste inside each new app, I want to maintain and develop only one codebase (the project library).
I have read and read, but I can'tt find any real solution.
I tried this in my settings.gradle:
include ':AppCopy1', ':..:LibraryProject'
It works, but I cant use any classes in AppCopy1.
This sounds like a good candidate for Product Flavors. The Gradle build system has support for maintaining a single codebase and building multiple apps from that codebase that only differ by a few files changes. See the configuration examples here: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants for details.
Im going to develop a very large scale android project, which has thousands of classes and resources. Im planning to separate application in to modules and develop them separately as library projects. Later combine them together. (Application may contain 5 - 6 modules, so planning to create 5 - 6 library projects and combine them)
Is this approach ok? or android experts, please suggest a way to maintain and develop such a big project?
Edit:
Libraries hold shared code for multiple applications -> Yes agreed 100% true
But this project is like combination of several projects.
Its like this:
Home Screen Dashboard has 8 buttons which represents 8 modules
you click on one button - > it opens up an activity and it has its own thousands of fragments, layouts, drawables etc, which is independent from other modules
so likewise i have non interdependent use cases which can be separated easily, and 4 - 5 developers are going to be involved this project, so if I can separate in to several library projects, i can simply allocate developers easily based on modules(library projects)
So one approach is to create one project and create package structure by modules
com.name.something.Module1
under this package i have
com.name.something.Module1.activity
com.name.something.Module1.util
com.name.something.Module1.widget
com.name.something.Module1.data
com.name.something.Module1.dao
and module 2
com.name.something.Module2
com.name.something.Module2.activity
com.name.something.Module2.util
com.name.something.Module2.widget
etc.
so this is first approach but each module has thousands of classes and resources, layout xml files etc.
The other approach is to separate modules as library projects.
I dont know how large scale projects maintain their codebase, like facebook, twitter etc.
Please advise.
Libraries hold shared code for multiple applications... if you are entirely focused on a single application then there's no point in separating your code into 5-6 library projects.
One common way Android developers separate their project is by making sub-packages for different components. For example, custom Views and adapter's go in com.package.name.ui, utility packages go in com.package.name.util, etc. Other than that, you just have to be smart... starting an app from scratch that will have "thousands of classes" sounds pretty ambitious and there is not really any single piece of advice that will make your life easy.
Is each module separated from each other or do they share data (e.g. the same database)? If they are separated I would suggest to create 8 separate apps, which would reduce the memory footprint of your app and would improve launch time.
If some, or all are using the same database, you might be able to create a database on the SD-card and use it from each separate app.