Clean Surveys in Android

Reading Time: 9 minutes

This summer I have been adding some features to Nurse AMIE, an Android app proposed, developed, and tested by Dr. Kathryn Schmitz at the Penn State Cancer Institute.

In the last post about this app, I talked to you about the role of empathy in mobile apps for care management. We discussed the user interface design decisions that went into the weekly survey form, and why they mattered. In this post, I’ll talk about the technical execution of the form.

To help you understand my decisions about this form, you need to see the questions:

  1. What was the severity of your decreased appetite at its worst?
  2. How much did decreased appetite interfere with your usual or daily activities?
  3. How often did you have nausea?
  4. What was the severity of your nausea at its worst?
  5. How often did you have vomiting?
  6. What was the severity of your vomiting at its worst?
  7. What was the severity of your constipation at its worst?
  8. How often did you have loose or watery stools (diarrhea/diarrhoea)?
  9. How often did you have pain in the abdomen (belly area)?
  10. What was the severity of your pain in the abdomen (belly area) at its worst?
  11. How much did pain in the abdomen (belly area) interfere with your usual or daily activities?
  12. What was the severity of your shortness of breath at its worst?
  13. How much did your shortness of breath interfere with your usual or daily activities?
  14. What was the severity of your cough at its worst?
  15. How much did cough interfere with your usual or daily activities?
  16. What was the severity of your numbness or tingling in your hands or feet at its worst?
  17. How much did numbness or tingling in your hands or feet interfere with your usual or daily activities?
  18. How often did you have pain?
  19. What was the severity of your pain at its worst?
  20. How much did pain interfere with your usual or daily activities?
  21. What was the severity of your fatigue, tiredness, or lack of energy at its worst?
  22. How much did fatigue, tiredness, or lack of energy interfere with your usual or daily activities?
  23. What was the severity of your pain or burning with urination at its worst?
  24. How often did you have hot flashes/flushes?
  25. What was the severity of your hot flashes/flushes at their worst?

Each question had a set of radio button responses, like so:

Screen Shot 2020-07-04 at 3.28.34 PM

Many of these questions are similar, but not exactly the same. I’ll show you where I placed my seams, and you can choose whether you agree with my choices or not.

Among these 25 questions, I notice that each one takes two categories.

  1. A symptom. Each question asks about one of thirteen symptoms: decreased appetite, nausea, vomiting, constipation, diarrhea, abdominal pain, shortness of breath, cough, numbness/tingling, general pain, fatigue, urination pain, and hot flashes/flushes.
  2. A modifier. Each question asks about one of three modifiers: frequency, severity, and interference in daily life. Some symptoms have questions for all three of these modifiers, but most only have questions for one or two.

We’ll want our view to divide up the survey into sections for each symptom. The real potential for duplication in this code, though, lies in the radio buttons. We have 25 questions that fall into three modifier categories, and for each of those modifier categories, the radio buttons have the same labels:

  • frequency: never, rarely, occasionally, frequently, almost constantly
  • severity: none, mild, moderate, severe, very severe
  • interference: not at all, a little bit, somewhat, quite a bit, very much

Reusing Views in Android

Android allows us to extract our own layout XML files and then include them in other layout files like this:

In this case, the layout in fragment_weekly_survey.xml includes a custom view that lives in an xml file called severity_question.xml.

There are some weird rules about how these custom layouts work. First of all, I can assign an id to my custom view (see line 3), but it only gets registered if I also assign the layout_width and layout_height (see lines 4 and 5). Also, if I want to be able to assign an id, then my custom layout has to contain a single child, and that child has to be of the layout type, like so:

Android developers the world over cringe at this because fragment_weekly_survey.xml already has a base layout, meaning that this custom view nests a layout inside a layout, and the deeper you go doing that, the longer it takes Android to render the screen. (Luckily, just one layer doesn’t usually produce a noticeable difference). Moreover, in this case, the weekly survey fragment’s base layout is already a LinearLayout that stacks views up on top of each other without overlapping them—so the additional LinearLayout in the custom view doesn’t provide any new information about how the views should be arranged.

Android does have a way around this, called the <merge> tag. I could put the custom view inside a <merge> tag, and this will tell Android to drop all the views inside it wholesale into the parent layout, without requiring their own layout. I tried it on this app, but it turns out <merge> tags do not play nice with assigning an id to the custom views, and I need to do that to be able to tell which radio group is answering which question in the fragment.

View Binding

Here’s the onResume() method of my Fragment, where you can see the view binding:

Yikes. It’s long and repetitive.

Theoretically we could do some fancy meta-programming here with string evaluation of the view ids to collect all the question responses, but I didn’t think that length alone was sufficient justification to do something that clever instead of leaving it clear what’s happening. It’s also worth noting that lines 7-31 would be unnecessary with view binding as long as the variables had the same names as the view IDs (or even, it turns out, camelCase versions of equivalent snake_case_view_ids). Unfortunately, view binding does not play nice with the “include” syntax, and in the process of trying it on this code base I learned that the generated view binding classes look like this:

