Forem: Nate Ebel

Kotlin vs Java for Android Development FAQ

Nate Ebel — Mon, 26 Apr 2021 12:00:00 +0000

Kotlin vs Java? Which language is best for Android development in 2021?

New Android developers want to know which language they should learn for building modern Android applications. Development teams want to be sure that Kotlin will not have a negative impact on their app’s performance, their ability to hire qualified engineers, or on their overall developer productivity.

To help inform your decisions, we’ve curated a list of some of the most frequently asked questions regarding Kotlin vs Java for Android development.

Frequently Asked Questions About Kotlin vs Java for Android Development

Which is better for Android development – Java or Kotlin?

Kotlin is the preferred language for Android development in 2021. Both Java and Kotlin can be used to build performant, useful applications, but Google’s libraries, tooling, documentation, and learning resources continue to embrace a Kotlin-first approach; making it the better language for Android today.

Does Google recommend Kotlin for Android development?

Yes. Google recommends developers start building Android applications with Kotlin, and has taken an increasingly Kotlin-first approach to modern Android development. Many Android Jetpack libraries have been either written completely in Kotlin, or support Kotlin language features such as coroutines.

When did Google start supporting Kotlin for Android?

Google announced official Android support for Kotlin at Google I/O in 2017.

When did Android become Kotlin-first?

Google adopted their current Kotlin-first approach to Android at Google I/O in 2019.

Is Java still used for Android development?

Yes. Absolutely. Java is still 100% supported by Google for Android development. The majority of Android apps today have some mix of both Java and Kotlin code. Developers can build the same functionality with Java as they can with Kotlin.

Will Android stop supporting Java?

It’s unlikely that Android will stop supporting Java any time soon. The Android SDK is still mostly written in Java. The majority of Android apps still include Java. The Android OS is built upon a Java Virtual Machine. To move away from Java completely would represent a monumental shift in the Android ecosystem.

Is Kotlin replacing Java?

No. Java will not be replaced completely by Kotlin. Java will likely continue to lose some marketshare to Kotlin within the Android ecosystem, but Java will remain one of the most used programming languages in the world.

While Java for Android continues to be constrained to Java version 8, beyond Android, Java is evolving quickly and adopting many features from other modern programming languages; including Kotlin.

Is Kotlin enough for Android development?

Yes. You can build Android applications using only Kotlin, and as documentation, tooling, and libraries become more Kotlin-focused, building apps exclusively with Kotlin will become even easier.

Should I learn Java or Kotlin for Android?

You should learn Kotlin first. If you have to pick between learning Java or Kotlin to start developing Android apps, you will have an easier time using current tools and learning resources if you know Kotlin.

If you already know Java, and want to focus on learning Android, then you could defer learning Kotlin in favor of focusing on the Android SDK.

Can I learn Kotlin without Knowing Java?

Yes. While knowing Java, or any programming language, will make it easier, Kotlin is a great first language thanks to things like static typing, type inference, and abundance of learning resources, and strong IDE support.

Is Kotlin easier than Java?

Many will find Kotlin easier to learn and write than Java. A number of things factor into this experience including Kotlin’s concise syntax, type inference, explicit nullability, and extensive standard library.

Can I get a job as an Android developer without knowing Kotlin?

Yes, but Kotlin is becoming an increasingly desirable skill for hiring managers looking for qualified developers. A LinkedIn search for “kotlin android developer” jobs turns up ~7,700 job postings while a search for “java android developer” returns ~7,800 results in the US. The relative number of postings is similaraly balanced in India with ~11,100 results for “java android developer” and ~11,000 for “kotlin android developer.“

As codebases, teams, libraries, and Google continue to move more towards Kotlin, expect Kotlin to become an even more important skillset for Android developer jobs.

Is Kotlin faster than Java?

No; although the true answer depends on what performance metrics you are interested in. At runtime, the performance of the languages is very similar. At compile time however, Kotlin is measurably slower than Java. The extent of the slowdown depends on a number of factors such as the usage of annotation processors, and the presence of mixed Java + Kotlin source sets

Where Can You Learn More About Kotlin and Android Development?

Check out our other posts on Kotlin and Android development here on goobar.

And you can find courses and tutorials on our YouTube channel.

The post Kotlin vs Java for Android Development appeared first on goobar.

Non-Coding Tips for Coding Interview Assignments

Nate Ebel — Tue, 20 Apr 2021 01:04:51 +0000

Unsurprisingly, when discussing take-home assignments for coding interviews, much of the focus is put on code. Can you code? Are you using “best practices?” What tools are you using?. There’s lots of code-related things that people think about, or even stress about.

Unfortunately, non-coding tips for coding interview assignments don’t get talked about nearly as much. And, in my experience, there are a lot of non-coding things we can do to put our best foot forward and impress a hiring committee with our take-home assignment.

Telling Your Story

What are these non-coding tips? If we’re completing a programming assignment, what else should we pay attention to?

Put yourself in the mindset of a reviewing engineer.

How will they experience your project?
How can you guide their experience?

How can you tell your story?

What do you want a reviewer to know about you after they review your code?
What interests, skillsets, workflows, or values do you want to highlight?

We want to help a reviewer get to know us – to understand what we can do. We want to think about giving reviewers reasons to be impressed by our projects and we want to do our best to limit head scratching moments.

Take-home assignments provide a unique opportunity to tell these stories because they are done asynchronously. During a take-home assignment, engineers are not typically under the watchful gaze of the hiring committee. We have a chance to be more natural; to think more clearly; and to take greater ownership of the impression we make.

Make a good first impression

Take-home assignments, as with many things, can really benefit from a positive first impression. If a reviewer starts exploring your assignment on a positive note, the rest of the review is likely to go better.

Using Project Metadata To Give Additional Context

If your project is using GitHub, git, or some other form of version control, then you have a great opportunity to showcase project information through various forms of “metadata” available to you.

If using git, your git history is a great way to highlight how you work.

If your project lives in GitHub, add relevant attribution. Give it a useful description. Add relevant topcis such as “android” or “kotlin” to give a quick overview of what the project is about. You might leverage GitHub Issues, PRs, and Milestones to give reviewers a sense of how you like to work and manage your tasks.

What can you add to your project to give helpful context to a reviewer? Don’t spend a lot of time here, but often a little bit of investment here can help give your project a more professional look.

Highlighting Information Using A Project README

Having a helpful project README in the root directory of your assignment submission is a terrific idea. A README the perfect place to document assumptions, outline your tasks, or add screenshots or video of the project.

Imagine yourself sitting down to present your project to a reviewer. Where would you start? What information would you want to highlight right away? Think of your README as this overview.

Use the README to guide the efforts of a reviewer. Call out interesting functionality. Call out tools and libraries that were used.

Use it to tell your story; whatever that may be.

Guiding Reviewers With Clear Project Organization

The last item to a great first impression is clear project organization. In most cases, I suggest you organize your project by “feature”, or by “layer”. You want your reviewer to be able to navigate your project easily.

You also want to demonstrate that your organization would scale to real-world, production projects. Putting all your files in a single directory might work for a small take-home assignment, but wouldn’t be a great choice for a large application.

Not sure if your project will be easy to navigate? Try navigating the project without your IDE. You might explore the project in GitHub or from your file browser. If it’s easy to navigate without an IDE’s search and class-lookup functions, then you should be good to go.

First Time User Experience

At some point, a reviewer is most likely going to run your code. What will that first-time-user experience be? A focus on two main things can really have a large impact on how a reviewer feels about your project.

Ensuring A Functional Experience

Make sure your app doesn’t crash when a reviewer installs it. You don’t want your app to crash at all, but it’s especially important that it doesn’t crash on startup. A crash on startup means a reviewer may not be able to evaluate the functionality – this does not usually lead to a great assignment review.

If you have the time, test your app startup across a few different device configurations. Maybe 2-3 different OS versions, and a couple of different screen sizes. If your app starts up, and is functional, across these configurations there’s a good chance your assignment reviewers will also be able to successfully start using your app.

Impressing With UI Polish

Once your app is started, what is the first thing a reviewer sees? If your main screen leaves a positive first impression, it can go a long way towards creating a positive feeling towards the project as a whole.

How can you leave a good impression? A little bit of design polish goes a long way. A few design items that are not time consuming, but really help the look/feel of your app:

A unique, visually appealing, color palette.
- The Material Design Color Tools is a great resource for this
Consistent spacing
- Using the Material Design 8dp grid is a great way to go
- Define a couple of dimension resources and use them throughout your layouts for a more professional look
Touch feedback
- Add a ripple effect when touching views is a nice UI addition
- This can be accomplished with very little effort and again goes a long way towards a more professional look
Don’t reinvent the wheel
- If you’re not sure how to structure the UI/Navigation in your app, look to existing apps for inspiration
- If your “weather app” assignment behaves like an existing app, it’ll likely make it easier to use for a reviewer, and that can often lead to a better overview impression
Adaptive design
- Ideally, your app’s UI would adapt to different screen sizes/configurations
- If your app doesn’t work well on small screens, or in horizontal layouts, call that out in your README or elsewhere.

What does your code say about you?

The way in which you write your code, whether it’s functional or not, can say a lot about how you operate as an engineer.

Leveraging Consistency To Improve The Review Experience

A big part of being a professional software developer is reviewing code. Code is easier to read and review if it uses consistent styling and conventions. This is true whether in a produciton codebase, or a take-home assignment.

Before you submit you project, run a code formatter on the code to ensure you are using a consistent style.

Building On A Solid Foundation

It’s great to highlight fancy libraries, or to build flashy features into your project. However, if they come at the expense of the fundamentals, they might actually hurt you more than help.

For example, if building an Android app, it’s considered best practice to define user-facing strings as String resources in a strings.xml file. Hardcoding all of your strings might be a red flag to reviewers.

If your project requires special permissions, and you don’t build a permissions workflow into the app, it could reflect poorly on your submission. Or if you place all of your code into a single, large class – it might reflect poorly on your submission.

The moral here is that well organize, well structured code that doesn’t miss on the basics is likely going to be better off than a project that uses the “new shiny” library but is built on a shaky foundation.

Documentation

Software developers often joke about their lack of documentation, or argue about whether good code even needs documentation. However, in an interview situation, good documentation is without a doubt a helpful tool.

Take home assignments are often about tradeoffs. You usually have a set number of tasks to complete with a limited amount of time in which to carry out the assignment. Tradeoffs must be made to balance completing the assignment with writing our ideal solutions.

Use documentation to detail those tradeoffs and to simulate the discussions that would come up during a typical work situation.

Documenting Your Decision Making

What assumptions did you make about the specified requirements? What questions did you have, and how did you answer them?

Why did you choose Library X over Library Y? Why did you choose Architecture A rather than Architecture B?

All of these types of decisions are opportunities do document and share your thinking.

You can go further than that as well. You could include more narrative documentation about areas you chose to focus on, and why? Why did you add unit tests? Why did you add a CI workflow? How did you come up with your custom color palette? These are all interesting notes that you can document and share with reviewer to give a sense of how you work.

And lastly, be sure to document anything that isn’t work – or isn’t working as specified.

Was your weather app supposed to show precipitation, but the api you chose only offers that data if you pay? Document that limitation so its absence doesn’t seem like an oversight.

Does your app crash when rotated? Call that out in the notes so it’s clear that you found and understand the issue. You might even get bonus points for including a suggested fix.

With most reviewers, you’re not going to lose points for transparency. Being upfront about what is, and isn’t, working builds trust – and trust is a very important part of choosing to work with someone.

Choosing Documentation Formats

Your documentation can come in a variety of forms. You might find that a mix of documentation formats is ideal for you, or you might focus on one above the rest. While I do highly suggest having a README, choose the documentation option(s) that work best for you.

A few documentation examples include:

A README in your project’s root directory
Code comments
GitHub Issues, Pull Requests, Milestones
A wiki in your repository
Architectural Decision Records
A recorded video of you walking through the project

Make It Your Own

Take-home assignments typically have a concrete set of requirements; usually a set of tasks to complete and specific functionally that must be present. That doesn’t mean that those tasks are the only things we can work on.

Telling Your Story By Customizing Your Submission

As mentioned earlier in this post, think about the story you want to tell to a reviewer. What do you enjoy working on? What is your “genius zone?” And how can you highlight those things in your submission?

Do you enjoy working with CI infrastructure? You could setup a simple CI workflow for your project and maybe include a small writeup on your preferred CI architecture.

Maybe you really enjoy bringing to life beautiful designs? You could add a unique animation or user interaction. A custom loading indicator or “empty state” screen are great opportunities for this.

Do you really believe in Test Driven Development? Write some tests for the project and include a summary of your testing philosophy.

