Donn Felker

I Don’t Have Time is a Myth

November 6, 2017 by Donn Felker 18 Comments

“I don’t have time” is a myth.

The statement, “I don’t have time”, really gets under my skin.

Why? Because you do have the time.

Get up early. Cant? Go to bed earlier.

Stop watching TV shows and YouTube channels that do nothing to help you progress in your dreams.

Stop playing video games.

Stop going out to the bar.

Stop wasting time reading news websites, Reddit, surfing Facebook or Instagram for hours.

You have the time. Its right there in your hands. Use it.

How much time would you get back if you stopped doing all of those things above? You’d be blown away by how much time you’d get back. In fact, let us dig in a little bit deeper …

Watching 45 Days of TV Per Year 👎

The average American spends 3 hours a day watching TV.

3 HOURS A DAY!

Some reports show an upwards of five hours a day.

Let us be conservative and stick with 3 hours.

That’s 21 hours a week!

90 hours in a month!

1,095 hours in a year.!

That’s over 45 days of watching TV for 24 hours straight!

This is just watching TV. This does not include time spent looking at your phone!

That’s just insane.

“I don’t have time.”

Pffft. Whatever.

No, you do have the time – you’re just choosing not use it for the things you say “You don’t have the time for.”

The magic of time optimization

Is life hard sometimes? Yes, it is. Oh god yes. It can feel completely overwhelming and you might feel like you can’t get a breath. But … you still have time … if you don’t waste it.

Single mothers and fathers exist and they make magical things happen. They work multiple jobs, have little or no help from family and they have to do everything themselves. Somehow, they make magic happen.

You know what? I bet you most of these folks have “more time” than most.

Why? How?

They optimize their life to maximize their time.

Furthermore, I bet you they read more books than most too.

Imagine being one who catches the bus at 6:30 am after dropping the kids off at early-drop off and/or daycare/preschool. So what do they do with that next 10–30 minutes of commuting time (before and after work)? They probably use that next 10-30 minutes to listen to a book or podcast or watch a video tutorial that they downloaded on their phone instead of passively looking out the window or on FacebookInstagramRedditNewsetc.

They have the time & you have this same time.

Maybe you don’t commute via train, maybe you drive to work.

Same thing.

Use that time to learn, grow, etc. Maybe you work at home? That’s cool. Listen to books/podcasts while driving/walking to the grocery store or dentist/or wherever you’re driving.

For example, let’s think about the time in the shower. Could that be put to use? Hell yes, it can. Put an audio book on while you’re in the shower. That’s 10-15 minutes a day. 10-15 minutes a day for 30 days is 5 to 7.5 hours. You can easily listen to a book a month simply by listening to it in the shower. Use the Audible app to download books and listen to them on the go.

“I don’t have the time.” Yeah. Ok.

“… but I don’t have time to eat healthy and work out”

Maybe you want to work out and get yourself into better health and don’t have time for the gym. I get it. Do a bodyweight program by any number of fitness trainers 3-5 days a week at home. There a TON of them online for free. Eat salads for lunch. The best shape I got into in my life I worked out two days a week and ate healthy (salads and steamed veggies). The diet did more for me than working out did.

Maybe you don’t have a ton of time for meal prep. Ok, I get it. Then follow intermittent fasting – it helps you learn how to control your hunger and is proven to be very good for your health. Fewer meals to prepare – eating less and improving health? Yes. I’m in. Eat steamed veggies from the microwave for two meals a day with lean grilled meats. Do a meal prep day on Sunday. There are always options.

I once knew a girl in college who would cook beans and rice every Sunday and have that for lunch because she didn’t have time to make lunch every day and bring it to college. She did the work on Sundays. She found the time, owned the problem and fixed it – even on the cheap.

Finding Time is Easy

Finding time is easy if you look hard enough. It’s everywhere. 10 minutes here, 15 minutes there. Before you know it you have an hour or two each day you can use.

