Simple Display of Open Source License Info in Android Apps?

Open Source License Info for Android

This past week I came across a page in the Google developer documentation for a new plugin and related library in Google Play services for Including Open Source Notices.

Displaying open source notices is certainly important, but it also tends to be a tedious and sometimes painful process so I was intrigued by the promise of a simplified workflow that could nearly automate the process.

I decided to give it a quick try.  Quick is an appropriate term here, because It really did take only a few minutes to get a working example up and running to quickly evaluate the new tools.

I’ll explain how I made my evaluation below, but the tl;dr is … this is probably not the tool you are looking for.  Unless all the libraries you’re using have the correct license info included in the POM (they probably all don’t), you’re most likely going to want to find a different solution.

This is not the tool you’re looking for…probably.

Continue reading

Bug Busting: ‘cannot generate view binders’

Android

I’m a big fan of Databinding for Android, and have been using it with much success for a while now.

Every once in a while though, I end up with a baffling error that grinds productivity to a halt.  The most recent error looked like this:

cannot generate view binders java.lang.StackOverflowError

Continue reading

Further simplification of Android app distribution with Beta by Crashlytics

A while back, I wrote about simplifying our app distribution process using Beta by Crashlytics.

 

Simplifying App Distribution with Beta by Crashlytics 

Since that time, I had been thinking (and receiving questions) about how to handle multiple buildTypes and productFlavors more gracefully. When I originally described our approach we only needed to worry about a single build target. After a while, we added a second productFlavor and the fastest solution was to simply copy our custom gradle tasks and make new versions for the new build target.

That solution got us up and running quickly, but it always bothered me that we now had a sizable chunk of duplicate code in our gradle file. When it came time to add yet another product flavor, the time had come to think about a better solution

Thankfully, it was pretty easy to leverage the power of gradle to create custom distribution tasks for each buildType/productFlavor combination without having to manually duplicate any code.

 

Continue reading

Code Health: Styles and Conventions

As a software developer we spend much, if not all, of our day in front of our computer screens reading code. Notice I said “reading” code and not “writing” code. This certainly varies from day to day, but in general, I spend much more time reading through our codebase than I do actually making changes.

For me, this stems from a saying my dad used to share with me “Measure twice, and cut once”. To understand how a potential change is going to fit into the existing code base, I have to understand what the existing code does and how it works.

If it’s easier to understand my code, it’s easier to find errors. It’s also then easier, and faster, to fix those errors. Less time fixing bugs leaves more time for adding features to my project and therefore value to the end user. The point I’m trying to make is that having clean, consistent, easy-to-read code can have a significant positive impact on a project.

Continue reading