I want to use SURF for feature detection found here and use it in a Java applicaion, however the nonfree modules are not included in the library by default, as they are patented.
How do I access this module? I have searched and tried a few things but none have worked; many focusing on Android, which I don't fully understand.
Can I add it when using cmake to build the library? or is there a better mean?
Actually when I was using cmake, nonfree library module was selected as default. So you should have this module built in your lib folder. Nonfree module includes some functionality that may be patented in some countries. So you should be careful if you are building a commercial application adn you will sell it in one of these countries.
To use it, you need to add it to your references and include the headers.
EDIT
I checked the docs here : http://docs.opencv.org/java/ there seems to be no module with name nonfree and there is no class related to sift or surf. I thought it should be same with c++ library but I was mistaken.
On the other hand, people claim that they built it for OpenCV4Android. That means it can be somehow compiled unofficially for java as well but no one seems to overcome this. Like here : http://answers.opencv.org/question/11185/how-can-i-generate-java-bindings-for-non-free/
Also there is a issue here about this : http://code.opencv.org/issues/2825
So at the moment no solution out yet. Implementing a JNI and loading compiled c++ nonfree lib may solve the problem by the way.
One more edit :)
In a tutorial, someone implemented JNI for nonfree module to be used with android. I don't have enough knowledge to try it for java at the moment. But a volunteer would be nice to try this with java :
http://web.guohuiwang.com/technical-notes/opencv_nonfree_android_jni_demo
Related
Firstly, apologies if I have not included all the required info for this question to be answered. I am somewhat new to Android development and am still getting my head around the build tools, API levels etc. So please let me know if there is any additional info I should provide to help you help me!
After updating my Android project compile sdk version to 27, I realised that version 27.0.2 of com.android.support:support-v4 no longer includes AsyncTaskCompat (that class has been deprecated & removed).
I have a third party library that is not open source, not easily replaceable, is no longer supported and still uses AsyncTaskCompat.
Since AsyncTaskCompat is open source, I was thinking I could simply reintroduce it somehow by redefining it in my project.
I've tried redefining it under my project in com.android.support.v4.os but even though the project compiles without any issues, when I run the section of the app that uses the third party library I get a crash with a class not found error for AsyncTaskCompat.
Is there something obvious I might be missing?
No need to add a specific Android Library module.
Only add the classes bellow to your project using the package name "android.support.v4.os":
AsyncTaskCompat
AsyncTaskCompatHoneycomb
Answering my own question here after another day of hacking away.
It is in fact possible to re-implement these deprecated/removed classes in a way that the dependency will be able to use it.
The steps are described here in case anyone needs it in the future
Create a new Android Library module for your app
Reimplement the missing classes using the appropriate namespace
In my case I needed to reimplement android.support.v4.os.AsyncTaskCompat which is open sourced so all I had to do was copy the code from source.
Add the module as a dependency of your main app module.
I'm running into a strange problem in Android Studio. I'm also using latest JDK. I can't seem to import the following :
javax.xml.stream
javax.xml.transform.stax
They both are unavailable and I don't know why. In a non android project I'm able to import these. Any clue why these are missing in android?
If not, the simple solution is that I added these dependencies from maven. But after running I'm getting this error:
"Ill-advised or mistaken usage of a core class (java.* or javax.*) when not building a core library.
Android doesn't use the same Java JDK as what you use for a desktop or server app; it uses its own implementation of the JDK, which adds the android.* hierarchy but leaves out some packages that are in the standard JDK, especially in the javax.* Java extensions. Unfortunately for you, javax.xml.stream and javax.xml.transform.stax are among the things they didn't choose to implement. Moreover, the Android runtime won't allow you to load any java.* or javax.* classes from an external JAR file for security reasons**. This answer may describe the situation a little better.
Your best bets are probably: 1) use a different third-party library specifically built for Android, such as SimpleXML; 2) look for a repackaged version of the libraries, like this JAXB effort; or 3) use a tool like Jar Jar Links to do the repackaging for you.
Also see this excellent guide on parsing JSON and XML in Android.
** Note: I can't find any documentation from Google to substantiate this; it's just a commonly repeated "fact". If anyone can point to an authoritative statement about Android's handling of third-party java[x].* classes, please comment with a link, or edit this answer.
I am supposed to deliver a SDK in Java for the company I work for.
I have a few years of Java EE experience but not so much when it comes to develop API and SDK.
The problem here, is that the SDK is already available in .NET C# and working just fine. I made it myself.
Switching to Java is a nightmare. I tried several solutions. All failed, some were inconclusive due to the fact I could not progress.
As the title says, I a need to develop a Java Library that has modules. Internal modules. Modules the world out there is NOT supposed to see / use / modify.
In C#, it's easy as pie : create your modules respective namespace, make their classes and methods privates, expose one or more wrappers (bridges) to the entire assembly (project) with internal so that the "main module", through it's own public wrapper accessible by the world, can use the tools provided within these internals modules.
The keyword, here, is INTERNAL. I think it's pretty easy to understand. So let's take an example.
Let's say the SDK is consisting of 4 modules.
The 1st module, is the main module, the one that is public and
exposed to the whole world. In other words, the unique entry point
of the SDK. It's like a master of its own universe. It can use the
internal modules at will, but will never show them to the world.
Never.
The 2nd module is network-related. As in, it deals with network to manage connexions to remote services, read and write data from and to a stream. It offers its own little wrapper so that the main module does not need to use the 2nd module internal tools. Like a universe inside a universe.
The 3rd module is a data processing module. It receives packets (hand-made by the 2nd module) so that it can be processed and relevant information dealt with.
So here we are. How can I do that in Java using NetBeans ?
I tried Maven with POM Project, and Netbeans modules. A nightmare.
I tried creating multiple libraries (one per module), tweaked the Main Module library to include its (modules) dependancies but it does not work.
In a standard Java EE console application, as soon as I attempt to instanciate my SDK Manager (ergo the main wrapper from the main module), it fails because Class Not Found exception : could not find classes related to the internal sub-modules.
If I add all modules respective Jar into this Java Console app, it can access all wrappers. Where is the fun in that ?
Thanks for the help !
Project Jigsaw will eventually give you what you want when java 9 comes out.
See this article about how jigsaw works, in particular,
An exports clause in a module declaration makes the public types in
the package it names available to other modules, so we can with Jigsaw
defines boundaries, and not all public types could be used from other
modules, we must explicitly specify which types are visible.
I have built a free version of a game app which is now on the market with a name like com.mycompany.myfreegame. Now I want to make a paid version. There will no doubt be tweaks and bug-fixes to both versions required for years to come so I want to encapsulate the encoding of the free vs paid information in as compact a way possible so that I can essentially fix bugs in both versions simultaneously.
If the entirety of the differences between the two versions was handled at runtime then I could set a single flag in the source code and that would be the end of the problem. Unfortunately there are two other things to consider,
The name of the package needs to be different between the two versions.
Some xml needs to be different. For example the free version needs linear Layouts for holding ads, the paid version does not.
What is the simplest way to achieve this goal?
I think the first approach I'd try is using 3 projects in Eclipse: one for either version of the game, and a library project with all of the shared code. The library project would be where all the code for your core gameplay goes, and the version specific projects manage loading different layouts, putting ads in the free version, and adding levels/features/hats to the paid version.
You might be able to accomplish your goal of a single code base with a compiler flag using an ant task, but that's beyond me.
I think what you're looking for is a Library Project http://developer.android.com/guide/developing/projects/index.html#LibraryProjects
From that web page:
If you are creating an application that exists in both free and paid versions. You move the part of the application that is common to both versions into a library project. The two dependent projects, with their different package names, will reference the library project and provide only the difference between the two application versions.
Another question, very similar to this one, seems to have a decent discussion and answer: Multiple Apps with a shared code base
Edit: Here is a link on how to implement a library project. http://developer.android.com/guide/developing/projects/projects-eclipse.html
In regards to different versions being slightly different, a library project can accomodate. The library project is built first, then the parent (the project that uses the library) is built last and they are merged together. Both projects can define the same resource identifiers and the project built last (parent project), gets priority (overwrites). So essentially, you can override strings/layouts (possibly more, not sure?) in the parent/calling application.
For example: Say you have two projects, free and paid.You could create a string with a default implementation (free version) and override it in your paid version (parent app).
Code in shared libraries Strings.xml file:
<string name="AppName">My Application (Free)</string>
Code in parent app Strings.xml file:
<string name="AppName">My Application Premium</string>
I would go with Maven. You can define a parent project with three sub-projects, say:
Common
Paid
Free
Maven allows to have different configuration files, while having the same code base.
For example, I currently have a project where two databases are used, so all the app config files remain on a common project, where the database configuration files and classes remain on each project folder. When I do a build in the parent, every child project is built, unit tests passed, etc...
Moreover, this is only one of the thousand advantages of maven!
EDIT: I just found out, you have an android-plugin for maven, with cool features also
May be the best way now is to use Android Studio + gradle.
This case allows to build both paid and free versions with one command in console.
More details are in this post: https://stackoverflow.com/a/17286142/1705370
I think you are looking for something similar to this:
Multiple Android Application Package .apk files from single source code
Basically, the easiest approach here is to have two different manifest files and two different main activities and switch the compilation using Ant, though the latter is optional.
Hope it helps.
This must be quite a common problem. An application depends on Library A and Library B. Library A depends on Library C-v1 (version 1 of Library C) and Library B depends on some newly introduced features in Library C-v2 (version 2 of Library C). And of course, there was some major refactoring in Library C-v2 which means it can't be backwards compatible with Library C-v1. But Library C-v1 and Library C-v2 have the same package names and class names.
Now, it should be possible to effectively "re-namespace" Library C-v1. For example, a class called com.example.MyClass could be re-namespaced to old.com.example.MyClass. It should be completely possible to build an automated tool that takes a binary JAR and changes all the package names in this fashion.
It should also be possible to change the references in a dependent library. For example, any reference in Library A to Library C should be changed to point to the new package names.
Surely there must already be a tool available to do this?
(PS: I'm sure some clever person will mention OSGi, but I want to do this as a one-time activity).
jarjar does what you are asking:
You can avoid problems where your library depends on a specific version of a library, which may conflict with the dependencies of another library.
The libraries are repackaged into your jar and renamed in the process. It also includes an Ant-Task.
Try the maven-shade-plugin. It will change packages you specify: http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
No, what you're talking about is major surgery, not a cosmetic renaming. There's no tool to help do this except for an IDE and lots of hard thinking.
You can't expect any warranty or certification of correct behavior to hold if those libraries are from a 3rd party.
I agree that it's a problem (e.g. the conflicts between Spring and Hibernate dependencies), but your solution isn't the way to go. This is what OSGi was born for.
If you had the source code, you could create an Ant task to do the refactoring, then reJar the old library.