Screen Shot 2020-07-30 at 9.00.13 AM

So they’re not producing a more efficient pattern; they’re just generating boilerplate that devs were writing manually*. That’s minimally helpful. It would edge over into helpful if it worked seamlessly, but it doesn’t:

Screen Shot 2020-07-30 at 8.57.30 AM

What’s happening here, I believe, is that the generated class needs to be explicitly casting those view assignments with findViewById<ViewType> rather than straight findViewById. At this point, I’d rather spend three minutes cranking boilerplate that I know is going to work than patch generated code.

*View binding does add null safety, which findViewById lacks. This is, theoretically, its big selling point. Guess what, I found the special sauce, and it’s this:

Screen Shot 2020-07-30 at 9.03.46 AM

A @NonNull annotation. This is still not, to me, edging out functioning boilerplate by very much.

Moving on.

Lines 35-60 tie each response view to a name that we use to refer to the question that the response answers. Then on lines 72-76, during form submission, we map each of those key-value pairs to a new key-value pair, with the same key as the original pair, pointing to the string label of the radio button that is filled in for that question. There will be no nulls here: instead of introducing logic to handle null, we set a default value of "UNKNOWN" for unanswered questions. As it so happens, we also insist that all questions be answered before letting someone submit this form, but even if we didn’t do that, our app would not crash over a null pointer exception here.

This is the method that extracts the responses, as strings, from our custom response views (and sets the form to valid or invalid based on whether all questions have an answer):

This code also reveals the purpose of the surveyResponses hash that we initialize in onResume(): on lines 7 and 11, we manipulate the background color of the view in that hash’s value to help the person easily see which responses still need to be filled in when they try to submit without completing the whole form.

To dupe…or not to dupe?

I did not extricate custom views for the collection of section headers, or for the questions themselves. There is some duplicate wording in those questions that therefore propagates to the code. I’m okay with this. In my experience, DRY-ing up text (and code, for that matter), with subtle differences is a fun thought experiment that doesn’t fare as well on a cost-benefit analysis as we programmers tend to assume it does.

So the XML that renders the hot flashes/flushes question that you see above lives in the fragment_weekly_survey.xml file, and it looks like this:

I could theoretically use data binding to consolidate common view patterns a little more. I struggled with this for a while, but I could not find a solution to, for example, make the TextViews above an included question_view and pass in a text attribute.

I’d love a better way to label and handle the responses such that adding and removing questions requires changes in fewer places. That’s my personal aesthetic preference, though: I don’t have any evidence so far that we’ll need to do that.

And so…ta-da! Our view. In the next post on this application, I’ll talk about how we persist this weekly survey data to a local database.

If you liked this piece, you might also like:

The three-part series on teaching a programming course

The behind the scenes series

The leveling-up series on advancing your own skills (which will soon be an audiobook read by yours truly. Preorder here).


  1. Thanks for this (and all your other) posts from a long-time lurker but infrequent commenter 🙂

    “In my experience, DRY-ing up text (and code, for that matter), with subtle differences is a fun thought experiment that doesn’t fare as well on a cost-benefit analysis as we programmers tend to assume it does.”

    ^Definitely my gradually-learned opinion too! I’ve learned to avoid DRYing out new views even when the number of cases is initially very small because it is inevitable that 6 months from now that view will have 2^10 different theoretical configurations (of which < 10 are actually in use) due to bolted-on booleans 😀

    Side note, as an Android folk, I wasn't quite sure what you were referring to requiring API 29+? AFAIK both data binding (older, essentially deprecated) and ViewBinding (newer, effectively replacing databinding) can be used on pretty much any API level. Some links that might help clarify: (API ≥ 14) and (no min API, just a min Android built tools version, I think?)

    • Ah, you’re right! I should have checked my math: I wrote this piece a while after I wrote the code, and in this case I remembered that something didn’t work, but I seem to have mis-guessed as to why 😅

      In this particular case, with data binding, I think the actual problem was that I couldn’t get, for example, this type of thing to work with my custom, included layouts:

          android:text="@{user.firstName, default=my_default}"

      Which was a shame, because then I could have made the whole question-and-response unit its own layout and included THAT in the fragment rather than the question and response views directly (to your point, I am wary about removing duplication for sure, but the 25 questions do all have the same format and so this case, if I could manage to pull it off within my timebox, I think I would have). I’ll update the piece to reflect that.

      ViewBinding: it’s interesting that you mention that. Your link suggests that it would take some additional setup (on newer apps that I generate, I guess it’s enabled by default), but that maybe it would work for this. I might have to give this a try and see if I can eliminate that wall of “findViewById” in “onResume()”. Will report back.

      Thank you!!

      • Reporting back! View binding, like data binding, did not play nice with include 🙁 in trying it, though, I learned a little bit about how the generated classes work and included that in this piece, so your commentary still resulted in a more informative piece! Thank you.

      • Oh nice, glad to got to experiment with it! are just tricky to bind well, I guess!

      • Edit: should read “Oh nice, glad you got to experiment with it! includes are just tricky to bind well, I guess!” (typo + html escaped :P)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.