So... I'm trying to create a plugin for one of my apps. This plugin would require several views, images, an activity and a parser for CharSequences... Ideally, this plugin would be downloadable from the Android Market.
I understand how to create a library, but that would need to be included in the application.
I understand how to create an app as a service and just call it via intents, but I need direct access to objects and code that is neither parceable nor serializable.
What I have been looking at is eyes-free TTS. With their implementation, the developer includes a small TTS_library_stub.jar file in their app, which looks like it defines a lot of the necessary classes/objects.
So my question is, how would I go about building something like this and generating this "stub" .jar file, which would be included in my app? I've been trying to work my way through the TTS code, but it's a massive codebase, and I'm having trouble finding what I'm looking for.
Any help would be massively appreciated :)
The service and the app need to have the same sharedUserId in the manifest and be signed with the same key. Then the app and service can share eachothers assests, classloader and even run on the same thread. I have never included part of the GUI in a service, so maybe that is a limitation...not sure.
If there is a limitation, you must be able to work around it. Look at OpenIntents. It is open source, it is a service and you can download that from the Market. It provides a GUI file browser to any app that uses its intents.
Didn't full understand what you needed, but thought this might help.
If you want android library to be downloaded from market, It has to be standalone android application. (not android library project!). Then you can upload it to market, download it to phone and communicate with it via intent(which this library can handle) or service(aidl) or provider(the data from library) and perhaps receiver, but I never used it in that way.
If you would design your app for an OSGi environment like apache felix it might be possible to load libraries at runtime.
In their presentation they described how the whole concept is working.
Since only APKs can be shared in the android market you would need to write your own "update mechanism" which downloads your OSGi bundles (your plugins) and deploys them to felix.
Related
Background: I have an android application that has been published in GooglePlay and I want to create SDK from that existing application so that others can use it as a library inside their apps.
So far: I was able to generate .ARR file from the existing app source code with little tweaks. and it is working pretty good.
The problem: is I have some sensitive information stored inside my app
since I made .arr file from my app codebase I'm little worried that they can easily get access to my SharedPreferenceManager (util class of mine to deal with SharedPreference) DataBaseManager so on and they can subclass library class and tweak the behaviors
So How can I avoid library users not to misuse my library to exploit my existing app?
is there any other way to export my app as a library?
The basic process would be as follows:
Figure out what you want to expose in your SDK
Move all of this into an android library module
Deploy the AAR
Can you explain a little more what you mean by "I'm little worried that they can easily get access to my SharedPreferenceManager (util class of mine to deal with SharedPreference) DataBaseManager so on and they can subclass library class and tweak the behaviors" ?
You can always utilize obfuscation techniques and finalize classes to make it difficult. I don't think you can guarantee absolutely no misuse, but I am not sure how this would effect your application. If you have a server, for instance, then you would still control the software there and be able to sanitize and sort through the input.
The internet is full of solutions where someone with no coding experience can design an app, and then have it deployed to their phones via another app. So for example you can log on to appsheet, create all the parameters for an application, then download appsheet to your phone. from there, you log into your appsheet account, and download any of the apps you have created.Does anyone know how this is accomplished?
My use case is that I have an app that I would like to offer to Universities, but would like each universities' mobile application to be custom built for their needs. I have developed web, android and ios apps in the past, and have a Software Engineering background, so I am looking for the right methodology to accomplish something like this. Are there any specific frameworks or technologies you would advise me look at to accomplish this tasking? If you have any questions or concerns for me, please do not hesitate to ask!
I work at AppSheet. There are two basic approaches an app builder can follow: (a) act as a code generator, or (b) implement an intepreter. In the former case, it spits out code that gets compiled into an executable package that can be installed and run on a device. In the latter case, the "app" you define is meta-data in a higher-level definition that is interpreted in a host wrapper app. Each has its strengths and weaknesses. AppSheet uses the latter approach.
My bet is that they just have one universal, configurable app which they configure for your specific needs by generating a config file or something like that, and then packaging it all up into an apk.
Your idea is great but that is not possible. We cannot imagine every scenario to build such app. We have to imagine for each scenario and have to code for such scenarios.
Presently in my Android system, I have developed a native library to communicate
with a connected media device over linux driver and we are accessing it from an
apk application via the Java native interface. This has been working fine till
now.
But we also have another application which needs to access the same native library
in parallel with the first application. As expected, because of the different data
section for the linked native library in the new application this approach is not
working.
To subvert this, we though of writing a new service/application which will be linked
with the native library and other applications access the APIs using binder calls to
this new service/application.
My question is:
Is this new approach feasible? Can someone help me with a better approach.
If yes, then we also need to return buffers in the API and some of the APIs are
callbacks. Can these types of functions be handled using the binder interface?
Thanks,
Ashutosh
Build an external library in a jar that provides the higher level API which in turn accesses the native library. Then use this jar library as any other lib. You may have to check how to put the .so file into the jar file to have a single library file.
I believe that the service approach is exactly how opencv achieves this.... specifically, OpenCV has a manager in thr app store. You can develop an app that implements BaseLoaderCallback, which gets the .so library from this manager. Behind the scenes, this uses a Service, ServiveConnection, and aidl to get the library... if memory serves me right.
Update...
Now that i think about it, i think OpenCV manager might just be passing the path to the library, which can then be loaded with the System.load command, which accepts the library path.
I'm producing an application for multiple clients. Each of these apps only slightly differs (in the ui presentation) from the others and almost all of the other code is identical.
In the best case scenario I would brand something like a boot-strap app for each client so they could have their logo on a separate app in the market. Once a user installed a client's app it would download the core functionality, set some prefs and launch as if it had come from a single download. This way I could get the benefit of updating for bug fixes once rather than for each application (slated for 20-30 by end of year.) I've read that this isn't possible because of security measures though (and additional visits to the market place for the second download or having to allow installation from unknown sources isn't acceptable.)
I'm thinking that worst-case/only-case might be to include this shared code in each application and create some batch build and deploy once updates are ready.
I'm looking for a .dll like approach for economy of effort and safety.
I'd appreciate any input on this.
Thanks!
The java equivalent of a dll is a jar file. You can extract all of your shared functionality into a library project that compiles into a jar and then include that as a library in your other projects.
If I needed to build an android SDK that other developers can integrate into their android apps, is jarring my SDK the only way to go about it? As far as I have learnt, jarring has the following considerations:
If your app uses a layout, then you have to create it programmatically. Since jar files cant carry any resources.
The jar will needs to be placed in the lib/assets folder and added to the build path (in Eclipse) -- Learnt here: Android - Invoke activity from within jar
The main app will have to create an Intent object and specify the package and class name in the jar to start the activity.
Any one have other ideas of going about any of the above steps?
Thanks
George
Creating a JAR is, in my opinion, a very bad decision. Android has specific features just for the kind of thing you're looking for. If your JAR:
provides some sort of (structured) data to be used in other applications, use a ContentProvider;
does some backround processing and makes that processing's results available to other applications, use a Service;
provides an Activity that gets some input from the user (or shows some information about something), eventually processes it and returns it to the calling Activity, just create that Activity and any application will be able to start your Activity as long as it's installed on the phone.
If you use one of the three solutions above, third party apps will be able to probe for whether your application is installed and, if not, prompt the user to install it. Only if your application does not fall into one of the three bullet points mentioned above should you use a JAR. Otherwise, using a ContentProvider, Service or Activity provides:
More standardized interaction between components
Better maintainability -- if you update your SDK you won't have to call everyone who uses it and tell them to upgrade.
No duplication -- if you were to provide a JAR and multiple applications that use it would be installed on a device, multiple copies of the JAR would be present on that device, thus using more memory than it has to. If you provide one of the three components mentioned above, one copy will satisfy all applications that need to use it.
Again, these components are specifically designed and provided by the Android OS for creating such SDKs. Please, only use a JAR if you really, really have to. Otherwise, provide a standardized ContentProvider, Service or Activity and document the way it's supposed to be used (i.e. how to use/query/integrate it).