Thursday, September 17, 2015

Efficient CSS Using Child-Selectors

So, I'm working away on and I find myself forgetting this over and over. I figured it would be a good idea to write a blog post about it to remind me there's a better way. 

Here's a typical use of CSS to assign margin to some images: 

    .issuerpics { margin: 15px; }

<div style="text-align:center">
    <img src="~/images/home/logobluecross.png" alt="Blue Cross Blue Shield" class="issuerpics" />
    <img src="~/images/home/logoaetna.png" alt="Aetna" class="issuerpics" />
    <img src="~/images/home/logocoventry.png" alt="Coventry One" class="issuerpics" />
    <img src="~/images/home/logocigna.png" alt="Cigna" class="issuerpics" />
    <img src="~/images/home/logouhone.png" alt="United Health One" class="issuerpics" />

Note that each image has a CSS class assigned to it. It's a logical technique, but not the most elegant one. Below, the parent element (div) is assigned a class and then the CSS is written to style the child elements of that class. It's less code, more readable, and in general more elegant. 

    .issuerpics img { margin: 15px; }

<div class="issuerpics" style="text-align:center">
    <img src="~/images/home/logobluecross.png" alt="Blue Cross Blue Shield" />
    <img src="~/images/home/logoaetna.png" alt="Aetna" />
    <img src="~/images/home/logocoventry.png" alt="Coventry One" />
    <img src="~/images/home/logocigna.png" alt="Cigna" />
    <img src="~/images/home/logouhone.png" alt="United Health One" />

In general, it's best to make the code as readable as possible. Less code is usually better as long as it doesn't sacrifice readability. This change accomplishes both. 

Thursday, August 14, 2014

Lime ORM for Android

Hey friends. I wanted to let everyone know I've released a little library called Lime for Android. It's an ORM layer inspired by Microsoft's Entity Framework. I feel it has a few advantages over some of the other layers out there.

  • It's fast. Lime uses reflection to populate objects from cursors, but object inspection is done only once and cached. 
  • It's efficient. Lists of objects are backed by cursors so scrolling through huge data sets only requires conservative memory allocation. 
  • It's flexible. Most layers in Lime are exposed to make using as much or as little as necessary a simple matter of choice. 
  • It's familiar. Lime works with Android's content providers, observers, and loaders. It's all the things you already know, but easier. 
Stop by the Lime site on Bitbucket and take it for a spin. I think you'll dig it. 

Wednesday, July 9, 2014

Pull To Refresh on Android with SwipeRefreshLayout

In March of 2014, without much fanfare, Google added the SwipeRefreshLayout widget to the Android SDK. This addition formalizes the pull-to-refresh mechanism on Android. Let's take a look at how we'll use it.

First, make sure you have R19.1.0 or newer version of the Android Support Library in your project. R20 is the first version of the library to include the new layout. Once it's in your project, create a simple activity layout with the SwipeRefreshLayout at the top of the view hierarchy. While this isn't explicitly necessary, it makes sense that the entire activity be pulled down to refresh.

It is explicitly necessary that this layout have only one child. In this example, we'll make the only child a TextView for simplicity. Here's a look at our activity layout:

< xmlns:android="" android:id="@+id/layout" 

   <TextView android:id="@+id/text1" 
   android:text="@string/hello_world" />


Now that we have the layout added, we'll need a little code to make the refresh happen. The new layout has a method to setOnRefreshListener. So let's take a look at our activity with that listener connected:

public class MainActivity extends Activity { 

   SwipeRefreshLayout layout; 
   TextView text1; 