These additions don’t have to be massive time investments, and honestly they probably shouldn’t be because we need to make sure the core functionality is there. But, an additional feature, test, or other custom element can be a really valuable way to highlight how you would be a uniquely valuable asset to any team.

Leveraging Non-Coding Tips For Your Next Coding Interview Assignment

Next time you have a coding interview assignment, don’t forget about these non-coding tips. Remember to put your best foot forward by:

Making a positive first impression
Ensuring a stable and pleasing first-time-user experience
Writing consistent, readable code
Documenting your code and decision making process
Making the project your own

If you can do these things, and complete the required assignment tasks, you will have gone a long ways towards helping yourself get that next job!

Where To Learn More?

Watch on our YouTube channel.

The post Non-Coding Tips for Coding Interview Assignments appeared first on goobar.

Free Up System Resources For Faster Gradle Builds

Nate Ebel — Tue, 09 Mar 2021 15:34:28 +0000

Are your Android Gradle builds ever slower than you expect? Sometimes even painfully slow?

I think most Android devs have felt this at one point or another, and many engineers spend countless hours optimizing Gradle builds to improve the productivity of mobile dev teams.

Unfortunately, sometimes, even a well-optimized Gradle build can be slow. Even really slow at times.

This was the case for our team recently.

We’ve invested a lot of time and effort into getting our Gradle builds under control; making them faster and more efficient across the team. And yet, over the past couple of weeks, we had noticed a frustrating trend of extremely slow builds for one of our devs.

According to our Gradle Enterprise data, some of their local builds were taking 5-15x longer than expected. This was far beyond our typical range of expected build times.

Obviously, something abnormal was happening here, but what?

Thankfully, between Gradle Enterprise build scan insights, and good old-fashioned pair-debugging, we were able to get a good sense of what was causing these extremely slow builds and take steps to rectify the situation.

I’m going to walk through some of our thinking and process in this post, but the moral of the story is this:

If your system is taxed BEFORE your Gradle build even starts, your build is likely going to be slow

Understanding What’s Working And What Isn’t?

How did we start investigating the cause of these slow downs?

As with most build speed issues, we started by investigating some of our build optimizations

Was local caching turned off for any of these builds?
Was remote caching turned off for any of these builds?
Were we suffering from negative cache savings when accessing the remote build cache?
Are we experiencing a high number of cache misses?
Were there extremely large change sets being built?

How we answered these questions is a post for another time. The short story is that we used Gradle Enterprise to explore the buildscan details for specific builds.

What matters here is that our build speed optimizations were generally working how we expected. And when comparing the execution of the same Gradle task across different developers’ machines, we continued to see a very large discrepancy in the execution time.

This hinted that there was something going on specifically with this machine, rather that with the project as a whole.

To help further rule out anything specific to the code or the build configuration, we tried one final test.

We ran ./gradlew help on two machines

On my dev machine which was building as expected
On the machine seeing the slowest of local build times

What we found was surprising, but helped highlight the possible issue.

Running the help task on one machine took ~1-3 seconds while on the affected machine it took over 2 minutes.

Clearly something was wrong here.

The help task helps us highlight only the configuration time of a Gradle project. If configuration alone is so bogged down that it’s taking minutes to complete, then maybe something is off in the environment itself, rather than with our build at large.

Examining System Configuration

If Gradle build optimizations were behaving as expected, only slower, then perhaps it was differences in the machines themselves.

To start digging into the development machine itself, we started by taking a look at the system’s CPU and available memory.

i5 processor
16GB memory

These specs immediately helped us understand that we couldn’t directly compare the build times from the affected machine and some of the other laptops on our team. We have a mix of devices. Some very similar to this i5/16GB configuration, while others are more similar to an i7/32GB configuration.

A lower spec’d machine would account for some increase in build times, but not to the extent we were seeing with as much as a 15x increase, and certainly wouldn’t explain why the help task took over 2min to finish.

So, we then went deeper; to look more closely at how the available resources were actually being used.

Examining System Resource Pressure

Running an Android Gradle build can be a taxing process; asking a lot from both system memory and from available CPUs.

If there are a lack of available system resources, perhaps the builds are being negatively impacted.

To check the status of the system, we opened up the MacOS Activity Monitor. We wanted to check two things:

Idle CPU %
Memory Used

The results of this stuck out like a sore thumb.

Without Android Studio or a Gradle build running we saw the following:

15% idle CPU (Meaning 85% usage)
25% available memory (12GB used out of 16GB total)

As soon as we opened Android Studio on the affected machine, we saw further large spikes in CPU and memory to the point where the machine started to lock up across the board; bringing everything to a halt.

We had found our culprit.

The combination of Android Studio, Android Virtual Devices, video calls, and endless browser tabs was severely taxing this laptop’s system resources. Add in an Android Gradle build and suddenly CPU and Memory were maxed out, causing things to come to a screeching halt.

Freeing Up System Resources

Thankfully, this hypothesis was pretty easy test and remedy. We used Activity Monitor to examine what was taking up CPU/Memory and tried to close the most taxing processes.

CPU

On the CPU front, a few things stuck out to us

pretty consistently high usage from the browser; likely coming from the video call we were on
several unknown processes that looked to be taking up a lot of CPU. At least 2 of these were known issues on MacOS
an Android emulator running in the background that wasn’t taking up a lot but still requiring some consistent CPU usage

Memory

It was a bit easier to understand where the system memory was being allocated.

the web browser was taking up a large chunk of memory; likely due to a high number of tabs open and an active video call
an Android emulator running in the background taking up ~3GB of memory
Slack, and additional apps running in the background
when opened, Android Studio consumed ~4GB

After closing out of numerous tabs and programs, changing web browsers, closing the Android emulator, and closing Android Studio, we re-ran the help task from the command line.

This time, the task completed in a few seconds as we would expect.

For a more comprehensive test, we ran our default build task again, and were again happy to see that build times were much closer to our expected baseline performance.

Recommendations For Keeping Your Build Fast

The moral of this story is that our Android builds are going to be painfully slow if our systems do not have enough cpu and memory resources available.

So, if you’re experiencing unusually slow builds, you might try some of the following before cursing Gradle and the Android build system.

change to a less resource web browser
avoid building your app while on a video call
use a physical device for testing to avoid the use of an emulator
build your app without Android Studio being open
build your app without any other taxing programs being open
adjust Gradle’s JVM memory settings to something that isn’t likely to consume all your available memory
keep your machine well cooled to avoid thermal throttling of your CPU

And last, but certainly not least, try to get a more powerful development machine if you can.

If you’re in a position of leadership/influence in your team, and you see a coworker dealing with slow builds simply because they have an underpowered machine, I encourage you to put together a developer efficiency business argument for getting them a faster machine.

A couple of thousands of dollars for a new laptop is likely going to be cheaper and faster than trying to shave another couple of minutes off your already optimized Gradle build.

Wrapping Up

Hopefully this will help those out there that are maybe scratching their heads as to why their well-optimized builds are still building so slowly; or intermittently slowly.

With so many more video calls, more documents being passed around, and a lack of access to physical testing devices, it’s maybe not surprising if we are over-taxing our laptops and slowing down our builds.

The post Free Up System Resources For Faster Gradle Builds appeared first on goobar.

Benchmarking Gradle Builds Using Gradle-Profiler

Nate Ebel — Thu, 12 Nov 2020 17:38:59 +0000

In this post, we’re going to take an introductory look at benchmarking Gradle build performance using the gradle-profiler tool.

By the end, you should have a basic understanding of how to use gradle-profiler to gain better insights into the performance of your Gradle build and how you might use those insights to improve Gradle build performance for your project.

What is the Gradle-Profiler Tool?

The gradle-profiler project describes itself in the following way:

“A tool to automate the gathering of profiling and benchmarking information for Gradle builds.”

What does that mean to you and your project?

Imagine you want to get a sense of how fast your Gradle build is.

You might run your target Gradle task, wait for the build to complete, and take that build time as your result.

Now, because build times are often variable, you may want to run your Gradle task multiple times and average the execution times. So, you kick off your build, wait for it to finish, write down the total execution time, and repeat the process.

This process of manually benchmarking your Gradle build will likely take a while. Depending on how long your build takes to complete, and how many interactions you want to run, you could find yourself repeatedly coming back to your computer to check whether it’s time to start the next build or not. Even if you stay busy with other things, this is still a drawn out, tedious process that relies on you, as the developer, manually recording build statistics for each iteration.

It’s this process that gradle-profiler aims to automate for you.

Rather than you having to manually kick off each build and recording the resulting build statistics, gradle-profiler allows devs to start a single command which will repeatedly run a specified Gradle task and record all the build stats in an easy to examine output format.

This takes Gradle build benchmarking from a tedious, manual task to something that can be highly automated with little need for human interaction or monitoring.

I’ve been using gradle-profiler recently in an effort to keep my primary project’s build times low, and to examine the build impact of proposed changes. In this post, we’re going to walk through how you can start using gradle-profiler to gather benchmark data for your Gradle build, and how you may start using that data to understand the impact of changes on your project.

Installing Gradle-Profiler

Before you can start benchmarking Gradle build performance, you’ll need to install gradle-profiler to your development machine.

You can do this in one of several ways

Install From Source

You could clone the git repository to your local machine, and build the project from source.

→ git clone git@github.com:gradle/gradle-profiler.git
→ cd gradle-profiler
→ ./gradlew installDist

You would likely then want to add gradle-profiler/build/install/gradle-profiler/bin to your path or create some kind of alias that enables you to invoke the tool by executing the gradle-profiler command.

Install With Homebrew

If you are using Homebrew on your machine, installation is quite simple.

→ brew install gradle-profiler

Other Installation Options

If building from source, or installing using Homebrew, aren’t good options for you, you could try either of the following installation methods:

Examples On GitHub

You can find example commands and example benchmark scenarios in my sample repo on GitHub.

Find The Code

Benchmarking Your Gradle Build

Now that gradle-profiler is installed, and the gradle-profiler command is available to us, let’s start benchmarking Gradle build performance for your project.

Running the Benchmarking Tool

To generate benchmarking results for our project, we need two things:

The path to the project directory containing the Gradle project
A Gradle task to run

With these, we can start benchmarking our build like this:

→ cd <project directory>→ gradle-profiler --benchmark --project-dir . assemble

Let’s break down this command into its individual parts.

gradle-profiler – invokes the gradle-profiler tool
--benchmark – indicates that we want to benchmark our build
--project-dir . – indicates that the Gradle project is located within the current working directory
assemble – this is the Gradle task to benchmark

When this command is run, the benchmarking tool will begin. You should see output in your console indicating that warm-up and measured builds are running.

When all the builds are completed, two benchmarking artifacts should be created for you:

benchmark.csv – provides benchmarking data in a simple .csv format
benchmark.html – provides an interactive webpage report based on the .csv data

The output paths should look something like this:

Results written to /Users/n8ebel/Projects/GradleProfilerSandbox/profile-out
/Users/n8ebel/Projects/GradleProfilerSandbox/profile-out/benchmark.csv
/Users/n8ebel/Projects/GradleProfilerSandbox/profile-out/benchmark.html

Understanding Benchmarking Results

Once your outputs are generated, you can use them to explore the benchmarking results.

Interpreting .csv results

Here’s a sample benchmark.csv output generated by benchmarking the assemble task for a new Android Studio project.

CSV benchmark results for assemble task

This report is very streamlined and highlights only a few things. The most interesting data points are likely:

Which version of Gradle was used
Which Gradle tasks were run
The task execution time, in milliseconds, for the warm-up and measured builds

Notice that the first warm-up build took significantly longer than every other build? Is this a problem? Is something wrong with your project’s configuration?

By default, gradle-profiler uses a warm Gradle daemon when measuring build times. If you’re not familiar, the Gradle daemon runs in the background to avoid repeatedly paying JVM startup costs. It can drastically improve the performance of your Gradle builds.

So, for this first warm-up build, task execution time is much longer as the daemon is started. After that, you can see that subsequent builds are much faster.

If we ignore the warm-up builds, and look only at the set of measured builds, we see that the build times are consistently fast as one might expect for a new project.

Interpreting HTML results

In addition to being an interactive webpage, the benchmarking.html results provide more data than the .csv file. By viewing the results this way, you’ll have access to:

Mean, Median, StdDev, and other statistics from the measured build results
Gradle argument details
JVM argument details
And more…

HTML benchmark results for assemble task

The HTML results provide a graph of each warm-up and measured build to help you visually understand performance over time.

If you aren’t interested in automating the analysis of your benchmarking results, then viewing the HTML results is often the most convenient way to quickly understand how long your build takes, and to quickly see if there are any outlier executions to examine.

