I am developing a Xamarin project for both Android and iOS. I would like to use a Xamarin Component (from the store) in my shared code base. Currently, I have created a "Shared Project", but it seems like it is not possible to add the component to this project. Is this correctly understood? And if so, is there some kind of workaround?
Thanks.
Add the component to all your platform specific projects and then you can use it on the shared project. If there are any discrepancies in the API's between the platforms you will have to resolve these with compiler flags or partial classes/methods.
http://developer.xamarin.com/guides/cross-platform/application_fundamentals/shared_projects/
A Shared Project does not get compiled on its own, it exists purely as
a grouping of source code files that can be included in other
projects. When referenced by another project, the code is effectively
compiled as part of that project. Shared Projects cannot reference any
other project type (including other Shared Projects).
Components are platform specific. To use platform specific code in a shared or PCL project you can use DI to pass a reference to a common interface into your shared code.
http://developer.xamarin.com/guides/cross-platform/xamarin-forms/dependency-service/
Related
I have read some sample codes, I find that many project use library module structure, you can see Image A.
Could you tell me the benefit to use library module in Android Studio ?
What code do I need to place it in library ?
And More, both app and lib module use the same namesapce in the sample code, I don't know if it's suitable, could you tell me ?
Image A
Library module gives you two options to create library Android and Java.
Android library module-> Android library compiles into an Android Archive (AAR) file that you can use as a dependency for an Android app module . It allows you to add android specific components like resources and manifest file, which allows you to bundle in shared resources like layouts and drawables in addition to Java classes and methods.
Java Library -> It builds a JAR file. JAR file is useful for many projects especially when you want to share code with other platforms. But it does not allow you to include Android resources or manifest files, which is very useful for code reuse in Android projects. So when you do not need any android specific resources in library you should create a java library.
Library modules are beneficial for projects :-
When you're building multiple apps that use some of the same components, such as activities, services, or UI layouts.
When you're building an app that exists in multiple APK variations, such as a free and paid version and you need the same core components in both.
Quoted from developer.android.com
Other than that same namespace is not problematic unless you have same package name inside App and libraries . You should use a different namespace for libraries.
PS-> If you are familiar with Clean Architecture, The idea behind most of the software design pattern is Separation of concern . In Clean architecture a project is divided into multiple modules. When you implement clean architecture in android you'll see that some of the module you can create as Java library like domain module. Creating module is really useful to follow re-usability and SOLID principles and Inversion of control.
Firstly, don't look into the package name declared in the java directory. Look into the manifest file. You can see that these modules have different package name. It means that all modules in a project must have different package name.
Regarding to your question, what are the benefit of naming library module as lib?
There's no benefit at all. Some people are comfort with lib name, so they can differentiate the demo and library module easily. However, using lib as library's module name requires you to add additional configuration in the lib/build.gradle, i.e. archiveBaseName. This Gradle attribute will rename the JAR/AAR from lib.aar to work-runtime.aar, so people can use it like this:
implementation "androidx.work:work-runtime:$work_version"
If archiveBaseName is not set, people will use it like this:
implementation "androidx.work:lib:$work_version"
In real case, let's take my open source library as the example, MaterialPreference. I used to use lib name on this project, but now I think lib is not a good module name. Using materialpreference as module name will remove additional configuration archiveBaseName. So I feel it is more simple.
I've been developing a library to use in my project, and while it is working locally, I would like to share it and use it as an external dependency.
How do I wrap my library so that built AAR contains both *.so native library and generated *.java classes (generated by Kotlin compiler) ? Because there are two-way interactions in my library: Kotlin external functions defined in C++, and some C++ code calling Kotlin classes and methods.
So, my questions are:
How to correctly package Kotlin + JNI android library ?
How to upload said package to Bintray so users (and myself) could use it as a dependency ?
(Note: I've seen tutorials and examples, but they were either Kotlin/Android or Java/Jni/Android)
If you want to package .so with your application, note that you can always put it inside JAR file. Then, you can unpack it, and load it using System.load.
You can find sample here: https://github.com/mkowsiak/jnicookbook/tree/master/recipes/recipeNo031
Note
Remember that packaging .so inside application is a risky thing. As you deal with native code, you have to be 100% sure that all native dependencies are there. You have to pay attention to architecture as well.
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...
I am currently working on an android project that requires me to make use of functions included in a shared library (.so). I also only have header (.h) files for the library provided to me.
Is it possible to work with just these two files? Or do I need to create my own implemenations via c++ codes?
I am using Android Studio intend to use CMake.
Regards,
Philip
Most Android apps are written in Java. Google has released the Native Developer Kit (NDK) in order to allow developers to write libraries in C++. However, these libraries are usually very low level and called from the Java code which defines the UI and higher-level app logic. Most likely you will need to write a wrapper for the library so that you can call it from Java code. Looks like this blog is a good place to start.
I am developing a system where I want to share WCF Service logic between an Android app and an IOS app
I thought the best way of doing this was to create a PCL which I can reference in both
I have shared code which I have packaged up into a shared project.
This is referenced by my PCL. So far so good!
However, as soon as I reference this PCL in my IOS app I get a problem, it appears as though 2 versions of ILocation, one for PCL and one from my actual project.
Am I right in thinking that the only way around this is to have my WCF code in a
I am experimenting with shared projects in Visual Studio 2013
I have an Interface ILocation which is included in my shared project
You just have to move ILocation.cs from SharedProject into Pcl project. Files in SharedProject will still be able to access ILocation type because SharedProject files are actually part of Android and iOS project.
Shared project is nothing more then group of files that are linked(added) into project referencing shared project. This is same as if you would have some folder in your solution folder called SharedFiles and add links to files in this folder from other projects(Android, iOS..). Compiling this projects results into generating new IL(intermediate language code) for each of this projects and types are conflicting. If you ever used common AssemblyInfo.cs and used file linking for this... Well this is same only difference is that you don't have to reference new file in each project but only SharedProject.