In which I was in a podcast

It has been a month since IO and in case you missed it, I got to chat with Kaushik of Fragmented. And by golly, I made it into an episode! At that point I was about to lose my voice, so I sound really husky. :p

~1 min read

Taking a closer look while debugging

One of the most common sources of bugs (at least of my bugs) is math. I have been working on dynamically resizing a View the past days, and it was driving me nuts! I needed to consider preserving aspect ratio, device density, original view size, etc etc. Math is hard guys!

4 min read

LinearLayouts, TextViews and Drawables

I sent out a series of tweets today about LinearLayouts and unexpectedly, quite a few people like them. I decided to get off my lazy ass and actually write it down in a post for easy reference.

2 min read

Squashing Bugs

This has been one hell of a busy week for me. I think you can sort of tell from my Tweets and G+ posts that I have been debugging A LOT.

1 min read

Annotating all (or most of) the things

If, like me, you are old and have been developing for Android for a while, you should, like me, appreciate the fact that the backwards compatibility of the OS has come a long way. Sure, they may toy with my feelings from time to time, but we all need a little excitement every now and then.

I have recently decided that I will invest more time into learning how all the tools at an Android developer’s disposal can make me code better, faster, cleaner, and less buggy (I initially said “buggier” because I want to rhyme but someone who supposedly does English better complained).

To start with, I have been trying recently to consistently use the Resource Type annotations. These annotations prevent code like this from exploding:
<pre class="brush:java">private void setThingsToTextView(int res1, int res2, int res3, int res4) {
// do stuff
This will explode because:
1. Fields are named horrendously
2. Without reading what the method does, it is so easy to pass the wrong resource ID (I can only assume that it wants resource IDs)

Resource annotations help with reason #2 by letting you and the compiler know just what type of resource is expected. There are a lot of available annotations (Read the docs!) but I find that the things I use the most are, well, the things I use the most:
@StringRes - expects an R.string.*
@DrawableRes - expects an R.drawable.*
@IdRes - expects an*
@ColorRes - expects an R.color.*

I have updated my SDK Sandbox project with an Activity to illustrate use of these annotations. FAIR WARNING: IT USES ENUMS. If this annoys you, DO NOT click through.

So how do we stop the method above from exploding? Let’s fix all the things!
<pre class="brush:java">private void setThingsToTextView(@IdRes int textView, @StringRes int introText, @DrawableRes int heroImage, @ColorRes int backgroundColour) {
// do stuff
Ahhh. Easy. And so much better.

1 min read

NOT another day at the office

We had another round of Innovation Day at Domain last month, and I wrote about it. We started out dreaming up this ambitious project – too ambitious for two days! Here’s a partial list of what we had to do:<div><ul><li>Build a wall</li><li>Stick devices on said wall</li><li>Make app that cycles through photos from listings</li><li>Load said app on those devices that we stuck to the wall</li><li>Figure out how to track people who get devices</li><li>What if someone just gets a device?!</li><li>Figure out how to let people give back devices</li><li>Oh! oh! oh! Wouldn’t it be cool if other devices cheer when one of them “comes home”?</li><li>How do we put new versions of the app on those devices?</li><li>Run tests, maybe?</li><li>What if the website team wants to test responsive designs?</li><li>Do they even charge????!!!</li></ul><div>It was a LOT of work. But it was awesome.</div></div>

~1 min read

In Which Things Got Cheesy

Today, Android Developers published Domain’s Developer Story. In it, Gary and Rique talked about how the Domain Android app was rated very poorly and had all sorts of problems. Fast forward two years and it is now a highly-rated, top-ranked lifestyle app in Australia. You would think that going from a 2.8 star rating to 4.1 stars is all sorts of amazing. And it is!

Rique mentioned how 2014 was a really big year for Domain; in a very personal sense, it was for me too. This video coming out gave me pause and kicked off a bit of a melancholy spell for me.

Around the middle of last year, I packed up half of my clothes, left all of my books and games, said goodbye to my family and my friends and my love, and moved to Australia. The choice to relocate was hard, and I almost didn’t take it. I was just about to accept a new job at a big OEM, my boyfriend and I just bought an apartment, my friends and I have regular game nights – everything was going really well. I really had no plans of going anywhere, I have long given up on the overseas dream. And then BAM, the Universe decides to spring this surprise onto me; and out of nowhere came this chance to work on something I truly enjoy doing.

I am so lucky and grateful to have been a part Domain’s journey over the past year. The app did a lot of growing up, so did I.
<blockquote class="twitter-tweet" lang="en"><div dir="ltr" lang="en">My tech life has grown by leaps and bounds since I’ve moved to Sydney. Yay? Yay!</div>— Zarah Dominguez (@zarahjutz) June 30, 2015</blockquote>I have possibly learned SO MUCH over the past year than the three years before that combined. Sure, it can get lonely being alone in a foreign country. Of course I miss my mom. Of course I miss my boyfriend. I surely do miss my friends – I can never get anyone to play board games with me here. But at the same time, I have been meeting a lot of really great, really awesome people. I have learned how to cook (it turns out I can make a great cranberry feta salad, which technically is not cooking, but whatever). I have been on a lot of adventures, traveled to cool new places, jumped out of a plane, drank a lot of beer.
<blockquote class="twitter-tweet" lang="en"><div dir="ltr" lang="en">Who has the best team ever? I do! Got to the office with this on my desk. :)</div>— Zarah Dominguez (@zarahjutz) August 23, 2015</blockquote>Plus, I DO have the best team ever. :)