If you feel like you don’t have time try to find all the spaces where you’re not doing anything (dentist office waiting, doctors office waiting, at a kids drama practice, waiting) and then use that time to push the ball a little further down the field. I bring my laptop everywhere, just in case I have a free moment to crank things out. In fact, I’m writing this post at my accountant’s office this AM while he’s preparing some documents for me.

I’m not saying to give up that time you spend with your family. That has importance too. Maybe one of your goals is to be a great parent and/or spouse. Then execute on it and find the time to be a great parent. Use the spare time for that. Same for anything else that you find that you want to accomplish. It doesn’t have to be “work” or “business”. If you “don’t have time to walk the dog”, then stop surfing Facebook or Instagram while you’re on the toilet (you know you do it too).

The moral of the story is – you do have the time, it’s most likely being wasted on needless activities that provide no real growth value to you.

Tips

One thing I advise is to try to get up earlier – before anyone else. I’ll admit, it’s not easy. One thing I do the night before is write down a couple of things I want to get done before everyone else gets up (could be work out/run, get task x done, read, work on your project, etc). You get such a head start on the day that you feel positive and happy.

Can you do the same at night? Yes, for sure. Maybe you’re a night owl and get most your work/etc stuff done from 9pm-3am. That’s fine too. However, I will say this – when you’re tired, it’s much easier to simply go to bed and miss out on those hours. When you get a head start at the beginning of the day you start off on the right foot. Waiting to get some stuff done at the end of the day can sometimes fall apart (bad day, super tired, made a bad decision by having few too many at happy hour, etc).

Next, focus on whatever you want to accomplish and execute until it’s done. Don’t lose focus. Do not get distracted. Kill all external distractions. Complete the task at all costs. Striking an item off a to-do list (even if it is mental) is a huge win. Build upon these wins and snowball them.
Be obsessed with your passions and goals. Its ok to be that way. Do you want to be the best parent in the world? Go do it. Don’t let anything stop you. Do you want to be the best long-distance marathon runner? Go do it. Do you want to be the best rheumatologist in the United States? GO. DO. IT.

No one is going to give you anything. You have to get it yourself. You have to take the risks. You have to make it happen. To do those things you’ll need to find the time and trust me, you have it.

Make it happen.

Photo credit: @loic

Android MVVM with DataBinding – Removing Logic from Your Views with BindingAdapters

October 20, 2017 by Donn Felker 3 Comments

One of the things that’s great about MVVM (I’m using data binding in my implementation) is the lack of the boilerplate that you have to deal with. When working with the MVP pattern you are forced to deal with an obscene amount of get/set boilerplate code. Sure, this does make your UI logic more testable but it doesn’t get around the fact that there is a lot of boilerplate.

While MVVM with Data Binding does remove a good deal of this boilerplate you also run into new issues where logic is now present in the views, like this:

<TextView 
    ...
    android:visibility="@{post.hasComments ? View.Visible : View.Gone}" />

As Joe Birch accurately pointed out in his article – this has a code smell and it just feels gross.

The logic is now buried in an Android XML view and its near impossible to test unless you’re rigorous about your Espresso tests … and let’s be brutally honest here… you’re not rigorous about your testing.

Removing Logic from XML Views with Custom Binding Adapters

Removing logic from XML Views is quite easy with custom BindingAdapters. Early adopter and DataBinding aficionado, Lisa Wray, posted about this back in 2015: Pro tip: More data binding — Easy view visibility in XML! I heard you guys l….

In short, you create a binding adapter in Java (or Kotlin as I’ve done below) and drop it into your project.

@BindingAdapter(“isVisible”)
fun setIsVisible(view: View, isVisible: Boolean) {
  if (isVislble) {
    view.visibility = View.VISIBLE
  } else {
    view.visibility = View.GONE
  }
}

