I'm trying to let a user "make his own service". most direct method I could think of is creating an empty service and letting him "fill it". he will write his own code and I'll compile it along with my project.
(If it's not understood, the code should be injected to the service programmaticaly and not manually).
There are limitations that require it's done this way.
Here's a post about programmatically compiling and running Java code,
How do I programmatically compile and instantiate a Java class?
This is pretty ugly though. You might want to look at having the use supply a script in a higher level language, and executing it via the android scripting environment,
http://google-opensource.blogspot.com/2009/06/introducing-android-scripting.html
There's also the SL4a project,
http://code.google.com/p/android-scripting/
Related
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 am trying to build an application that runs under JavaSE and Android. Most of the code is the same between the two, but there are some specific functions that need to be separated. I use Eclipse. So I decided to put the shared code in a separate project, and then build one more project for Android and one for Java, which reference the shared project. I put all Java and Android specific functions in one class residing in the Java and Android specific projects. These classes are called UtilsJ (for Java) and UtilsA (for Android). The code in the shared project uses a factory to determine at runtime which version it needs to pick, and then calls the class loader to load the right class. Essentially: if property java.vm.name equals Dalvik, load UtilsA, else load UtilsJ (and of course cast to the Utils interface before returning).
My question is simply if this is a good idea or is something going to eventually break? I've never used class loader before. Any other suggestions how to implement this sharing would also be appreciated.
Generating an interface implementation dynamically is certainly a valid technique. For instance, having a data access interface that has multiple implementations; one each for flat files, MySQL and WebDAV. The program can pick an implementation at run time based on system/platform properties.
But this feels different. If I saw that I had a Java app and an Android app that had a lot of common code, my goal would be to create an Eclipse project that generates a jar file that I could just drop into the libraries of both projects. In that case, the jar file wouldn't contain any code that was incompatible with one platform or the other. So there wouldn't be any reason to have a platform-specific implementation.
Let's take your example some code reading an initialization file. If it's common code, you have an input parameter which is a file. On Android, maybe it's "/data/data/com.whatever.blahblahblah" and on Java you're getting the "user.dir" system parameter for the top level directories. But one way or another, it's a File, and you hand it to your common setup method. That's okay. But if your initialization file read code e.g. needs a Context to get a Resource to read the file for Android, then it's not common code. And it doesn't belong in a library jar for a JVM-hosted app.
So I think that in your case the platform-specific implementation classes are overkill. If it's common code, it's the same code — period.
Let's talk about another example in your comment. If you are using desktop Java, then you are probably using Swing or AWT, so you still have the same issue of running some network task off the UI thread, notifying when it completes, maybe even updating some progress indicator UI while it's processing. Same function, same operation, but the code is so different that I can't see how having it in the same library next to an AsyncTask version could be of any benefit.
And testing might get tricky. Obviously JUnit will work for everything, but some tests would need to run on a device or emulator.
I stated that it was a valid technique, and of course you may have other compelling reasons to choose the multi-platform option. You asked the question; is anything going to break? My answer is: Probably not, but why risk dealing with some heartburn down the road? Speaking for myself, I wouldn't do it. If I had to support multiple MVC apps, my common library would have nothing but M.
I installed the Activity Explorer, and H2 standalone server. Everything works fine, as I see: I can start a workflow, claim and complete user tasks, but that's not enough. I need the workflow to call external services, suppose via REST. But I have no idea how to deploy the code to do that.
Is that possible using javascript (or groovy) in the workflow xml, or is there any way to inject Java code, or even deploy Java module?
I am totally confused about the technology, any example could help.
I am sorry for this type of question derived from my lack of experience...
Anyway, I would like to answer it.
One should wright a class implementing JavaDelegate, and pute desirable code inside the execute(..) method, compile, export as jar and put the jar in WEB-INF/lib.
In the .bpmn diagram which is pure xml, Service Task node there should have a reference to that class.
I think there enough key words to have a clue how to search details, so that's all for now.
We have a big Java application under Android ("big" just means it's too much work to translate the application). We must access to an engine written in .Net (this engine is also too "big" ...). This engine is only calculation.
We therefore seek a solution with monodroid. Our main problem is interop betwen monodroid and Java. At this time, we get :
call a Java function in a .jar library from a Mono application
But we can not call and start a Java activity. Is it possible ?
The second problem is that we do not know how to communicate from Java to Mono. Is it also possible?
There are several ways to call integrate Java and managed code, depending on what exactly you want to do.
Java to Managed
If you need to call some managed method, you may be able to use Android Callable Wrappers, which are generated for every Java.Lang.Object subclass. However, there are a number of limitations, so that may not be ideal.
If you need to create an Activity, you can use Context.startActivity(), the same as you would in Java. You can view the generated obj\Debug\android\AndroidManifest.xml to determine the appropriate class name to use, or you can use e.g. ActivityAttribute.Name to manually control the Java-side name. (Using ActivityAttribute.Name is not recommended, as it slows down type loading.)
The same is true for Services: use Context.startContext() and continue on your merry way.
If you need to share data, the easiest way would be to use a ContentProvider. ContentProviders are usually intended for cross-process data sharing, but they should be usable intra-process as well, when you need to share data between Java & managed code and you hit the limitations of Android Callable Wrappers.
Managed to Java
By and large, calling Java code from C# is the mirror of Java code calling C#: you can use e.g. Context.StartActivity() to start a Java activity, use a Java-side ContentProvider through the the Context.ContentResolver property, etc.
An example of starting a Java activity from managed code is the GoogleMaps sample, in which Context.StartActivity() is used to launch the included Java activity.
You can also use Java Native Interface (JNI) support to create Java instances from managed code and invoke methods on those instances. This is painful and brittle, but it works and allows invoking APIs that aren't otherwise exposed.
You can easily call Java activity from native code like this:
var intent = new Intent().SetClassName(this,"com.myapp.java.JavaActivity");
StartActivity(intent);
As I understood from this article you can invoke native code from Java via ACW, but I think that it's too difficult
I'm trying to develop an external library (not sure if that's the right term) to provide prepackaged functionality in Android projects. Working in Eclipse, I've added the appropriate android.jar file to the build path, and everything is happy both while editing and upon compilation.
However, when I use Android's Handler and Message classes (android.os.Handler, android.os.Message) for inter-thread communication, I get exceptions unless I'm running within an Android app, on the emulator or a device. I can no longer test my library in a "standalone" way without having to go through a running Android target.
Is there any way for me to include these two Android classes and still be able to test my library standalone? Do I need to have the Android source available? Or would it require some sort of conditional compilation hand-waving?
Is there any way for me to include
these two Android classes and still be
able to test my library standalone?
Not readily, by any means I can think of.
Do I need to have the Android source
available?
I don't know where else you would get the implementation from. But, more importantly, those things are not designed to work in isolation outside of the OS, any more than you could just grab a Cocoa class or two and pull them into your Objective-C library and expect them to run on a Windows box.
Off the cuff, knowing nothing about what you're building, I would make whatever dependency you are introducing on Handler and Message be more pluggable. Test outside of Android using a pure-Java implementation, perhaps even just some mocks. Test inside of Android using the real implementation.
You could try the lib Robolectric, that implements the android API so you would be able to create JUnit tests for some isolated code you have:
http://robolectric.org/