As an Android developer, it’s useful to know about the latest tools, tips, and trends. Here are a number of my favorites ways of staying up to date in the world of androiddev. Weekly Newsletter Android Weekly Newsletter This is probably my single favorite way to stay up to date because it…
Introduction “Sealed classes are used for representing restricted class hierarchies…” As such, Sealed Classes are useful when modeling state’s within various app workflows We’ve leveraged this to simplify a few different use cases in our app, and wanted to share what we’ve found about modeling ViewModel states using sealed classes. Our Problem We commonly…
Originally posted on Medium I’ve spent some time recently incorporating React Native components into our existing app This comes with the extra requirement of release builds requiring the creation of the bundle file I would have expected this to be a straightforward, well documented workflow, but was unfortunately a bit disappointed. It took a bit…
Last week I setup a project to use Crashlytics for Android as our crash reporting tool.
Use Crashlytics (NEW) and Perf Monitoring to increase app retention and keep users happy!#FirebaseSummit live → https://t.co/eSmn1vZtaf pic.twitter.com/1tZAM4jzZN
This week, at the Firebase Dev Summit, support was announced for Crashlytics issue reporting from within your existing Firebase console.
Since I prefer to use as few different service consoles as possible, I wanted to migrate over to the new Firebase Crashlytics reporting. It was a pretty straightforward process with a couple small gotchas, so I thought I would share what I found.
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.
A while back, I wrote about simplifying our app distribution process using 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.
I wrote a follow up to this post in which I describe a more straightforward version the approach detailed here.