Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I need a WP8 project and an Android project. Until now I have only seen a PCL called Core which is linked to all platform projects. The problem is, that I have platform specific references, which I need to include, depending on the platform. How can I handle this?
I have also seen this: https://github.com/Redth/WshLst . This project has no PCL and uses cloned projects.
Which way should I go?
There are 2 ways to share code as you state. The PCL approach and using file linking (cloned).
With file linking, you normally use #if directives to specify platform specific features in your core. Like:
#if MONOANDROID
var androidGlobal = this.GetService<Cirrious.MvvmCross.Droid.Interfaces.IMvxAndroidGlobals>();
_geo = new Geolocator(androidGlobal.ApplicationContext);
#else
_geo = new Geolocator();
#endif
With PCL projects, you would typically create an interface, then create separate platform specific implementations.
So you may have an ILocationWatcher in your PCL core project. Then you can create a WinPhone.LocationWatcher and Droid.LocationWatcher in each of the platform projects.
Usually you would use some sort of Inversion of Control (IoC) container to register the patform specific type at startup. Then your Core project would get an instance, either via dependency injection or resolving via the IoC container. Your core PCL would program strictly against the interface and not have to worry about the specific implementation.
This is how MvvmCross plugins work. Pretty much all the plugins come with a core interface and a platform specific implementation.
Which way you should go depends on your app and your needs.
Platform specific resources can be injected into PCL using Service Location and Plugin techniques:
https://github.com/MvvmCross/MvvmCross/wiki/Service-Location-and-Inversion-of-Control
https://github.com/MvvmCross/MvvmCross/wiki/MvvmCross-plugins
N=31 in http://mvvmcross.blogspot.com
Alternatively, you can use shared code with partial classes, #if, etc
Advantages and disadvantages of the 2 approaches are discussed in this excellent answer - What is the advantage of using portable class libraries instead of using "Add as Link"?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 months ago.
Improve this question
I am building an Android SDK in Kotlin that would be consumed by both Kotlin and Java users. It relies of common language patterns for Java & Kotlin like callbacks for async operations. In order to improve DX for Kotlin coroutines users I want to add modified versions of various callback operations to use Kotlin's suspending functions, Flows, etc.
I see that the common pattern, used by e.g. Android KTX or OkHttp, is to put coroutines overloads in a separate package, often named xxx-ktx or xxx-coroutines.
1. Are there any downsides of including coroutines support in the main library package?
Afaik it might increase method count, which might DEX method limit, but this could be addressed by proper Pro-guard config to allow removing unused coroutine related methods.
2. Are there any other considerations for adding coroutines to the main package vs having it in a separate package?
1. Are there any downsides of including coroutines support in the main library package?
Apart from what you have mentioned, adding the additional dependency in your main library also exposes the new Coroutines related methods as public API surface from your main library. Which will make harder for you to evolve your library. If it would have separate library you can opt for different compatibility schemes for the add-on library
Also since these dependency will also be added as a transitive dependency for the client, it will can also make their project setup difficult. One example could be let's say you add Room database then client app also has to configure the kapt.
2. Are there any other considerations for adding coroutines to the main package vs having it in a separate package?
In my personal opinion, you should always design your library as abstracted as possible and design all the nice to have integration as seperate libraries. You can expose adapters where any external implementation can hook itself. Similar to the designs followed by Retrofit
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I want to develop an App for iOS and Android. For easier maintenance I want to have a shared codebase where the business layer and all the algorithms are implemented.
But I don't want to program the whole application in for example Xamarin. I would like to develop the presentation layer in Xcode and Eclipse and use a framework which has implemented the business layer, algorithms and so on.
It is very important for me that the presentation layer is programmed in the corresponding development environment (Xcode, Eclipse) and the shared codebase is implemented as a framework/dynamic library.
I tried Xamarin (Mono) and Qt for iOS but it seems like there is only the way to develop the whole application in this development environments.
To sum up what i wanna do:
/--> iOS App --> implements framework --> .app
shared codebase* --> framework --<
\--> Android App --> implements framework --> .apk
* e.g. Java / ObjectiveC / C# / C++ / Xamarian / Qt or whatever
Do you know any development environment or a trick how to do this whith Xamarian?
I googled a lot and didn't found anything which helped me solving this problem. I also know that here on stackoverflow are some questions covering this topic but they didn't completely answer my question.
Thank you a lot for your answers!
Xamarin allows you to create business logic in C# and use them for both Android / iOS / Windows Phone. You have to write your view logic also in C#. Xamarin has ported the API for both iOS and Android to C#. You can still use the designer tools from xCode (I guess for Android as well) and use them in your project. But it's true you'll have to use Visual Studio or Mono Develop to create your app.
So you either use the xamarin solution or you'll have to create a cross-platform library in C/C++. For iOS you can indeed just add C++ code. For Android you'll have to use the NDK. You'll have to use JNI (Java Native Interface) to be able to let the Java and C++ code talk to each other.
NDK: https://developer.android.com/tools/sdk/ndk/index.html
JNI Tutorial: https://code.google.com/p/awesomeguy/wiki/JNITutorial
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm looking into porting an application called ygopro (source code here) to Android. I was just wondering if anybody can help me out by telling me what would be the best way to go about doing this? I would prefer to not spend more than about 60 hours on it and I certainly don't have the time to go through and rebuild everything from scratch. The code is in C++ and there are about 5,500 Lua scripts to do various things. Is there any easy way I can port this?
First, you'll note that the graphics library used by this project is based on has been ported to android.
There are two demos available for that project. Those will show you how to write an android application that uses this library. I suggest you essentially hack your projects source into the framework they provide.
In terms of Lua, again you'll want to use an existing port. Many of the Lua ports are oriented towards allowing access to LUA from Java via JNI, but you just want a Lua shared library out of them to link to from your C++ code. You will probably want something like AndroLua rather than the Android Scripting Environment. Pretty much, add all the folders in it's jni folder to your Android.mk includes, add it as a library, and you'll be good to go.
In terms of actual porting, I'm assuming that the project currently compiles happily under GCC. If that is the case, as you try to build it, it will complain about functions that are platform specific, and you will have to replace these. That should be manageable, if you are slowly adding code to the graphics framework demo as suggested. Beyond that, some libc functions are missing, but generally only rarely used ones.
Hope this helps. It goes without saying that you should complete some Android Native tutorials before starting. This project is more than a weekend.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Intro: I have a native library (C++) with Java (JNI) wrapper. The library engine is cpu intensive, we don't want more than one app linking this lib to be running at the same time, and complex objects should be returned by the lib engine.
The question: What is the best way to engineer such an Android library?
So far, I could find just find 2 valuable examples: OpenCV manager and Connectbot ssh-agent.
I can think of a few solutions:
Solution 1: Make a (bound or AIDL) service that wraps the library functionality. (should the service run in its own space? or in the space of the application that links to it? how can the native lib be loaded if it's in a different app space(System.load("/data/data/com.company.myLib/lib.so")). How to return complex objects in AIDL?). This should be the Connectbot way.
Solution 2: Divide the lib into 2 components:
A standalone package which keeps the native libs + a manager service
An android lib-project which only contains Java wrappers which users can use to build their apps.
This should be the OpenCV manager way. I don't know exactly the details, but this way one does not need a service to interface with and can just import com.company.myLib.LibWrapper. On the other side the LibWrapper class should perform System.load("/data/data/com.company.myLib/lib.so"). Correct?
I would personally go for solution 2. Unfortunately Android is a new land and there are not many models yet on how to develop a library. Is there any other/better solutions? Is there other considerations to make?
Consider the following scheme: you build an "empty" app that contains no activities, no settings - only the manifest, the icon for "manage apps" list and the native lib that is installed by the system in /data/data/package/lib directory.
This native library may, but doesn't have to expose JNI functions. In a typical situation, this lib will be a straightforward port of an opensource LGPL library - e.g. libdmtx.so.
The "client" apps will call loadLibrary() for the "external" lib, and after that it will call the usual load() for its JNI wrapper. This lib has the only purpose to translate Java methods to the public C APIs of the external lib.
The JNI wrapper and the corresponding Java class may be distributed as a .jar or as sources, they are not bound by LGPL license of the external lib.
Such scheme is, IMHO, the only way to ensure LGPL compliance on Android: anybody can recompile the "external" lib from the open source, package it as an "empty" app and install it on their device.
Regarding your concern about concurrent access to the lib, I actually doubt that it is so important: the high end devices have four cores more powerful each than one core on cheaper devices. OTOH, it's easy to use Linux synchronisation methods, e.g. named pipes, to keep track of active instances.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've been looking around, in vain, for some information on using a dependency injection container in Android development. Specifically, how to override the creation of an Activity in a way that will also work when coming back from being killed (for whatever reason).
Has anyone got any experience in this area?
It appears you can use Google Guice 2.0 with Android. You might also look into roboguice.
Edit:
Spring is also now available for Android
Edit:
Roboguice is now deprecated. You might try Toothpick as mentioned in the comments by the developer behind Toothpick.
You might also want to consider Spring ME. Although originally intended for Java ME, I have seen reports from people using it for Android as well. The benefit would be that you have a familiar programming model (Spring) without the penalty: Spring ME has a 0k footprint.
If you are used to use Spring in other projects, you won't be very happy with Spring for Android (it's only a REST library with Auth support), Spring ME (completely different workflow and reduced featureset) or Tiny Spring (e.g. only Spring-like configuration).
You could however give my project RoboSpring a try. From the description:
RoboSpring is a (real) port of the Spring Framework to the Android platform. Additionally it offers preliminary support for functionality introduced by RoboGuice like injecting View references into Activities and more. RoboSpring is based on version 3.1.0 RELEASE of Spring's core, beans, context and aop components. It offers the following functionality:
Configure application components with a Spring configuration file
(XML)
Autowire your Android components with beans from the Spring application context.
Inject the Android application context into your Spring Beans.
Inject views into Activities.
… and more
https://github.com/dthommes/RoboSpring
There is also a new Spring project for Android: Tiny Spring. It solves the very basics of XML configuration but doesn't do everything that Spring does.