#uncategorized @en

[leifjanzik]

In almost every project, we need to configure something for different environments, e.g. different backend URLs. To that problem, I have seen various attempts at a solution to this problem, which, however, primarily required manual changes to the source code or copying and renaming of configuration files.

The next version of the Maven plugin for Android is offering an additional (and much more practical) option: defining of own constants in the BuildConfig class. You have to use the current snapshot (3.6.1-SNAPSHOT) at the moment in order to use this new function.

Since these constants are not configured in the source code directly, but rather in pom.xml, it is possible to redefine the values through various build profiles.

In our example, we simply want to configure the backend URL for development and production differently. Most builds will be built against the development backend, therefore, the development URL is the default value. We create a new profile for production called “production”. In addition to that, we assure that the “production” profile is also used for a release.

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://ift.tt/13J5Aq9; xmlns:xsi="http://ift.tt/Atvu06; xsi:schemaLocation="http://ift.tt/IH78KX http://ift.tt/19Bz6pF; [..] <build> <plugins> <plugin> <groupId>com.jayway.maven.plugins.android.generation2</groupId> <artifactId>android-maven-plugin</artifactId> <version>3.6.1-SNAPSHOT</version> <extensions>true</extensions> <configuration> <buildConfigConstants> <constant> <name>BACKEND_URL</name> <type>java.lang.String</type> <value>http://ift.tt/1m3YAB1; </constant> </buildConfigConstants> </configuration> </plugin> </plugins> </build> <profiles> <profile> <id>production</id> <build> <plugins> <plugin> <groupId>com.jayway.maven.plugins.android.generation2</groupId> <artifactId>android-maven-plugin</artifactId> <extensions>true</extensions> <configuration> <buildConfigConstants> <constant> <name>BACKEND_URL</name> <type>java.lang.String</type> <value>http://ift.tt/1m3YAB3; </constant> </buildConfigConstants> </configuration> </plugin> </plugins> </build> </profile> </profiles> </project>

If we simply call “mvn install”, the generated BuildConfig looks as follows:

