Generate JUnit assertions from your JSON


Got some JSON you want to build into a model and test?

It can be pretty tedious writing all of that code. Instead, why not generate the assert* code automatically? I’ve been writing code manually for a while now and finally decided to build something to write that boilerplate code for me.

I’ve put up a live version for anyone to use, as well as open-sourced it on GitHub. Let me know what you think!

Here’s some JSON to test with:

     "id": 2,
     "name": "An ice sculpture",
     "price": 12.50,
     "tags": ["cold", "ice"],
     "dimensions": {
         "length": 7.0,
         "width": 12.0,
         "height": 9.5
     "warehouse_location": {
         "latitude": -78.75,
         "longitude": 20.4

Wi-Fi issues on Moto X 2nd Gen


I received my 2nd Gen Moto X today. During setup, I attempted to connect to our company’s Wi-Fi network to no avail. I was able to connect to another public Wi-Fi in the area but for some reason not to our typical Cisco WAP setup at work. All of the other devices we have at work are able to connect to the network, so I’m not sure what is going on.

I’ve contacted Motorola customer support, supplied a logcat output of the Wi-Fi-related messages during the connection attempt, but they were not immediately able to resolve the issue. Instead, they’ve gathered my information and will be reaching out to me after escalating the issue internally.

I’ll follow up more here as this issue and hopefully resolution progresses.

UPDATE 1 [2014-09-26T14:30:00EST]: Motorola has called me back and are currently connecting me to their “level 2 support”. I’m on hold now waiting for them to chime in. Will update more as this progresses.

UPDATE 2 [2014-09-26T14:40:00EST]: Motorola got back on the phone with me and explained that their level 2 support is currently swamped and that they have my information and will call me in the next 24 hours.

In the meantime, I’ll just blow through my carrier data allocation as I install all of my apps again (because I had to reset my phone to see if that’d solve the problem).

UPDATE 3 [2014-09-27T14:07:00EST]: Someone by the name of ‘Matt’ followed up on this blog in the comments to ask me to bring the conversation to email. So, I did. The conversation so far is as follows:

Me to them

From: Dallas Gutauckis <[redacted]>
Date: Fri, Sep 26, 2014 at 11:37 PM
Subject: Re:


Someone naming himself Matt commented on my blog post about the Wi-Fi issue some users are having with their 2nd Gen Moto X asking me to reach out. I already have an ongoing support issue ([redacted]) where I also already shared logcat output — not much but all I could give.

Let me know if there is something else I can provide to get this matter resolved expediently.


Them to me

From: Motorola Support Forums <[redacted]>
Date: Sat, Sep 27, 2014 at 10:00 AM
Subject: Re:
To: Dallas Gutauckis <[redacted]>

Hi Dallas.

Have you updated your router software? The Wifi team says old software versions of Cisco APs have problem with PMF supported devices. Cisco fixed this issue in later software versions.

Let me know if that helps. Thanks.

– Matt

Matt and Mark
Social Media – Customer Care
Motorola Mobility
Visit us at

Me to them

From: Dallas Gutauckis <[redacted]>
Date: Sat, Sep 27, 2014 at 2:06 PM
Subject: Re:
To: Motorola Support Forums <[redacted]>


I’m unaware of whether the AP is up to date, and unfortunately, I’m not going to be able to simply try to update the routers because we don’t employ any full-time IT staff capable of managing the routers — this would instead require we pay a contractor to come in and ensure they’re up-to-date, something I’m not willing to do if we can’t be sure it’s the problem.

I know of other people having the issue — they might be able to check such a thing on their network. See

What I still don’t understand is why this is a 2nd-Gen-specific issue and not 1st-Gen. I realize they’re different devices, and potentially different networking hardware, but I would assume if it can work on one, it can work on the other.

Not yet sure where this is going to get us…

UPDATE 4 [~2014-09-27T9:00:00EST]: Got a call that went to voicemail (because I was still asleep). The caller said they were just checking in on me to see if my issue was fixed or not. If it wasn’t, they gave me the number to contact their level 1 support (seems I’ve been downgraded). Obviously, nothing has changed, so nothing is resolved. Note that this call came in before the email response from Matt.

UPDATE 5 [2014-10-07T19:30:00EST]: Our IT contractor happened to need to come in to set up network redundancy for our internet connection, at which time we also asked him to update the Cisco controller. The update seems to have fixed the PMF as suggested by Motorola support. Quick! Call your IT gang out to update your controllers. Best of luck to all. Still a ridiculously shitty experience to have for a new device [where they know it’s going to be broken for users].

Android Animation — Bringing Your Applications to Life @ Droidcon NYC 2014


Last weekend, I gave a talk on animation on Android at the innaugural Droidcon NYC (2014). The talk was well-received and I got some tough questions. Nonetheless, I’m happy I did it and I’m posting the presentation for your viewing pleasure. I highly recommend checking out the actual Keynote file (linked to from the Speakerdeck site) if you can as it includes the videos/animations as opposed to just static images.

You can check out all of my presentations (regardless of how old they are) at

Listing connected Android devices with OS version and model


I was wandering down the path of trying to associate the myriad of devices connected to my machine for debugging. I wanted to know very easily what the devices’ model and OS version were without having to manual check by disconnecting and reconnecting devices and using the process of elimination.

One way to see this information is using a special flag with adb:

adb devices -l

This yields something like

List of devices attached
HT16JHX24920 device usb:14130000
015d2a506750081b device usb:14120000 product:nakasi model:Nexus_7 device:grouper
4d005e148cc950eb device usb:14112000 product:ja3gub model:GT_I9500 device:ja3g
0A3BC06A11010002 device usb:14140000
e08b84fd device usb:14113000
HT346W912280 device usb:14114000

Which as you can probably tell doesn’t give us all of the information we want, nor does it seem to work on every device.

So instead, I wrote a script for printing out what I needed. The bash script reads properties from the device via adb shell.

The output for that looks like:

    HT16JHX24920 [ 4.0.3]: PG86100
015d2a506750081b [ 4.4.2]: Nexus 7
4d005e148cc950eb [   4.3]: GT-I9500
0A3BC06A11010002 [ 4.1.2]: DROID RAZR
        e08b84fd [ 4.1.1]: SAMSUNG-SGH-I747
    HT346W912280 [ 4.1.2]: HTC One

View, download, or fork the script

In case you were curious, the corresponding properties are:

$ adb shell getprop ro.product.model


$ adb -s HT16JHX24920 shell getprop

Making Borders for Views Using layer-list


Android is full of many ways to do things differently. One of those things happens to be making a border for a View.

The common approach I’ve seen is for developers to have two Views. One View is the View with a background (be it solid, bitmap, or otherwise). The other View acts as a border, typically either 1px or 1dp in width or height, the other side matching the height or width of the other View. Although this is certainly an easy approach, at adds more to your layout than is likely necessary.

Example with Views:

    android:background="#ccc" />

    android:text="Hello, World" />

Assuming those Views are encapsulated in a LinearLayout with vertical orientation, you’ll end up with a TextView with background of #eee and top border of #ccc.

Now, let me introduce you to layer-list

layer-list allows you to do many things regarding multiple drawables. One of the more common implementations is adding a border to something.

I’ll explain by example:

<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="">
            <solid android:color="#ccc" />
    <item android:top="1px">
            <solid android:color="#eee" />

What this example shows is the layer-list way of going about the previous example. This will produce a drawable that has a 1px solid top border colored #ccc and a background of #eee. The confusing part to this for most people tends to be where the 1px is designated. layer-list draws top-down in the XML. This means that #ccc is drawn in the full background first, and then #eee is drawn over top of that, with a 1px top offset.