# Android and Material Design

The new Android version, so far called ‘L’ and most likely winding up being called Lollipop when it will be released, has a new visual style called Material Design.

For Android this change of visual style means that the code base also needs to service both old API deployments (lower than v20) as well as the new ones (v21 and upwards). In effect this means you have to create res/layout-v21 and res/values-v21 directories to customize the layout and modify the styles for the new API.

In your module’s build.gradle you have to change the compileSdkVersion to 'android-L' and the targetSdkVersion to 'L'. If you have any dependencies on support-v4 or appcompat-v7 you need to switch those to v21.+ to pick up future updates, such as a different release candidates up to the released version.

# Revisiting Android and support libraries (support-v4 and appcompat-v7)

I have previously written on this subject, but now I am using IntelliJ IDEA 13 with the latest Android SDK of this writing (September 2014) and when you create a project you might be greeted by an error message like the following:

Error:Gradle: A problem occurred configuring project ':projectname'. > Could not resolve all dependencies for configuration ':projectname:_debugCompile'. > Could not find any version that matches com.android.support:support-v4:0.0.+. Required by: Projectname:projectname:unspecified > Could not find any version that matches com.android.support:appcompat-v7:19.+. Required by: Projectname:projectname:unspecified

The Android SDK has switched over to Gradle since I last wrote about it. In this case the default setup already searches the local libs directory under Projectname/projectname for any jars to compile with the build of the application. But if you would follow the instructions from my previous post the chance is high that you keep running into this problem. Aside from the installation of the Android Support Library, you will also need to install the Android Support Repository in order to make dependency resolution work. Do verify that your Projectname/local.properties contains a set property for sdk.dir that points to the root of your locally installed Android SDK.

Now, you might still run into problems. The thing is that in your Projectname/projectname/build.gradle you generally want to have the compile lines for support-v4 and appcompat-v7 match the version of your targetSdkVersion. So this might become:

dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:support-v4:20.0.0' compile 'com.android.support:appcompat-v7:20.0.0' }

These numbers can be found in the SDK under extras/android/m2repository/com/android/support under the respective entries for appcompat-v7 and support-v4. If you would use + for the version identifier, you run the chance of picking up the latest version, including release candidates and this might break your build. So in this case being explicit is better than depending on it implictly.

Edit: On second thought, it might be better to use 20.+ or 20.0.+ for the version identifier in order to automatically pick up bugfix releases down the line. Looking at the release notes of the support library it seems that Google is quite strict in sticking to semantic versioning.

# Eclipse and TestNG

I was playing around with Eclipse and TestNG, the thing you need/want to do is, after you have installed testng via de Eclipse market place and restart Eclipse to go to the project build path.

So right click the project and select from the popup menu Build Path » Configure Build Path...

In this window, make sure you have selected the Libraries tab in the right-hand side of the window.

Next select Add Library... and from the resulting window that pops up select TestNG (or JUnit).

When you select Next or Finish (depending whether you picked TestNG or JUnit), you will then see TestNG under the JRE System Library entry as another library entry. If you expand this you see the testng.jar being included and pointing to the right jar file that’s in Eclipse’s plugins directory.

When you now press OK you should see the imports getting resolved.

You will need to remove any external jar dependencies for TestNG or JUnit of course, because it’s double and will most likely lead to problems.

Now, when you go to Run » Run Configurations... you see a TestNG (JUnit) entry. When you select that entry and create a new configuration underneath it, it should already resolve everything you need (classes, packages, and so on).

Oh, do keep in mind that you will have to mark the test folder as a source folder for it all to work. Right click the folder, select Build Path » Use as Source Folder.

# Setting up Eclipse 4.2 as I like it

Download Eclipse 4.2 Classic 64-bits version from the Eclipse website. Extract the contents to a location, such as C:\Eclipse. Adjust the eclipse.ini in that directory according to my post in order to pin it to the taskbar.

Next, within Eclipse, go to Window » Preferences » Install/Update » Available Software Sites » Add... and add the following URL under something like “4.2-M builds”: http://download.eclipse.org/eclipse/updates/4.2-M-builds. After adding you can hit Reload to reload the information from the website. Exit all windows through pressing OK. Then follow up by going to Help » Check for Updates and you will most likely get an Eclipse SDK update right away. Accept the licensing terms and wait until it downloaded and installed everything and restart Eclipse.

Go to Help » Install New Software... » Work with, select the Juno entry and from the resulting list of software select General Purpose Tools » Marketplace Client followed by Next » Next, accept the license and Finish. Restart Eclipse when done. Now under Help is an entry called the Eclipse Marketplace.

Open the Eclipse Marketplace and search for and install the following: “code recommenders”, “MercurialEclipse”, “mylyn” (not selecting the Bugzilla connector). It might ask if it is OK to install unsigned content, acknowledge it.

You can enable support for certain forward version features via the android.support namespace. In order to accomplish this you need to start the Android SDK Manager and make sure that under the Extras heading you select and install the Android Support package.
Once done you go into the directory extras/android/support/v4 and copy the android-support-v4.jar to your own project’s libs directory. Next go within IntelliJ IDEA to File » Project Structure and under Project Settings go to Modules, make sure your application is selected in the middle pane, then on the right side select the Dependencies tab. In the window below click the plus-icon and select Jars or directories. From the resulting window browse to your libs directory and select the android-support-v4.jar and press OK to close the window and add the jar-file to the dependencies of the project. Since you are now using certain constants from a newer version of Android the Module SDK needs to be changed to Android 4.0.3 Platform as well. Press Apply and close the Project Settings by pressing the OK button.