Android: Split up Eclipse project without introducing cyclic dependency errors? - android

I have an Android Eclipse project that I'd like to divide into two sub-projects. The problem is that both projects would need to depend on the generated Android "R" resources (R.string, etc.).
I can't figure out how I can do this (or if it's even possible) without causing a circular dependency error. What I tried to do is this:
Designate one as the main "Android project," which has Android nature, contains the generated sources.
The secondary project is a plan Java project, but depends on the Android project to resolve the R.string.xxx dependencies.
Ideally, the main project would then depend on the secondary project to include needed code, but this causes a cyclic dependency error in Eclipse.
Is there another configuration that makes sense that would avoid the circular dependency?

A project can have more than one source folder. Maybe that's all the separation you need?

I'm going to go with the usual "bidirectional dependencies are bad" rule.
I'll just divide the project into two, where one is the Android project, and the other doesn't have direct knowledge of the R resources.
Then, whenever I can just pass the R resources as needed from the Android project to the auxiliary project during initialization, or as needed.

Related

How to use same libraries on whole project?

I'm using many applications in one project like :
So i have some questions here, Application must implement iterated libraries ?
Assume i have com.android.support:appcompat in my "app" gradle and have the same one in my "opencv-java" gradle the apk will compiled with both libraries and double the size?
If no, then what happened in compiling process?
If yes, How i can avoid this, is there a way or some thing?
Update :
If i have libraries (e.g: "volley", "support" etc..) in my app "gradle" and also i used it in my open-cv "gradle", that's make me able to remove those libraries from app "gradle", it's seems that main app that used compile project(':another-app') in "gradle" can use another-app libraries, with codes and assets, every thing.
the apk will compiled with both libraries and double the size?
No.
then what happened in compiling process?
Well, one of two things:
If you use compile "com.android.support:appcompat-v7" consistently, Gradle will only use one copy of that dependency.
Your build could fail with an error message complaining about duplicate Java classes, stemming from the duplicate libraries. This would happen if you are not actually using com.android.support:appcompat-v7 in one place, but instead are adding appcompat-v7 by some other means (e.g., directly compiling against a copy of that library project).
What can't happen is your double-the-size scenario, as you cannot have two copies of the same Java class in a single APK.

Migrate project from Eclipse to Android Studio with more projects depending on a single library

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.

What is the right way to insert an activity in another project?

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!

Building Android project with ant having a library project dependency on another library project

I have maybe this not so common setup:
(> = dependency)
Android project > Android library project 1 > Android library project 2
So I have an Android library project which has a dependency to another library project.
When I'm building project in Eclipse everythings works fine but I cannot get my build working with Ant.
First Ant compiles Android library project 2 which generates a classes.jar and puts this file in the bin folder.
Then Ant tries to compile the Android library project 1 but then I'm getting errors becouse it is missing classes from Android library project 2.
Well this is not so weird becouse the jar file is not included in the libs folders.
But in project.properties i've made a dependency to the library project 2 so why does Ant not copy the classes.jar to the libs folders of library project 1?
Well I can think of a solution to use an Ant task to copy the file to the libs folder, but then I have to modify the build.xml which I do not prefer.
** EDIT
The problem is that the R class is missing, when I look in classes.jar this java file does not contain the R class. So my solution would proberly not work.
This behaviour was caused by a change in R17 of the build tools: http://tools.android.com/recent/dealingwithdependenciesinandroidprojects
In a nutshell: R files for libraries are no longer packaged in the classes.jar for that library. However, since the pareent.R for the parent-library (project1 in your example) also contains the resource-references for the 'child' library (project2 in your example), you don't have to refer to the child-R anyway.
Replace all project2.R-import statements in project1 with project1.R import statements and you should be fine.
For ant to compile add dependency in ant.properties.
eg:
android.library.reference.1=../path/to/library
This sounds like a very brittle setup - you may have good reason for this, but could you instead decouple the libraries dependence on each other?
For example; implement a bridge pattern to translate the calls between both libraries, and make the calling Android project attach them. This way, you have no code in either library that depends on the other, and the only project that needs to handle dependency setup is your main project.
One of the main reasons for using a library is to make the code re-usable, this approach ensures someone (you, a colleague, your successor...) could plug in just one library and create their own implementation of the other one.
Here is another good article on applying the bridge pattern in Java: http://java.dzone.com/articles/design-patterns-bridge
Well the problem was that the R class was missing.
So i removed the R class dependency between the two library projects.
I don't know if this is fixable but i think it is bad practice any way.
Without this dependency Ant builds fine.
Old question, but like me, others might be banging their head on this...
The official answer is "it cannot be done", specifically:
At build time, the libraries are merged with the application one at a time, starting from the lowest priority to the highest. Note that a library cannot itself reference another library and that, at build time, libraries are not merged with each other before being merged with the application.
(extracted from the official documentation: "Referencing a Library Project").
Which means that anything goes, as there is no "clean" way to do it with the tools (and dirty methods are in order).
Hope it helps

Using Activities from Library projects

