Is there a way to implement interface which doesn't exist in Android SDK version that I'm using for development but exists in later Android versions through reflection or somehow else?
I need to implement interface "WebViewClassic.TitleBarDelegate" which (as well as class WebViewClassic) appeared in API-16, but don't exist in earlier API's.
How can it be done without upgrading development to API-16?
It must be implemented by my custom class derivative from WebView, because WebView implementation invokes methods of this interface.
So alternatively maybe some trick can be made to substitute one method to another in runtime at the moment of invocation?
Or maybe finally appeared some means to make releases for different API versions in one package?
Any suggestions would be great.
Maybe you can take relevant files from the Android Sources and put them into your project? I've seen this for some classes when someone needed to tweak those classes a little. Not sure about your case though.
Related
Lets say that a lot of functionality are using methods from this class test.MyClass, but it's very slow and I'd like to code in JNI in hopes of improving the timing...
Is there a way to replace test.MyClass so that the library does not need to be changed, but the codes in the library will use the new test.MyClass with native implementations for certain methods from now on? It's the classic "PC is fine but the timing for Android is crap" problem.
Just create your test.MyClass in the same package/hierarchical structure as the one in the package you want to override. The classloader should load your implementation first and if it tries to load the one from other library the load will fail, because there can be only one loaded instance in the classpath.
As the title suggests, I need to implement Coarsened Exact Matching inside a Java application. I found out that Renjin embeds this library but I cannot figure out how to use it in my Java app, i.e. how to install it, invoke matching methods etc...
Any idea or example? Thx a lot.
I added tcltk stubs to Renjin today, so with the latest version you can now use the cem package.
There are no plans to add true support for Tcl/Tk graphical user interfaces, so any functions from cem that actually rely on tcltk will fail, but all of the actual computation should work.
Read better:
This package cannot yet be used with Renjin it depends on other packages which are not available: tcltk
The reason is that TCL/TK requires native code, which is a pain to use in Java. Because nobody did write that code yet it cannot be used yet.
I have created a library which supports an application, however in the newest version of the application the developer has changed the structure without changing the class names.
So version 1 of the application has classX in package A but version 2 has classX in package B. How can I develop my library in a way which allows supporting both of these in the same build?
Edit: My library is dependent on the application, not the other way around.
That is a bad decision, if you still want to make it work you need to provide skeleton classes with old structure and delegate calls to new version of class but it would get very dirty
better to not provide backward compatibility if you are firm with the renaming decision
Short answer: You can't.
Real answer: Your library should be able to exist independently of any application that uses it. The purpose of a library is to provide a set of reusable, modular code that you can use in any application. If your library is directly dependent on application classes, then it seems like a redesign should be seriously considered, as your dependencies are backwards. For example, have A.classX and B.classX both implement some interface (or extend some class) that your library provides, then have the application pass instances of those objects, or Class's for those objects, to the library.
If your "library" can't be designed this way then consider integrating it into application code, making it a direct part of the application, and come up with a better team workflow for you, the other developer, and others to work on the same project together.
Quick fix answer: Do not provide backward compatibility, as Jigar Joshi states in his answer.
Bad answer: You could hack a fragile solution together with reflection if you really had to. But please note that the "real answer" is going to last in the long run. You are already seeing the issues with the design you have currently chosen (hence your question), and a reflection based solution isn't going to prevent that from happening again (or even be reliable).
I just finished my Full version on my app. I am now looking around trying to figure out how to make my Lite version of the app. Not a whole lot is different but there are differences especially when you are playing the trivia game. How do I go about managing both of these versions in Eclipse? I looked at this guide:
http://blog.donnfelker.com/2010/08/05/howto-android-full-and-lite-versions/
But it seems like the linked tutorial is outdated based on the comments below the tutorial about adding Proguard to the code. There has to be an easy way to do this. Is the best way still to make 3 projects like the above linked tutorial says but just find away to get around the Proguard issue?
Not sure if this counts as an answer but I have positive experiences from using library projects when creating dual version Apps like free/pro, lite/paid or whatever you choose to call them.
You can separate the differences in logic either by using simple if-statements, like if(AppType.isFree(context)) where in the helper method you check if the context package is that of the free or paid version.
Or by using inheritance and interfaces to take advantage of polymorphism and dynamic binding.
For example the menu activity in your lib might invoke a getGameActivity, which depending on sub class (free or paid) returns the appropriate version of the game and where most of the logic is in the abstract lib GameActivity class.
And about ProGuard, if you are not very afraid of reverse engineering, it's not really necessary to bother with it.
As good as the Java API is, I need to change the code of some classes in the default API packages (for example java.util.Scanner) for a project I am working on.
Ideally, I would extend the classes I am interested and create my own sub-classes, but the classes I want to extend are declared 'final'. How do you suggest I do this? Will I get into trouble with the compiler if I customize the source code of these packages?
If you can, you should rather wrap and delegate, as suggested in another answer. See the Adapter Pattern.
But there are of course ways to do this if you really need it.
A straightforward approach is to simply modify the code in downloaded sources and substitute your own version of a jar in the classpath.
Another option is to use aspect-oriented programming techniques, likely with AspectJ to intercept and modify calls as needed.
It might also be possible to hack together a solution using reflection and home-grown classloaders, but it will be painful to code.
All of these are however quite risky if you don't know what you're doing. Frequently classes are made final for good reason.
If you tell us more specifically what it is you're hoping to change, we might be able to provide assistance in avoiding what you currently think you need.
you really cant extend a final class..
if u really want to add a functionality by extending a class you can do it by modifying class src. from JDK and save it as your own class and use it.
Don't do that. Write your own code which wraps around the original scanner and use that. To update internal packages, there is an endorsed directory property which you can provide at runtime.
Never do it! Never change core classes. If class is final - use composition not inheritance.