Initializing app start is an unexpectedly complex problem. I have already briefly raised the subject here:
I will address how the new App Startup library from Google’s Jetpack handles (or doesn’t handle 😉) the problem in a different blog post. This one simply describes how to bind App Startup with Hilt.
All the sample code is available here:
For the most up to date version follow the official guidelines for setting up Hilt dependencies.
Right now (when the
2.28-alpha is the newest version available) the setup is as follows:
2. In your
I started writing this as a simple answer to Facilitating dependency initialization with Dagger multibindings, but it grew very quickly so I eventually decided that I should release it as a standalone post. So that more people are able to read it.
Don’t treat this as an “attack” against the author of the original post. This is an explanation of a common misconception & misuse that many people are unaware of.
To give you a very condensed version of the mentioned post:
Initializerclasses inside your Dagger setup.
2. And to initialize all of them…
UI tests are so important that any Android Developer should feel comfortable with setting up the test environment.
Unfortunately, this usually is not the case (and probably an important factor on why people are not writing UI tests). Preparing everything in such a way that it’s easy to write new tests and that tests give repeatable results, can be very overwhelming.
One important thing to figure out is this (from Android Developer docs):
To give you a rough idea of what you should be looking for, think of when need to list a whole bunch of arguments for a function.
Why is it that everyone is telling you, that you shouldn’t be using Reflection, yet you see it everywhere?
A numerous of well known, reliable, and loved open source libraries are based on Java Reflection.
When is using Java Reflection good and smart? And when is it bad and dangerous? What are the rules that a developer should be following not to have a shit storm above his head for utilising Reflection?
This is the most important rule of them all. If you’re using a piece of code from another developer, you’re getting…
Most annotation processors that generate some code have two components:
Annotations is a lightweight component that can (but does not have to) be packed within your application.
Compiler is a “heavier” component that should never be included in your app. Its goal is to find usages of Annotations within your code and do some work based on that. It helps with building your code into the executable app (it helps with the compilation process).
If you’re designing the sort of annotation processor that generates some code, you have to quickly realise one important thing:
Annotation processors cannot modify exisiting code.
Easy! That sounds like AT MOST hour worth of work!
That’s how it all started.
Fast-forward half of the night later, I am figuring out how to upload a library snapshot for every single of my 22 commits in the repository.
Okay, let’s back up a little.
Ever heard of ExoPlayer? That’s a pretty awesome player library from Google. Yes, the one that has a demo app, which used to be able to play Youtube videos in background (anyone paying for YouTube Red for that feature 😉?).
When Google developers released ExoPlayer 2.x.x they thought about releasing ExoPlayer 2 with…
This unusual combo of two Java 8 features is a great way to clean some of your Android code. The great thing about it, is that you can use this trick for all Android SDKs. There are no limitations.
It works for simple
abstract classes with a single
abstract method that you would use to create Anonymous classes in your code.
See how you could apply that to
DebouncingOnClickListener from Jake Wharton’s Butterknife.
The way you would use it in your code (even using Java 8), would be:
If some part of your layout xml is not clear right off the bat (e.g. the existence of seemingly unnecessary View or weird parameter), mark your intentions with a comment (in this xml).
You can treat this tip as a paraphrase of Explanation of Intent section (chapter: Comments) from the:
With the specifics of Android SDK this tip gets a special meaning if you consider layout xmls.
The things you can set in the layout xml can sometimes be just not enough for your case. E.g. you might need to introduce a seemingly unnecessary
View to make your