Android applications can grow very quickly. As they are composed of components (Activities, Services and Content Providers), it should be easy to extend an existing application to create new applications by just reusing already developed components. Recently, the akquinet Mobile Team had to develop several versions of the same application with a different set of features. This might sound easy, but Android does not really support such kind of modular development. Indeed, we faced several issues coming from the Android development model.
This blog post explains the encountered issues and how we fixed them by using rindirect. This tool allows, inside an Android application, to integrate components defined in other Android applications. This reuse pattern is close to impossible to achieve without rindirect or implies major limitations. Rindirect is developed by akquinet and is now available as open-source. This tools is well suited for Maven-based development, and so, works pretty well alongside the maven-android plugin.
Despite of not being in widespread use in the Android world, Apache Maven is a great tool to develop Android applications. Maven has a lot of advantages relevant for Android application development:
- It can be integrated on a continuous integration server, allowing continuous testing and nightly-build delivery
- It provides a strict release process avoiding errors and inconsistencies. The resulting APK are ‘marketplace-ready’
- It also provides a common way to build and package the applications
- It supports modular-development allowing the integration of classes and resources from others projects
This post explores how to quickly start developing Android applications using Maven. It presents three archetypes allowing getting a running application in less than 2 minutes!
Developing sophisticated Android applications is challenging. Despite tools provided with the SDK and the recommended ADT Eclipse Plugin, maintaining and developing an Android application is time-consuming.
This blog post introduces a series on the rationalization of Android application development. It aims to explain how the akquinet mobile team have changed the way to create Android applications to improve the efficiency and quality of the developed applications. This series covers several topics, from the utilization of Apache Maven, the integration with a continuous integration server to the customization of the logging framework.
akquinet has participated in the improvement of all the tools used and presented in this series and has also released several internally developed components as open-source projects.
The last post of this series has introduced a couple of useful options to manage built modules in a multi-module project. This post focuses on failure. Maven proposes three different way to manage failures in reactor builds: fail-fast (default), fail-at-end and fail-never which will be described in this post.
How do you test your JSF application? Using JSFUnit allows you to perform integration test of your JSF application. The tests are run inside the container. JSFUnit tests can access the internal state of your application. The JSFUnit documentation describes how JSFUnit can be integrated into a Maven build environment. It leverages the maven-cargo-plugin and the maven-surefire-plugin to deploy the tests to an application server and execute them using JUnit.
However this is only explained for a plain Web archive (.war). It remains unclear how a JSF application can be tested which is packaged within an Enterprise archive (.ear). Continue to read if you are interested to see how we used JSFUnit to test our EAR based JSF application and how we integrated it in our Maven build environment.
The last post of this series introduced you to a couple of useful options to manage dependencies in maven. In this post, we’ll focus on multi-module builds — a.k.a., reactor builds. Starting with version 2.1, Maven provides a couple of very interesting options allowing to avoid re-building all modules after a small change. This can save a lot of waiting for the build to complete and is what this post is all about.
This post is the first post of a Maven-related series. It focuses on the Maven command line that can do a lot more than just mvn clean install. This first post explores the options to configure the dependency resolution like using another local repository, forcing updates, and working offline.
Are you developing an Apache Ant based Maven Plugin? Do you have problems to use the Maven Ant Tasks from within your implementation? In the following article we describe what steps are necessary to use the Maven Ant Tasks within an Ant based Maven plugin.