I'm working on an Android project using Eclipse. The project contains multiple modules connecting to a central core, and it would make sense to organise them into subpackages, e.g.
com.example.myapp -- containing core classes and activities
com.example.myapp.module1 -- classes and activities pertaining to module 1
com.example.myapp.module2 -- classes and activities pertaining to module 2
and so on. Since each module cannot work independently, everything is included in a single Eclipse project.
Now, it would be great to organise the resources into separate packages as well. At the moment all of my layouts and drawables are precompiled into com.example.myapp.R.
Is there any way to organise the project so that Eclipse would automatically put resources for module 1 into com.example.myapp.module1.R etc.?
com.example.myapp.module2.SomeClass are Java package names and you can freely choose them for every class. You don't even need to start with com.example.myapp.
But com.example.myapp.R is generated from the package name defined in your AndroidManifest.xml and that is fixed since that package name identifies your app and resources belong to the app. There is as far as I know no way to split that somehow into further packages (if you keep it in one project).
However if you use library projects to include in your app it might be possible that you can have different .Rs.
Related
I have read some sample codes, I find that many project use library module structure, you can see Image A.
Could you tell me the benefit to use library module in Android Studio ?
What code do I need to place it in library ?
And More, both app and lib module use the same namesapce in the sample code, I don't know if it's suitable, could you tell me ?
Image A
Library module gives you two options to create library Android and Java.
Android library module-> Android library compiles into an Android Archive (AAR) file that you can use as a dependency for an Android app module . It allows you to add android specific components like resources and manifest file, which allows you to bundle in shared resources like layouts and drawables in addition to Java classes and methods.
Java Library -> It builds a JAR file. JAR file is useful for many projects especially when you want to share code with other platforms. But it does not allow you to include Android resources or manifest files, which is very useful for code reuse in Android projects. So when you do not need any android specific resources in library you should create a java library.
Library modules are beneficial for projects :-
When you're building multiple apps that use some of the same components, such as activities, services, or UI layouts.
When you're building an app that exists in multiple APK variations, such as a free and paid version and you need the same core components in both.
Quoted from developer.android.com
Other than that same namespace is not problematic unless you have same package name inside App and libraries . You should use a different namespace for libraries.
PS-> If you are familiar with Clean Architecture, The idea behind most of the software design pattern is Separation of concern . In Clean architecture a project is divided into multiple modules. When you implement clean architecture in android you'll see that some of the module you can create as Java library like domain module. Creating module is really useful to follow re-usability and SOLID principles and Inversion of control.
Firstly, don't look into the package name declared in the java directory. Look into the manifest file. You can see that these modules have different package name. It means that all modules in a project must have different package name.
Regarding to your question, what are the benefit of naming library module as lib?
There's no benefit at all. Some people are comfort with lib name, so they can differentiate the demo and library module easily. However, using lib as library's module name requires you to add additional configuration in the lib/build.gradle, i.e. archiveBaseName. This Gradle attribute will rename the JAR/AAR from lib.aar to work-runtime.aar, so people can use it like this:
implementation "androidx.work:work-runtime:$work_version"
If archiveBaseName is not set, people will use it like this:
implementation "androidx.work:lib:$work_version"
In real case, let's take my open source library as the example, MaterialPreference. I used to use lib name on this project, but now I think lib is not a good module name. Using materialpreference as module name will remove additional configuration archiveBaseName. So I feel it is more simple.
I have different configurations for my Android project (e.g. google, amazon). Gradle allows generating BuildConfig parameters, that can be checked at runtime, but this isn't what I am really after. I want to have a particular code (method, class, etc) to be present or absent (not just bypassed) in the project, depending on configuration.
This is how I implement that in Eclipse. I have a folder in an Eclipse project (named e.g. platform-specific), not included in BuildPath as well as several Ant scripts (make-google, make-amazon), that copy relevant files from platform-specific folder to src folder and delete irrelevant files from src folder.
Since Eclipse provides an Ant window to view all scripts, I can run a particular script and reconfigure the project to suit chosen configuration.
Is there a way to do that in Android Studio? I know that Gradle allows running and even importing an Ant script, but it isn't a convenient as with 'true' Ant, and I can't find a way to choose a script to run. Maybe Gradle provides its own way to do that?
For two flavours it will work, but if I have say 3 flavours, module 1 appears in flavours 1 and 2, module 2 in flavours 1 and 3, will it mean replicating those modules in each folder? So, every time I modify a code a such a module, I need to replicate the modification in another folder.
Not if you organize your code.
You appear to be using "modules" generically. Android Studio has a specific definition of that term (what Gradle refers to as sub-projects). And you can leverage those to help your cause.
Suppose that you create google, amazon, and yandex product flavors. Then:
Any code that is common to all three goes in src/main/.
Any code that is unique to a single flavor goes in that flavor's source set (e.g., src/yandex/).
Any code that is shared by two flavors goes into a library module that is added to the appropriate flavors using flavor-specific dependencies (e.g., yandexCompile and amazonCompile).
In all cases, there is one copy of your code. Whether it can go in the application module (e.g., app/) or goes into a library module depends on which flavors need that code. For a scenario like this, dependency injection will help you manage what code then gets wired together for each flavor.
I have an Android Studio project
which consists of a login activity with relative style, manifest, IntentService and other stuff.
I want to insert this little project in many other apps, what is the best way to proceed ?
Is Module the right way ?
The ultimate goal is still to easy maintenance, such as if one day the server should change URL, I would not have to make changes in any application that uses this login activity :-)
You need to extract these components in a separate module:
A module is a discrete unit of functionality which you can compile,
run, test and debug independently.
Modules contain everything that is required for their specific tasks:
source code, build scripts, unit tests, deployment descriptors, and
documentation. However, modules exist and are functional only in the
context of a project.
Then, include that module in all projects using it.
In fact, you can create the module in an independent "library" project of its own. And add it as a dependency for all projects using it.
Going a step further, you can publish the output of an open source library project as .aar or .jar on maven central, jcenter and other public repositories. Then other people will also be able to use your module.
Some important points to remember when creating android library projects:
The resources (strings, layouts, xmls, images) of a library will be merged with those of final project on build. Still your module's R class will stay under your module's package name.
Some attributes from manifest file of library might be merged to that of final project (like that of <application> ). So, a library module should have a minimal manifest file, with at most, the package name.
You may include an example application project inside a library module, but do not redestribute the example app project with library. It will cause trouble for someone building an application using your library.
I think that what you need to do is to export your original project first:
File>>Export
Then go to your new project and import the original one.
Dont forget to amend the setContentView() method to point to your original activity(the one you imported)
and finally dont forget your intent method!
if you have any issues let me know and i will create a detailed answer for you but i think that you will be ok!
I have two 'android application modules' in one project and they create independent apks.
But I want to combine these two modules into one hence creating dependencies between the modules so that one apk can be generated and one 'android application module' can invoke activities from another 'android application modules'.
Most of the examples suggests me to convert one 'android application module' into a 'library module' but I don't want to do that.
Document here suggests that there can exist more than one 'android application module' in one project but never could I find an example that does that.
Please suggest some ideas.
So guys I figured the right way to handle this problem.
So I created a placeholder library module under the project that had 2 android application modules and modified the build.gradle(i.e. I introduced android SourceSet objects) of that library module to point to sources(src and res folders) of the other application module that I wanted to merge into other application module.
In this way both the application module may coexist under the same project and you never have to touch your application module(that you wanted to convert to a library module).
The only difference would be that the manifest file of this library module will not be having a 'LAUNCHER' intent filter for any of its activity since an application module can not have more than one LAUNCH activities.
So this way you can still have 2 independent apks and continue to develop the applications independently and if you want to include one in the other then use a placeholder library module to point sources of the app modules.
Each application module creates a separate APK. What you may want to do is to create a library module to contain code common to both APKs and then add a dependency between them.
I am currently working on a Android Project where we are expected to merge our App with 2 more apps from vendors who wouldn't be sharing their code.So just wanted to know Is there any way we could just include there Source code as JAR Files in our project and then include their resources and point to them(I did do it using getResources().getIdentifier("splash", "layout", getPackageName()) But Its still not working ?? I think I have tried all possible methods so hoping you guys could help me with this.
To quote CommonsWare from this question:
Bear in mind that your packaged classes cannot reference resources (at
least not via R. syntax), and that JARs cannot package resources,
manifest entries, etc. If all you are trying to JAR up is pure Java
code (perhaps using Android APIs), then you should be fine.
Basically, you can only use JARs that contain pure java as libraries in your app, not entire other projects.
The Activities can be compiled into a jar and added to the main Android project and we need to add their project's resources into your Project. The only we could make it work is using the getResources().getIdentifier("splash", "layout", getPackageName()). Even the Widgets like TextView, Button and all those should be referred to using the getResources() method. Like, for example, If you want to perform a action on particular button then we need to identify them by getResources().getIdentifier("Button" /*id in the XML File*/, "id"/*type*/, getPackageName()).
One more thing: you need to specify all the Activities in your Main Android Project's AndroidManifest.xml file with their package name. I hope this solves something.
In order to support faster build times, the r16 tools are creating their own jar files inside of Android Library Projects. You can use this feature to solve this issue. If a vendor would like to release their Android Library Project but without source code, they can make a copy of that Android Library Project that contains everything except for the source code tree. Next, include the jar file from the original Android Library Porject (the one that the r16 tools built.) This will allow you to have a component you can distribute that does not require source code. The consumer of this new Android Library Project will need to manually add any necessary meta data to their own project's AndroidManifest.xml file as needed (Activities, Providers, Permissions, etc).