I was recently given shared libraries (.so files) to incorporate into our Android application.
Along with the shared libraries I was given a few Java classes and the following file, that offers me some Java methods to call when I want to call the library methods:
public native long doSomething(String str, int i, int i2, int i3, boolean b);
public native Result doAnotherThing(CustomObject obj);
static {
System.loadLibrary("DoSomethingLib");
}
There are, of course, a lot more methods than in the example above. After some testing I figured out, that all the methods that only receive and return base types (int, byte, boolean, String, etc). work like a charm. So the linking to the library and all is working.
However, all methods that take custom Java objects, like the second one in the example above, return null.
I am assuming that the library is not able to handle these custom Java objects correctly.
How does the .so library know how to treat the custom Java objects that I pass to the native calls? Am I missing something? Do I have to tell the .so library where it can find my Java objects somehow? Or should all of this be handled inside the library itself?
Is there a way to find out why the library is not happy with the objects I pass to it?
I do not have access to the library source code.
Recently at my company a debate started after reviewing a different approach for writing heavy duty classes.
A big Java class holding component specific logic (no standard OOP principles made sense) had to be rewritten in Kotlin. The solution provided was splitting the logic in categories and the categories into separate files with internal extension functions to the main class.
Example:
Main.kt
class BigClass {
// internal fields exposed to the extension functions in different files
// Some main logic here
}
BusinessLogic.kt
internal fun BigClass.handleBussinessCase() {
// Complex business logic handled here accessing the exposed internal fields from BigClass
}
What are your thoughts on this? I haven't seen it used anywhere maybe for a good reason, but the alternative of thousand lines classes seems worse.
You have to consider that an extension function is nothing more than a function with an implicit first parameter which is referenced with this.
So in your case you'd have something like:
internal fun handleBussinessCase(ref: BigClass)
which would translate to Java as:
static void handleBussinessCase(BigClass ref)
But this could be assumed to be a delegate pattern, which could be encapsulated much cleaner in Kotlin as well.
Since the properties have to be internal anyhow, you could just inject these as a data class into smaller use-cases. If you define an interface around these (which would make the properties public though), you could create a delegate pattern with it and still reference each property with this in your implementation.
Here are some thoughts on making extension functions for the class:
It will be a utility function that will operate with the object you're extending, it will not be an object function, meaning that it will have access to only public methods and properties;
If you're planning to use class that being extended in unit tests, these methods (extensions) will be harder to mock;
Most likely they wont behave as you expect when used with inherited objects.
Maybe I missed something, so please read more about extensions here.
I have a class that consists only of static member variables and static methods. Essentially, it is serving as a general-purpose utility class.
Is it bad practice for a class to contain only static member variables and static methods?
No, I don't think so at all. It is worse practice to have a class full of instance methods which don't actually depend on a particular instance. Making them static tells the user exactly how they are intended to be used. Additionally, you avoid unnecessary instantiations this way.
EDIT: As an afterthought, in general I think its nice to avoid using language features "just because", or because you think that that is the "Java way to do it". I recall my first job where I had a class full of static utility methods and one of the senior programmers told me that I wasn't fully harnessing the OO power of Java by making all of my methods "global". She was not on the team 6 months later.
As long as the class has no internal state and is essentially what is known as a leaf class (utility classes fall into this category), in other words it is independent of other classes. It is fine.
The Math class being a prime example.
Sounds reasonable.
Note: Classes that do this often have a private no-arg constructor just so that the compiler yields an error if a programmer tries to create an instance of the static class.
Static methods don't worry me much (except for testing).
In general, static members are a concern. For example, what if your app is clustered? What about start-up time -- what kind of initialization is taking place? For a consideration of these issues and more, check out this article by Gilad Bracha.
It's perfectly reasonable. In fact, in C# you can define a class with the static keyword specifically for this purpose.
Just don't get carried away with it. Notice that the java.lang.Math class is only about math functions. You might also have a StringUtilities class which contains common string-handling functions which aren't in the standard API, for example. But if your class is named Utilities, for example, that's a hint that you might want to split it up.
Note also that Java specifically introduced the static import: (http://en.wikipedia.org/wiki/Static_import)
Static import is a feature introduced
in the Java programming language that
members (fields and methods) defined
in a class as public static to be used
in Java code without specifying the
class in which the field is defined.
This feature was introduced into the
language in version 5.0.
The feature provides a typesafe
mechanism to include constants into
code without having to reference the
class that originally defined the
field. It also helps to deprecate the
practice of creating a constant
interface: an interface that only
defines constants then writing a class
implementing that interface, which is
considered an inappropriate use of
interfaces[1].
The mechanism can be used to reference
individual members of a class:
import static java.lang.Math.PI;
import static java.lang.Math.pow;
or all the static members of a class:
import static java.lang.Math.*;
While I agree with the sentiment that it sounds like a reasonable solution (as others have already stated), one thing you may want to consider is, from a design standpoint, why do you have a class just for "utility" purposes. Are those functionals truly general across the entire system, or are they really related to some specific class of objects within your architecture.
As long as you have thought about that, I see no problem with your solution.
The Collections class in Java SDK has static members only.
So, there you go, as long as you have proper justification -- its not a bad design
Utility methods are often placed in classes with only static methods (like StringUtils.) Global constants are also placed in their own class so that they can be imported by the rest of the code (public final static attributes.)
Both uses are quite common and have private default constructors to prevent them from being instantiated. Declaring the class final prevents the mistake of trying to override static methods.
If by static member variables you did not mean global constants, you might want to place the methods accessing those variables in a class of their own. In that case, could you eleborate on what those variables do in your code?
This is typically how utility classes are designed and there is nothing wrong about it. Famous examples include o.a.c.l.StringUtils, o.a.c.d.DbUtils, o.s.w.b.ServletRequestUtils, etc.
According to a rigid interpretation of Object Oriented Design, a utility class is something to be avoided.
The problem is that if you follow a rigid interpretation then you would need to force your class into some sort object in order to accomplish many things.
Even the Java designers make utility classes (java.lang.Math comes to mind)
Your options are:
double distance = Math.sqrt(x*x + y*y); //using static utility class
vs:
RootCalculator mySquareRooter = new SquareRootCalculator();
mySquareRooter.setValueToRoot(x*x + y*y);
double distance;
try{
distance = mySquareRooter.getRoot();
}
catch InvalidParameterException ......yadda yadda yadda.
Even if we were to avoid the verbose method, we could still end up with:
Mathemetician myMathD00d = new Mathemetician()
double distance = myMathD00d.sqrt(...);
in this instance, .sqrt() is still static, so what would the point be in creating the object in the first place?
The answer is, create utility classes when your other option would be to create some sort of artificial "Worker" class that has no or little use for instance variables.
This link http://java.dzone.com/articles/why-static-bad-and-how-avoid seems to go against most of the answers here. Even if it contains no member variables (i.e. no state), a static class can still be a bad idea because it cannot be mocked or extended (subclassed), so it is defeating some of the principles of OO
I wouldn't be concerned over a utility class containing static methods.
However, static members are essentially global data and should be avoided. They may be acceptable if they are used for caching results of the static methods and such, but if they are used as "real" data that may lead to all kinds of problems, such as hidden dependencies and difficulties to set up tests.
From TSLint’s docs:
Users who come from a Java-style OO language may wrap their utility functions in an extra class, instead of putting them at the top level.
The best way is to use a constant, like this:
export const Util = {
print (data: string): void {
console.log(data)
}
}
Examples of incorrect code for this rule:
class EmptyClass {}
class ConstructorOnly {
constructor() {
foo();
}
}
// Use an object instead:
class StaticOnly {
static version = 42;
static hello() {
console.log('Hello, world!');
}
}
Examples of correct code for this rule:
class EmptyClass extends SuperClass {}
class ParameterProperties {
constructor(public name: string) {}
}
const StaticOnly = {
version: 42,
hello() {
console.log('Hello, world!');
},
};
I'm trying to modify chromium on android for research purposes.
Chromium comes with a ContentViewCore.java class. This class calls a native function:
nativeEvaluateJavaScript(mNativeContentViewCore, script, null, true);
This method is defined in the same class as follows:
private native void nativeEvaluateJavaScript(long nativeContentViewCoreImpl,
String script, JavaScriptCallback callback, boolean startRenderer);
The class has the following annotation:
#JNINamespace("content")
As I understand it, the JNI Generator links these methods to the correct native (c++) methods of the correct class.
My question: To which class is ContentViewCore.java linked? Where can I find the implementation of nativeEvaluateJavaScript? Where is it defined that a specific java class is linked to a specific c++ class?
The only thing I can find is content_view_core.h (src/content/public/browser/android), but that file doesn't get me any further. Googeling for 'nativeEvaluateJavaScript' revealed nothing. I've been searching for about 10 hours now and I'm not getting any closer.
The JNI generator will generate JNI binding file under "(SHARED_INTERMEDIATE_DIR)/<(jni_gen_package)/jni/" during the build time.
For example, the corresponding JNI binding file for ContentViewCore.java is "out/Debug/gen/content/jni/ContentViewCore_jni.h". And you can see the native method of 'nativeEvaluateJavaScript':
static void EvaluateJavaScript(JNIEnv* env, jobject jcaller,...
I am new to android. If my question is wrong please forgive me,
My Question is:
Can I write a method in android which can be accessed from anywhere inside my application?
I've studied VB for all these years and now I am trying to program in android, I couldn't stop comparing them when I write code.
In VB we can create modules and access it from anywhere. Is there anything I can do in Android...??
Answers and advises are needed!
You have to create a class with a static method:
public class MyClass {
public static void myMethod() {
// Your code here...
}
}
And you can call it like this: MyClass.myMethod();
You can try extending Application and put your common functions there.
In all activities you can access this via context.
For reference follow this:
http://www.devahead.com/blog/2011/06/extending-the-android-application-class-and-dealing-with-singleton/
It is a long topic to discuss , but as you have simply ask whether method is accessible or not , then answer is yes but with some respect of java rules.
Android is again like java coding, You can do same thing what we can do with java.
Same Data type
Method Format
Class structure
Inheritance, Public , private , protected, etc.
So while you write your code you should care for that all things and these all thing you know because you are working in VB.
VB module equivalent is not there in java(android),
but some how you can mock them to some extend by using final classes with static methods.
Anyway you need to import the package containing these type of classes wherever you use it.