The logic for showing a view is now determined by a Boolean value. To use this in an MVVM Data Binding XML View you’d do the following in your view:

<TextView 
    ...
    app:isVisible="@{post.hasComments()}" />

The logic for the hasComments code is now kept inside of the View Model which can be easily unit tested.

Testing the Custom BindingAdapter

We may have removed the logic from the XML view, but we still have code that needs to get tested. Now that the view logic is based upon a Boolean we can easily test this with an Espresso test:

@Test
fun isVisibleShouldBeEasilyControlledWithABoolean() {
  val v = View(InstrumentationRegistry.getTargetContext())
  setIsVisible(v, true) // visible
  assertThat(v.visibility).isEqualTo(View.VISIBLE)

  setIsVisible(v, false) // gone
  assertThat(v.visibility).isEqualTo(View.GONE)
}

You’re going to put this in your androidTest folder.

I know what you’re thinking – this is an Espresso Test, it runs slow. Not really. You’d be surprised at how fast this test runs as it does not need to fire up an activity and start clicking on buttons/etc.

You now have logic that can (and is) tested via a simple test. Your display logic is then kept inside of your View Model (does a post have comments or not, that’s a fairly simple true/false boolean).

Furthermore … your ViewModel is not riddled with Android package references (which can make it harder to test). Which brings me to …

Keep the ViewModel free of Android Dependencies

One goal that I have is to keep the View Model free from Android Dependencies if at all possible. This allows me to utilize JUnit unit tests for a quick feedback loop. I can write, test and iterate much faster with a unit test than I can with an Espresso based test.

Yes, you could put some of this logic into the View Models, but I find keeping it as clean a possible provides for the best possible outcome when it comes to testing.

As with everything, there are always caveats to this – using resource identifiers (as they’re only integers, etc). My rule of thumb is to try to avoid the Android packages in my view models. That way it makes testing a snap.

Make the Most of Your Time

September 14, 2017 by Donn Felker 5 Comments

Photo: Uroš Jovičić

Recently, a friend of mine asked if I wanted to partake in a small side project with him. Unfortunately, I didn’t have the time to commit to the project so I politely declined.

He responded with:

Dude I totally understand. I’m single at the moment and pretty much have my ass alone to take care of and I can barely remain afloat. You are a rockstar. I don’t know how the hell you can do it.

What he’s saying is that he has no idea how I get so much stuff done with my situation (Married, 2 kids, consulting, founding a company, a podcast, presenting, writing, 3 dogs, 3 cats, etc etc etc).

So how do I get so much stuff done?

Time optimization, 100%.

Don’t get me wrong … I’m not some zen-productivity-master, not at all. I just value my time.

The way I see it is like this:

Time is your life.

Life is Finite

One time I did an exercise that scared me: I took a look at the average life span of a US Male (~78 years) and I calculated the days I had left in my life.

Hint: It’s not that much. 😯

After seeing that number it catapulted me into action. To check yours go here: http://www.countmydays.com/

I’m not being morbid about life, it’s merely factual.

Seeing the Number of Days Left in Your Life is Scary

My friend replied back with a shocked face:

I calculated the waking hours I had left in my life.

Holy cow, this freaks me out … 😮

I know the feeling. Every time I look at the number, it’s smaller. 📉 It never goes up. 😢

Not many people look into how many days are left in their life. They should though – as it’s a humbling exercise. I think it’s important as it helps keep yourself grounded and keep your ambitions high because, well, your time is limited. You have less of it than you think.

There’s a popular blog post titled The Tail End in which the author draws little pictures of how many months, weeks and days he has left. He goes on further to outline how much time we have left with loved ones, time left doing things you love, face time with children, etc. Read it, it’s worth your time (pun intended).

You probably never thought about this, but around 90% of the time that you will have spent with your parents was done from the ages of 0-18. So if you have kids – remember this. My daughter just turned 9 and I realized that I’m already 45% through the average time that I will spend with her in our combined lives. That really sucks, but it also puts urgency into what matters – being with my children as much as possible and not taking it for granted.

