I make sereval Android apps with similar code, but I need to stay flexible for customizing the apps. My solution right now is, that I have a Library-Project, where I can override functionality in the Project by extending classes. For the following example, I call the Library Project PL. P1 is a customized Project using PL and P2 is another customized Project using PL.
My Problem is now, that in PL I would like to make an instance from StudentPL.java. In P1, there is no need to make any changes to StudentPL, so the compiler should take this class, but in P2, there I have StudentP2.java, that extends from StudentPL.java. So the instance made in PL, should be an instance of StudentP2.java.
My idea was now, that I make a package called mirror, that is directly in the src-Folder of the Project PL. There I make the class mirror.Student.java that extends from StudentPL.java. In the Library-Project, I make now an instance of Student.java. For Project P1, there are no changes needed. In P2 I make the same folder mirror in src Folder and I make the same class mirror.Student.java that extends from StudentP2.java now. The Idea is, that the ClassLoader now loads mirror.Student.java from P2 and ignores mirror.Student.java from PL, but this results in the following error:
Dex Loader] Unable to execute dex: Multiple dex files define Lmirror/Student;
Conversion to Dalvik format failed: Unable to execute dex: Multiple dex files define Lmirror/Student
Here is a UML of what I'm talking about:
http://www.koenix-band.ch/images/other/Stackoverflow.gif
Maybe I should overwrite the ClassLoader, but I have no idea how to do this? Does anyone have an idea to solve this problem? Maybe someone has another idea, how i could customize the apps.
Michael
In my opinion it would be better to make your MainActivityPL abstract with a setStudent or similar method. The bulk of the activity and all its logic would still be shared from your library, but it would allow your other projects an option to use different student objects by extending the StudentPL class.
Related
I want to use this class to render the animation in the word thread,
But now I can't find this class, who can tell me why this class was deleted？
question why it was removed should be answered by someone from Android team. probably they just refactored some internal animation utils due to new possibilities...
you can always copy-paste this class source and paste into your project (with different name just in case), you probably should find workaround for FallbackLUTInterpolator usage (or just remove related items, supplying different Interpolator in this place, eg. linear)
SOURCE
Because of just one wrong written line of code in FloatingToolbar.java i was force to copy the entire source code in my library to patch it. This work but now the problem is that this unit call also com.android.internal.R. The problem with com.android.internal.R is that it's could be different between release, (because it's internal), so to be safe i must also duplicate the definition
in r class i have for example :
public static final class layout {
public static final int floating_popup_open_overflow_button=xxx
}
where to find the xml (i think it's an xml?) that define floating_popup_open_overflow_button ? actually in \android-sdk-windows\sources\ i can find only the java files
where to find the xml (i think it's an xml?) that define floating_popup_open_overflow_button ?
You can find a copy in $ANDROID_SDK/platforms/android-NNN/data/res/layout/, where $ANDROID_SDK is wherever you have installed the Android SDK and NNN corresponds with the version of the Java that you forked. There may be other variants of floating_popup_open_overflow_button.xml in peer directories (e.g., layout-xlarge); I have not checked them all.
I am trying to find memory leaks in my Android application.
I have the following situation:
class A created a class A$24 which created a thread. This thread has a reference to class A, so this is the leak.
I understand that A$24 is an anonymous class created in class A, but how can i find out where is was created, in which line in the code.
My problem is to understand who is the problematic thread.
In the project explorer of the resource perspective use the view menu, select "Customize view..." and uncheck "Inner class files" and "Java output folders". Now you should see the generated class files in the project explorer in a "bin" folder.
If you navigate to your A$24.class file, you can open it using a double click. Look for lines at the top talking about field selectors, like this
// Field descriptor #10 Z
private final synthetic boolean val$fStartMinimized
In this example, a final field fStartMinimized is used by the anonymous class (and therefore copied into the anonymous class). Using that field name you should be able to locate the anynomous class in question.
If there is no such field declaration (and also no method name giving you a clue), then you may get more insight with the ByteCode outline plugin (but I've never used that myself).
I am experimenting with implementing plug-in architecture in Android, more specifically, cross-apk class loading
assume I have the following:
apk A and apk B, with the same sharedUserId defined in AndroidManifest.xml
interface I is defined in apk A, and apk B contains a class IB that implements I
I tried the following approaches
in apk A, use createPackageContext to obtain context of B, then call Context.getClassLoader and load the desired class name. However, due to the fact that this creates two class loaders, and therefore I cannot cast the class IB loaded in B into interface I; which means I need to use reflection...
pass apk B to DexClassLoader (path to apk B obtained by ApplicationInfo.sourceDir) and failed with "Class resolved by unexpected DEX", probably because there is a duplicate interface I in apk B as well...
modify build xml and follow the approach in Custom Class Loading in Dalvik to create a separate jar containing the class IB in B which implements I and put the jar into apk B's assets directory. This approach looks promising, as I can load class IB and cast it to I without problems. However, it creates the need for copying the jar, and I am not sure what will happen when NDK shared library is involved.
My question is, is there an approach that involves no modification of build.xml/ant.properties and works with NDK so library?
Not sure about other approaches, but for approach 2, you can exclude interface I when you were packing B to apk. Just exclude I.class file generated is enough.
You may find this post by Fred Chung helpful and may give you some hint. http://android-developers.blogspot.kr/2011/07/custom-class-loading-in-dalvik.html
I have a common library where I've put classes that are used between multiple Android projects. However, now I encountered a situation where I have to make minor changes to the functionality of the class in one project. How should I organize the classes, keeping in mind easy readability of code and future extension possibilities?
Should I
Extend the class (MyClass) with modifications that are special to the subproject (MyClassSub extends MyClass)? What about if I have references to MyClass in the library classes, but in this special subproject MyClassSub should be called?
Have switch OR if clauses for each special part in the class file? And then pass some variable to the class?
Some other option?
This is probably a trivial question, but I am quite new to java and can't quite figure it out.
Definately 1.
Create a library (jar) containing the base class, and then use that jar in the projects that need its base functionality. Each project should provide the specialized class that extends the base.
If the new functionality is specific to the one project, I would avoid putting the functionality in the library. Go with a subclass or a replacement class. If later you find that this extended behavior is more widely usable, you can migrate it to the library (perhaps creating an entire new version of the library, much in the same way that the Java API evolves.)
Unfortunately the answer is "it depends."
Specifically, a class hierarchy should be designed such that the behavior of the base class holds for all subclasses of the class. One way to look at this is to say that the subclass may expand the behavior of the base class. The corollary is that a subclass should not restrict the behavior of the base class. So a Square IS NOT A Rectangle.
Also consider "favor composition over inheritance" unless the base class is specifically designed for inheritance, as a change to the base class might BREAK the subclass.
Have fun!