This HTML view becomes even more useful when benchmarking multiple scenarios at the same time as we’ll see later on.

Detecting Gradle Performance Issues

Now that we have some understanding of the output generated by gradle-profiler benchmarking, let’s explore how we might begin to use that benchmark data to compare the performance of our Gradle builds.

The simplest approach is generally as follows:

Collect benchmarking data for your current/default Gradle configuration
Change your Gradle configuration
Collect benchmarking data for updated configuration
Compare the results

We could use this approach to compare the impact of caching on a build. We might compare the performance of clean builds versus incremental builds.

Any tweak to our build settings or project structure could be examined through this type of comparison.

Comparing clean and up-to-date build performance

Let’s walk through a quick example of this kind of analysis using gradle-profiler. We’re going to compare the impact of an up-to-date build over a clean build.

First we’ll benchmark up-to-date builds of our assemble task and collect the results.

→ gradle-profiler --benchmark --project-dir . assemble

We’re referring this as the up-to-date scenario because after the first execution of the assmble task, each task should be up-to-date and subsequent builds should be extremely fast as there is nothing to rebuild.

Next, we’ll benchmark our clean build.

→ gradle-profiler --benchmark --project-dir . clean assemble

In the clean build scenario, we are discarded previous outputs before executing our assemble task, so we should expect the clean build to take longer than the up-to-date build.

Once we’ve generated both sets of output, we can compare the benchmarked performance. I’ve taken the .csv results from each of those benchmarking executions and combined them into the following table for comparison.

With this, we can see that our up-to-date build takes ~1 second while our clean build is taking ~7 seconds. This seems in line with expectations about the relative performance of these two build types.

Comparing caching impact

We’ve seen the performance of an up-to-date build. We’ve seen the impact of doing a clean build.

Let’s expand on our example by now benchmarking the impact of enabling Gradle’s local build cache.

First, we’ll once again benchmark a clean build without enabling the build cache.

→ gradle-profiler --benchmark --project-dir . clean assemble

Next, we’ll enable Gradle’s local build cache by adding the following to our gradle.properties file:

_org.gradle.caching_=true

Now, we can re-run our clean build benchmark scenario; this time with the cache enabled.

→ gradle-profiler --benchmark --project-dir . clean assemble

Once again, we can compare results to get a sense of how enabling the local Gradle build cache can benefit build performance.

No Caching		Caching
scenario	default	scenario	default
version	Gradle 6.7	version	Gradle 6.7
tasks	clean assemble	tasks	clean assemble
value	execution	value	execution
warm-up build #1	26492	warm-up build #1	24568
warm-up build #2	10345	warm-up build #2	6838
warm-up build #3	9853	warm-up build #3	4901
warm-up build #4	8757	warm-up build #4	5145
warm-up build #5	8705	warm-up build #5	4382
warm-up build #6	7377	warm-up build #6	5309
measured build #1	7268	measured build #1	4825
measured build #2	7378	measured build #2	4674
measured build #3	7750	measured build #3	4428
measured build #4	6707	measured build #4	4577
measured build #5	6635	measured build #5	4053
measured build #6	7542	measured build #6	4236
measured build #7	7066	measured build #7	4388
measured build #8	6398	measured build #8	4131
measured build #9	6341	measured build #9	5818
measured build #10	7416	measured build #10	4016

Merged CSV results comparing the build speed impact of enabling the Gradle build cache

From these results, we see that enabling local caching seems to improve the performance of clean builds from ~7 seconds to ~4.5 seconds.

Now, these build times are artificially fast as it’s a simple project.

However, this approach is applicable to your real-world projects, and these general results are what one might expect from a well-configured project; up-to-date < clean with caching < clean w/out caching.

Configuring Benchmarking Behavior

When running these benchmarking tasks, you may find yourself wanting greater control over how benchmarking is carried out. A few of the common configuration properties you may find yourself needing to change include

changing the project directory
modifying the output directory
updating the number of build iterations

We’re going to quickly examine how you can update these properties when executing your benchmarking task.

Changing Project Directory

Throughout these examples, we’ve been operating as if we are running gradle-profiler from within the project directory.

Here, we see that after the --project-dir flag, we pass . to signify the current directory.

→ gradle-profiler --benchmark --project-dir . assemble

If we want to run gradle-profiler from any other directory, we are free to do that. We just need to update the path to the project directory.

In this updated example, we change directories into our user directory, and pass Projects/GradleProfilerSandbox as the path to our project directory.

→ cd
→ gradle-profiler --benchmark --project-dir Projects/GradleProfilerSandbox/ clean assemble

Changing Output Directory

When gradle-profiler is run, by default, it will store output artifacts in the current directory. If you would prefer to specify a different output directory, you can do so using --output-dir.

gradle-profiler --benchmark --project-dir Projects/GradleProfilerSandbox/ --output-dir Projects/benchmarking/ clean assemble

This may come in handy if you want to automate the running of benchmarking tasks and would like to keep all your outputs collected within a specific working directory.

Controlling Build Warm-Ups and Iterations

Another pair of useful configuration options are --warmups and --iterations. These two flags allow you to control how many warm-up builds and measured builds to run.

This might be useful to you if you want to receive your results more quickly, or if you want more data points, and hopefully greater confidence, if your benchmarking results.

If we wanted to have 10 warm-up builds and 15 measured builds, we can start our benchmarking task like this.

→ gradle-profiler --benchmark --project-dir . --warmups 10 --iterations 15 assemble

Benchmarking Complex Gradle Builds

We’ve really only scratched the surface of what gradle-profiler is capable of. Real world build scenarios are varied, and often quite complex. Ideally, we’d be able to capture these complexities, and benchmark Gradle build performance for these real-world conditions.

Let’s take a look at how we can define benchmark scenarios that give greater control and flexibility into what is benchmarked.

Defining a Benchmark Scenario

As our command line inputs become more complex, it may become difficult to manage.

Look at the following command.

gradle-profiler --benchmark --project-dir Projects/GradleProfilerSandbox/ --output-dir Projects/benchmarking/ --warmups10 --iterations 15 clean assemble

This command is still executing a fairly simple benchmarking task, but has already become quite long and unwieldily to execute from the command line every time.

This is especially true if we want to start benchmarking multiple build types, or want to simulate complex incremental build changes.

To help define complex build scenarios, the gradle-profiler tool provides a mechanism for encapsulating all of the configuration for a build scenario into a .scenarios file. This helps us organize our scenarios in a single place and makes it easier to benchmarking multiple scenarios.

To define a simple .scenarios file, we’ll do the following.

First, we’ll create a new file named benchmarking.scenarios.
Next, we’ll define a scenario for our up-to-date assemble task.

assemble_no_op {
  tasks = ["assemble"]
}

In this small configuration block, we’ve defined a scenario named assemble_no_op that will run the assemble task when executed. We’ve used the “no op” suffix on the scenario name because this will test our up-to-date build in which tasks shouldn’t have to be re-run each time.

Benchmarking With a Scenarios File

With our scenario file defined, we can benchmark this scenario by using the --scenario-file flag.

gradle-profiler --benchmark --project-dir . --scenario-file benchmarking.scenarios

From this, we get an HTML output similar to this.

HTML output from running the assemble_no_op benchmark scenario

We can see that the assemble_no_op name used to define our scenario is automatically used as the scenario name in the output.

In the next sections, we’ll see how to changes this to something more human-readable and why this can be important.

Configuring Build Scenarios

Within our .scenarios file, there are quite a few configuration options we can use to control our benchmarked scenarios.

We can provide a human-readable title for our scenario:

assemble_no_op {
  title = "Up-To-Date Assemble"
  tasks = ["assemble"]
}

We can provide multiple Gradle tasks to run:

assemble_clean {
  title = "Clean Assemble"
  tasks = ["clean", "assemble"]
}

You could pass in different Gradle build flags such as for parallel execution or for the build cache:

assemble_clean {
  title = "Clean Assemble"
  tasks = ["clean", "assemble"]
  gradle-args = ["--parallel"]
}

We can also explicitly define the number of warm-ups and iterations so they don’t have to be passed from the command line:

assemble_clean {
  title = "Clean Assemble"
  tasks = ["clean", "assemble"]
  gradle-args = ["--parallel"]
  warm-ups = 3
  iterations = 5
}

This is not an exhaustive list of scenario configurations. You can find more examples in the gradle-profiler documentation.

Benchmarking Multiple Build Scenarios

One of the primary benefits of using a .scenarios file is that we can define multiple scenarios within a single file, and benchmark multiple scenarios at the same time.

For example, we could compare our up-to-date, clean, clean w/caching builds from a single benchmarking execution, and receive a single set of output reports comparing all of them.

To do this, we first define each of our unique build scenarios within our benchmarking.scenarios file.

assemble_clean {
  title = "Clean Assemble"
  tasks = ["clean", "assemble"]
}

assemble_clean_caching {
  title = "Clean Assemble w/ Caching"
  tasks = ["clean", "assemble"]
  gradle-args = ["--build-cache"]
}

assemble_no_op {
  title = "Up-To-Date Assemble"
  tasks = ["assemble"]
}

Then we continue to invoke gradle-profiler in the same way; by specifying the single .scenarios file.

gradle-profiler --benchmark --project-dir . --scenario-file benchmarking.scenarios

From this, we will receive a merge report that compares the performance of each scenario.

HTML output for multiple build scenarios

Scenarios will be run in alphabetical order based on the name used in the scenario definition; not the human-readable title.

When viewing a report with multiple scenarios, you can select a scenario as the baseline. This will update the report to display a +/-% on each build metric where the +/-% is the statistical difference between the current scenario and the baseline scenario.

What does that look like in practice?

In this example, we’ve selected the clean build w/out caching scenario as our baseline.

HTML output for multiple build scenarios with a selected baseline

With the baseline set, we see that the mean build time was reduced ~4% for the clean build with caching scenario and ~80% for the up-to-date build scenario.

By setting a baseline, you let the tool do all the statistical analysis for you leaving you free to interpret and share the results.

Benchmarking Incremental Gradle Builds

The last concept we’re going to touch on is that of benchmarking incremental builds. These are builds in which we need to re-execute a subset of tasks because of file changes. These files could change due to source file changes, resource updates, etc.

Incremental scenarios can be very important for real-world benchmarking of Gradle build performance, because in our day-to-day work, we’re often performing incremental builds as we make a small code change, and redeploy for testing.

When using gradle-profiler we have quite a few options available to us for defining and benchmarking incremental build scenarios.

If building with Kotlin or Java, we might be interested in:

apply-abi-change-to
apply-non-abi-change-to

If building an Android application, we might use:

apply-android-resource-change-to
apply-android-resource-value-change-to
apply-android-manifest-change-to
apply-android-layout-change-to

With these options, and others, we can simulate different types of changes to our projects to benchmark real world scenarios.

Here, we’ve defined a new incremental scenario in our benchmarking.scenarios file.

incremental_build {
  title = "Incremental Assemble w/ Caching"
  tasks = ["assemble"]

  apply-abi-change-to = "app/src/main/java/com/goobar/gradleprofilersandbox/MainActivity.kt"
  apply-android-resource-change-to = "app/src/main/res/values/strings.xml"
  apply-android-resource-value-change-to = "app/src/main/res/values/strings.xml"
}

This scenario will measure the impact of changing one Kotlin file, and of adding and modifying string resource values.

The resulting benchmark results look something like this.

HTML benchmark results including incremental build scenario

As expected, the incremental build was measured to be faster than a clean build, but slower than an up-to-date build.

This is a very simple example. For your production project, you might define multiple different incremental build scenarios.

If you’re working in a multi-module project, you might want to measure the incremental build impact of changing a single module versus multiple modules. You might want to measure the impact of changing a public api versus changing implementation details of a module. There are many things you may want to measure in order to improve the real world performance of your build.

What’s Next?

At this point, hopefully you have a better understanding of benchmarking Gradle build performance using gradle-profiler, and how to start using gradle-profiler to improve the performance of your Gradle builds.

There’s still more that can be done with gradle-profiler to make it more effective for detecting build regressions and to make it easier to use for everyone on your team.

I’ll be exploring those ideas in upcoming posts.

If you’d like to start learning more today, be sure to check out gradle-profiler on GitHub and Tony Robalik’s post on Benchmarking builds with Gradle-Profiler.

You can find more Gradle-related posts here on my blog.

The post Benchmarking Gradle Builds Using Gradle-Profiler appeared first on goobar.

Understanding, Profiling, and Optimizing Gradle In Android Builds

Nate Ebel — Mon, 26 Oct 2020 16:05:46 +0000

If you’ve spent any time as an Android developer you’ve probably experienced some level of frustration with Gradle in Android builds.