So … Why am I harping on this so much?

I’m doing so because your time here is finite. You only have so many at bats and then the game is over. That’s it. All done. Why not give it all you have, all the time? Why not chase those ambitions and dreams? Fix those broken relationships? Say sorry instead of being stubborn. You get what I’m saying.

The value of my time is a primary driver in my decision to work remotely. I know I only have so long with my kids, my wife, my family. Why waste that valuable resource commuting to and from work just to sit at a desk? To me, that’s absolutely insane.

Unfortunately, even though this information is quite eye opening, sometimes people will still avoid doing what they want to do due to fear.

Fear of failure.

Fear of rejection.

Fear of success (yes, it’s really a thing).

Break Down Your Fears and Do It

One of my favorite things to use to combat fear is to utilize a technique known as “Fear Setting“. I picked this up from Tim Ferriss, and you can watch a video on it here – Fear Setting by Tim Ferriss (Ted Talk). It helps you determine what you’re scared of and helps you realize it’s usually not that big of a deal. The video is very important, so please take a few minutes and watch it. Queue it up while you eat your lunch, etc. One of the quotes he uses in the talk is this one –

We suffer more often in imagination than in reality. – Seneca

This is so true. Using quotes like this and a mix of Stoicism to remind you of important things in life makes it easy to appreciate what you have, and how much time you have left and what you can do to maximize it.

Lastly, Steve Jobs has a quote that I often refer to:

Remembering that I’ll be dead soon is the most important tool I’ve ever encountered to help me make the big choices in life. Because almost everything — all external expectations, all pride, all fear of embarrassment or failure — these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart. – Steve Jobs, Stanford 2005 Commencement Speech

I’m not a huge Steve Jobs fan, but this speech really helped ground me. I have a recurring calendar event every 3 months to watch this speech. It always helps course correct me when I’m wandering in the sea of life.

Yeah, I know … you’ve heard that life is short, but seeing it in numbers is humbling and action inspiring, no doubt.

So, how do I get so much done?

I remind myself that life is finite.

I’d like to thank Kaushik Gopal for reviewing this article.

TDD Your UI Layer – #uitestsmatter

January 24, 2017 by Donn Felker 17 Comments

A recent conversation developed on twitter when I posted a link to a Caster.IO lesson where I talk about using TDD to drive your UI development.

The problem?

Some folks feel that you cannot TDD your UI layer with a functional testing framework like Espresso.

I disagree.

Why? Well, before I dive into details, I thinks it’s only pertinent to re-establish what TDD is.

What is TDD?

TDD by definition is: Test Driven Development. TDD is a software development process.

Key word: process.

The process of TDD is comprised of 5 steps:

Add a test – each new feature, update, fix, etc starts with writing a test to cover that new code/change/etc.
Run all tests and see if the new tests fails (typically to save time, I’ll run the new test in isolation to speed things up, then loop back later to run all of them to check for regressions).
Write the code (this is what you orignally needed/wanted to do anyway – implement a feature/etc).
Run the test(s) – Again, typically I’ll run my single new test in isolate to speed up this process a bit. If it passes, I run all the tests to see if I broke anything.
Refactor – After all tests are passing, you now have a safety net to catch you in case you make a mistake. At this time you can now start refactoring to change the desired implementation of the code.

Then … repeat the steps for each new feature/update/fix/etc. You may need to do this many times over. One test for the “happy path” (when everything works as you hope/expect it would), one for all the edge cases, one for null value paths, one for catastrophic failures, etc etc. You usually end up with may tests covering all the different expected (and unexpected outcomes) for that given code path.

So, how do you TDD your UI Layer?

Let us keep the full TDD process in mind when walking through this example …

This means writing your test first, even before particular UI elements exist. In this case I’ll do it with Espresso, the defacto Android UI testing framework along with jUnit as the driver.

