Last year, there was a hot topic on Twitter about how relevant RxJava was with modern Android development, which garnered a pretty interesting debate with some convincing arguments from both sides.
The claim was that given the popularity of modern frameworks, RxJava is too bloated and should be removed. The debate was even given a catchy title, which prompted a panel discussion at Droidcon Berlin last year, with Hasan, Ivan, x, and myself.
The purpose of this article isn’t to go into detail on how to migrate from one framework to the other, or whether one is better than the other, but rather to emphasise the situations that might require one over the other, and where the strengths of utilisation differ. …
Much of our responsibility as software engineers is based upon problem solving, we are required to use the our knowledge of available tools, and our experience, to find the most appropriate solution to a given problem.
That’s what I’d like to focus on here, on finding the most appropriate solution.
But quite often, we can feel like the solution might not be “clever” enough, and this urge to show off a little, or even just to flex our creative muscles, causes us to miscalculate the problem, or even worse, write solutions to problems we didn’t even have. …
Android Data Binding is a support library that allows us to bind UI components to data sources declaratively rather than programmatically, it’s potentially really powerful and complex, but used effectively it can really cut down on presentation boilerplate.
We started off with Data Binding beta in 2015 when Google announced it after Google IO as a support library that can be used right back down to Android 2.1 which is API version 7, to write declarative layouts and minimise the glue code required to use your application logic in layouts.
With the Android Gradle Plugin 3.1, it includes the new Data Binding Compiler v2, this includes incremental class generation, so this means that it will speed up your build times a little bit, and it will include precompilation of classes, this means that your Data Binding classes will actually be available prior to your first build. If you’ve used any annotation processors that generate classes that you rely on at runtime you’ll know that this is an absolute pain, so it’s nice to have these even if your build buggers up! …
I’ve been pretty quiet recently, and that is in half due to my own business, but recently my uncle had died, normally I would try not to make this type of thing public, but my uncle was an extraordinary man.
Jamie, was an extraordinary man, because he always shared an extraordinary passion, curiosity, and genuine awesomeness, and he shared it with everybody.
I remember when he took me to the nearby dirt hill when he liked to motorcycle, I remember when he used to help me with my computer problems (no matter the hour!), …
For the last few months I’ve been making my way through the Udacity VR Nanodegree coursework, hoping to complete it by the end of the year.
One of the projects for the course is to design, test, complete and most importantly document the process to completion, with an emphasis on the journey from day one to submission.
Overall the concept of the game was relatively simple, following the mechanics you can expect from a Simon Says game, though there were a number of unique considerations that you would have to make.
Designing for VR is much different than other environments, given you must cater for user movement, visibility, intuitive behaviour and make sure things react how a user would expect them to. …
Early on in my career, you could say I had what you might like to call a mentor, we were friends, we still are, and naturally he taught me a few things.
Things like how to be taken seriously in the workplace as a young developer, how to deal with office politics, but also something quite significant, which has stuck with me since then.
Something that I’ve always believed to be his mantra, to, as he would put it, “fucking own it”.
At first, I believed this to just be his fervour, he was pretty enthusiastic; but I started applying it to a couple of things, and started to realise how powerful it really was. …
Last month, I went into detail about how to use the recently released Dagger 2 Android modules, and how you can make your injection code much more concise.
Google have gone through a lot of effort to enable developers to use Dagger with very little integration and more importantly on how to use a common injection paradigm without the injection target being concerned with how it is being provided with it’s necessary dependencies.
The fundamental actor in this scenario is the
AndroidInjector class which can target different elements of an Android application such as Activities, Fragments, and Services.
Additionally, Google introduced a new annotation
ContributesAndroidInjector to generate the necessary components used for Android injection, giving us a clear example on how to use them, but most importantly allowed us to use safe paradigms without having to write extensive boilerplate code. …
Many of the articles I write tend to involve application structure or architectural design patterns; and one of the most recurring topics I tend to visit is that of dependency injection.
Dependency injection is probably one of the most important topics of modern application development, whilst often overlooked as a necessity, it allows us to build highly scalable, powerful applications and platforms.
Dependency inversion works seamlessly with many other design principles and in many ways facilitates them, most specifically single responsibility. Effective dependency injection is achieved by providing dependencies through the constructor, usually as interface types, thereby allowing the class in focus to not worry about the instantiation of these types. …
Modern day development can be one of the most tasking professions around, but without a doubt also one of the most rewarding. Amongst the trialling tasks we must go through each day, one of the most arguably difficult necessities is how we name our types.
This is partly due to the different naming conventions that come into play when using multiple words, underscores, hyphen, camel-case. Though we usually have code style guidelines to enforce a consistent use, this doesn’t really address the original problem.
It can be often overlooked, but naming is essential for the readability of code, how you name your types will later influence how your code is interpreted and understood by your fellow colleagues, and it’s your responsibility to make sure that meaning is conveyed in the best possible way. …
The concept of dependency injection is a relatively simple one, and can usually be adhered to with a small set of rules when writing your code.
Specifically, avoid creating new instances of objects within your classes, and opt to have the instance provided through the class constructor. This allows your class to focus on the key operations without having to worry about the state or creation of it’s dependencies.
This means that your class will be small, concise, readable, and most importantly, easily maintainable since it only contains the logic required to perform the necessary operation.
One of the main benefits to this approach is dramatically increased testability, by having small modular classes, preferably with only a single reason to change (see Single Responsibility Principle), your class is much easier to test. …