I’m no exception to this rule. I’ve often enjoyed a laugh at Gradle’s expense, or laughed and nodded along as coworkers shared their own harrowing stories of lengthy or broken builds.

However, I also think much of this frustration and complaint is unwarranted, or at the very least, misplaced. The Android build toolchain has a number of unique components and I often find others, and myself, blaming Gradle for something that might not actually be Gradle’s fault at all.

So this week, I want to pull back the curtain, and share a bit about Gradle and how it relates to our Android builds.

How Does Gradle Relate To Your Android Project?

Let’s start at beginning.

What is Gradle?

Gradle is a build tool capable of building software projects across a variety of different languages and domains.

Gradle projects are configured using a Groovy-based DSL (Domain Specific Language). Groovy, itself, is a multi-purpose programming language for the Java Virtual Machine (JVM).

How then do these both work together to build our Android apps?

What Are The Individual Components Of An Android Build?

To build our Android apps using Gradle, we rely on another important component; the Android Gradle Plugin.

The Android Gradle Plugin builds upon the generic concept of Gradle plugins to support the Android build requirements. Custom Gradle tasks, and build configuration options are provided by the Android Gradle Plugin to control how an Android application is built.

Android Gradle Plugin (AGP) is not directly tied to Android Studio, though they do often have a close connection. As new features are added to the plugin, Android Studio is generally updated to take advantage of those features to provide a better developer experience.

How Is Your Android Gradle Project Structured?

A Gradle project is comprised of one, or many, modules. A module may consist of any combination of source code, resources, assets, and build configuration.

Your Android project configuration is comprised of several different files:

a top-level settings.gradle file to indicates which individual Gradle modules should be loaded
a top-level build.gradle file that can be used to declare project-level dependencies, plugins, and other configuration
one, or many, module-level build.gradle files that define how each individual module and built and how they relate to one another

If you create a new project in Android Studio, you generally have a single :app module created.

How do these build components work to build your app?

How do all of these pieces work together to actually build your Android app?

Your project, and each module, use the Groovy language and Gradle DSL to control how they should be built.

Any of these projects that need to know about the Android framework will use the Android Gradle Plugin to configure Android-specific build options such as minSdk, buildTypes, lintOptions, etc.

This is easily recognized by applying the plugin to a build.gradle file

plugins {
  id 'com.android.application'
}

and by modifying the Android configuration block

android {
  compileSdkVersion 30
  buildToolsVersion "30.0.1"
  ...
}

All of these build.gradle files will work together to define which tasks should be generated and run. Each Gradle task is responsible for one small piece of the project compilation and packaging process.

To see a list of all Gradle tasks available for your Project, you have two options:

Run ./gradlew tasks from the command line
Open the Gradle tool window within Android Studio or IntelliJ

Once all tasks are defined and configured, the general Gradle build tool will process the build files, generate any needed tasks, and ultimately execute each task.

Most Gradle plugins use enhanced tasks which means they contain all the behavior needed to perform their desired action. Enhanced tasks also are responsible for declaring needed inputs and outputs.

You can think of a Gradle task as a function that takes in a set of inputs, and generates a specific output. The work executed could be processing a file, merging resources, uploading an .apk to Firebase, or any number of other actions.

Once these tasks finish executing, the Gradle build is complete.

What Are The Pain Points Of Gradle In Android Builds?

I hear, and have experienced, several common complaints about different parts of this build process.

Defining build logic

Many people feel it’s too difficult to define, or customize, build logic. Gradle often gets blamed for this, when in reality, it’s like Groovy that developers are unfamiliar with.

Because Groovy can be both dynamically, and statically, typed, it can feel very foreign if you’re not expecting dynamic typing. How do I define a variable to determine whether we’re building on CI or not? How to I loop over a collection of build variants? Lack of robust auto-completion can leave developers feeling lost when trying to define custom build logic.

To help with this, you may benefit from learning more about Groovy as a language. The language syntax guide may be a good starting point for you.

Additionally, improvements to Gradle and Android Studio have made it possible to define your Gradle build logic using statically typed Kotlin, rather than Groovy. If you miss static typing and Kotlin language features when defining your build logic, read more about how to start using the Gradle Kotlin DSL.

Exploring the Android Gradle Plugin

Another big Gradle-related frustration for Android devs is that they don’t know what configuration options are available. What flags are available to control how a project is built? How do you work with Android-specific facets of the build during the Gradle build process.

To help answer these questions, it be be useful to read through api reference docs for the Android Gradle Plugin. This gives detailed documentation on what configuration blocks, and types can be used to control your build.

For example, if you were looking for more information on how to control Android Lint tasks, you could reference the lintOptions { } configuration block.

Other configuration blocks include

Working with annotation processors

One of the most common, and serious, build issues Android developers may face is that of slow builds.

There are lots of reasons your build may be slow; and we’ll look at some tools for detecting and fixing these issues. One of the most common culprits of a slow build are annotation processors. Tools like Dagger or Android DataBinding rely on annotation processors to generate code at compile time. This saves code and the cost of slower builds. This issue is particularly bad when using annotation processors in Kotlin projects.

To help with this, take a look at the Annotation Processing with Kotlin guide. In it, you’ll find several tips for ensuring your build is better optimized for annotation processing.

Profiling Gradle In Android Builds

As you start to further understand your Gradle build, you’ll likely want to profile it to really dig in and see which parts of your build are taking the most time.

The go-to tool for this are Gradle build scans. A build scan provides deep insights into your gradle build including, which tasks were executed, which tasks were pulled from local and remote caches, and which tasks are taking the most time.

To generate a build scan for any Gradle build, you can add the –scan build flag after the invocation.

Once the task finishes, you’re receive a link to a report like the following.

A sample build scan

Open the report into a web browser, and you’ll be able to explore every facet of your build, and can use this information to start optimizing your build.

If your team is using Gradle Enterprise, you’re likely already familiar with using Gradle build scans. To get the most out of these scans, it’s helpful to make them easily discoverable for everyone on your team. I recently shared about how we surfaced Gradle build scans within our GitHub Actions workflows.

For more on Gradle build scans, you can follow this guide.

Benchmarking Gradle In Android Builds

As you start profiling your build, you may identify avenues of possible improvement. When making changes to your build. it can be useful to benchmark current, and updated, build performance to know whether your changes are actually impacting your build.

To do this, you can turn to the gradle-profiler tool.

Gradle-profiler helps you automate the repeated testing, and data collection, needed to really understand build performance.

Imagine running 10 Gradle builds in a row, collecting the build times, and performing statistical analysis on those build times. That’s effectively what gradle-profiler provides.

With gradle-profiler you can benchmark a single simple task, a complex build scenario, or even a suite of build scenarios.

These benchmarks can also be run against different branches of your app. This can allow you to compare the benchmark performance of any given branch to that of your default branch; ideally detecting build regressions before they’re ever checked in.

For a great overview of using gradle-profiler check this post from Tony Robalik.

Optimizing Your Gradle Build

Finally, once you’ve profiled your build, and once you know how to benchmark the impact of any build changes, you’re going to want to start optimizing performance to have the fastest, most efficient build possible. This can save your team both time and money.

Enabling performance settings

There are several build properties that can be set to help provide quick build performance wins:

org.gradle.parallel=true
org.gradle.vfs.watch=true
org.gradle.caching=true

By setting the parallel flag, you enable your project to build multiple tasks at the same time, as long as they are in different modules. If you have a multi-module setup, this can be a great performance win.

The vfs.watch flag enables the new filesystem watching feature of Gradle which monitors information about which files are changing to improve incremental build times.

Gradle build cache

The caching flag is one of the biggest performance changes you can make. Gradle has two different build cache types: local and remote.

Setting the caching flag will enable the local build cache.

With caching enabled, the outputs of Gradle tasks are saved to the cache and reused for future builds. This can dramatically speed up clean and incremental builds.

Similarly, you can enable a remove build cache that moves this concept to a remote server. You might configure your CI server to push task outputs to the remote cache which can then be reused by everyone on your team, and by future CI builds.

Browse the Gradle Build Cache guide for more information on enabling caching for you project. Additionally, there’s a great webinar from Gradle on how to get the most out of the Gradle build cache. I highly recommend watching that to learn more on profiling and optimizing your Gradle build.

JVM memory settings

You may also want to update your JVM memory settings to provide Gradle/JVM more memory when building your app.

org.gradle.jvmargs=Xmx2g

Build performance plugins

There are also two really useful plugins I can recommend for helping you fix and monitor Gradle build issues.

First, the Gradle-Doctor plugin helps you diagnose common issues such as mismatched JDK versions and negative remote build cache savings. If building an Android app, gradle-doctor can also help you understand how much time is spent by Dagger annotation processing.

Second is the Android Cache Fix Gradle Plugin. This is a must-try plugin for Android projects.

It provides workarounds for Gradle build issues present in the Android Gradle Plugin. Most noticeably, it helps fix cache misses due to these issues with AGP. In a well configured Gradle build, fixing cache misses can have a massive positive impact on your build times.

Integrate this plugin, re-run your benchmark scenarios, and you’ll hopefully see nice positive improvements to your build times.

Android builds are complex, with multiple languages, tools, and plugins to consider. As we spend so much of our time waiting for code to compile, or CI builds to run, it’s in the best interest of ourselves, our teams, and our organizations if our builds are fast and efficient.

I think the best way to start improving the efficiency of our builds is to better understand our build tools and the overall build process.

Hopefully, this has helped you better understand some of these individual build components, and helped point you to resources to help you further your understanding of the Android build process.

The post Understanding, Profiling, and Optimizing Gradle In Android Builds appeared first on goobar.

Remote Work in 2020 is Not Normal – Will We Evaluate It Fairly?

Nate Ebel — Mon, 19 Oct 2020 12:30:00 +0000

How are you feeling about working from home right now?

As I look around the internet, it appears to me that results are mixed. Many are loving the new remote work lifestyle. Many others are stressed, working more hours, and feeling pressure to maintain productivity while working from home.

I don’t believe either of these groups are right or wrong. Everyone’s situation is unique.

One thing I do believe strongly though;

Working from home right now, during a global pandemic, is NOT the same thing as “remote work”.

I feel that this is getting lost in too many discussions lately.

This is not a normal year

With large companies like Google, Facebook, and Microsoft continuing to adopt more permanent remote-work policies, it looks as if remote work is poised to stick around for a while.

I don’t think remote work is right from everyone. It’s not, and it doesn’t need to be.

But I also don’t think the current realities of working from home are an accurate, or fair, representation of what a remote work culture can be.

According to Buffer’s State of Remote Survey, remote employees largely want to stay remote. However, if 2020 is your first foray into remote work, I wonder if that is still the case.

We’re extra stressed right now.

There are more distractions throughout the day; kids learning from home; extra deliveries; partners also working from home; etc

We can’t really get out of the house to work.

We can’t meet up with others to work, chat, brainstorm, collaborate.

On top of all of that, it seems many companies haven’t actually shifted to a remote-first mindset.

All-day meetings are even more draining right now. Employees are feeling pushed to work nights and weekends. Defaulting to real-time communication adds to the pressure of being always at a keyboard; even when that’s at odds with the realities of being at home.

In short, translating the on-site work experience to the home is challenging, and in many ways, just doesn’t really work. This leaves employees feeling overwhelmed, less creative, more isolated, and longing for a return to work-normalcy.

All in all, there are currently many things which are very atypical of enjoyable, and successful, remote work.

I worry that during this big initial push into remote work, let’s call it v1, that the evaluation by organizations/managers/individuals will fail to take into account everything else going on right now. I fear that this will keep many from getting to remote work v2 in which there are hopefully fewer abnormal circumstances and more of the traditional benefits of a remote work culture.

What does remote work usually look like?

Are you getting your first taste or remote work here in 2020, and it’s not what you thought it would be?

I can relate.

I’ve been remote for 4+ years now, and this year has still been unusual. It has not been the same remote work situation that I’m accustomed to, or that I enjoy so much.

How does remote work usually look?

For me, remote work has generally been filled with far more connection, flexibility, and variety than it has here in 2020.

I miss getting out of my home to work from a coffee shop, or library, or a co-working space.

I miss being able to change locations when the home is too loud; or too distracting.

I miss meeting with local co-workers or friends to chat, work, brainstorm, plan, organize, etc…

The lack of 1 on 1 chats, meetups, and conferences has me feeling disconnected, isolated, and uninspired.

In the past, I’ve been able to travel and meet my remote team in person. This builds trust, improves communication, and leads to a better working relationship. In 2020, I haven’t even been able to meet remote teammates living in the same city; let alone the ones from all over the world.

Speaking of travel, it’s difficult right now to get away and recharge in the same way we used to. Even just going outside for a relaxing walk is not as simple or relaxing as it used to be. This has accumulated over the year; myself and others are starting to feel the fatigue of our current situations.