Step 1: Create the Test

I’ll create a test like so:

As you can see, the buttonx id does not exist yet (this is why it is red). At this point I’d go implement the button and we’d then see something like this:

The id, buttonx, is now found (it changed colors and we can navigate to its definition now). How I implemented it is not important as it’s an implementation detail and we’re worried about the TDD process here. I can compile successfully. Ok, now I can move onto step 2 of the TDD process:

Step 2: Run The Test
I run the test and I expect it to fail because the text “Hello from buttonx” does not exist. If it does not fail (meaning that it passes) I have a problem and I need to dig into that. Let’s assume it fails and at that point I’m ready for Step 3 …

Step 3: Write The Code
At this point I’m able to write the code that is needed in order to get this code to pass (whatever that may be – adding a click listener to buttonx and having it output “Hello from buttonx” somewhere on the screen). Then move onto step 4 …

Step 4: Run the test(s)
We run the test(s) to make sure that the tests passes and to make sure that other tests still pass. This is integral to the TDD process. You will want to run all the tests (usually at least all the tests that interact with this component/screen/etc) to catch any regressions that may popup because of this new code you have added. After everything is green (passing) I’ll move onto Step 5 …

Step 5: Refactor
This is where I’d come in and clean up the code to make it more proper. Maybe make things more private, final, or extract methods, etc. Maybe I find an area of code that I can improve the design on/etc. If thats the case; for example maybe I’ve refactored some logic into a new class I’d introduce a new TDD test process for a new refactoring/etc. When would that happen or why? Maybe I see that I’ve duplicated code in a few places and I can extract this into another class. At that point I’d probably want some tests around that class so I’d go through the TDD process with that class.

I’ve followed TDD to implement a feature/change a chunk of code/fix a bug/etc that is on the UI using Espresso.

Most importantly – I used TDD a process to implment it.

Arugments Against TDD in this Context

Sure, this example is fairly contrived and it’s super simple, and it’s that way for a reason – I’m trying to demonstrate a point. TDD is a software development process. Alas, there are some folks who feel that TDD represents something different. Let’s chat about those opositional points of view.

TDD should not use a UI Testing Framework

I completely disagree with this because TDD is a software development process. The UI is part of the software and if you want to develop it using TDD then you can. Step 1 states that we need to write a test. Does it matter what framework we use to write it in? No. IMO, any test is better than no test (but thats another topic for another day). Looking at the Wikipedia entry for TDD I found the following under the definition of Part 1 – Add a test:

The developer […] can write the test in whatever testing framework is appropriate to the software environment.

We’re writing the UI, therefore Espresso is an appropriate testeing framework to use as it is a UI testing framework. Right tool. Right job.

The reason most folks oppose following TDD with UI testing is because it’s slow, which brings me to the next item …

When doing TDD, all tests should be fast

I totally can relate to this one. I’ve been part of teams that have HUGE Espresso/UI test suites and they can take hours upon hours to complete. Running the full test suite can be a pain and it’s simply not feasible. In this case I rely on CI to run full test suite. During development though, for steps 2 and 4 (where we run the tests) I’ll run a small subset of tests. Usually the test(s) that I’m writing or the small suite of tests in that test file/package that is pertinent. This allows me to remain nimble. Typically this is anywhere from one to twenty tests (give or take).

I agree, this is slow compared to JVM unit tests that can run at hundreds (if not thousands) per second. However, I’m doing UI development here so given the state that UI testing is in (for Android) we’re unfortunately stuck with some slower tests. It is what it is, but the TDD process can still be used.

Doing TDD on the UI is an Anti-Pattern

I’ve seen this mentioned a few times, and it’s mainly because having slow running tests is an anti-pattern … but as I stated above, that’s the situation were in. How do you get around that though? Extract your logic out into something like the MVP pattern. You can then test the majority of your code in fast jvm tests. You’ll still need a thin layer of UI tests to make sure your UI works as you (and your customers) expect it to.