2 min read

Raising Activities From the Dead

One of the scenarios I admittedly almost always forget to test is “What happens when my app goes into the background, then the OS kills is to claim memory, then I try to resume?” Usually it’s “Well, I handle onSavedInstanceState not being null, so I am great!” It is fine and dandy for simple apps; but once your Activity or Fragment gets beefier and you start relying on state for more and more things, it can get complicated pretty quickly (In my case, the Fragment has setRetainInstance(true)).

This scenario in particular is kind of hard to reproduce willingly. I usually see this when I leave an app running, make my phone do some heavy work overnight, then resume the app the next day.
<div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: left;">
</div><div class="separator" style="clear: both; text-align: left;">So what you gonna do?</div><div class="separator" style="clear: both; text-align: left;">
</div><div class="separator" style="clear: both; text-align: left;">It turns out that Android Studio has the answer! There is this magical tiny red button that allows you to simulate this exact scenario.</div><div class="separator" style="clear: both; text-align: left;">
</div><div class="separator" style="clear: both; text-align: left;">1. Open your app to the Activity you want to test (I use a very simple app here just for demo).</div><div class="separator" style="clear: both; text-align: center;">

</div><div class="separator" style="clear: both; text-align: center;">
</div><div class="separator" style="clear: both; text-align: left;">2. In Studio, go to Android Monitor (make sure that your app is selected). Note the process ID, in this case it is 25647.</div><div class="separator" style="clear: both; text-align: center;"></div>
3. Push your app to the background. Pressing the HOME button should be sufficient. This will call onSaveInstanceState, which is all that matters really. It is after all what we want to test.

4. Back in Studio, press the magical tiny red button pointed to in the previous image. Notice that Studio now appends [DEAD] to your app’s process. It is now gone. He’s dead, Jim!
<div class="separator" style="clear: both; text-align: center;"></div>
5. Resume your app. I usually just do this via recent apps.
<div class="separator" style="clear: both; text-align: center;"></div>
6. If you look at Studio, you’ll see that your app is now no longer dead, but has a new process ID, in this case 26742.
<div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;">
</div><div class="separator" style="clear: both; text-align: left;">If at this point you step through your code, you will notice that your Activity will go through the whole (re-)creation process with the Bundle given the values you have saved in onSaveInstanceState. No more waiting overnight, yay!</div>

1 min read

Lies I’ve been told today

So I played around with data binding today. And these are the lies that the dev guide told me (explicitly or inferred):

<ul><li>There is a method DataBindingUtil.bindTo(viewRoot, layoutId)</li><li>That this will work MyLayoutBinding.bind(viewRoot);</li><li>Android Studio has auto-complete</li></ul>

~1 min read