Code Zen

I have been getting more into Android testing lately, especially for a core library that we use within our team that may be shared across projects and may have different developers modifying it to suit there own needs. Not making sure that every commit doesn’t break the code for someone is a recipe for trouble (and I have been there). To avoid that as much as we can, last week I set up an continuous build environment that can run tests against the core library on every commit.

The parts:

• AWS: There are a bunch of advantages of using AWS, but the biggest advantage is the availability of preconfigured stacks called AMIs that can be deployed immediately on an EC2 instance.
• Jenkins: Jenkins is a pretty popular continuous integration server. Jenkins is deployed as a Java War Its used at other parts of the company too so I can seek help if I get into trouble.
• Github: Github is a very popular code hosting service. We have been using it for a bit and its been very convenient for code that needs to be shared or open sourced.

Steps:

• Select the Bitnami AMI from the AWS marketplace and deploy it on a new EC2 instance
  • The AMI creates a couple of users on the server: A default “bitnami” user and another “tomcat” user thats actually starts up a Tomcat server thats has the Jenkins app deployed.
  • The Bitnami AMI has also created a user named “user” with password “bitnami” that you can use to log in to Jenkins. You can at this point decide how you want new users to be added to the system and who has access permissions.
  • If the deploy works, you should be able to go to the root of your server and see a link to the running instance.
• On the left nav, click on Configure link to set up global configuration for your install
  • Click on plugins and make sure to install / update the Git plugin and the Android plugin
• Under Manage Jenkins  >  Configure System
  • Make sure Ant is set up to download if needed
  • For Android make sure “Automatically install Android if needed” is checked
• Create a new Job and choose “Build a free-style software project” 
• In the configure tab, under the Source Code Management section, choose Git and paste the Github URL for the project.
  • Note this part is a little buggy. The problem that took me way too long to realize is that the Tomcat user doesn’t have Github.com in its list of known hosts. Follow the steps here to fix that.
• On the server, as the Tomcat user, create your ssh keys that you will use to authenticate your pull requests with Github. See Github’s guide for doing that here
• Add the public key in the account for an authorized Github user (May not be a bad idea to create a new Github user just for build purposes)
• Log in to your Jenkins account on the web again and in add your private key against the user account in the user settings section. Conveniently, Jenkins can read ssh keys from the running server but you may need to enable that.
• At this point the system is pretty set up. Now make sure your Android project is set up for testing by following the guide on the Android Developers site. At the end you should have 2 projects: Your main application and a test application. Both will have Ant based build.xml files that you will have Ant on Jenkins run. Commit your projects to Github.
• You can point to the build.xml
  file you want to execute. If there is a build.xml
  at the root of the project that’ll be executed by default.
• You should now be able to build your project explicitly at least. Go to your “Job” and click build now.
• You can then set up automatic builds by going into your project settings on Github and go to > Service Hooks > Jenkins (Git Plugin) and pointing it to your server url.
  

Thats it. Now every time a developer pushes to Github, Github will notify Jenkins, which will pull your repo and run the appropriate build file.

Continue reading “Setting up a continuous build environment for Android with AWS, Jenkins and Github”

One of the most commonly overlooked parts of building Android applications is touch feedback. While some views like Buttons have touch feedback built into them, thats not the case when using custom views.

The Android Design Guidelines explicitly talk about the UX part of touch feedback and it was also discussed a while back on the Android Design In Action YouTube series:

The problem is that there are no clean standard hooks in the Android framework to implement these. The only implementations I have found have been:

• FrameLayouts have a foreground property that can be used
• ViewGroups like the ListView that extend the AbsListView class have a property called “drawSelectorOnTop” that can be used to draw the background selector on top of your custom item renderer.

Given the lack of default apis in most of the common layouts, one approach that you jump to (like I did) was to listen to touch events and change background on touch down  and up. This is hard to implement perfectly because a touch event can be canceled in a bunch of ways. For example, a user may be swiping across your view and you may still end up showing touch feedback which would be wrong. In our app, we often ended up with views stuck in an incorrect state.

The Android framework’s selector system (or rather the StateListDrawable class) handles a bunch of these situations appropriately already. The best approach therefore is to create a selector and the apply that to your view. Setting that selector as your view’s background though will draw that under all the views on top which doesn’t work either. To fix that, the best approach is overriding the dispatchDraw method and then after calling super, calling your new drawable’s draw method within the bounds of the View, something like:

@Override
protected void dispatchDraw(Canvas canvas){
super.dispatchDraw(canvas);
touchFeedbackDrawable.setBounds(0,0,getWidth(), getHeight());
touchFeedbackDrawable.draw(canvas);
}


The one gotcha here is that the base ViewGroup does not invalidate custom drawable invalidated automatically, so this is something you have to do by overriding a different method:

@Override
protected void drawableStateChanged() {
if (touchFeedbackDrawable != null) {
touchFeedbackDrawable.setState(getDrawableState());
invalidate();
}
super.drawableStateChanged();
}

Props to Rich Ratmansky for solving this quirk.

The final result looks something like this:

I have created a sample project to show the experience. You can find the project on Github. This works well, but as you can see it does require a custom ViewGroup class. If anyone from the Android framework team is reading this, having a “touchFeedbackDrawable” property would probably be really useful extension to the framework.

[Update] Had an interesting discussion on this on Google+, whether touch feedback should be shown in a view’s background or foreground. The consensus seems to be background as long as the background is fairly prominent/visible. For opaque content like say images, foreground feedback is pretty much required.

Most developers know about the different ways to specify dimensions of visual elements in Android. While setting dimensions for visual elements is usually done in “device independent pixels”, it is recommended to use “scale independent pixels” (sp) for type. The Android OS provides a setting (under the Display category on stock Android) where users can set the default minimun font size of all applications to small, normal, large or huge, an important accessibility feature for users with poor eyesight. Any text fontSize set in sp’s will scale up or down to respect this setting.

That said, you may want your textView to not scale up or down with the settings. Setting the TextView value to some sp value in the layout.xml file will do that. However if you are setting the text size in code, remember that even if you do read the dimensions from a dimen.xml file with values set in dp, the value returned cannot be used in textView.setTextSize (value) since it will interpret those values as sp’s regardless. To set dp values, use the other setTextSize method that takes an additional parameter: how to interpret the numbers being read.

TL;DR: Use setTextSize(TypedValue.COMPLEX_UNIT_DIP, xx) to set dp values to textviews