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.
Related
My desired end result is to have a Project that can output different productflavors of Mobile, Tv, and Wear apps, that share the same code-base. So I would like the codebase to be a dependency for all three app-types, where each app module would only contain activities and interaction with the codebase.
My first idea was to add a "Android Library Module" to my newly created project, but I noticed that this is really just a new app module with its own resources and everything. I would like the codebase to function more like a "Java Library", but it needs access to packages like "android.graphics.Color".
So in short, is the correct way of achieving this result to use a java library that has a reference to an android sdk or am i just going about this the wrong way?
Continuation of this question at:Does an Android Library need a manifest ,app_name,Icon?
There's no in-between. If you want access to Android APIs, then the library needs to be an Android library so that the build system can properly link it in to dependent projects. It's true that Android Libraries have resources and other things you may not need, but you can ignore those bits and treat it essentially as a plain Java library if you wish. Even if you're not using resources, you may find useful the ability to specify AndroidManifest.xml attributes to be merged into the dependent app.
The Android Library project doesn't build a fully-fledged APK as its output; it generates an AAR, which is conceptually similar to a JAR archive, but has resources and meta-information useful to Android projects.
Supplemental answer defining terms
The Android Studio documentation defines a module as follows:
A module is a collection of source files and build settings that allow
you to divide your project into discrete units of functionality. Your
project can have one or many modules and one module may use another
module as a dependency. Each module can be independently built,
tested, and debugged.
So basically a module is a subproject in your bigger project.
Types of modules
Android app module - The app module is usually what you are working with in a normal project. When you compile it you get an APK file that will run on a device. Here are the different types of app modules that exist:
Phone & Tablet Module
Android Wear Module
Android TV Module
Glass Module
Library module - The purpose of a library is to share code. For example, you could have a project with a couple different app modules. The common code that they both use could be located in the library.
Android Library - In addition to Java code, this allows you to also include Android resource files and a manifest. If you are making an Android project and are wondering what kind of library to use, then choose the Android Library. When compiled it creates an AAR (Android Archive) file.
Java Library - This only allows you to include Java code files, no Android resource files. This is useful for cross-platform code sharing. When compiled it creates a JAR (Java Archive) file.
Google Cloud module - This type of module is the Google Cloud backend for communication with your client side app.
One additional point that I've not seen well documented: An android library module can have a dependency on another android library module or java library module, but a java library module cannot have a dependency on an android library module.
I have started working on a project where I will need to share a bunch of Java classes across a bunch of apps. In Eclipse it was possible to create one project with all such classes and use it as a library in a workspace with all your dependent projects, but in Android Studio it doesn't seem possible to do so (At least not easily).
I have been reading a bunch of posts and a lot of them suggest setting up a library project, generating an aar file and then using that in my projects. But, as I understand it, this will make my library open-source (Am I right?), which I don't want. I am doing this for a client and I want the code base to be private.
Also, I know that a module can be imported into a new project. But this creates a COPY of the original module. This is not what I want at all. I don't wanna maintain multiple copies of the same classes, which completely defeats the purpose of 'code sharing'.
Is there any good way of achieving what I am looking for? Any help is appreciated.
You have a couple different options.
One option is to maintain your libraries as separate projects and compile them to an archive format, such as JAR or AAR; JAR files are for pure Java libraries, and AAR is for Android libraries (which contain code that accesses Android APIs and/or has Android resources). As was pointed out in the comments, AAR doesn't force you to publish your code to the world any more than JAR files would; it's just an archive file format whose files can be local to your machine or your organization.
With that archive file in hand, you can include it in other projects. If you're part of a multi-developer organization, you may find it convenient to use a repository manager to publish and maintain those libraries within your organization, and you can use Maven coordinate-style specs to include libraries in your projects, which you don't have to manually copy over to your development machine.
The disadvantage of this approach is that it makes it a little harder to make changes to those libraries: you need to load up the project, make changes, build an archive, and distribute the archive.
The other approach is to keep the library as a source module like you did in Eclipse. You observed that Android Studio will make a copy of the module if you import it via UI, but if you bypass the UI and modify the build scripts directly, you can do what you want, which is to use the module in-place and share a single copy among multiple projects. To do this, work in your settings.gradle file and add this:
include ':module_name'
project(':module_name').projectDir = new File(settingsDir, '../relative/path/to/module')
I would strongly encourage you to not use a pure relative path here; in this example, the path is anchored to the settingsDir variable supplied by Gradle, which is defined to be the directory where settings.gradle is found. If you use a pure relative path (i.e isn't anchored to anything), you're dependent on the working directory being the same in all environments where the build file is run (command line vs. Android Studio vs. CI server), which isn't a good thing to assume.
You need to think in the eclipse projects as Android Studio/IntelliJ Idea modules. Then, you can generate android (or java) libraries and then include them in your project.
To mark an Android Studio module as a library you can go to File -> Project Structure -> Facets and there click on Library Module
I was in same situation as you, and i founded an approach using git.
Steps to do, to have library:
Create project in Android Studio.
Create android library module in that project.
In that library module create git repository.
Add modulename.iml in .gitignore file
Use GitHub or Bitbucket for private cloud repository. and push your library to it.
Create new android library model in any project that you want.
Close Android Studio (not sure is that mandatory).
Using explorer go to your created module folder.
Remove all data in it, except modulename.iml.
Clone your library from "GitHub" into it.
That's all.
Now you are able to use library in multiple project whether you are at home or at work. Just after finishing you work not forget to push library changes. And after opening new one pull them.
I think you can automate this thing somehow.
The benefit is that you don't need to build any jar, or aar.
You can certainly create and use a library without making it open source or available to others.
First, you don't need to make it an aar unless it contains Resources.
If it's just plain classes, you can just make it a .jar file.
Either way, the easiest way to share these libraries (either aar or jar) is to set up your own repository. Nexus and Artifactory are the two most common repository managers.
You keep the library in its own project, and then publish it to your own, in-house repository.
Then, projects that need to use the library are configured (in gradle) to use the in-house repository, and get the library from it.
I have an Android code base which uses APIs with settings to get different data for several apps. All apps use the same code base but with one or two design tweaks. So how do I re-use the main code base without having to copy the whole Android project each time?
iPhone uses multiple targets in the same project which works well. If android cant do this do I need to compile binaries of the code base in one project and then import into each new app project? If so how? I'm using Eclipse and am an intermediate Java developer.
Any help much appreciated!
Doug
Check out "Working With Library Projects" from the Android documentation. This should be just what you're looking for: http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject
The current way to approach this issue if you are using Android Studio with Gradle is by using Gradle, Build Type + Product Flavor
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
Build Variants
One goal of the new build system is to enable creating different versions of the same application.
There are two main use cases:
Different versions of the same application
For instance, a free/demo version vs the “pro” paid application.
Same application packaged differently for multi-apk in Google Play Store.
This new concept is designed to help when the differences are very minimum. If the answer to “Is this the same application?” is yes, then this is probably the way to go over Library Projects.
Note: This answer is basically obsolete now that one can create .aar libraries with resources. It still works, though, and there may be times when the portability of a .jar is desirable, so I'm leaving it here.
Blumer's answer is a good one, and you should definitely look into Android's idea of library projects. However, there is another alternative. If you have a module that contains only Java code, but no resources of any kind (images, layouts, etc.), you can compile it to a .jar file separately and use the resulting .jar in multiple application projects. It works like this:
Create a new Java project in Eclipse (not an Android project) and move the source code of your module there.
If your module references any classes from the SDK, you'll need to add the Android SDK .jar to the project's classpath (Project > Properties > Java Build Path > Libraries > Add JAR).
When your module is ready to use, bundle up its .class files into a .jar. You can do this manually, or you can look around to figure out how to get Eclipse to do it for you.
Copy your module .jar file into the "libs" directory of your app's main project.
Add the module .jar to the project's classpath (again, Project > Properties > Java Build Path > Libraries > Add JAR).
Now you should be able to build multiple apps using the same .jar, while maintaining only one copy of the module's source code.
Depending on your particular situation, this may or may not work any better for you than the standard Android library mechanism. But it's worth considering as an alternative.
The Android documentation recommends another approach if there aren't too many "different APIs" used.
The idea is to use reflection instead of making direction references to the code. Make sure to use optimized reflection instead of lookups every time.
References
http://developer.android.com/training/multiple-apks/api.html
http://developer.android.com/google/play/publishing/multiple-apks.html#ApiLevelOptions
You might want to consider using a source control system like Subversion (or GIT). Keep your most feature complete version in the trunk, and make branches for your separate versions that use different data sources or require minor layout changes, etc.
I have a public transport app for one country and I want to create a separate app for another country. Most of the code will be shared, but I need some classes to have different implementations for example TransitProvider.
Is it possible to share code using Android Library Project? Can I do the following?
Have TransitProvider (that extends
AbstractTransitProvider) in the
library project. The class has methods left unimplemented.
In application project > AndroidManifest.xml I have different package name than in library's manifest. I have also TransitProvider in this project, that is in the same package as the library's TransitProvider.
When I use TP in library project code, the implementation from app. project should be used (ie application project's TP overrides library's TP).
Is it possible to share code using Android Library Project?
Yes. That is the primary purpose of a library project. If you do not need Android resources, you can also use an ordinary JAR, created in a separate project.
Can I do the following?
You cannot have the same class (in the same package) defined in two places, if I understand your proposed steps properly.
You should:
Define AbstractTransitProvider in the library project or JAR
Optionally have one or more concrete implementations of AbstractTransitProvider, for straight-up reuse, in the library project or JAR
Apps using the library project or JAR can have their own concrete implementations of AbstractTransitProvider, in their own Java packages, in addition to using any concrete implementations supplied by the library project or JAR
I'm pretty new to Android development, but I have some experience with Java and Eclipse. I'm looking for ways to create re-usable libraries (controls, helpers, "standard" activities, etc.) that I could use in my own projects, but that could also be distributed to other developers without disclosing the source code.
Normally, I'd package the class files into a JAR file and any other developer could add it to the classpath and use the packaged classes.
How can I do that with Android projects? I've read about Android Library Projects, but as the documentation states they can not be packaged into a JAR, but will be compiled along with the project that references the library project. This means I also have to distribute the source code.
I've also read this post, which asks about the same question but didn't provide a satisfying answer.
So: Is there a way of compiling and packaging a set of classes and other files (including XML layouts, resources and stuff) and distribute only that package without any source codes so that it can be "referenced" and used like a JAR file by any other developer?
I've read about Android Library Projects, but as the documentation states they can not be
packaged into a JAR, but will be compiled along with the project that references the library
project. This means I also have to distribute the source code.
Not true. It does require a bit of extra packaging work, but you can compile your code to a JAR and distribute the JAR in the library project's libs/ directory.
So: Is there a way of compiling and packaging a set of classes and other files (including
XML layouts, resources and stuff) and distribute only that package without any source
codes so that it can be "referenced" and used like a JAR file by any other developer?
Use an Android library project. I have some stuff written up here that describes a bit more of the packaging options, plus pointers to some "parcels" that follow the conventions described therein.
Thanx for your solution. From what I understand, you still can not access the resources private to the library from within the libary code. So assume your library has a string resource named "my_lib_resource" under res/values in the library. You bundle this in the jar along with the source code. Can you access this resource from the library source code using something like:
int id = res.getIdentifier("com.example.mylib:string/my_lib_resource",null,null)
assuming your library package name is com.example.mylib.
For me this does not work.
Brave new world of dependency management:
http://tools.android.com/recent/dealingwithdependenciesinandroidprojects