   OnRefreshListener refreshListener = new OnRefreshListener() { 
      @Override public void onRefresh() { 
         text1.setText(new Date().toString()); 

   @Override protected void onCreate(Bundle savedInstanceState) {
       layout = (SwipeRefreshLayout)findViewById(; 
       text1 = (TextView)findViewById(;
       layout.setColorSchemeResources(color.holo_blue_dark, color.holo_blue_light,color.holo_orange_dark, color.holo_green_light); 

Notice that we need to call layout.setRefreshing(false) when our refresh code is finished. This method stops the animation and let's the layout know that our work is done. Typically this would be called when a loader in the activity completes. 

Also, take a look at SwipeRefreshLayout.setColorSchemeResources. This method allows you to choose 4 colors to be in the animated bar while the layout is refreshing. 

SwipeRefreshLayout is a great addition to the SDK and goes a long way to standardizing a user interaction method. Implementing will give your users comfort that their app is acting in a standard fashion and also save you space on the ActionBar where your refresh button previously would have been!

Thursday, August 9, 2012

Emulating the Nexus 7 Display Properties

Ahh the new Nexus 7 tablet is a sweet piece of hardware! On top of that, it's selling like mad. Are you on the waiting list, but need to make sure your apps are ready for it? This blog post is about creating an emulator image to emulate the display of the Nexus 7.

Before we start, please read the Android developer blog post on getting ready for Nexus 7. It's a good start to our discussion. Getting Your App Ready for Jelly Bean and Nexus 7.

Now that you're up to date, you know the new tablet is one of the first to sport the tvdpi screen density. If your app isn't ready for it, you might be in trouble. So, what do we need to do to set up an emulator for this density?

  1. Open AVD Manager and create a new virtual device named "nexus_7".
  2. Unless you have set up the hardware accelerated emulator set the "Target:" to Android 2.3.3. This will run fast enough to test your apps for the display. Note that you're not creating a real Nexus 7 emulator but this will be sufficient to test your app for the display! If you really want to test Jelly Bean, you'll want to set up the hardware acceleration for your emulator. Hopefully we'll discuss that in another blog post.
  3. Set up a sufficient SD card size. 
  4. Under "Skin:" choose resolution and specify the Nexus 7 resolution of 720 x 1280. Note that we put 720 first because we want the emulator to start up in portrait mode just like the device.
  5. Under "Hardware:", choose an Abstracted LCD density of 213. This is tvdpi!
Now you're set! When you start the emulator you will probably want to set the Launch Options to scale the display to 8 inches, especially if you're on a laptop screen. Now you should be able to test your layouts for the new Nexus 7. Have fun. 

Saturday, February 18, 2012

AT&T Mobile App Hackathon Dallas

I'll be attending the upcoming Hackathon this weekend representing the Dallas GTUG. Get signed up on Eventbrite! There are still a few spots left.

About the Event:
 Mobile App Hackathons is an event geared towards getting your app, business or idea venture to market! We will provide on-the-ground technical support, known as "senseis", from AT&T, Microsoft, Amazon, HTC and others to help you accelerate the execution of your ideas/business, rapidly kickstart a prototype mobile application and spin-off a successful venture.

Cost: FREE
Kickoff: Friday, February 17, 2012 6:00PM-8:00PM
Hackathon: Saturday, February 18, 2012 at 10:00AM-8:00PM
Sign Up:

Monday, November 7, 2011

Startup Weekend Google Tech Bootcamp

I'm excited to annouce the upcoming SW / GTUG Bootcamp. There will be lots of good Android information and a code jam to get you ready for Startup Weekend. Here are the details:
Startup Weekend - Google Tech Bootcamp
Admission $5
Saturday November 12, 1:00pm - 5:00pm
ng Connect Gravity Centre
2900 West Plano Pkwy Plano, TX 75075
The following topics are on the agenda with more to come soon:
  • Android Cookbook - Scraps and Ideas for Startup Weekend 
  • Getting Started with App Engine
Keep an eye on this page for updates!

Monday, September 26, 2011

Software Versioning

This post describes a strategy for version numbering software builds. We’ll assume that we have 4 digit places to work with. Before we look at how to version a build, let’s look at the audience for each section of the version number. In this example, we’ll use version v1.2.35.76.

Each section of the version has a different “owner”. By investigating what each part of the organization requires from a version number, we can plan a numbering system effectively.

Numbering Versions: 

The first two sections of a version number are owned by marketing. I mean "owned" in that the marketing organization should control what appears here. Imagine that this is the customer-facing section of your version number. From a marketing perspective, code changes may result in an increment from v1.2 to v.1.3 or we may decide to jump to v2.0. If we imagine that marketing owns the first two digits, none of the rest of the business is impacted by these decisions. We can do what's best and most meaningful for the customer.

 The third section (35 in our example) is owned by the Quality Assurance and Testing organization. In most cases, QA will want this number to perpetually increment with each build they receive. So, if they’ve just received version X.X.34.X, they will expect the next version to be X.X.35.X. This number should never reset to 0! Having assigned the 3rd section completely to QA, we can assume they will ignore every other section. Marketing will be free to increment (or decrement) the first two sections and dev can have their way with the fourth.

The fourth section (76 in the example) is owned by the development organization. Each time a build is produced to be shared outside of the developers desk, this number should be incremented. This way if a manager reports an issue, the question “What build do you have?” will always yield a useful answer. This number should also never reset to 0! By constantly incremental this number, dev will always know where a bug occurs when it is reported.

When to Version: 

As we’ve said, the final “build number” section of the version should be incremented each time a build leaves the developers desk. But when do we change the other numbers? The answer is as soon as possible.

For example, let’s say you’ve just delivered v1.2.35.76 to QA. Your very next code change should be to increment the QA section from 35 to 36 because you know that all further changes will be targeting the 36 QA release.

Similarly, as soon as marketing decides that there is funding to deliver a v1.5 of the product, we should increment our first two digits. Anyone can look in our source code system at any time and know that we're contributing code to what will become the revision 1.5.

By incrementing immediately after you generate a release, you’re ensuring that if someone pulls a build at any time, they will have the correct version number.