I have a Library project set up and a project which depends on this library project - Everything compiles fine and I've had the Dependent project running fine however;
I'm have an intermittent problem however while using an Activity from the Library project.
My Library project can be "unchecked" as a library project and the "picker" Activity can be run in isolation. Running the Library project in it's own right works fine with no problems.
When I use the Library project (and the "picker" Activity) from the dependent project it gives me either NullPointerExceptions (or historically DexOp) errors saying that the "picker" Activity can't find it's resources.
Can anybody tell me if they have experienced this before?
EDIT
Manually copying the layout.xml used by the Library project activity to the dependent project makes the project open the "picker" Activity correctly. Is this required?! Surely not? This further makes me wonder if there is a problem with merging/referencing the integer id's from R.java in the Library project.
EDIT
I'm not sure if this is of any consequence, but one of my Library projects is a wrapper around a set of custom views used in different front end projects.
These custom views each have an Activity so that they can be tested in isolation.
One of these view's has custom attributes, which while running in isolation work very well. However, it doesn't seem like the dependent project correctly pull's in the attributes and keep's them in their original namespace, causing the imported layout's to throw compilation errors:
[2012-05-16 12:07:28 - Project] D:\opt\workspace\CustomGlowList\res\layout\main.xml:14: error: No resource identifier found for attribute 'listId' in package 'com.company.library.glowlist'
[2012-05-16 12:07:28 - Project] D:\opt\workspace\CustomGlowList\res\layout\main.xml:14: error: No resource identifier found for attribute 'type' in package 'com.company.library.glowlist
EDIT
DexOp errors were solved by removing a duplicate file name which was present in the Dependent project. Not sure if the file name was the problem or the contents of the file.
EDIT
I've been unable to find a solution to this problem as of yet (although #yorkw's answer certainly helps with the xml attributes! Thanks).
I have managed to make this problem intermittent however:
I have gone through each of the library projects and ensured they all had their own namespace (ie, com.company.library.component1, com.company.library.component2 etc). After a couple of clean's (each project ordered with the correct precedence) this problem resolves itself, however does eventually come back when switching around library/not a library to test components.
Cause:
Issue 9656: Library projects don't support custom XML attributes for custom classes
Solution:
Upgrade to latest SDK & ADT version (fixed was released since r17) and use http://schemas.android.com/apk/res-auto as custom attributes' namespace URI, see Revisions for ADT 17.0.0:
Added support for custom views with custom attributes in libraries. Layouts using custom attributes must use the namespace URI http://schemas.android.com/apk/res-auto instead of the URI that includes the app package name. This URI is replaced with the app specific one at build time.
Related Topic:
Help with a custom View attributes inside a Android Library Project
not sure how you use the android library , but i've done this thing a lot of times without any problems , so please have a reading of the next things regarding using android libraries:
in order for an android project to use an android library project , you can either edit the "project.properties" and add the path to the library project there , or , much easier, right click the project (that uses the library project) , choose "android" category , and choose there "add" and choose the library project.
in order to make the android project to always open the android library project , also choose "java build path"->"projects" and choose the library project.
on the "project.properties" , try to set the target to the same target for both projects , and to the newest one that you have (latest now is 15) ,even if you can't test the app on this android version .
source files and all resources files (in the res folder) are ok to be used on the library projects.
assets folders cannot be used inside the library project . only on the android project that actually runs , the assets folder can be used . same thing goes to the proguard file .
the manifest of the library projects almost doesn't need to have almost anything . see this post for more information: https://stackoverflow.com/a/10445630/878126 . if there are activities on the library project that you wish to be able to access via the project that use it , don't forget to include them in the manifest of the android project (no need to write them in the manifest of the android library) .
remember to run lint before you export the app . it gives you plenty of warnings , but the most important warning is when you use too-new functions that cannot run on the range of APIs that you target . this is important for libraries since it's easy to get lost if there are multiple sources .
if you wish to extend activities on the android library , you need some kind of a method to go between them . the only way i know of is to extend the application and let it be the manager of how to create an intent for each of the activities . i think you can do other tricks , but they are all probably similar to this one.
if you have the same resource (any resource on the "res" folder) on both the android library and the android project, the one on the android project will replace the other one . this has advantages and disadvantages . remember that you can't have different file extensions for the same resource .
The problem was being caused by the R files from each of the Library projects not correctly being built and referenced. The resource files are built and referenced directly from the calling project.
Each of the Libraries need to have unique package as defined in the AndroidManifest.xml. This leads to each of it's resources being compiled in that unique namespace within the calling project alongside the Library jar which contains the class files.
The problem becomes intermittent when switching between a library and a runnable project because a clean and build needs to take place to regenerate these files as it isn't done automagically when unclicking the Use as library checkbox, where as the jar (and java classes) don't require as much coaxing for them to be correctly referenced as the library projects references them when acting as a Library.
This can lead to intermittent and also varying errors including missing references, DexOp and NullPointerExceptions depending on to what degree the R.java files have been mangled or partially built and what conflicts are taking places between packages.
I have same issue like, I have one library project and it has some activity.
When I was calling library project's Activity from my Main project, layout files resources were not getting loaded properly for the libray project's activity and giving "nullpointer exception" or "class could not be loaded", etc.
Solution: I have noticed that same layout file name is getting used in my Library project and Main project. I have just renamed those activity and it is solved.
May be this will help you.
I had similar issue when referencing Library project inside the Android App project. I deleted the R.java file from Library project so it generated again and App picked up the generated file. You should see the generated R.java file under your app project->gen->library_namespace_R.java.

Categories

Resources