I say this because you need to verify what your customer is going to see … because …

If your apps UI fails/crashes/doesnt do what it is supposed and it does not do what the customer wants, they’ll think its garbage. It doesnt matter if your app is beautifully architected with fancy patterns and so forth. If the UI doesnt work and do its job as expected, the customer is unhappy and will most likely not use your app. At that point all your work is moot.

How many times have you used an app and initially it looked great, but then when you started using it … well … it just felt like things were wrong. What was your reaction then? Most likely a negative one. You probably didnt use the app or even uninstalled it right away. I definitely don’t want that and I’m sure you don’t either. #uitestsmatter

What I’m trying to say is, UI tests are extremely useful, even if its a thin layer and that layer can be test driven thorugh TDD.

… but, I heard TDD is Dead

This has been going around for the last few years. I’ve been through the TDD inception/rediscovery in 2003 by Kent Beck and seen it rise and fall and rise again and so forth. It’s cyclical. One moment it’s in favor, the next its not. The hard part is … TDD is hard. With some languages TDD is seen as a way to help improve the overall design of the app (which is usually the case with statically typed languages like Java). Dynamic languages have some other benefits when it comes to testing and mocking that statics do not (but they have their own downfalls too, which I wont get into here).

Back in 2014, Martin Fowler, Kent Beck and DHH hosted a series of online videos where they discussed if TDD was dead or not. You can find them here – Is TDD Dead? I’ll let you decide if TDD is dead. Each person in the group had great points and at times I agreed separately with each one of them on different topics.

I’m not here to argue if TDD is dead. I’ll leave that up to you to determine.

However, I do hope that this article does prove the point that TDD can be possible with UI development.

So … Is TDD with UI Development Possible?

Yes.

Remember, TDD is a software development process that can be applied anywhere in software.

As always, please leave comments below. Thank you for reading. 🙂

Automating Screenshots: Simplifying Internationalization on Android

February 11, 2016 by Donn Felker 5 Comments

I’ve worked on some fairly large internationalized apps (50MM+ installs on each app) and on each app I’ve always had a problem with internationalization. It presents its own set of challenges. If you have not internationalized an app before you’ll quickly realize that your app design may not fit various locales – especially when text widgets are horizontally adjacent to each other. The text will eventually overlap or just look wonky and this can create odd UI bugs. You’ll find this out during testing, or as in my experience, when someone reports an odd text widget is overlapping another part of the UI. Finding these issues usually resulted in having your QA team go through each screen in the app to visually inspect the app for each locale. An optimal solution would be to visualize all of the different screens in the different locales so that it would be easy to inspect. Unfortunately that, solution did not exist …

While there is no silver bullet for this situation, there is a new tool that can help with this process (which also has ancillary uses as well).

I recently had the honor to work with the Fabric team – the same trusted team who brought us the Crashlytics tool that we all rely on. They were looking for some feedback on a new open source tool called screengrab. I got to try it out, and after some setup, I had an “Aha!” moment that made me want the tool immediately. It’s a tool that any pragmatic Android developer should evaluate as a possible candidate for their Android development toolbox – especially if your app is internationalized.

Let me explain why …

What is screengrab and why should I care?

Put simply, it is a command line tool that helps you take screenshots of your application at desired execution points in your functional android tests (Espresso) … in any locale.

running-screengrab

A screenshot tool? Really? Any Locale? Why Should I care about that?

Therein lies the magic …

One thing you notice during the localization effort is that during design and development strings that fit in one language (English for me) do not necessarily translate well to other languages. Meaning that a five-letter word in English may translate to a twenty letter word in another language.

This is problematic when you are dealing with horizontal space. Longer text entries will overflow onto other widgets and you’ll have a problem.

As stated above, you often don’t realize it until it’s too late because manually testing your application on various locales is difficult and extremely time intensive.

