RebelLabs is the media partner for the Virtual JUG, the online Java User Group which brings you the best sessions by world class speakers. The best part? You don’t have to leave your house or office to enjoy them! You can educate yourself and become a better developer even from the comfort of your home!
The latest expert opinions, articles, and guides for the Java professional.
Android development is fun there’s no doubt about it! But there is also a lot of repetitive boilerplate code that the platform forces us to write. Quite a lot of it is related to the UI components that you need to process. Some of it is required when you want your application architecture to be clean. There are a lot of operations executing asynchronously in the background – in fact, it’s quite easy to end up with a bunch of spaghetti code that is unreadable or just does not feel right.
Today we’ll look at 7 Android libraries that help you keep your code clean and readable, using an example project so that you can see the libraries in action.
RxJava is growing in popularity in Android application development. However, it is also very capable for server-side apps. RxJava makes concurrency easier even though a seasoned Java developer would have to re-learn the concepts to become comfortable with the new idioms.
Welcome to the tenth RebelLabs cheat sheet! This time we’ll focus on the useful JVM options you might want to use, but forget about. In this post, we’ll describe what each of the featured options do.
We have previously published articles that, surprisingly, are not about JRebel for Android, but are useful for every Android developer. We’ve talked about your Gradle build times, about getting started with Retrofit 2 and so on.
Today, I’ll take a look at build cache that is coming to Android development toolbelt in the future. This can potentially have a great impact on improving build times. Which is universally a good thing, since no one likes to spend more time waiting for the project to build.
One of the best things about the Devoxx Java Conference in Antwerp each year, is that even after our 5th time going there we still meet lots of new developers who aren’t quite sure what JRebel actually is. They might have heard different speakers mention it during their talks as being helpful for speeding up development, or saw the ZeroTurnaround team at the booth in the exhibition hall, or just ran into someone wearing a new JRebel t-shirt in the beer line.
Not long ago, I inherited a bunch of spaghetti code sitting inside a big legacy enterprise application, and I found myself hoping that everything I needed to deal with was already there (and hopefully working properly). But when I needed to change something, how could I tell what will be affected? The side effects of any changes I make should be clear from the beginning. If only I could do unit tests AND see the ripple effect across the code too…
Well, I can. It’s called Mocking, and it lets you create alternative realities for your application to play through, without having any side effects or consequences in reality.
This post continues our series of one-page printable cheat sheets about Java and related technologies that we’ve been producing for almost a year now.
Today it’s all about Java generics. The feature was added to Java 10 years ago, and even today it still confuses many Java developers.