I have two modules in my android project. And I want both of these modules to access the layout files of other module and perform operations like Intent().
But, Using compile project (':x ') is not working for this.
Edit:
Both the modules are successfully added into the project and gradle was synced properly and manifests are merged. I want to how to access res/layout files of one module from another module's java file.For context, I have activityA.xml in module 1 which I need in module two so that when a button is clicked in module 2, it transits to ActivityA.xml with intent.
ok so to use resources from another module you must do a few things.
Determine how you will package and use your module. Is the module "just" for this app or is it used in others.
If it is used by more than one project then I recommend packaging it as an AAR and hosting in a Maven Repo of your own and pulling via Gradle to avoid project dependencies on the code base itself.
If it is only used by this project then you must do a couple things as well.
1) Ensure that the settings.gradle has the module included. You can do this with simple :moduleName if it is local to the project directory. Otherwise you can do it with
include 'myLib'
project(':myLib').projectDir = new File('../../../workspace/libs/myLib')
Once you have done this confirm Gradle Sync pulls the module into the project. And not just an empty folder with an IML. If it is an empty folder confirm your path and try again.
Step 2) So you successfully imported your module and you can see it in your directory. However, you can't have a module depend on the app and the app depend on the module. It is called circular dependency, so you must only have the app depend on the module. Go to your app's module the one where it has
apply plugin: 'com.android.application'
and go to the dependency section and include
compile ':myLib'
Now you need to confirm your compile myLib is working (myLib is the name of your lib). To confirm you can do an assembleRelease from the terminal and see if it has any issue or you can do a Gradlesync as well.
If it worked you can now import resources or files into any Activity of the parent app module by simply including the import statement at the top.
Now you can do things like HelperClass.doSomething (where helperClass lives in myLibs).
So let's take it one step further. Maybe you need HelperClass to be able to respond to the app module. Then you must supply an interface inside the myLib of IMyCallBack with whatever methods you would call out to and have the parent module calling activity implement the interface for calling back.
Does this answer your question or are you having another issue. A there should be no issue accessing the content of your child module if your dependency is setup correctly.
Related
I created a custom Lint check and want the check applied to all dependent modules in my Android project. The custom Lint check lives in the checks module, and I can successfully run it in other modules by adding lintChecks project(":checks") to their respective build.gradle files. What I'd like to do is add something similar to api <dependency>, so all dependent modules also run the check. There is a core module already serving the purpose for other functionalities. Is there an API or configuration to prevent lintChecks redundancy? Such that all I'd have to do is add lintChecks project(":checks") to the core module.
I did not create an IssueRegistry file in the correct directory, resulting in Gradle not showing the task. Found out lintChecks in build.gradle files was never necessary.
Say I have two modules. Module A and Module B. Lets assume Module A is my app module and I have a library dependency called myLib which has a class called LibClass, Say I find my self needing to reference LibClass in Module B.
What is the recommended approach to do this? I am currently adding myLib again as a dependency in Module B that way I get a reference of LibClass in Module B.
I'd like to achieve this without needing to declare the library twice in Gradle (For Module A and Module B).
I also have a feeling this approach may be problematic.
Is there an effective way to go about it?
You can handle both as separate modules (folders), each with their own build gradle file.
if you want to reference the lib (Module B) to the app (module A) add
implementation project(':your-lib-module-name');
to have both in the file explorer/editor, create a settings file with the code
include ':your-module-name'
project(':your-module-name').projectDir = new File(rootDir, 'Library-name')
Note that you can't reference module A to module B, and Module B to module A at the same time, because will cause a circular reference.
How can I access Activity from AAR library which is not directly included into the project but is embed to another AAR library?
I got an error java.lang.NoClassDefFoundError: Failed resolution of:
The class is public and if I compile it directly in project application it can be used without problem.
I included an AAR to my project like this :
ProjectApplication
|
+--sharedModule (android library - AAR or any working solution)
| |
| +--Module1 (android library - AAR or any working solution)
| |
| +--Module2 (android library - AAR or any working solution)
| |
| +--Module3 (android library - AAR or any working solution)
compile (project(":sharedFrameWork")){ transitive = true }
which has also included in itself 2 other AAR libs. They are also set to be Transitive. When I try to open an activity from one of the sub AAR libraries. I got the class not found error. But when I include that particular AAR into my application directly the class is found and can be used. It looks like I do not have access to any sub AAR libraries which are not included directly into my Application.
To better describe my situation :
I have to create an integration AAR library (later called 'sharedFrameWork') which includes multiple AAR libraries and is later embed into an application.
Multiple AAR -> Shared AAR 'sharedFrameWork' -> Application
The sharedFrameWork has some method which starts some activities from the included AAR's or set up basic communication with the server. I have read that if all the dependencies are set to be transitive it will make it work, but unfortunately it does not.
So When I call from my application a method which should start an activity from one of the included AAR in sharedFrameWork the app reports me that no such a class was found.
But when I include that AAR module right to my application not to sharedFrameWork, and then call the exact same functionality the Class is found and the project is working as it is designed. Can you help me how can I create this sharedFrameWork to be working as it is designed? Can it be done by using AAR or should I take another approach? If any other way it can be done and the result will be that I can deliver just one library and it will work as designed so it can access its submodules I will go with it, feel free to point me out the best approach for this problem.
If I get it right, you want to create a fat AAR and achieve a single import of several libraries.
Now, since you haven't provided more info, I'm going to assume you are using gradle 2. In gradle 2, submodules don't share their dependencies. neither does anything you put into the libs folder. So, first, I would upgrade your projects to gradle 3, switch from "compile" command to "api" command, and check.
If that does not work, the next step would be to apply the gradle maven plugin to each one of your modules, and deploy the resultant AAR file to either your local maven repo (automatically created when you install maven), or a remote repo, like jitpack. If you have AARs/JARs into the libs folder, deploy them to a repo too and import them from there (libs folder scope is local in gradle 2, and in general, is a bad idea to use it instead of a centralized repo. You can even use github as a repo). Then, use the artifacts.
Finally, the last solution for your problem would be to use "shading"; the process to pack several different artifacts into one. If you can't upgrade to gradle 3, or deploy the artifacts somewhere (unlikely), this is what you should do. There are several plugins for this:
https://plugins.gradle.org/search?term=shade
https://github.com/zawn/android-shade-plugin
if those don't work for you, switch to maven and use the maven shade plugin.
As a side note, you should not provide a fat AAR. Is better to keep your framework in separate modules. That will speed up your build process and allow you to save space if you don't require some classes. Even in a multimodule project, you can create separate artifacts, one for each module, and import them as you need. Just avoid circular references (a module A that requires a module B which requires module C which requires module A) and you'll be fine.
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.