I would like to have a little bit of information before starting a new android project. I have read that the android-maven plugin works nice and smooth... Is that true?
And more important, what are its possibilities? I have something in mind.
Let's say I want a modular application. Thus, I want an app made of apps (all of them android-maven). Imagine I have an app for log in in some server, an app that connects to a service1 to get some information and another one that gets information from another service2.
Can I create three individual apps (log in, service1 and service2) and then use them as a dependency on a container maven app?
Is is worth it?
Thx! E.
Maven is great project management and build tool, and can be used to build android applications with proper plugin ( maven-android-plugin IIRE provides apk packaging )
But you do not build PAK from another apks, but plain java jars - zou can tap whateveryou like form wast maven repository of jars but have to keep in mind that not every java jar or framework is usefull, makes sense , or will run on android.
There is no such thing as "container app" on android - but you can define dependencies
to other apps and android library porjects. And applications can (and should) communicate via intents and exported services.
Related
I searched a little about this here but didn't found anything that helps me, maybe because it's impossible but I need confirmation.
The situation is the following:
I have an android app that integrate with many mobile POS, these card machines, and because I have many classes to integrate with these machines, the app became heavy for some POS stores, like Stone.
I saw that it's possible to impplement the libs modules and dependencies for specific flavors with android, so I would generate an specific appp, with just the classes that this integration use and nothing more, but I have everything together now, just like in the pics.
And when I build an app that will be used with Stone, for example, it will put all integrations in the JS interface.
I stated changing it, imlementing by flavor but as the implementation is per integration now, the Cielo class starts having problems with its dependencies because, as the app will be for Stone, it doesn't download the Cielo dependencies. The generation process crash.
When I started changing the structure, I manage to make the gradle build work, but after that, everything crashes.
There is something I can do ? Maybe impost only when the Cielo package really exists, or something like that.
If its needed to change the entire structure, it's ok, I just need to make it smaller but still in one place.
Thanks!
I tried useing flavors and separating the source sets alongside main directory, like:
-main
--assets
--java
-cielo
--java
-stone
bus it still have a problem when building because the import inside my main class.
You can split your application to multiple parts:
Main application which implements the app's features except an integration.
Android service API which defines API between the main application and an integration service
Integration services one for every platform. Each service have to implement API from point 2 to provide required contracts to the main application.
Finally you can deploy the main app and only one required integration service.
I wanna write an android application which can be extended with modules (android libraries). The modules shall be loaded at runtime. Therefore they'll be downloaded from an url and stored in a directory.
The modules are aar files.
Is there a way to load aar files dynamically at runtime?
I know it's possible to just load the contained classes.jar with an URLClassLoader. But than I can't load the layout, string, ... resources. HM
Does anyone know a way how to solve this?
EDIT:
I found a few related topics:
Dynamically loading aar library
https://stackoverflow.com/questions/25919338/is-possible-to-include-a-dynamically-aar-file
Write Plugin for Android App
Plugins architecture for an Android app?
How to develop an app that has add-ons?
Android - Build an application that supports add-ons
It seems that it doesn't work because of the answer from the first link. I hope I'm wrong with that thinking.
I'm having a kind of similar problem.
i want to add plugins on runtime without forcing the user to reinstall the app.
I found a very good chapter called "Plugin Patterns" on "The Busy Coder's Guide to Android Development" book. I am still reading it so can't really say if it covers exactly your needs but it contains plenty of information that might be useful for your case.
Here is a sample of the chapter, found on the books web page, so you have an overview of what it covers
For the purposes of this chapter, a “plugin model” refers to an app (the plugin “host”) that is being extended by other apps (the
“plugins”) that are largely dedicated to that job.
Certainly, there are plenty of ways that apps can work together
without one being a plugin to another. The user’s Web browser is not a
plugin of your app when you call startActivity() to view a Web page,
for example.
By contrast, the Locale app can be extended via plugins, written
either by two forty four a.m. (the authors of Locale) or third
parties. These plugins have no real value to the user other than by
how they improve what Locale itself can do. This sort of structure,
therefore, qualifies as a plugin model.
In particular, this chapter will focus on two general scenarios for
wanting a plugin model, though others certainly exist:
You want to allow third parties to extend the capability of your app,
much as two forty four a.m. wanted with Locale, or You want to reduce
the number of permissions in your core app by delegating some
permissions to plugins, so users can “opt into” those permissions
I hope that helps a bit.
There is a gradle plugin that can help to decouple aar into resources and dexes. Check this out When you are building your project with inject dependency this plugin extract aar and merges resources with your project resources, than merges manifests and after that collects all jars(inside each aar and just jar dependencies) and creates a dex file which you can upload to any server and at runtime download that dex and load.
It's quite often that we see two versions of an android app: a paid version and a free version. I'm also developing an app that would like to release two versions. What is the best way to do this? Creating two projects and copying files in between does not seem to be the best way in my mind.
Use Library Project, as the official dev guide suggested:
If you have source code and resources that are common to multiple Android projects, you can move them to a library project so that it is easier to maintain across applications and versions. Here are some common scenarios in which you could make use of library projects:
If you are developing multiple related applications that use some of the same components, you move the redundant components out of their respective application projects and create a single, reuseable set of the same components in a library project.
If you are creating an application that exists in both free and paid versions. You move the part of the application that is common to both versions into a library project. The two dependent projects, with their different package names, will reference the library project and provide only the difference between the two application versions.
Update: This method is really only good for compiling with Eclipse, since Android Studio supports build flavors which can achieve exactly this.
While #yorkw's and #Nate's answers are both good, this is the method I use due to its simplicity. From the article:
com.example.myapp – Android Project Library - This is where my ENTIRE app lives. All the functionality for the FULL and LITE versions.
com.example.myapp.full - Android Application Project - This is a shell that contains graphics and resources needed for the full version only. Basically it’s a super lightweight shell.
com.example.myapp.lite - Android Application Project – This is another shell that contains nothing but graphics and resources needed for the lite version. Again, its a super lightweight shell.
I also keep a static variable IS_PRO in a library class which is set when the app launches. This should be used only for notifications, alerts, and so on (such as asking the user to upgrade to pro).
However, this method has one drawback: you must clean and rebuild any time the library or its resources are modified. Also be sure to read this post on sharing resources between a project and a library.
I would call this a FORK in development. Start a new App development, but have your common code coming from a common file location. Make your free based edits to the forked code, and try your best to keep that code completely separate.
I actually did this on an iPhone based app, I have a free version and 2 different payed versions (a single player only and a multi-player). I would do it the same way on Android.
U can use git for example.
Create branch "app_with_ads", and master will be your "paid" version.
Develop in master and merge periodically to another.
before publish u probably will have to change app package, or something else in Android\ Manifest.xml
Here's a little blog tutorial about doing this.
Basically a howto for building a Full and Lite version of the same app, using a library project to accomplish code reuse between the two versions.
We have a program that we wish to deploy across multiple devices.
Standalone Captive AIR
Web based flash app
iOS app
Android app
The code other than some UI stuff is identical in a lot of parts. I'm wondering what's the best approach. Should we have a shared library project or should we have one big project with different complier settings controlled through ant or some other method.
Accessing and using Shared Library Project is the best way to be implemented for cross platform Projects. Other than this Approach you can use ant Build.
The answer would ordinarily have a lot to do with the "UI stuff" that's different, but since it sounds like you're Flash/AIR, that's probably not a big concern. If it were me, I would go w/ the "one big project" approach, and get a serious CI/NI and SCM suite that was compatible w/ my IDE. If you're using Eclipse/Aptana, I like Husdon/Surround. (Full disclosure: I used to work # Seapine.) If you're not using Eclipse, you should check out the CI/SCM options that integrate w/ your IDE (and themselves; e.g., Hudson has a Surround module and vice versa). The shared library thing works, but since Flash is Flash darn near everywhere, I don't see the need for the increased division of separate projects. A full-featured CI can manage the compiler differences for you quite effectively.
We're using this combination of approaches for a large scale mobile/web project that currently exists in the IOS AppStore, and will soon be released on Android and the web:
One main project that uses compiler directives to handle specific platform logic and elements
Compiler directives to handle specific platform logic within the main project codebase
A separate project for our video and interactivity engine, which is mostly platform independent, using switch statements for platform specific logic
One shared SWC for graphical assets. Platform specific elements are prefixed with the platform and an underscore. Compiler directives are used to specify which movieclips get displayed on screen
Ant scripts to do the compiling for the various platforms
Native Extensions to interface with hardware specific features
We use some commercial, some open source, and some homemade ANE's for things like AppStore integration, social media features, network monitoring, notifications and inter-app communications.
com.adobe.extension.NetworkInfo.ane
com.milkmangames.extensions.EasyPush.ane
com.milkmangames.extensions.GoViral.ane
com.milkmangames.extensions.StoreKit.ane
(I have no affiliation with milkmangames)
I'm currently writing an Android ANE to handle inter-app communication using Intents. It's a project I'm open sourcing at:
https://github.com/interactivenyc/ANESampleProject.
I'm currently stuck on a problem there and will be posting a question very soon with the details if anyone is interested in following that project. The project setup is fairly well described in the ReadMe file displayed on the front page of the project.
If you use git for versioning take a look at submodules. I used it to keep everything in one project, but versioning each module separately, and it resulted a fine solution.
i have to setup an android maven build for a customer, which previously was based on ant.
The base app is a white label implementation and the app is distributed to several third party customers. Each of those customer versions uses the same source code and a set of shared resources. But every customer also has some resources specific to their company (constants, assets, etc).
The structure of my android project looks like this. I only included relevant files/folders and the structure is remained from the ant build:
App
|--src
|--res
|--res-customer1
|--res-customer2
|--pom.xml
This means i have to build multiple .apk artifacts from the same source with different resources. What is the best approach to do this?
The first thing i tried was to use different profiles in my main projects pom for every customer. Then i wrote a shell script to execute all maven builds (1 per customer).
Then i came up with using only one release profile in my main project and passing the customer specific properties via command line. Properties are passed via a shell script, similar to my first approach.
But i'm not happy with that, so i thought about using multiple modules. One per customer. But my problem here is, how i can build those from the same source without copying the source from my main project over to all modules?
Or do i have to setup an android project for every customer and refer to my main project as apklib? Will this merge the shared and the customer specific resources?
Is there a best practice to do something like this?
Any other approach is also very welcome.
For only small differences it can be sufficient to just use profiles and a few different properties with resource filter. Profiles however are a bit of a bad pattern in the Maven world and can be hard to work with.
Your hunch to use separate modules for each customer and have the base application be an apklib is correct. I know of several people that have reported on the maven android developers list that this is what they use and works for them. I would personally use that approach in your case as well.
In general I would suggest to ask or at least mention this question on the mailing list.