I am looking now into re-architecting a library based Android App, so that instead of providing each library's functionality at build time (limiting its expansion to me only), I would just provide a base App and an SDK that would allow any developer to independently write a plugin.
I couldn't find many ways of accomplishing this on Android (unlike .NET's Unity dependency injection framework which supports independent DLLs). What I found was:
APK based approach:
http://blog.raffaeu.com/archive/2015/05/31/android-plugin-application.aspx
Service based approach:
http://androidsrc.net/creating-android-app-plugin-architecture-tutorial/
My question is: Are there additional ways of accomplishing this? (note: ways that are legal from Google Play's ToS)
Also, in your opinion, which of the two approaches that I listed above is superior?
Generally, if an app will accept some sort of plugins from other developers, those plugins are distributed in the form of APK files, whether through the Play Store or through some other channel. Those plugins may need different permissions than yours, for example, and that can only be accomplished if they are first-class citizens on the Android device.
Hence, a plugin is merely some other app that interacts with yours through some documented and supported IPC mechanism. The big four Android components — activities, services, receivers, and providers — are all possibly relevant for a plugin. It really depends on what you want the plugin to do and what the plugin needs from your app to be able to do it. In the abstract, we cannot tell you which of those to use.
Personally, if I were going to do this sort of thing, I would write the base app plus at least three plugins. The act of "eating your own dog food" when writing those plugins will help guide you towards what IPC mechanisms are needed. Even if, in the end, you ship the plugins' functionality directly baked into the main app, having "real" plugins will help shape your SDK, your security model, etc.
Related
Background
I was recently tasked to work on an SDK that Android developers could use via simple dependency (got this working for Jitpack&Github, here).
One of the tasks I was given is to use Firebase for remote-config and Analytics (and maybe Crashlytics too), to be able to gather statistics and have some control of it using the cloud.
The problem
All tutorials, articles and documentations (example here) that I see of Firebase are for Android apps, and so the preparation itself requires a package-name of the app to be set.
This is impossible for an Android library that is supposed to be used as an SDK, as it's meant for many apps, each has its own package name.
What I've tried
I tried to ask Firebase support about this, but they told me they can only talk about Android apps, and gave me a Github link (here), probably hoping I could get something out of it.
I also tried to ask on reddit (here), but nobody knew the answer to this.
Looking at the list of available, official SDKs (here), I think such a thing might be possible if I register as if it's a website (or web-application), and then in code I would reach it as a website (using REST API on Retrofit), but not sure if there is a better way, whether it will work, and whether it's even according to the rules of using Firebase (I think should be ok).
There might be a way to use the C++ library that Firebase offers, too, but this would probably require a lot of adjustments.
Seeing that this might not be offered natively, I even made a request about it., here.
The questions
Is it possible to use Firebase inside Android libraries? As an SDK? Is it according to the rules of Firebase?
How do I do it? Is there perhaps a library for this? Maybe a general Java library ? I guess I should also be able to make it focus on my SDK's classes and functions, and ignore what's on the app itself.
If there is no library, where can I find the various functions that are available for the various services, so that I would implement them?
in my company we plan to develop an app with different modules. We develop Apps for Apple, Android and Windows. We have some default modules like inventory and relocation, but for some customers, we need to develop custom modules. The question is, what is the best way to provide this app to our customers and how we can use update functions?
If we build one app with every module, and just unlock the modules based on the customers licence, it will be massive inflated, at the time. We have up to 20 customers and each of it needs 2 or 3 custom modules.
To build 20+ apps and distribute it over the store, it will be really difficult to manage each app. And if we update some core functions, every single app must be updated. Not a good way.
So what is the best way to develop custom apps for our customers and ditribute and update it?
sorry for my english, it's not the best..
So you don't want to include all modules in every app installation, and you don't want to distribute many different versions of the app, each one with a different combination of modules.
It seems to me that the only solution you have is to download your modules after the user has installed the app and chosen their license.
The easiest way to implement this is with a web app as opposed to a native app. However if you want to write a native app you are able to download and execute binaries at runtime.
This thread contains a few different approaches to achieve that:
Is it possible to dynamically load a library at runtime from an Android application?
Good luck!
I'm intending using Localytics (http://www.localytics.com) for an app which will be released on both iPhone and Android. My question is: Should I aim to use a separate app ID for the two platforms? I'd really like to just use one (so that all my analytics apply to both apps) but I notice that some things like "operating system version" just appear as a bit of a mess if I use the same ID for both.
There's nothing in their integration guide mentioning this - anyone have experience of this one way or the other?
I work on the Localytics SDK team and I'm happy to help.
While there is no technical reason you can't share a single key, we recommend keeping them separate. In addition to having a combined list of devices, operating systems, app versions, etc, your users likely behave differently on each platform. Using a single key will make it more difficult to see platform specific trends in your app usage.
I have a customer requirement to provide some proprietary business logic in a market licensed application. I've been reading up on Android services and I'm wondering what the best way to do that is. Is it possible to provide a local service through the Android market? It seems the customer would need source code to interact with a local service.
I am a .Net developer, fairly new to the Android world so I apologize if this is a routine question for the seasoned Android developer, but I've searched through other questions and haven't come up with the exact answer I'm looking for.
It's probably worth noting that although we are somewhat concerned about the possibility of de-compilation of this code to acquire the business logic, we believe we have enough back end server capability to protect us for the foreseeable future.
Thanks,
Lance
There is no requirement for an Android “app” (.apk) to actually contain any user interface. There's even a category in Android Market for such things. You can sell your component and have other apps provide the actual UI.
To provide complex services to another application, you define a bound service. You may need to provide some source code defining the interface for communication, to enable others to use your interfaces, but you will certainly not need to provide any of the “interesting” parts of your source code.
(Sorry for my english)
I'm new using Android (in fact, I'm just testing android) and I have a lot of questions...
Well, let me explain you the situation. In this moment, in my job, I am writing my code with C# and run it on Windows Mobile 6, the apps are used to make sales, send bills, reserves, etc. The devices (iPAQ 216) are given to the salesmen, and they must use the apps and update them via internet.
Each salesman have a unique client list, unique data and (in some cases) an unique set of apps, which means that I need to prepare a different package for each salesman. Using a Microsoft tool (cabwiz) I can prepare automaticaly a different package for each one of the 150 salesmen. They download their specific package using a tool wirtten by me, and install it and everyone is very happy (maybe)...
Is that possible in Android? How? and if it is not possible, do you know an idea how to accomplish somewhat like that...?
It's not going to be as easy as cabwiz, I can tell you that. But it would be possible, theoretically, to write a script that modifies/generates the unique portions of the source and then compiles a new copy for each user.
If the only difference between the apps is the data on them, then there is no need to generate a different package for each user: have the app download the data from your server and save it after the app is installed. You could also make some modules (I can only guess what kind of functionality you're talking about with regards to different apps per user) only accessible to particular users.
Yes, it's possible however:
You may want to look into writing in java rather than C# as that's more officially supported on android
There are some limitations of the android APIs, in particular there are basic behaviors of the device that can't be altered - without rooting there's no equivalent to the "hook" functionality of windows.
Make sure you get devices with the menu option to enable installation of applications from 'unknown sources'; otherwise deployment will be a lot more difficult. At that moment, this amounts to avoiding AT&T, as their devices presently confine you to the android market or physical connection to a machine running the developer tools as distribution channels. (As a work around you can upload your apps to the market and not publish them, though that won't fully keep them private unless you also include something to require authorization when they run. You could also install the minimal set of dev tools on the salesmens' laptops)
You will probably want to learn about the command-line application build tools and scripting in order to generate a custom apk for each salesman. Once the devices are set to allow unknown sources, you should be able to email the salesman the apk (or a link to it) as an attachment. You should also be able to make the custom apk refuse to run except on a device matching some fingerprint data you've previously collected. While you can develop for android under windows, you may want to look into switching to linux in order to make some of this scripting a little more natively elegant.