How Does screengrab Help?

The screengrab tool will help automate the process of visually inspecting the various locale output of your app. You can configure screengrab to load up different locales, run all the UI tests and take screenshots during the execution of the test on various devices and configurations at the same time … and then ….

Screengrab will output all of the screenshot files for each locale for you. You can then use those files to quickly visually inspect if there are in fact visual problems with your application and locales.

Simply scroll through the files and check to see if anything is broken.

This can result in huge time savings when you make a feature change, add a new screen, etc.

How Do I Install It and Use it?

As usual, the Fabric team is making this as easy as possible. It’s one file to setup after the installation that anyone on your team can run once it’s checked into github (setup once, setup everyone forever).

Once installed you can start taking screenshots in your tests with the following Screengrab.screenshot(“screenshot_name”);

@Test
public void testTakeScreenshot() {
    Screengrab.screenshot("before_button_click");

    onView(withId(R.id.fab)).perform(click());

    Screengrab.screenshot("after_button_click");
}

The above code is a jUnit 4 test that allows you to take a screenshot before an action with a the tag “before_button_click”. This tag will show up on the screenshot so you can trace the execution of your test and screenshots.

Then we click on a button, then take another screenshot.

Almost done …

Configuring Various Locales

Now, lets assume you have mulitpe locales and you want to test those various locales and see the screenshot results. To do that you’ll need to provide some configuration values in the screengrabfile.

The screengrabfile was generated when you installed screengrab. You’ll want to add the following information to the screengrab file:

# locales to test
locales ['en-US', 'it-IT']

# clear all previously generated screenshots in your local output directory before creating new ones
clear_previous_screenshots true

This configures screengrab to run the US Ensligh locale and the Italian locale.

Now Lets Run It

You’ll need to make sure you’ve built your application so that you have an application APK and the test APK. Build that with the following command:

$&gt; ./gradlew assembleDebug assembleAndroidTest

Now that the application and test app are built you’re ready to kick off screengrab. Execute the following command:

$&gt; screengrab

This will fire off your tests in each locale and you’ll see your device(s) reacting and your console going wild, as this gif showcases:

(Click for larger)

When screengrab is done your screenshots will be stored in the fastlane/metadata/android/images directory of where you ran the screengrab command.

View The Results

Viola! Open the file to see how everything went. Here’s an example:

(Click image for larger resolution)

What else can I use this for?

The screengrab tool integrates with the Ffastlane toolsuite right out of the box.

It’s fairly new for Android, so if you haven’t heard about it I totally get it. Here’s a quick synopsis – fastlane lets you, as a developer or release manager, automate your deployment pipeline. From integrating with continuous integration taking screenshots, to placing them into device frames (currently iOS only though, hopefully Android soon! Hint Hint Fabric team!), to upload the files to Google Play automatically. Fastlane helps you automate the deployment process of your Android apps. Check out fastlane for more detailed info.

The screengrab tool has a few additional use cases:

Design/Product Manager Review
- Keep your product and design teams up to date with all of the screens in your application on a per build basis.
Automate Screenshots for release
Automate Screenshot automation for internal dog fooding and review processing with other tools.
… and of course, to validate what might have gone wrong during a test.

Does this replace my other screen capture tooling?

No, screengrab complements the existing toolchain that is out there. If you need/want to use your other solutions, feel free to keep using it. Screengrab is just another tool in your toolbox.

Pragmatic Development Tooling

I’m very pragmatic in my day to day development. When I do internationalize my next app (which I’m actually doing in the next month or two) I will be reaching for screengrab as the tool to help sanity check my work.

Why?

It’s simple. It’s easy. It helps me solve a problem and it gets out of my way. I don’t need to write the tool myself. It just works.

As with anything new, it has a purpose and it now occupies a space in my toolbox. Maybe it will help you save some time too.

« Previous Page