None of these things matches my previous experiences with remote work.

What’s the future of remote work?

I don’t expect all companies to shift to remote-first work; not all can or should. And I know that my experience with remote work may be very different than yours.

If you don’t want to work remotely, there’s absolutely nothing wrong with that.

But if you thought you might like remote work, and aren’t enjoying it here in 2020, I hope some of this resonates with you and maybe gives you hope that your remote work dreams are still possible under different circumstances.

I do worry that the efficacy of remote work will be unfairly judged during this period, and I’m also encouraged by the number of people that find themselves adapting to remote, acknowledging the realities of 2020, and still finding themselves wanting to make a more permanent shift in remote work.

I hope the increase in remote work stays around. Not because we’re forced into, but because more teams find themselves adapting to it favorably, and in a way that emphasizes outcomes, trust, and the human being. As discussed in this recent CNBC article, these changes in leadership are needed to make the effective shift into remote work. It seems like this may be the case, but only time will tell.

In my experience, effective remote work has enabled me to work around life, rather than living around work. That’s what I wish for all of us, and I see increased remote work opportunity as a powerful tool in realizing that for more people; not because everyone should be remote, but because I hope those that wish to be remote can find healthy, thriving remote teams in the future.

The post Remote Work in 2020 is Not Normal – Will We Evaluate It Fairly? appeared first on goobar.

Surfacing Gradle Build Scans Within GitHub Actions Workflows

Nate Ebel — Tue, 13 Oct 2020 12:37:00 +0000

This post demonstrates several approaches for surfacing Gradle build scans within GitHub Actions workflows; thereby making them more discoverable and hopefully more useful to a team.

Recently, our Android team at Premise Data has worked with the Gradle Enterpriseteam to optimize our Gradle builds. Gradle build scans have been a key tool in this work. Build scans have helped optimize our build, and have helped detect regressions and other build trends for both CI, and local developers’, builds.

Because of the value we’ve seen in regularly reviewing these build scans, I wanted a way to make these scans easier to find, and to use, for everyone on our team.

Table Of Contents

Working With Gradle Build Scans?
- What are Gradle build scans?
- What does a build scan look like?
- How to generate a Gradle build scan?
- How to enable build scans for your Android project?
Surfacing Gradle Build Scan URLs as Pull Request Comments
- Adding a Single Job’s Gradle Build Scan URL as a Pull Request Comment
- Adding Build Scan URL Comments for Multiple Jobs
- Consolidating Multiple Job’s Build Scan URLs Into a Single Pull Request Comment
Storing Gradle Build Scan URLs In GitHub Actions Workflow Artifacts
- Writing Gradle Build Scan URLs to a File
- Storing Build Scan Files as Workflow Artifacts
- Storing Multiple Build Scan Files as a Single Workflow Artifact
Learn More
Wrapping Up

Thanks to Tony Robalik for pointing me in the direction of adding build scan urls as PR comments.

Working With Gradle Build Scans?

Before we dive in, let’s quickly review Gradle build scans; what are they, and how to enable them for your project?

Find the Code

If you want to check out these full examples, you can find them on GitHub.

Open In Github

What are Gradle build scans?

Gradle build scans provide a detailed overview of your Gradle build. These details include a myriad of information including tasks executed, build cache performance, test results, environment details, and much more.

What does a build scan look like?

Build scans are presented as interactive webpages hosted at either scans.gradle.com or within your own Gradle Enterprise instance.

Sample build scan

When scans are generated for a build, a link to the build scan will be included at the end of the console build output.

How to generate a Gradle build scan?

Generating a Gradle build scan for a single Gradle task execution is simple. We only need to add the –scan option to our task invocation.

./gradlew assembleDebug --scan

At the end of this execution, we see the following in our console window:

Publishing build scan...[https://gradle.com/s/](https://gradle.com/s/)<scan id here>

It’s this url that I wanted to surface to our team.

How to enable build scans for your Android project?

If your team is leveraging Gradle Enterprise, or you just want to generate build scans for all builds, you can integrate the Gradle Enterprise plugin into your project.

First, you’ll want to add the Gradle Enterprise plugin to your settings.gradle file.

plugins { id "com.gradle.enterprise" version "3.4.1" }

Next, you can configure build scan behavior in your settings.gradle file.

gradleEnterprise { buildScan { termsOfServiceUrl = "https://gradle.com/terms-of-service" termsOfServiceAgree = "yes" publishAlways() } }

With this setup in place, a build scan will be generated for each build of your project. We took the time to review this setup because we’ll make use of this later on.

Surfacing Gradle Build Scan URLs as Pull Request Comments

Now that we’re familiar with Gradle build scans, let’s return to the idea of surfacing these build scans in our GitHub Actions workflows.

We’ve now seen that urls for these build scans are logged at the end of our Gradle task execution.

If running on a continuous integration (CI) server, this often means having to scroll, and parse, through hundreds or even thousands of lines of build output to find this url. And that’s only useful if developers even know the url exists in the first place.

One way to help with this problem is to add these urls as comments on an open PR. In this section, we’re going to examine several variations of this idea. In each variant, we’re going to make use of the following GitHub Actions:

gradle-command-action – for executing Gradle tasks
add-pr-comment – for commenting on an open pull request

These actions will do most of the heavy lifting for us.

Adding a Single Job’s Gradle Build Scan URL as a Pull Request Comment

Code Sample Here

Let’s first imagine we have a GitHub Actions workflow running a single job. That job is configured to assemble our app.

We can use the gradle-command-action action to run our desired Gradle task.

- id: gradle uses: eskatos/gradle-command-action@v1 with: arguments: assembleDebug

This action will automatically parse our build output, find the build scan url, and add it as an output that can be accessed from other steps in the job.

steps.gradle.outputs.build-scan-url

Notice the structure of this output. steps.gradle is referencing the job build step with id gradle. Then, outputs.build-scan-url is referencing a specific output for that build step.

Now that we have access to the build scan url, we can use the add-pr-comment action in add the url as a pull request comment.

- name: Add Build Scan URLs to Pull Request uses: mshick/add-pr-comment@v1 with: repo-token: ${{ secrets.GITHUB\_TOKEN }} message: Buildscan url ${{ steps.gradle.outputs.build-scan-url }}

We could go one step further, and customize the PR comment a bit more.

In this example, we’ll add the workflow run id for this specific build scan so we can more closely tie the url to the workflow.

- name: Add Build Scan URLs to Pull Request uses: mshick/add-pr-comment@v1 with: repo-token: ${{ secrets.GITHUB\_TOKEN }} message: | \*\*Buildscan url for run [${{ github.run\_id }}](https://github.com/n8ebel/GitHubActionsAutomationSandbox/actions/runs/${{ github.run\_id }})\*\* ${{ steps.gradle.outputs.build-scan-url }}

Once this workflow is run, we’ll now get PR comments for each successful run of our workflow.

Example pull request comment including a Gradle build scan url

Adding Build Scan URL Comments for Multiple Jobs

Code Sample Here

In many cases, our workflows will have more than one job. If we’re running Gradle tasks for each job, this will result in multiple build scans.

So how can we surface each build scan for the workflow?

The easiest approach, is to extend our previous example and add PR comments for each job.

jobs: test\_job: name: Test runs-on: ubuntu-latest steps: ... - id: gradle uses: eskatos/gradle-command-action@v1 with: arguments: test - name: Add Build Scan URL to Pull Request uses: mshick/add-pr-comment@v1 with: repo-token: ${{ secrets.GITHUB\_TOKEN }} message: | \*\*Test job buildscan url for run [${{ github.run\_id }}](https://github.com/n8ebel/GitHubActionsAutomationSandbox/actions/runs/${{ github.run\_id }})\*\* ${{ steps.gradle.outputs.build-scan-url }} assemble: name: Assemble Debug runs-on: ubuntu-latest steps: ... - id: gradle uses: eskatos/gradle-command-action@v1 with: arguments: assembleDebug - name: Add Build Scan URL to Pull Request uses: mshick/add-pr-comment@v1 with: repo-token: ${{ secrets.GITHUB\_TOKEN }} message: | \*\*Assemble job buildscan url for run [${{ github.run\_id }}](https://github.com/n8ebel/GitHubActionsAutomationSandbox/actions/runs/${{ github.run\_id }})\*\* ${{ steps.gradle.outputs.build-scan-url }}

Here, we’ve added a comment for each of the jobs run. In this case, we’ve customized the comment text to indicate which job the build scan is associated with; Test or Assemble.

The resulting PR looks something like this:

Multiple build scan PR comments; one for each job in the workflow

This approach succeeds in surfacing the build scan urls. However, it also results in a lot of PR noise as each workflow run may result in multiple PR comments.

Consolidating Multiple Job’s Build Scan URLs Into a Single Pull Request Comment

Code Sample Here

To improve upon the previous example, we’ll consolidate all the build scan urls for a workflow into a single PR comment. That way, we’ll have a 1:1 mapping between a workflow run and build scan PR comments.

The general idea of this approach is this:

Expose each build scan url as a job output
Delay adding PR comments until all relevant jobs have completed
Add a new job that waits for relevant jobs, and adds a single PR comment including all the build scan urls

jobs: test: name: Test runs-on: ubuntu-latest outputs: buildScanUrl: ${{ steps.gradle.outputs.build-scan-url }} steps: ... - id: gradle uses: eskatos/gradle-command-action@v1 with: arguments: test assemble: name: Assemble Debug runs-on: ubuntu-latest outputs: buildScanUrl: ${{ steps.gradle.outputs.build-scan-url }} steps: ... - id: gradle uses: eskatos/gradle-command-action@v1 with: arguments: assembleDebug notification\_job: needs: [test, assemble] name: Add Build Scan URLs runs-on: ubuntu-latest steps: - uses: mshick/add-pr-comment@v1 with: repo-token: ${{ secrets.GITHUB\_TOKEN }} message: | \*\*Build scans for run: [${{ github.run\_id }}](https://github.com/premisedata/mobile-android/actions/runs/${{ github.run\_id }})\*\* \* Test Build Scan ${{ needs.test.outputs.buildScanUrl }} \* Assemble Build Scan ${{ needs.assemble.outputs.buildScanUrl }}

With all build scan urls consolidated into a single comment, our PR output might look something like this:

A single build scan PR comment for all jobs in the workflow

Now, we will see a single comment for each workflow run.

If any job fails for a workflow run, we can find the associated build scan url for that job, and start investigating the issue.

Storing Gradle Build Scan URLs In GitHub Actions Workflow Artifacts

Surfacing build scan urls as PR comments might be a useful improvement to your pull request workflows.

However, not all workflows have an associated pull request. You may have a nightly build. Or a scheduled release build. Or any number of other automated workflows that don’t have an associated pull request.

If something goes wrong for those builds, we still want to quickly find the associated build scan and start diagnosing the problem.

How then can we improve discoverability of build scans for non-pull-request workflows?

One solution is to write the build scan urls to a file stored as a build artifact.

Within our GitHub Actions workflows, we can store any number of different build artifacts. These could be things like testing or linting reports, or maybe your .apk file.

Storing artifacts is quite straightforward using the upload-artifact action.

- uses: actions/upload-artifact@v2 with: name: some-artifact path: path/to/artifact/some\_artifact.txt

This sample will store the file some_artifact.txt in a workflow artifact named some-artifact.

We will use this approach to save a set of files that contain build scan urls for workflows that don’t include a PR.

Writing Gradle Build Scan URLs to a File

To write our build scan URL to a file, we can make use of the buildScanPublished {} callback of the Gradle Enterprise plugin.

We see in this example that we’ve added the buildScanPublished block, which is called with the current PublishedBuildScan object, once the scan is published.

gradleEnterprise { buildScan { termsOfServiceUrl = "https://gradle.com/terms-of-service" termsOfServiceAgree = "yes" publishAlways() buildScanPublished { PublishedBuildScan scan -> file("buildscan.log") << "${new Date()} - ${scan.buildScanUri}\n" } } }

Once we have the scan, we can use it however we want.

In this case, we’re creating a new file named buildscan.log and writing the build scan uri to the file, along with the current timestamp.

Locally, as multiple build scans are generated, this file will continue to populate that list.

On CI, where builds are run in a clean environment, this file will include only the most recent build scan.

Storing Build Scan Files as Workflow Artifacts

Code Sample Here

Now that our builds will generate these build scan files, we need to store them as a workflow artifact so we can go back and view them for any arbitrary workflow.

For each job, we’ll add a build step that stores the buildscan.log file as a build artifact.

jobs: test\_job: name: Test runs-on: ubuntu-latest steps: ... - name: Save Build Scan Log uses: actions/upload-artifact@v2 with: name: buildscan-test path: 'buildscan.log' assemble\_job: name: Assemble runs-on: ubuntu-latest steps: ... - name: Save Build Scan Log uses: actions/upload-artifact@v2 with: name: buildscan-assemble path: 'buildscan.log'

To avoid overwriting the artifact, each job writes the buildscan.log file to a different artifact.

The result is something like this:

Multiple workflow artifacts storing build scan files

This allows us to find the build scan urls for a non-PR workflow without browsing the build logs.

Unfortuneately, this approach requires us to download multiple artifacts to view all of the workflow’s build scan urls.

So for one final improvement, we’ll look at how to consolidate all the buildscan.log files into a single file artifact.

Storing Multiple Build Scan Files as a Single Workflow Artifact

Code Sample Here

To store our build scan files in a single artifact, we need to be able to customize the file name of the buildscan.log files.

There’s probably many different ways to go about this, and I’ll cover just one here.

We’ll add an environment variable to the Gradle task build step. This variable will be used as a filename prefix for our buildscan.log file.

jobs: test\_job: name: Test runs-on: ubuntu-latest steps: ... - id: gradle uses: eskatos/gradle-command-action@v1 env: BUILDSCAN\_FILE\_PREFIX: test with: arguments: test ... assemble\_job: name: Assemble runs-on: ubuntu-latest steps: ... - id: gradle uses: eskatos/gradle-command-action@v1 env: BUILDSCAN\_FILE\_PREFIX: assemble-debug with: arguments: assembleDebug ...

Now, we can update our buildScanPublished{} configuration to use the prefix when naming the buildscan.log file.

buildScanPublished { PublishedBuildScan scan -> def scanNamePrefix = System.getenv("BUILDSCAN\_FILE\_PREFIX") ? "${System.getenv("BUILDSCAN\_FILE\_PREFIX")}-" : "" def filename = scanNamePrefix + "buildscan.log" file(filename) << "${new Date()} - ${scan.buildScanUri}\n" }

Now, each job’s buildscan.log file should have a unique name corresponding to the environment variable adding to the Gradle execution build step.

So our last step, is to update the workflow so that each job uploads the unique buildscan.log files to the same artifact.

jobs: test\_job: name: Test runs-on: ubuntu-latest steps: ... - id: gradle uses: eskatos/gradle-command-action@v1 env: BUILDSCAN\_FILE\_PREFIX: test with: arguments: test - name: Save Build Scan Log if: ${{ always() }} uses: actions/upload-artifact@v2 with: name: buildscans path: 'test-buildscan.log' assemble\_job: name: Assemble runs-on: ubuntu-latest steps: ... - id: gradle uses: eskatos/gradle-command-action@v1 env: BUILDSCAN\_FILE\_PREFIX: assemble-debug with: arguments: assembleDebug - name: Save Build Scan Log if: ${{ always() }} uses: actions/upload-artifact@v2 with: name: buildscans path: 'assemble-debug-buildscan.log'

Now, when our workflow is completed, we’ll have a single artifact called buildscans.

A single workflow artifact for all build scan files

Once downloaded, we have access to each buildscan.log file for the workflow.

The single workflow artifact will contain all the buildscan.log files once unzipped

Now, for any workflow that’s run, we can download the buildscans artifact and immediately find the build scan urls for that workflow.

Learn More

More GitHub Actions

Check Out The Docs

Wrapping Up

In this post, we’ve explored several different ways of making Gradle build scan urls easier to find within our GitHub Actions workflows.

The effectiveness of these approaches likely depends upon your team. If your team is using Gradle Enterprise and everyone is comfortable using that tool to find build scans, then surfacing them in workflows may not be that helpful.

However, if not everyone on your team is familiar with Gradle Enterprise, or you’re not using Gradle Enterprise, then surfacing the build scan urls in a more visible location may in fact help your team quite a bit.

The post Surfacing Gradle Build Scans Within GitHub Actions Workflows appeared first on goobar.

GitHub CLI – GitHub From The Command Line

Nate Ebel — Fri, 01 May 2020 16:30:01 +0000

GitHub recently announced GitHub CLI; a first-party command line tool for interfacing with GitHub from the command line.

With GitHub CLI, developers can check the status of GitHub issues and pull requests, search for a specific issue or PR, create/fork a repo, or create new issues and pull requests right from the command line.

In this post, we’ll walk through some common daily developer workflows. As we do, we’ll focus in on how we might manage our issues and pull requests using GitHub CLI.

What Is GitHub CLI?

So we’re all on the same page, we’ll start with a short overview of GitHub CLI. If you’re already familiar with it, jump ahead to the next section.

GitHub CLI is best described as “GitHub from the command line.”

Currently, GitHub CLI is at version v0.6.3 and consists of a focused set of functionality around three GitHub artifacts:

Issues
Pull Requests
Repositories

With GitHub CLI, developers can perform the following commands in relation to this different artifacts:

create
list
status
view
checkout (pull requests only)
clone (repo only)
fork (repo only)

As mentioned previously, in this post, we’re only going to focus on commands related to issues and pull requests.

How to Install GitHub CLI?

To install GitHub CLI on your development machine, check out the installation guide found on GitHub. You can also follow along with the tutorial on my YouTube channel.

GitHub CLI is available across MacOS, Windows, and various Linux distros, so you shouldn’t have a problem getting the tool up and running on your machine.

Using GitHub CLI To Manage GitHub Issues

If working with GitHub Issues is a regular part of your development flows then GitHub CLI likely has several helpful commands for you. Let’s walk through what a typical work day might look like and highlight some examples of using GitHub CLI to work with issues on GitHub.

List Issues With GitHub CLI

Let’s imagine we are just sitting down at our computer for the day, and we want to list out the open GitHub Issues for our project.

gh issue list

If we want to list out ALL of the issues we could use the “state” flag

gh issue list --state "all"gh issue list -s "all"

Now, maybe we’ve realized that is too many issues to sort through, so we decide we only want to list out your currently assigned issues.

gh issue list --assignee "n8ebel"

Or, you can use the short form

gh issue list -a "n8ebel"

Check Issue Status With GitHub CLI

Next, we want to check in on the status of a couple of the issues we created yesterday. Maybe we don’t remember their exact numbers, but since we created them, we can use the status command to list them at the terminal

gh issue status

This will give us a list of issues that are assigned to us, mentioning us, or that were opened by us.

After checking in on these issues, we still can’t find the issue we’re looking for, so we might want to check whether it was closed or not.

gh issue list --state "closed"gh issue list -s "closed"

That’s great! Our issue has been closed, so now we’re ready to find our next task. We could start looking for new tasks by listing out issuses filtered by different labels.

To list out all of our open bugs, we could filter by the “bug” label defined in our GitHub repo

gh issue list --label "bug"gh issue list -l "bug"

If you’re unsure of what labels are available for the open issues, you could first check by listing all the open issues again

gh issue list

Now, we can see there is also an enhancement label we can search for

gh issue list -l "enhancement"

View Issues With GitHub CLI

Once we’ve found an issue we want to fix, we might want to assign that issue to ourselves. Currently, we can’t do that directly from the command line, but we can quickly open the issue from the command line using the “view” command.

gh issue view "15"

This will open the issue in a web browser where you can then assign it to yourself.

After assigning any issues to yourself, you can double check your assignments from the command line by listing out open bugs assigned to you.

gh issue list -a "n8bel" -l "bug"

Create Issues With GitHub CLI

Now, we just have one last command to explore.

As we’re working on our assigned issues, imagine we find an additional bug we need to report.

We can use the gh issue create command to create a new GitHub Issue directly from the command line.

gh issue create

Using this command as is will kick off an interactive terminal workflow to select any available GitHub Issue template, and then fill in the title and issue description. You’ll finally then have the option to submit the issue, open it the browser, or cancel.

If you’d like to simplify things a bit, you can specify the issue with the command using additional flags

 gh issue create -t "Sample Issue Title" -b "Sample issue description"

If you still prefer to create your issue from the web, you could use the following command to open up a browser window and jump right into the issue creation workflow in your repo

gh issue create --web

Helpful GitHub CLI Aliases

So with these various command and flag variation, we have quite a few options for creating, listing, and viewing our GitHub Issues.

We can make these commands even easier to work with by creating some command line aliases for them.

For example, when listing out all bugs, instead of using this full command

gh issue list --label "bug"

We could create an alias like so

alias listbugs='gh issue list --label "bug"'

That way, when we want to list all bugs we can simply type:

listbugs

Another example would be to use the following alias to list all bugs assigned to you.

alias listmybugs='gh issue list -a "<your username>" -l "bug"'

With this alias in place, we can search for all bugs assigned to you like this:

listmybugs

Managing Pull Requests With GitHub CLI

Now, let’s explore the use of GitHub CLI for managing pull requests. Again, let’s walk through an imaginary workday and see where this tool make help us.

List Pull Requests

Once again, we sit down at our computer for the day, and we want to list the open pull requests for our project.

gh pr list

If we want to list out ALL of the pull requests, both open and closed, we could use the “state” flag

gh pr list --state "all"gh pr list -s "all"

Now, maybe we’ve realized that is too many PRs to sort through, so we decide we only want to list out your currently assigned issues.

gh pr list --assignee "n8ebel"

Or, you can use the short form

gh pr list -a "n8ebel"

Check Pull Request Status

Next, we want to check in on the status of a couple of the PRs we created yesterday. Maybe we don’t remember their exact numbers, but since we created them, we can use the status command to list them at the terminal

gh pr status

This will give us a list of PRs that are assigned to us, mentioning us, or that were opened by us.

After checking in on these PRs, we still can’t find the pull request we’re looking for, so we might want to check whether it was closed or not.

gh pr list --state "closed"gh pr list -s "closed"

That’s great! Our PR has been closed, so now we’re ready to find our next task. We could start looking for new tasks by listing out pull requests filtered by different labels.

To list out all of our open bug fix PRs, we could filter by the “bug” label defined in our GitHub repo

gh pr list --label "bug"gh pr list -l "bug"

If you’re unsure of what labels are available for the open issues, you could first check by listing all the open PRs again

gh pr list

Now, we can see there is also an enhancement label we can search for

gh pr list -l "enhancement"

View Pull Request

Once we’ve found a PR we want to review, we might want to assign that PR to ourself. Currently, we can’t do that directly from the command line, but we can quickly open the PR from the command line using the view command.

gh pr view "14"

This will open the pull request in a web browser where you can then assign it to yourself, review it, etc.

You can double check your assigned pull requests from the command line by listing out PRs assigned to you.

gh pr list -a "n8bel" -l "bug"

Create Pull Request

As we’re working on our assigned issue, at some point, we’re going to want to create a new pull request based on our local changes.

We can use the gh pr create command to create a new pull request directly from the command line.

gh pr create

Using this command as is will kick off an interactive terminal workflow to fill in the title and issue description. You’ll finally then have the option to submit the PR, open it the browser, or cancel.

If you’d like to simpify things a bit, you can specificy the PR info with the command using additional flags

gh pr create -t "Sample Issue Title" -b "Sample issue description"

If you still prefer to create your PR from the web, you could use the following command to open up a browser window and jump right into the PR creation workflow in your repo

gh pr create --web

At some point, we’re going to want to test a PR locally. This generaly requires looking up the PR, checking the branch it’s on, then checking it out locally.

Using GitHub CLI we can streamline this process using the pr checkout command

gh pr checkout "14"

This will checkout the branch associated with PR 14 so you’re ready to start testing.So with these various command and flag variation, we have quite a few options for creating, listing, and viewing our GitHub pull requests.

We can make these commands even easier to work with by creating some command line aliases for them.

For example, when listing out all PRs, instead of using this full command

gh pr list --label "bug"

We could create an alias like so

alias listprs='gh pr list --label "bug"'

That way, when we want to list all bug related PRs we can simply type

listprs

Another example would be to use the following alias to list all PRs assigned to you

alias listmyprs='gh pr list -a "<your username>"'

With this alias in place, we can search for all PRs assigned to you like so

listmyprs

More GitHub Resources

Check out the follow articles for more ways to leverage GitHub in your development workflows.

Subscribe for more software development posts, videos, and resources

The post GitHub CLI – GitHub From The Command Line appeared first on goobar.io.

Android Developer Career Paths

Nate Ebel — Tue, 14 Jan 2020 01:32:16 +0000

What Android developer career paths are available and viable in 2020?

The beginning of a new year offers a fresh start for us all. A chance to consider where we’ve been, and where we’re going. For me, this typically includes time to examine my career and to think about where I’d like that career to go.

I’m pretty sure I’m not alone in this either. Developers are constantly asking questions like “Should I learn framework X or framework Y?” and “Should I be a specialist or a generalist?”. These questions largely stem from a desire to smartly invest in our careers to set us up for long term success.

In this week’s issue, I wanted to explore this idea within the context of Android development. I want to throw out and examine a few general questions like “What languages should I learn?” and “How can I get my name out there?” and then unpack some specific questions to shed light on the different ways in which you might consider building a career as an Android developer, and really just as a developer in general.

You ready? Let’s dive in.

Common Android Development Career Path Questions?

Is Android development still a viable career option?

Of all the questions I see about Android development career paths, this is the most common; and I believe the answer is Yes. Do a quick search for “Android” jobs on LinkedIn, and you’re presented with over 268,000 results.

While Android has been around for over a decade, and the operating system does seem to have reached some level of maturity, the job market doesn’t appear to be slowing down. There are still many many companies out there looking for skill Android developers.

So, if you want to build apps that run on Android devices, I think you’ll be able to find a job for at least a few more years.

Is Native Android development still a viable career path?

This is probably a close second in terms of popular Android career path questions, and is honestly a lot more interesting to me. Companies are clearly still looking to build apps and tools that work for Android, but are they moving away from native Android development in favor of cross-platform solutions like Flutter or React Native?

Again, looking at job postings is, I think, a reasonable metric to gauge the market interest in these different skillsets.

Let’s compare the job posting results for a few different searches:

“flutter” – 2,583 results
“react native” – 13,927 results
“android java” – 33,487 results
“android kotlin” – 9,542 results
“android c++” – 10,159 results

By these results, we can see that building Android apps natively with Java, Kotlin, or C++ seems to still be what most employers are looking for. So I think it’s safe to say that native Android development, and probably native iOS development are both perfectly viable career paths for the coming years.

Conversely, there’s also clearly demand for cross-platform developers as well, and we’ll explore that more as we continue on.

What languages should you learn?

What programming languages should you learn to build a career in Android development? If going the native Android development route, then you have three options: Java, Kotlin, and C++.

If doing typical Android app development, you’ll likely be considering between Java and Kotlin, and with Google’s “Kotlin First” approach to modern Android, I think Kotlin is a good investment of your time and learning effort.

If you’re going to be doing lower level SDK work or building high-performance games, you may need to work with C++

If you’re more interested in building for multiple platforms at the same time using frameworks like Flutter or React Native, your options are a bit more clear. When building with Flutter, you’ll use Dart, and when building with React Native you’ll most likely use Javascript.

Now, are these the only languages you need to know? Maybe to get started, yes. However, having familiarity with multiple languages can improve the way you think about code and how you write code. As you become familiar with new language features and paradigms, you’ll see how you can apply those to other languages and challenges as well.

Being comfortable with at least one scripting language is a great idea as well as it’ll enable you to automate development workflows when the need arises. Options such as Python, or Unix Shell Scripts could be a great choice here.

How can you get your first job?

Breaking into an industry with your first job can be a daunting task. The process is often filled with stress, uncertainty, and lots of waiting to hear back from recruiters. A few things I found helpful when searching for my first job include:

Setting realistic expectations about where I’m going to work. Not everyone can, or should, work at the big companies like Google, Amazon, Facebook, etc. There are many many wonderful places to work out there, and exploring more options improves your chances of finding that first job.
Demonstrating job competencies. A big factor in me landing my first Android development job was the fact that I had published an app to the app store and could explain to interviewers how I had built it, what the app publishing process was like, and what the major challenges were in writing production software. Having some form of sample project, portfolio, or published work is a great way for recruiters and interviewers to see what you can do. This will hopefully then improve your chances of getting job interviews, and of doing better in those interviews.
Reach out to people you know in the industry, and ask if they have entry-level or internship opportunities available. Direct referrals can often get your resume placed at the top of the list which is a huge advantage in getting called for an interview.
Stay positive. Like I mentioned before, finding a job is stressful and challenging. It can make our imposter syndrome flare up in a major way, and make us question whether or not we have the required skills to do the job we want. Remember that not receiving a job offer does not mean you can’t do the job. There are many factors involved, and sometimes all we can do is stay positive and move on to the next opportunity.

How can you get your name out there?

Once you’ve found your first job, you might start looking for ways to add to your career beyond your job. For this, there are a number of ways you might look to become more involved in the developer community including:

Open source contributions
Event organizing
Speaking
Blogging
Video Tutorials
Mentorship
Social Media

Any of these are great ways to add your experience and ideas to the public discussions around topics your interested in. The internet makes it easier than ever to connect with people all over the world and to carve out your own niche of interests, ideas, projects, and ways of giving back.

Career Options for Developers

Now that we’ve discussed some of these higher-level questions, I want to get more specific and focus in on some more concrete comparisons of different career paths available to us as software developers.

Developer vs Educator

Do you want to get paid to write code, or would you prefer to get paid to teach others how to write code?

I included this here because it’s becoming more and more viable to make money online by teaching others how to write code and to become software developers. Whether it’s at established edTech companies like Pluralsight and Udacity or with your own courses, it’s possible to make a living by teaching others.

Your career path as a developer doesn’t have to include getting a job to build someone else’s app. If you have a passion for teaching, mentorship, and helping others, then you might consider either a full-time, or at least a part-time, job in some form of developer education.

Freelance vs Company

Do you have to go work for someone else to make money as a developer? The simple answer is, No. If you’re someone that would prefer to work alone, or to work on a variety or projects, or to have greater flexibility in when/how you work, then freelancing might be the way to go.

As a freelancer, you’re likely to find greater flexibility in your work. This may also manifest as uncertainty. You may not always know where your next project and paycheck are coming from. You may get bogged down in the more administrative side of running your own freelancing business.

You may also find that the freedom provided by freelancing is a great fit. You may really enjoy the business aspect of freelancing, and in particular, you might find freelancing enables you greater freedom to pursue other interests such as content creation or travel.

FAANG vs Startup

If you prefer to work at a company, what type of company do you want to work for? Do you want to be in the fast-paced, VC-backed startup world? Do you want to work at the major tech giants like Google, Microsoft, and Amazon? Do you want to work for a less exciting, but very stable company?

Not all companies are created equally. Similarly, different business groups, organizations, and teams may operate very differently even within the same company.

When deciding what type of company to work for there are many questions you can ask yourself and use to filter out the options:

Do you want to work at a well known company?
Do you prefer to work on a small team or a large team?
Would you rather get paid more, or work from home?
Do you prefer to know everyone you work with, or would you rather work in a large organization?
What’s more important, fun perks like snacks and ping pong, or reasonable working hours?
How much project ownership will you have?
Would you prefer to go deep or wide on a project?

I’m sure you can think of many questions of your own. What do you value in your work? What tradeoffs are you willing to make. What have you liked about past companies, and what have you disliked? Taking time to consider these things will help guide your future decisions.

IC vs Manager

When you think about your career, do you see yourself writing code forever? Do you see yourself managing others? Do you want a mix of both? These are great questions to consider as many companies have different career paths to help fit what you’re looking for. The most common split is between an Individual Contributor (IC) role and a Manager role.

The exact requirements and responsibilities of each path will differ based on company, but in general, the IC path is going to be more focused on your writing code, while the management path will be more focused on making other developers more successful.

Both have their pros and cons, and both are completely viable.

Whoa! In this short article we’ve already touched on a lot of questions, comparisons, and potential career paths.

If you’re feeling a little overwhelmed that’s perfectly okay. I think we all become a little overwhelmed, lost, or even discouraged at times when considering our careers. There’s a lot to navigate in this game of life. The great thing is, we have time and resources available to us to learn new skills, pivot in a new direction, and build a career that we love. The trick is to be intentional about it. That doesn’t mean you have to plan out your whole career, that would be impossible given the rate of technological change, but you should regularly take time to think about what’s important to you, what you enjoy doing, and to survey the landscape of the industry around you and look for those areas where your passions, values, and financial needs align.

What in the world of Android development are you interested in right now? Join in the conversation in the comments below.

The post Android Developer Career Paths appeared first on goobar.io.

Android Development Podcasts — 7 Options to Choose From

Nate Ebel — Tue, 09 Jul 2019 01:48:45 +0000

Android development podcasts to help you stay up to date

Originally published at https://goobar.io on July 9, 2019.

I’ve had a number of questions lately about which podcasts I’ve been listening to, and where to find them, so I thought I’d share a small list of relevant Android development podcasts for you to check out.

tl;dr — 7 Android Development Podcasts

Fragmented

Fragmented Podcast

This has been my go-to Android development podcast for a long time. Donn Felker and Kaushik Gopal do a terrific job of putting out consistently great episodes on all manner of Android-related topics. They generally sit down with other Android developers to discuss tools, libraries, patterns, etc.; all relevant to the world of Android development.

Android Developers Backstage

Android Developers Backstage Podcast

This podcast comes straight out of the Googlers’ mouths as it’s hosted by Chet Haase and Tor Norbye from the Android teams at Google.

I enjoy this podcast because it generally offers deep dives into Android topics usually including guests that actually work on the tools/libraries. Because of this, I think it offers a level of insight that’s difficult to replicate elsewhere.

Talking Kotlin

Talking Kotlin Podcast

Talking Kotlin with Hadi Hariri is a wonderful resource if you’re wanting to learn more about Kotlin specifically. It covers everything from the world of Kotlin include Kotlin on Android, Kotlin Multiplatform, KotlinConf, etc.

The Context

The Context Podcast

The Context is another community-driven Android development podcast hosted by the trio of Artem Zinnatullin, Hannes Dorfmann, and Artur Dryomov.

This is another great option if you are wanting to hear what other developers are working on and thinking about in the world of Android.

Bonus Android Development Podcasts

I also want to include a few other podcasts that might be worth checking out.

Android Leaks Podcast — a French Android development podcast that I recently came across. I don’t speak French, so I don’t really know a whole lot about it but it’s out there.

Andro idiots Podcast — This is a new one which someone pointed out to me recently. It’s pretty new, but has a nice backlog of episodes going and covers a variety of Android topics.

droidkast.LIVE — Antonio Levia has a small backlog of episodes consisting of interviews with other Android developers which culminate in a smaller learning presentation at the end.

Where to Listen?

For those using Android devices, I highly recommend Pocket Casts as a podcast app. I’ve been using it for years to listen to Android development podcasts (really all of my podcasts) and have been extremely happy with it.

As an alternative, I’ve used Google Play Music for podcasts in the past which does a pretty good job as well.

I haven’t been overly impressed so far with the Google Podcasts app, but it’s out there as well and might be getting more attention from Google right now than Google Play Music’s podcast support.

Other Useful Resources

I love to meet/talk/discuss and help where I can. If you want to chat or ask a question you can follow me on Twitter, YouTube, Instagram and Facebook.

Check Out My YouTube Channel

Kotlin vs Flutter? Are you comparing them fairly?

Nate Ebel — Fri, 14 Jun 2019 02:59:48 +0000

Originally published at https://goobar.io on June 14, 2019.

Lately, I’ve seen, and been asked, variations of the following question: “Kotlin vs Flutter?”

It’s happened enough times that I thought I’d try and capture some of my thoughts regarding this question.

So here it goes…

Kotlin vs Flutter: Which should you learn?

It depends

“Comparing Kotlin toFlutter is comparing apples to oranges”

But before going too much further into the “It Depends” rabbit hole, I think it’s worth examining whether or not we’re even asking the right question.

Comparing Kotlin vs Flutter is comparing apples to oranges in many respects.

Flutter is an entire cross platform UI toolkit.

Because the differences between Kotlin vs Flutter are so large, the scope of the original question is quite larger; making it difficult to answer without exploring a variety of other questions first.

Choosing between Kotlin and Flutter is going to come down to a number of more specific questions.

Why do you want to learn either Kotlin or Flutter?

One of the first questions to ask yourself might be “why do you want to learn Kotlin or Flutter to begin with?”

Do you want to learn mobile development?
Do you want to get a job as a mobile developer?
Are you wanting to develop your own product as a solo dev or small team?

Do you want to learn mobile development?

If your primary goal is to simply dabble in mobile development, or to build a small hobby project, then the choice between Kotlin and Flutter likely doesn’t matter too much.

However, it’s important to remember that you’re not just picking between Flutter and Kotlin. You’re picking between:

Flutter/Dart
iOS/Swift/Objective-C
Android/Kotlin/Java

Flutter is an entire toolkit for developing applications. This includes the usage of Dart as a programming language, a new set of UI components, a unique set of programming patterns and best practices, and its own debugging tools and workflows.

To compare Flutter fairly to other platform toolkits, you need to take into account the entire ecosystem that you’re investing into.

Kotlin vs Flutter to get a job as a mobile developer?

If your primary goal is to get a job as a mobile developer, then it’s likely a good idea to take into account the demand for the different skill sets.

A quick LinkedIn search for jobs related to Kotlin and Flutter turn up the following results (in the USA)

Flutter: 315 results
Kotlin: 3,342 results

Flutter is still a new technology, and it represents a much larger change to the mobile development process than does the introduction of Kotlin to an Android project. Because of these things, there are fewer jobs available that mention Flutter.

This difference in job availability could mean 2 things

It could be harder to find a Flutter job in your area
It could be easier to get your foot in the door somewhere if you know Flutter well

These are somewhat contradictory, and what’s most applicable to you likely depends on your current life situation, how quickly you need to find a job, and how willing you are to relocate for that job.

On the other hand, there is still a lot of demand for native Android developers, and many of those jobs are looking for people that know, or are willing to learn, Kotlin. This greater number of jobs means more options for you to choose from, but also possibly greater competition for those jobs.

Kotlin vs Flutter to develop your own product as a solo dev or small team?

If you are deciding between Kotlin and Flutter because you want to build your own app that will turn into a business, then it’s a good idea to step back and consider the full picture.

If you want to build a product, then you very likely are going to want to build for iOS and Android.

You can do this with Flutter, but you can’t do this with Kotlin alone.

If you want to use Kotlin for cross-platform development, you’ll need to have familiarity with both the native iOS and Android frameworks. You could build a Kotlin Multiplatform project and share code via Kotlin, or you could build two completely separate apps. Either way, you’re going to need to understand native development for both iOS and Android.

So, if you’re wanting to build something for multiple platforms at the same time, Flutter might be the way to go. We’ll look at this in more detail in the next section.

What do you want to build?

Likely related to why you want to learn Kotlin or Flutter is what do you want to build?

Do you want to build an awesome Android app?
Do you want to build an awesome iOS app?
Do you want to build a mobile app for iOS and Android at the same time?
Do you want to build for platforms beyond mobile?
Will you want to write your own backend services?

Do you want to build an awesome Android app?

If your main goal is to build a standalone Android app with the latest and greatest features Android has to offer, choose native Android.

That doesn’t have to mean native Android + Kotlin. Android + Java is perfectly fine for building quality apps. However, I do believe learning Kotlin will make the development experience more enjoyable.

Do you want to build an awesome iOS app?

Similarly, if you want to build a standalone iOS app with all the latest features, then I would suggest going for native iOS development with Swift.

Do you want to build for both iOS and Android at the same time?

If you want to build for both mobile platforms at the same time the question is a little more interesting. You have 3 main options involving Kotlin and Flutter.

Build both a native Android app and a native iOS app
Build two native apps, but use Kotlin Multiplatform to share code
Build a Flutter app

Building 2 separate native apps

This option is going to require you, or your team, to build both apps from scratch without any shared code. If you’re a solo dev, it’s likely going to be the slowest option unless you’re already well versed in both iOS and Android development.

It’s also probably the safest option. Native development for both platforms is very mature. It’s unlikely that Apple or Google will abandon either platform out of the blue, and you’ll have access to new features as soon as possible.

Build 2 separate native apps with Kotlin Multiplatform

If you want to build your apps natively, but want to share as much code as possible you can chose to learn Kotlin and build a Kotlin Multiplatform project.

This is probably not the best option for less experienced developers. The Kotlin Multiplatform ecosystem is pretty new, and you might find yourself with fewer existing tools/libraries to choose from.

Build a Flutter app

Building a Flutter app is likely the quickest way to get an app running on both iOS and Android at the same time; especially if you are a solo dev.

Development times are quite fast with Flutter, thanks in large part to it’s great hot reload functionality. You’re also able to leverage a single codebase for both platforms. As long as you aren’t needing really low level access to system apis, or treating the look/feel of each platform too differently, you shouldn’t need to write a lot of custom code for platform-specific needs.

If you’re looking to quickly build an app for both platforms, especially a one-and-done app, Flutter is probably the way to go.

Do you want to build for platforms beyond mobile?

The Flutter team continues to invest in making Flutter viable to both desktop and web development. While this functionality is still being developed, the possibility is there to use your single Flutter codebase for additional platforms.

You could consider a Kotlin Multiplatform project to develop beyond mobile as well, but the value proposition is different. With KMP, you would be sharing code, but still having to write native platform code to create your UI and leverage the shared code. As you add more target platforms, this is going to increase the work/skill sets needed.

Will you want to write your own backend services?

An edge case to consider is whether you might want to write your own backend services for your projects.

Kotlin can be used to write backend code, and Ktor can make this quite easy. So if you’re going to be developing backend services in addition to some kind of mobile app, Kotlin could be a good investment since you can reuse the skill across multiple domains.

Do you already have development experience?

Another thing to consider is your current level of development experience as it applies to your primary motivation for learning either Kotlin or Flutter.

Are you already an Android developer?
Are you already an iOS dev?
Are you new to programming?

Already an Android developer?

If you’re already comfortable with native Android development, then learning Kotlin is going to be a much faster than learning Flutter. Knowing Kotlin will simply add to your existing knowledge and skill set and perhaps make you more efficient when building native Android apps.

Learning Kotlin could also allow you to write backend services in another language besides Java, and would enable you to use Ktor to simplify the process.

Learning Flutter will require learning a new language (Dart) as well as a new development ecosystem. The time required is likely going to be several times greater than to learn Kotlin.

If you’re not wanting to start leveraging the cross-platform benefits of Flutter, then it doesn’t make too much sense to learn Flutter only for Android.

Already an iOS developer?

If you’re an iOS developer looking to learn either Flutter or Kotlin the situation is a bit different.

If you’re wanting to continue building native iOS apps, then neither Kotlin or Flutter are of much benefit. Kotlin would at least give you another language with which to write backend code.

If you are an iOS dev that wants to start writing cross platform applications, then you could go the route of a Kotlin Multiplatform project or a Flutter project.

Like we discussed previously, Flutter is going to be its own isolated development experience for both mobile platforms while a KMP project is going to require knowledge of both Kotlin and the native development stacks.

So in this case, either way you’re learning a new language (Dart or Kotlin) and a new framework (Flutter or Android).

Are you new to programming?

If you’re completely new to programming in general, then again you likely need to take a step back and consider comparing Flutter to native Android development.

Learning Kotlin on its own isn’t all that useful if you aren’t applying it to something like mobile or backend development.

So if you’ll want to develop mobile apps, then you’ll want to compare choosing between Flutter and native Android development.

How do you learn?

How do you learn best? This could be an important question before diving into a new learning path for Kotlin or Flutter.

Looking for in-depth guided courses?
Want to learn as part of your university curriculum?
Will you look to seasoned vets for advice and best practices?
Do you regularly turn to blog posts?
Do you prefer to learn by doing?

Looking for in-depth guided courses?

If you prefer to learn with detailed, guided courses, you’re likely going to have more to choose from in the native development world.

Because Flutter is a new technology, there aren’t as many resources out here yet.

To be fair, there aren’t all that many Kotlin-specific courses out there either, but Kotlin is a much smaller concept to learn. If learning Kotlin, it’s likely within the context of Android development for which there are a plethora of courses available.

Want to learn as part of your university curriculum?

I’ve talked to a few people that were interested in learning native Android development at university. If you have this opportunity, I say go for it. When coming out of school, you’re likely looking for employment. Having a marketable skill like Android development is great for that, and you shouldn’t worry about whether native is outdated and you should have learned Flutter.

Get a job first, then upskill as necessary while someone is paying you.

Will you look to seasoned vets for advice and best practices?

The developer communities around Android, Kotlin, iOS, Flutter are a great resource for learning, mentorship, problem solving, etc.

When looking for people to follow, or turn to for guidance, you’re likely going to have an easier time in the native Android/iOS worlds. Again, this is because Flutter is a newer technology and there just aren’t as many people working with it yet.

That’s not to say you’re without options however. There are many great devs out there working in Flutter, and the devrel team at Google is going a lot of work to recognize those developers through the GDE program.

In either case, here are some lists of devs to follow for Kotlin and Flutter info:

Do you regularly turn to blog posts?

Blog posts are a great resource when learning any new technology. When thinking of Kotlin vs Flutter, there are a couple of things to keep in mind.

Flutter is relatively new, so there are fewer resources out there. Additionally, as it has evolved quickly, some of those resources might be out of date.

Kotlin likely has more resources available, but also is evolving quickly and posts regarding advanced topics might be out of date after only a few months.

If looking into Kotlin for its use in Android and/or iOS development you’ll have years worth of posts to sift through. Many of these will still be relevant, but others wont. So again, you’re left with having to determine how accurate and up-to-date these resources are when you find them.

Thankfully, I think whichever you choose, Kotlin or Flutter, the developer communities and devrel teams will continue to help us out by writing blog posts, building codelabs, and recording video tutorials.

Do you prefer to learn by doing?

If you are someone that prefers to learn by jumping in and building something, then you’re in luck. Both Kotlin and Flutter are very easy to try.

Have you considered the risks of choosing Kotlin vs Flutter?

When adopting any new technology, there are risks involved. It might be worth considering some of theses risks before choosing between Kotlin and Flutter.

What’s the organizational risk of adopting Kotlin or Flutter?
Is there any risk associated with your personal choice between Kotlin or Flutter?
Is there any risk of losing long-term support?

If considering adopting Kotlin or Flutter in your organization, it’s worth stopping to consider the associated risks.

Kotlin has been stable, and fully supported for Android for 2 years now. It can be integrated 1 file at a time and will work well with existing code. It’s pretty low risk and low impact to add it to your existing projects.

Flutter is a much larger risk because it’s a departure from the native development experience. It doesn’t have a long track record of successful projects. There are fewer developers familiar with the technology making it harder to recruit and requiring your existing team to learn a new framework/tools/language. Flutter works best in greenfield applications which makes it harder to adopt incrementally.

These are all non-trivial concerns to think about.

Additionally, Google has a track record of killing off projects with little notice, so there might be some small concern that Google gives up on either Flutter or Kotlin.

Realistically, I think Google will continue to support both of these for the next 2+ years at least, so if you’re considering Kotlin vs Flutter today I wouldn’t be too worried about either of them going away.

So, Should you learn Kotlin or Flutter?

At this point, hopefully this post has given you some food for thought that will help guide your decision of whether to learn Kotlin or Flutter.

Ultimately, it depends, but I can try and give the oversimplified, tldr; version of my opinions.

If looking for a job as a mobile developer right now:

If you want to build your own cross-platform app from scratch: If your team wants to build a new app for both mobile platforms:

consider Flutter, native, Kotlin Multiplatform
all three options are potentially viable. this one really depends on your team size, structure, and the project itself.

If you, or your team, wants to share some important business logic across platforms

A big thanks to Divya Jain, Shane Blackburn, and Aashish Bansal for offering to review and give feedback 👍

I love to meet/talk/discuss and help where I can. If you want to chat or ask a question you can follow me on Twitter, YouTube, Instagram and Facebook.

Check Out My YouTube Channel

Code Folding in Android Studio

Nate Ebel — Wed, 26 Sep 2018 19:57:46 +0000

Check Out My YouTube Channel

“Focus On What Matters”

When working in our IDE, at times it’s easy to become overwhelmed with all the code on the screen. To better focus on what’s most important, it can be useful to hide non-essential blocks of code from our editor window.

The Code Folding shortcuts in Android Studio help us do just that.

The allow us to fold Code Blocks & Region Blocks so we can have more fine grained control over what code we are looking at in any given moment.

Shortcuts

code folding shortcuts

The expand & collapse shortcuts allow us to quickly show or hide code blocks or code regions.

We can expand all or collapse all by adding shift to the shortcuts above.

Code Blocks

We can take an expanded block of code like this anonymous inner class

expanded code block

and collapse it within the IDE, using the collapse shortcut, so it visually looks like this.

collapsed code block

We lose the immediate view of the code, but if that code is not relevant to us in this moment, then it can actually help reduce the visual noise in our IDE.

To collapse a specific block of code, place your cursor within the block and execute the shortcut.

If you run the shortcut multiple times, the IDE may continue to collapse blocks of code in increasing scope until everything in the current file is collapse. The same logic applies when expanding code as well.

Region Blocks

We can define custom region blocks using comments. These regions can be helpful for documenting & group related sections of code; such as the implementation of an interface.

expanded region block

Using the collapse command, we can collapse the entire region so only the region label is visible within our editor.

collapsed region block

For more on code folding, check out my video on YouTube

I love to talk Android, tech, or geekery, so if you have feedback or want to chat you can follow me on Twitter, here on dev.to, or check out my blog

Check Out My YouTube Channel