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.
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 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 6 years ago.
Improve this question
I have an app that has about 10 different components (chat, feed, profile, settings, etc').
I need the ability to create multiple apps that each one of them will have a number of the components.
example:
app1 - will have chat settings and profile.
app2 - will have feed and settings.
How should i approach this?
I was thinking of building each component as a library and then for each app that i need to build a just connect the pieces like a puzzle.
Would this be the correct way? Or does anyone have any better suggestions?
Thanks
You can develop an "SDK" project (like the Facebook SDK) which includes all the components (chat, feeds, profiles, users etc.) and you can use that "SDK" as a library in other projects. Use whichever components you want for that particular app.
This approach will make the "SDK" project maintainable and easily upgradable. When you are adding a new feature (say, albums) you can integrate it into the "SDK" project and use with the existing applications.
An extensible, modular design of this sort is often quite useful for building larger scale software or software designed to handle a wide range of unanticipated future needs, especially if you're mixing in bottom-up approaches.
However, effective ways to approach this vary somewhat depending on the language and tools you are using.
An awkward part is how to make modules able to talk to each other when needed so that you can effectively piece them together like lego blocks. This will often become a practical need as the complexity of your software grows to a point where it will often cease to suffice to simply have modules completely decoupled from each other as stranded islands and only one "master" module to communicate with all of them. Often your needs will grow to require them to start talking to each other.
For example, if you are using a dynamic scripting language like Python, then it's easy for each module to publish its own public interface and you can start making modules talk to each other that way almost effortlessly.
If you are using a compiler and statically-typed language like C or C++, then this becomes a lot more awkward to make each module publish its own unique interface which is being directly imported and used by others. There you face the need to make headers accessible to all modules, worry about preserving ABI as you make changes, etc. A larger number of changes will break ABI and break other modules depending on a particular one's interface, so there we tend to design a bit differently.
In such cases, you almost always want a central software development kit containing all the abstract interfaces. Then your modules implement those interfaces and still communicate with each other, albeit indirectly (plugin A talks to SDK interface which is indirectly communicating with another plugin, B). The SDK establishes that central headquarters of communication, relaying messages from one module to another.
There is a core ERP mobile application for Android. A customer has requested additional features that will require more screens (and Activities) and extra functionality.
Is there a way I can add sort of an extension to the core mobile application in order to intergrate the extra features or should I code on top of the code of the core application?
I am interested in finding a neat solution focused on extendability since different clients might ask for different additional features. How would you deal with such an issue? Any tips on the structure of such a project would also be welcome.
Would it make a difference if the extra features need to use the same db as the core application?
Thank you in advance for your help.
The answer to your question lies in the Open/Closed principle introduced by Bertrand Meyer. Open/Closed Principle is a very simple Object Oriented Design principle which states that
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"
From your question its clear that you have identified the core functionalities in your application. So rather than Modifying this core functionalities and making it more specific, I would recommend, on the basis of the Open/Closed principle, that you should freeze your code features and write your customer specific functionalities over it without corrupting the core.
Now to answer your question on what kind of structure you may follow. I would recommend that you create a library project of your core functionalities and make different client specific projects that would include your core functionalities as a library project.
It won't make a difference if your application is using the same db as your core application provided all your applications uses it, else it should not be in your core application in the first place.
Hope this explanation help you.
Update:
My friend pointed out that I may not have understood the question right. So rather than correcting my old post(...which may be useful for others) I am updating it.
So if I understand it right, you have an ERP project which you may not have coded. The right approach, according to me,still would be that you build over this existing code. Rather than making changes on this project, include it as a library because if the project is downloaded from a reliable source, you will have the benefit of getting the updated version as and when it is available.
This is kind of a design philosophy question. Here are a couple choices that might give you ideas:
You could look into making your core application code/features into a custom library. Then your new core application is just a simple wrapper that includes the custom library. Your additional features for a specific customer could then be a different app that also references the core library but will include additional features. There are lots of tutorials on how to turn your app into a custom library. You would end up with different apps that target different a customers. (A tip that took a while for me to uncover is that if you have a resource name in your custom library you can "override" it by using the same name in the app that includes the library. Another tip is that you need to essentially duplicate the manifest of the library in the app by listing all the activities in the library that would be used by the app.) I haven't tried this but it might be that your additional features are each libraries that are included in different apps.
You could have an key the user inputs that will unlock certain features. You could save this as a shared preference so that they don't need to keep entering the key. This approach has the benefit that you can "reuse" features for other clients without any more implementation other than determining which client gets what feature. The majority of users just wouldn't have a key to unlock anything.
Both these solutions should use the same db since they would be calling the same core classes, etc.
Another possible solution is to create a Library Project. Put your core ERP app code inside the library Project, and then create different project for different customers. Each one of these projects will also use the same library project.
Your core library project could expose an api to dynamically register new features (Such as a menu that can expose new menu items).
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 2 years ago.
Improve this question
I've few questions on Android Framework. Can someone please answer
them
What does an Android Framework
do? What is it's job?
What are these managers -
Activity Manager, Location Manager
etc? Are they APIs or libraries?
I heard that the definition of
a framework is - a set of libraries
that say “Don’t call us, we’ll call
you.” So can I say that Activity
Manager, Location Manager etc are
such libraries? Or is it that they
are not libraries but APIs (used to
access underlying c/c++ libraries)
and the actual libraries that do
"Don't call us, we'll call you."
are hidden from us?
The android framework is the set of API's that allow developers to quickly and easily write apps for android phones. It consists of tools for designing UIs like buttons, text fields, image panes, and system tools like intents (for starting other apps/activities or opening files), phone controls, media players, ect. Essentially an android app consists of Activities (programs that the user interacts with), services (programs that run in the background or provide some function to other apps), and broadcast receivers (programs that catch information important to your app). The best way to learn this system will be to go through the Google Tutorials found here
AcitivityManager and LocationManager are examples of classes found in the android sdk (the framework). I do not know of any use for these classes, as I believe they are part of the system. I have never used them, but if you wanted to learn more about them i would look at the Android API
I believe your question is a bit 3 dimensional:
A library is a code source that a developer and add to their application. It is not source code, thus the inner details are hidden to the developer. You can only access the visible (public) parts.
An API is the documentation that accompanies a library to explain how to use the library (an example of this is the Android API listed above)
So to answer your question, ActivityManager and LocationManager are neither libraries nor APIs. Rather, they are classes within the Android SDK (which is a library) that are used by either the system, or the developer (if he can find any use for them). Also, everything in android is Java, so you wont find any C/C++ libraries for android
I hope that this answer was helpful for you.
The Android Framework is the entire stack of stuff that makes up the OS. This is the underlying Native libraries that are not directly accessible, the layer above that that you actually interact with and the code that developers write to run on the system. Yo are confused about Libraries vs APIs. Libraries are just chunks of useful code, APIs are the interface to those libraries. API actually stands for Application Programming Interface. The Managers do exactly what it says on the tin! The Activity Manager is the class that manages Activities, the Location Manager manages your current location.
Android framework is a set of those classes and methods whose fuctionalities can be selectively overridden by the user like examples content providers,activity managers,Location manager,Telephony manager etc.
Activity manager or Location manager are the classes whose methods can be override to use it as per the need of the output of the programme.
Android framework has APIs which are provided for android application development. Using these APIs, apps can access android functionalities like Wifi, BT, NFC etc.