public final class BuildConfig { public final static boolean DEBUG = true; public final static String BACKEND_URL = "http://ift.tt/1m3YABe;; }

But if we build the project against the “production” profile, the BuildConfig changes

public final class BuildConfig { public final static boolean DEBUG = true; public final static String BACKEND_URL = "http://ift.tt/1wM0fSq;; }

Of course, the plugin also allows to use your own or complex classes as constants.

<buildConfigConstants> <constant> <name>CONFIGURATION_ENUM</name> <type>my.package.MyEnum</type> <value>my.package.MyEnum.CONFIG</value> </constant> </buildConfigConstants>

And that’s it! With only very little effort, we avoid manual changes in our sourcecode and we are able to manage all information in one single place.

[leifjanzik]

As described in part II, there are different bugs and incompletions which render the release of the delivered app on the App Store practically impossible.

In this part, I want to briefly explain which parts I have made changes to before I published the app on the App Store. Overall, I didn’t spend more than 2.5h on this.

Delete unwanted content

When buying the app I didn’t know that, for example, my private Facebook profile would become part of the app, and since it has nothing to do with my blog, I simply deleted the tab bar with the social media links which only open in the web view anyway.

Necessary cosmetics

Being an experiment of mine, the app would of course also reflect on me in a way, so I prettified it with as little effort as possible. This was done pretty quickly, thanks to UIAppearance. Now the app looks like that:

Necessary legal changes

Of course the app didn’t have room for a publishing notice, which can hardly be expected since it’s a rather German phenomenon. Thus, I had to add the publishing notice as well.

The foreign account on the Google Analytics tracking was of course replaced with my own as well. I will probably remove it entirely on an update. For now, I wanted to leave it in there in order to change the app as little as possible.

First user tests and missing features

Prior to the Apple review, I showed the app to a few users in order to gather some opinions on it and to see, which features people expect from a blog reading app. The main points of criticism were:

lack of offline function

gallery on top is not recognizable and not clickable

links within the blog posts were opened in WebView as a website

videos were not played back clean in full screen

no pull-to-refresh for article/no loading of older articles when scrolling downwards

Thanks to Carsten Pelka, Mirko Lemme (mileon.net) and Kevin Grahl (kevingrahl.de) for testing the app and submitting feedback.

and now we wait..

The app has been submitted for Apple review. As soon as it has been rejected or published on the App Store, I will write the last part of this series.

[leifjanzik]

In almost every project, we need to configure something for different environments, e.g. different backend URLs. To that problem, I have seen various attempts at a solution to this problem, which, however, primarily required manual changes to the source code or copying and renaming of configuration files.

The next version of the Maven plugin for Android is offering an additional (and much more practical) option: defining of own constants in the BuildConfig class. You have to use the current snapshot (3.6.1-SNAPSHOT) at the moment in order to use this new function.

Since these constants are not configured in the source code directly, but rather in pom.xml, it is possible to redefine the values through various build profiles.

In our example, we simply want to configure the backend URL for development and production differently. Most builds will be built against the development backend, therefore, the development URL is the default value. We create a new profile for production called “production”. In addition to that, we assure that the “production” profile is also used for a release.

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://ift.tt/13J5Aq9; xmlns:xsi="http://ift.tt/Atvu06; xsi:schemaLocation="http://ift.tt/IH78KX http://ift.tt/19Bz6pF; [..] <build> <plugins> <plugin> <groupId>com.jayway.maven.plugins.android.generation2</groupId> <artifactId>android-maven-plugin</artifactId> <version>3.6.1-SNAPSHOT</version> <extensions>true</extensions> <configuration> <buildConfigConstants> <constant> <name>BACKEND_URL</name> <type>java.lang.String</type> <value>http://ift.tt/1m3YAB1; </constant> </buildConfigConstants> </configuration> </plugin> </plugins> </build> <profiles> <profile> <id>production</id> <build> <plugins> <plugin> <groupId>com.jayway.maven.plugins.android.generation2</groupId> <artifactId>android-maven-plugin</artifactId> <extensions>true</extensions> <configuration> <buildConfigConstants> <constant> <name>BACKEND_URL</name> <type>java.lang.String</type> <value>http://ift.tt/1m3YAB3; </constant> </buildConfigConstants> </configuration> </plugin> </plugins> </build> </profile> </profiles> </project>

If we simply call “mvn install”, the generated BuildConfig looks as follows:

public final class BuildConfig { public final static boolean DEBUG = true; public final static String BACKEND_URL = "http://ift.tt/1m3YABe;; }

But if we build the project against the “production” profile, the BuildConfig changes

Could not embed GitHub Gist 5896121: API rate limit exceeded for 85.114.130.136. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

Of course, the plugin also allows to use your own or complex classes as constants.

<buildConfigConstants> <constant> <name>CONFIGURATION_ENUM</name> <type>my.package.MyEnum</type> <value>my.package.MyEnum.CONFIG</value> </constant> </buildConfigConstants>

And that’s it! With only very little effort, we avoid manual changes in our sourcecode and we are able to manage all information in one single place.

[leifjanzik]

As described in part II, there are different bugs and incompletions which render the release of the delivered app on the App Store practically impossible.

In this part, I want to briefly explain which parts I have made changes to before I published the app on the App Store. Overall, I didn’t spend more than 2.5h on this.

Delete unwanted content

When buying the app I didn’t know that, for example, my private Facebook profile would become part of the app, and since it has nothing to do with my blog, I simply deleted the tab bar with the social media links which only open in the web view anyway.

Necessary cosmetics

Being an experiment of mine, the app would of course also reflect on me in a way, so I prettified it with as little effort as possible. This was done pretty quickly, thanks to UIAppearance. Now the app looks like that:

Necessary legal changes

Of course the app didn’t have room for a publishing notice, which can hardly be expected since it’s a rather German phenomenon. Thus, I had to add the publishing notice as well.

The foreign account on the Google Analytics tracking was of course replaced with my own as well. I will probably remove it entirely on an update. For now, I wanted to leave it in there in order to change the app as little as possible.

First user tests and missing features

Prior to the Apple review, I showed the app to a few users in order to gather some opinions on it and to see, which features people expect from a blog reading app. The main points of criticism were:

lack of offline function

gallery on top is not recognizable and not clickable

links within the blog posts were opened in WebView as a website

videos were not played back clean in full screen

no pull-to-refresh for article/no loading of older articles when scrolling downwards

Thanks to Carsten Pelka, Mirko Lemme (mileon.net) and Kevin Grahl (kevingrahl.de) for testing the app and submitting feedback.

and now we wait..

The app has been submitted for Apple review. As soon as it has been rejected or published on the App Store, I will write the last part of this series.