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.
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 6 years ago.
Improve this question
I develop an app for both iOS and Android, and I'm loon'ing for the best way to share code between this two platforms.
What I would like to do is creating all the View (UI part) in native but share the code for the logic (controller + model).
With all I found, 3 things seems to be quite good :
1) C++ --> Build library file Using c++ For the logic so I'll be able To use the .dll files in the 2 platforms
2) Azure mobile apps services. Is it possible to habe all the logic in a webservice? The issue is that if I dont have acces to internet, my app will be unaivalable, right?
3) I hear a lot about React native used by Facebook, but it seems to be used to create the UI, but I prever create it in native. Can I use react only for logic?
It seems like you have three options:
1. C++
You can't just have a compiled .dll and expect it to work for iOS and Android. They both have to be compiled in different architectures and it has to be a static library on iOS.
Dropbox's done it this way, and they've put up a lot of notes and example code, and code you can use so you can take a look.
Pros
• Pretty straightforward after you manage to set it up
• No additional layer of dependencies, bugs, etc (like in case of Xamarin/React Native)
Cons
• Setting it up and using it needs a lot of extra work: you need to setup additional compile steps and write wrappers for both platforms.
• Some other challenges you're surely going to meet when trying to compile the same code for two different architectures
Here's a SO post on how to do it in detail...
2. Xamarin
This option seems to extreme to use in this case. You're forced to use C# and introduce another layer of dependencies and bugs. You said you don't want to use another language for UI so I wouldn't recommend it.
3. React Native
Now this is a viable option. You can write scripts in JS and use them in native code in both Android and iOS.
Here's an article on how to share code with code examples...
Unfortunately it uses React Native for UI, but you can easily call React Native functions from native code.
There are a lot of downfalls to using this, including the fact that the calls are asynchronous as they're executed on another thread, so you would have to implement some kind of callback system for functions that return something.
Pros
• Seems to be easy to set up and write
Cons
• You'd have to implement a native callback for every function that returns something
• Using it has a lot of downfalls that the document describes:
• As events can be sent from anywhere, they can introduce
spaghetti-style dependencies into your project.
• Events share namespace, which means that you may encounter some name
collisions. Collisions will not be detected statically, what makes
them hard to debug.
• If you use several instances of the same React Native component and
you want to distinguish them from the perspective of your event,
you'll likely need to introduce some kind of identifiers and pass them
along with events (you can use the native view's reactTag as an
identifier).
Conclusion
I think I'd go with C++, mainly because a big company (Dropbox) tried it and succeeded and actually uses it in production. You could try React Native as an experiment, it would make a great study case!
I'd say that putting the "core" logic into a separate library is a sensible approach.
You are not the first who wants to do this, and I highly recommend looking at Djinni. It's a tool to accomplish just that. You can define common interfaces and datatypes and fill in the native parts. Communication is possible in both ways.
It's not as easy as writing the whole thing natively at once, but it supports clean design which you might benefit from anyway.
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"?
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 does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
THIS QUESTION HAS MOVED TO https://softwarerecs.stackexchange.com/questions/27841/plugins-architecture-for-an-android-app
I want to implement a plugin system for an Open Source app, because it has become really large, with many features that only a few users need. Releasing different apps is not a good solution, because userA wants feature7 and feature24 whilst userB wants feature39 and feature24.
Where can I find a good example of a plugin architecture?
Here is what I would like a plugin to be able to do:
Redefine the layout of a particular screen (load deflated XML?)
Redefine a method of a class (load dex class?, AOP?)
For instance, one of the plugins must add a button on a particular screen, and clicking this button increments a value in the app's database. This is not doable with Content Providers and Intents, as far as I know.
I want to avoid making the core app's code complex with tons of hooks everywhere.
The form of the plugin could be a file on the SD card, an app, or anything else.
I have done a framework that works like Robo-guice with some of its primary IoC functions. (Cut down on boilerplate codes that load views/service etc...)
But the core of which, I believe is the solution to your problem, is the ability to load separate APK "plugin" files, that includes "res" as well as <layouts>.xml files. The <layouts>.xml file can be independently inflated by the classes within that APK. That is, you can load a CustomView (that inflates its own <layout>.xml) into an originating/parent App. All this is done without the Parent App APK knowing how the UI was inflated in the plugin APK.
Example of what I mean:
I have a Mapping App, the framework will dynamically scan installed APK that matches the "contract" for a "add-on function" plugin, and loads the UI specific to it onto the App's View as a floating panel.
I would say a plugin framework for Android is do-able, as Android has most if not all of the necessary built in APIs to accomplish this.
These are your friends in this area of plugin development for Android:
PackageManager (Scan install packages, aka Plugins)
DexClassLoader (ClassNotFoundException will be a pain if you don't use the correct ClassLoader btw)
Java Reflection
Where can I find a good example of a plugin architecture?
Roman Nurik from Google has implemented a nice plugins framework in his open source app dash clock. The plugins themselves are Services that extend the DashClockExtension class in the API and are installed as completely independent APK files with their own resources. It's quite a lot of work defining the communication protocol via the AIDL, but it's nice and clean and works very well.
one of the plugins must add a button on a particular screen, and clicking this button increments a value in the app's database.
The parts of the main Layout which can be modified by the plugin will need to be pre-defined by the core app, and exposed via the communication protocol. It should be possible for the plugin to inflate an arbitrary layout, and send it to the main app, which could put that inside a pre-allocated area of it's own Layout.
If you are just going for an increase in modularity, I would recommend using a dependency injection container such as PicoContainer, Guice or Spring.
If you want a light-weight plug-in architecture, then go for Java Plugin Framework (JPF).
It allows you to define extension points, which can be implemented by your modules. The primary job of the plug-in framework is to provide a way that you can bundle these modules (as jars), which are dynamically found by the core application and given as implementations of the extension point.
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 7 years ago.
Improve this question
I am about to start android application development.
From What is NDK? documentation I was not able to extract the following information:
Does using NDK actually introduce new features comparing to SDK?
I am interested in this because using NDK greatly increases application complexity, so if I am not interested in performance increase, are there other reasons to go for NDK?
What I mean is for example:
-restart phone
(I know neither SDK nor NDK allows this, I just use it as an example of what I mean) let's say java SDK does not allow this, but some native libraries do - then the answer to my question would be yes, NDK does add some functionality
Thanks in advance for any helpful answers.
You really should use SDK, unless you have a good reason to use NDK. Good reasons may vary, but for example, you could use NDK:
If you want to use OpenGL ES 2.0 for Android 2.1 (Eclair), it is only avaiable through NDK. The SDK support for OpenGL ES 2.0 began with the Froyo version.
If you want to use Renderscript
If you have a great portion of your app's logic written in C/C++
The NDK is much more limited in terms of functionality.
What you do get from the NDK is the ability to write your app in C++ and compile it to native ARM code. If you like C++ better than Java, if you have an existing C++ app that you want to port to Android, or if you just need the extra performance that only native code can offer, then by all means you should use the NDK.
I haven't done this myself, but another alternative is to write hybrid app, where the app is written mostly in Java, with selected functions written in C++ that are called from the Java code.
The only reasons to use the NDK as far as I know is to squeeze extra performance out of your application and get closer to the bare metal. If you don't need to do either of these things, you should probably stay away from the NDK.
Also note that the Dalvik VM already has some pretty awesome performance and comparatively simpler.
For me, I think it’s important to know the NDK which is a powerful tool in the development of mobile applications. Especially if you want to develop a multiplatform application, the NDK is unbeatable in this domain. Since the same code written in C + + for Android can be easily ported and run the same way on the iOS, Windows or any other platform without changing the original code. Which actually save a lot of time in the development of applications which are developed for being run on multiple platforms; as games and other classic applications. Thing you cannot do with the SDK.
Native methods are platform-specific code. They are usually written in languages such as C or C++ and contained in libraries(dll's). It is possible to create a hybrid Java application that benefits from such libraries.
Reasons for Using Native Methods
Gaining access to special capabilities of your device or or Android
OS
Gaining extra speed
Gaining access to a large body of existing legacy code
Typically, good use cases for the NDK are CPU-intensive applications such as game engines, signal processing, and physics simulation
The major disadvantage of native methods is that you won't have cross-platform capability.
Now if you don't know what native code is, then probably you don't need to use native code. Android NDK documentation explains this well:
..., you should understand that the NDK will not benefit most apps. As
a developer, you need to balance its benefits against its drawbacks.
Notably, using native code on Android generally does not result in a
noticable performance improvement, but it always increases your app
complexity. In general, you should only use the NDK if it is essential
to your app—never because you simply prefer to program in C/C++. When
examining whether or not you should develop in native code, think
about your requirements and see if the Android framework APIs provide
the functionality that you need.