Android resources and their automatically generated references simplify the development of one app a great deal. But they also complicate the reuse of Android activities in multiple projects, and in general of any component that uses resources.
Library projects are a limited alternative. A project can depend on many library projects, but a library project can't depend on another, and adding additional JAR dependencies is not straightforward.
How do you reuse Android components (not plain old Java code)? Any tips and tricks?
I have some tips, tricks, and tools wrapped up in the Android Parcel Project.
Related
We use Xamarin Forms and I have been tasked with integrating a 3rd party AAR library from a business partner and I don't have control over the library or its dependencies. This library itself is distributed using Maven, which works great in Android Studio but is a pain in Xamarin, and it has many dependencies on both libraries that are standard in Android as well as other proprietary libraries.
Since I only need to interact with a small portion of the public API of the main library, I've created an Android library (AAR) wrapper project in Android Studio that only exposes the functionality I need and does not use any types that do not already have bindings.
I have created an Android binding project against the AAR wrapper library, and it compiles in Visual Studio without any warnings or errors.
I've created bindings for other libraries in the past and have the Xamarin binding documentation multiple times and searched online, but the part I'm missing is how to include the required/reference JAR/AAR files in the compilation process and the final Android application. Most of the standard libraries that I need already have NuGet packages (Androidx, Google Play Services, etc)., but the binding library compiles without complaint - so how do I include the other required libraries?
Do I really have to create a binding project for each required AAR/JAR and add as a reference? I don't need to interact with the types or resources in these libraries directly from Xamarin since I only interact with the the types/methods exposed in the wrapper AAR (e.g. I don't think I really need a Xamarin binding). Is there a way to simply have Xamarin process the required AARs and JARs without creating a Xamarin binding project for every library that doesn't already have a NuGet package? There are many many dependencies which makes this theoretically possible, but not in practice. There must be an easier way...
I noticed there is an AndroidLibrary build action that the documentation says can be used to directly reference an AAR/JAR file in a Android application, but I can find no examples of how to use this in practice. What does this build action do? How is it supposed to be used? https://learn.microsoft.com/en-us/xamarin/android/deploy-test/building-apps/build-items#androidaarlibrary
Thanks in advance for any help or direction on the best way to do this.
I am currently working on Android library project. Currently we have pure dependency injection(without any Frameworks). However, we expand our library functionality: providing more modules, separating code into new modules, dynamic delivery and etc. This is why our current DI will not suit our needs. We would need to invest tons of resources into that.
I did not used Dagger2 in the beginning, because I thought that library should have few dependencies. I am comfortable with Dagger2, so it won't create any issues.
However, what I fear is various issues, which my occur while integrating our library.
I wanted to ask, if it is possible to get Android gradle, or any other issues, if application does not use Dagger2 and library does?
Will integration issues occur if both application and library, uses different versions of dagger2?
Will integration issues occur if application uses another DI framework, like Coin for instance?
Thanks for answers!
Yes, you can use Dagger 2 for library project.
Dagger 2 is basically used to resolve dependencies into independent modules for better unit testing and various other optimisations of the project both library or user app.
No, integration problems doesn't occur if you can handle you Dex files. Also you may try using your library's files (external libraries) to avoid such errors.
No, integration error should not occur if two different external modules are used. But on must ensure thay if any common external module is being used by both DIs, both DIs must have same version of external module or well Dex managed.
I have an old eclipse android workspace which has the following structure:
one library project which has all the code and default graphics and resources
other projects which depend on the library project, but with different package names, different strings.xml and different graphic resources.
Basically what this means is that all my code is in the Library Project, and all other projects are really just different apps, based on the same code, but looking differently with different names
All these were in one Eclipse workspace and now I need to update the project, so upgrading it to Android Studio sounds like the best way to go.
The easy way is to hope that export works for your case. I battled with Eclipse->Studio migration for weeks. I had exactly that situation - one common project and other apps on top of it. Studio will just convert your common project into an Android library module, and other 'app' modules will be converted into Android app modules. Check out this answer: https://stackoverflow.com/a/22797387/2102748
When you're migrated, you should look to move your source files from the ant-style hierarchy to the gradle-style hierarchy. There is a lot of content for that here: http://tools.android.com/tech-docs/new-build-system/user-guide
Android Studio will also ask you to replace .jar libraries it knows about (like appcompat, google-play-services, etc) with gradle dependencies - do it. Life becomes so much easier.
So, I've got a handful of "Utility" style classes in some of my projects. I'm curious if I can move them to an Android Library Project that contains all or most of my non-app specific glue code (wrappers and interfaces, mostly).
So, my question is what happens to the files I don't need in that library. I know Android Library Projects basically just copy their code into the other project, so if I say use 25% of the code in my "general purpose" library, will my app actually contain the bytecode for all 100%, or does it properly strip it down to only the stuff I need.
I had some issues with unused classes in Proguard in the past, so I'm just once-bitten, twice shy with the ADT now...
Unfortunately, all your projects will grow when the library is getting bigger - even if most contents of that library are not used. I tested it myself by creating an app A and a library L. If L is a library used in A, the classes.dex file (and therefore the A.apk file) is growing if I add more classes - even if they are not used.
To sum up: Right now I would create a basic library for certain things that are small and that may be used by many projects, and create a new library for every new component that is going to be larger and only is used by some projects. A good candidate for a new library would be a new UI component with multiple images defined in the resources. A good candidate for the base library are commonly-used methods and things like file caches, for example. Compiled code is compressed quite heavily for Dalvik, which you can see here. (The whole presentation is actually fun to watch :-)
Edit: If ProGuard is activated, it will also remove unused code for you. The default proguard.cfg is sufficient. It will not run on the (default) debug built, but when the final .apk is compiled. So it actually is possible!
I have used 3 level deep Android library projects successfully though it is kind of a pain. The primary use-case is when there are a set of resources and classes that you want to share across a few projects. Since I use a version control system, I would rather not use symlinks.
Note that Android Library projects also suffer greatly when dealing with resources. ADT will rebuild R.java once for each library, and each R.java will contain a copy of all resource ids from all libraries. The core problem here is that resources are regenerated for the entire project as a whole, and there is no way to "build a jar" for a dependency as would be expected with normal "libraries". We tried integrating with OpenFeint, and had all kinds of hell dealing with libraries and dependencies. I think we ended up just merging all the OpenFeint source and resource files into our own project and ditching the "Library" project as it was offering little value.
Android Library projects are a clunky way of sharing code between projects and have a number of drawbacks. I've found that everything accomplished with a Library project can also be accomplished with symlinks (symlink source into two projects). I've yet to find a usecase where an Android Library project offered something that wasn't easy to replicate with other, less fragile means.
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.