I'd like to create small Excel worksheet from an android application using Mono for Android.
I tried using both EPPlus and ExcelLibrary .NET libraries, however I'm having trouble building the project:
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2,2): Error: Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Perhaps it doesn't exist in the Mono for Android profile?
Is there any fix for that or other way to manipulate Excel files through Mono for Android ?
Thanks.
It looks like you are trying to reference a pre-built .NET 4.0 assembly into your Mono for Android project. You can't reliably do this (sometimes it works if you get lucky). MonoTouch and Mono for Android do not have a System.Drawing assembly, so you can't use libraries that link to it.
What you'll need to do is create a new project for the EPPlus or ExcelLibrary libraries and use the Mono for Android Library Project type. You'll probably also need to make some modifications to the project such that it doesn't use the parts of System.Drawing that Mono for Android don't have (it has a few bits and pieces like System.Drawing.RectangleF and SizeF, but is missing most of it).
I was going to work on doing this for MonoTouch using the npoi project (which has a more agreeable license than EPPlus), but have been too busy with other things.
I've got a fork of npoi that I'm working on cleaning up the API here: https://github.com/jstedfast/npoi/tree/enumification
Once I finish that and get that merged upstream, my plan is to create a new branch where I will be working on porting the library to the subset of .NET that MonoTouch and Mono4Android use. I'll probably call it "mobile" or something.
In the meantime, the quick and dirt fix is to just create a new Mono for Android Library project, add all the source files to it in the same way that npoi has, and then try building. It will fail, but the errors will give you a good starting point for figuring out which parts of the library to rip out mercilessly. Keep doing that until it compiles.
If you use either of the npoi repositories that I linked to above, I've already done some of the work to make font.metrics and some other resource file I can't think of build properly for MonoTouch/Android, so there will be a little less work to do than if you use a release like 1.2.5.
Related
I have looked at Use prebuilt JNI library in Android Studio 3.1 and How to use .so in a second project in Android?. The first is trying to get a library file without headers working and the other seems to be focusing on a specific issue with his build (although there's some useful information there). I'm relatively new to app development and especially to native development on android. I've gotten a build with the JNI library and some c++ code working, but that seems to be just for building from source.
It's probably a simple answer, but I haven't been able to find documentation on this specifically in the android developers documentation. I'm interested in understanding the correct (or most conventional) place to put and way to use a precompiled library (module/lib/*.so and module/include/*.h) in an android project. Would I even need to use JNI or the NDK if the library is built with another build tool? Another project I have has a native library source object (*.so) in ./obj/local, ./libs, and in many other folders related to JNI. I'm guessing it would be somewhere in there, but I'd like to know what is conventional.
For some context, I'm trying to work with the essentia library. I have followed the guide on compiling for Android and have a build with the general hierarchy mentioned above (essentia/lib and essentia/include) that seems to be working.
I have a C++ codebase that is currently set up in Visual Studio (to run on Windows), with multiple Projects with inter-dependencies. I'm trying to bring it over to Android Studio, to get it running on Android.
I'm familiar with Visual Studio and C++, but quite new to Android Studio's Gradle and CMake.
My (possibly wrong) expectation is to try and treat Android Studio Projects like Visual Studio Solutions, and Android Studio Modules like Visual Studio Projects. Given that my codebase uses multiple Projects in Visual Studio, I am trying to create multiple Modules in Android Studio -- each one with their own build.gradle and CMakeLists.txt files.
The issue is that I cannot get one section of code (AS Module) to link with the other. I am compiling these different sections as STATIC using add_library() (I plan to have one Module that creates a SHARED library, to load into Java).
I can easily get the includes to work via include_directories("../OtherModule/src/"). However, I cannot get it to link. I cannot find the .so (or similar) file to link to (via target_link_libraries() or equivalent). When I extract the .arr file from a given Module, I do not see any .so or anything.
I realize that I could simply put the entire codebase under one Module (using one build.gradle and one CMakeLists.txt -- or network of CMakeLists.txt's using add_subdirectory()). I don't know if this is fine, or if it would take more/less time to build.
I'm sure that there could be multiple ways to set this up, and it could just be a matter of preference. All research that I've done thus far has only found strictly adding native code to the same module with Java code -- doing basic JNI native bridge stuff. I haven't been able to find a single article about multiple native Modules linking together.
I'm hoping that someone with more experience with native development on Android could help me out. Thanks!
TL;DR: Simplified scenario: (Without being concerned with the JNI native bridge) I have two Modules in Android Studio, both with only native code. I would like to have each Module have its own build.gradle and CMakeLists.txt, creating its own STATIC libraries. One Module depends on the other and must set the correct include and link directories. How do?! Is this even correct (or should there ever be only one Module with native code)?
I asked a related question here. It seems to me that AS...
...does not actually link the final module-library unless it's SHARED (it does allow static 'sub-libraries' within the module); consider making the final library shared - you will have to System.loadLibrary() it specifically in Java though.
...does not allow you to install files to other places (e.g., from your native module to your Android app). I work around this by fetching the library through set_target_properties( jniwrapper PROPERTIES IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/../libnative/build/intermediates/cmake/${BUILD_TYPE}/obj/${ANDROID_ABI}/libnative.so ) and setting BUILD_TYPE in build.gradle. Not overly elegant though.
Overall, this does not seem to be an encouraged use-case in AS...
We have developed an iPad application where the core logic is written in CPP code, so that we can use the same code files/libraries to other platforms.
Now I want to use those files and develop similar Android application, but unable to create .so files and integrate paths in Android.mk files and all. I am basically an iOS developer, this is first time I am looking into Android NDK.
Can anyone help and guide if there is any straight forward steps to it.
I have already gone through android developers site and few other tutorial sites. But none of those worked for me.
Require easy-clear steps to call cpp method in java, if I do have few cpp files and .a libraries with me already.
You aren't very specific at the step you are stuck at.
Here's a very quick explanation on how to call native code from java (android) :
first create a method to be exported by the native and called by java (this uses JNI, so google JNI , JNIEXPORT)
once you have this method defined in your native code, it's time to create a shared library (.so) file , using the compiler that comes in the NDK (because you are compiling for android ). You will need to compile for the correct architecture of the device (armeabiv7s is the most common now days).
you need to add the library file in your app.apk inside the armeabi folder (more details in NDK tutorials).
inside your java code you will need to load the shared library via the System.loadLibrary(LIBRARY_NAME);
inside your java code you will need to have defined static native methods that are in pair with the methods you exported from your CPP code
Quick tips :
use C functions,not CPP , since CPP will be mangled in the resulting shared library. In other words, you will need to create a C wrapper that will call your cpp code.
look over a hello world tutorial for NDK , and work yourself from there . Here's a link to such tutorial http://trivedihardik.wordpress.com/2011/06/16/hello-world-example-using-ndk-in-android/
You will bump later on into compilation issues with the makefiles, but by then you will probably be able to be more specific with your question.
Easiest way is to use the hello-jni Android studio sample project.
There are a lot of settings and configurations, you get them from the sample that is a working unit, always easiest when starting from something working.
First run (and modify) the hello-jni and learn how the interactivity between the Java and C parts works. About everything works except environmental ANSI C/C++ stuff. You have to get things like language, country etc from Java and transfer it to the C-code. You are in US in English with "inches and gallons" in JNI.
Then to an own project you create with android studio, copy and modify from it bit by bit from hello-jni. When you have our own branded hello-JNI you can add bit by bit your own code. Often using C-dummies for testing the interactivity with the Java part is easier, then change it to the real C/C++ code of yours.
Read the Android/Android studio documentation and learn and understand. Use the Android emulators, much easier and they are good.
The project configuration stuff is by far the hardest to handle at the start. If I would make a new project today, I would start from the Hello-JNI once again.
Novell's LDAP library is included as part of the Mono project, but it isn't available when building MonoDroid projects because the base libraries don't match (so it's not offered as a library Reference option).
So I complied it directly from the Mono source as an Android library, but I can't get the resources to be included because they are in resx files and making that work in Mono seems really hit-and-miss. Without the resources, the error messages don't work.
I know it's possible because #jonathanpeppers has achieved it in these binaries, but they have this bug, which I would like to fix and recompile.
If you go back in the history for the project, you can see the source file used to be included directly in. https://github.com/xamarin/prebuilt-apps/commit/0f8784ebc272f72d9398897b4e54eef8965af7a9
Most libraries can easily be recompiled from source!
I'm just getting started in Android development, and use Netbeans with NBAndroid and SDK 17.
I'd like to use the same Java source code in my Java and Android app.
http://developer.android.com/guide/developing/projects/projects-eclipse.html says how to do it in Eclipse (although it is sketchy on the .JAR connection thing), but I can't seem to make it work in NB.
Based on that link, My understanding is that the correct setup for the Android app is an Android Application project which references an Android Library project which in turn references a .JAR library produced by a Java Library project. I could then also have a Java Application project referring to the same Java Library project.
So, I've set up this project structure... I have an AndroidApp project which is a basic HelloAndroid Activity in a com.ex package. This project includes an AndroidLib library project in the Libraries folder. I also have a LibClass.java file which defines a simple LibClass class which has one function getText() that just returns a String to be displayed. The MainActivity in the AndroidApp calls this to get the String to output.
When I put LibClass.java directly into the AndroidLib project, everything is fine.
But what I want to do is to share the source code with Java.
So I want to move the LibClass.java into the JavaLib library, whose .JAR file is included in the AndroidLib project. However, when I tried that, I get an error in the MainActivity class, complaining it can't find LibClass. Looking at the Projects window, I can see LibClass.class inside the com.ex package in the JavaLib.jar in the Libraries folder of the AndroidLib project. And AndroidLib is visible in the Libraries folder of the AndroidApp project, but it doesn't show any packages or other contents there.
So I feel like I'm just one step away from making this work. Do I need to do something with one or other of the AndroidManifest files perhaps? Or do something with the build.xml files? Or am I on the wrong track altogether?
I'd be really grateful if someone could post a how-to for this.
I'm trying something similar; I've got Java EE projects, built using Eclipse, and I'm trying to utilize some of that code from my Android projects. This should give me a shared codebase rather than a bunch of confusing SVN externals which I've had to endure before.
Rather than creating JAR files I've found that working with the source and building for the platform works best (well, it has been working but I've got a problem with it at the moment). So, what I'm doing is:
c:\MySvnFolderStructure\MyJavaProjectFolder\src\ (and then all the source under that)
c:\MySvnFolderStructure\MyJavaProjectFolder\android\ (and all the Eclipse Android project gubbins)
c:\MySvnFolderStructure\MyJavaProjectFolder\jee\ (and all the Eclipse JEE project gubbins)
The Android and Java EE projects do not have their own src folders, they both link to the src folder in their parent folder. What this means is that each of the Java implementations is building its own byte code version from the source, and using its own external libraries (like the Apache HTTP ones, for example).
Naturally they can't share stuff like awt (as mentioned in another post), but there's plenty of stuff that does cross-over especially if it's core Java classes that are being used.
Also, it's proving a bit tricky writing JUnit tests as there needs to be some duplication of the test code at the moment because the Android ones need extra instrumentation, but I'm working on it.
Also, see this post about relative paths in Eclipse, which means the folders can be checked-out to different places on different machines (like we all do with our version control check-outs) and still be shared.
if I understand your situation correct, you are trying to use a custom java library for both your android and java applications.
For this scenario, you can build the java library first. Instead of adding the java library jar as android library, you can drop the jar directly inside the libs folder of android project and add it to android project's build path.
If you are using ANT scripts for building the java library jar , you can consider adding the source files also as part of jar. This will help you get code assistance when you develop the android part. But this part is purely optional.
The problem is that the Java platform in Android is different from the JDK platform.
In particular, the .JAR library CANNOT refer to anything that is not icluded in the Android platform. An example of things you can't refer to is java.awt.* (except you can have java.awt.fonts).
There is also a difference between JDK String and Android String -- Android does not implement the isEmpty() method.