Hi, Sten the Product Manager from JRebel for Android here. People keep asking me about the differences between JRebel for Android and Google’s own Instant Run. Since Android Studio 2.0 has finally been released, this is a good time to compare the two.
Back in November of 2015, Google announced Android Studio 2.0. Complete with a totally new feature titled “Instant Run”. Delivering faster build times to Android developers by supporting hot swapping code and resources in an already running application. The idea itself is nothing that new — it has been present in Java for over a decade. JRebel, the Java code reloading tool for Java SE/EE, has been enhancing developers’ lives for the past 8 years. This leads us to JRebel for Android. A tool that is approximately 1.5 years old, bringing the same technology to Android developers.
Today, I will provide an overview of how Google’s Instant Run and JRebel for Android handle code and resource changes. Side by side.
Have you ever argued about the efficiency of test-driven development in your day job? I certainly have, and on both sides of the argument. I have worked in the software development sector for 9 years as a developer and an architect on seven different projects ranging from mobile apps to a custom made telecom self services. I’m fed up of the pointless arguments – the ones based on solo experiences and anecdotal evidence. In this article I try to remedy this situation and clarify TDD in an objective way. Arguments should be based on a common understanding of what TDD is and your current project situation at hand: people involved, technology, goal, deadline, etc.
Every Java program tends to have one thing in common. They’ll all use Java collections! They’re so fundamental, we could not even avoid thinking to omit them from out RebelLabs cheat sheet collection. This is a tough challenge, since there’s so much you need to know about the collections framework, the implementation details, correct use cases, how to choose the right collection type, what can they do and when to turn to the third party libraries as opposed to using the built in collections in the JDK.
Anyway, no topic as broad as Java collections framework can be fully explained in a single A4 page, but we’ve tried to incorporate the most essential information you will need to reference again and again. The corresponding explanations and details behind the decisions are right here, in this blogpost.
NB! Our ZTLive webinar Microservices For The Enterprise was completed on April 19th. Read on for the topics covered in the webinar, and some background on our speakers. To watch the online recording of the webinar, just click on the REGISTER button below.
I’m the product owner of XRebel — the profiler for Java web applications that developers can use while they’re actually developing their applications. Recently I had to prepare a demo environment that I could easily share with my team mates. If the demo would have consisted of just a web app, without external dependencies, it would have been easy to share with the team: I’d just throw a WAR up on Dropbox and everybody would be free to do whatever they wanted to do with it. However in my scenario, I had an external dependency on MongoDB which made my demo a little less portable.
Naturally, I thought that Docker might be a good solution for this. The prerequisite though, is that my team members would have to install the Docker Toolbox in order to use the environment. But this is a wise thing to do anyway, isn’t it? Docker is an established container management system, with tons of resources available to learn the basics. We even recently published a Docker commands and best practices cheat sheet from which you can learn everything you need to navigate your way around Docker containers.
Let me sketch this out for you. The application is Petclinic – a web application, with a UI, that uses an embedded H2 database. In some scenarios, Petclinic talks to the Supplements application over HTTP. Supplements uses MongoDB to fetch data as JSON back to the Petclinic app, if requested.
Android development is great so long as your project stays relatively small. As the functionality of your project grows you’ll find that your build times follow suit. This puts you in the position where you spend most of your time figuring how to make your build run faster rather than adding more value to your actual app.
The interwebs are packed full with suggestions of how to squeeze the most out of your Gradle builds. There are some great posts on this, including ours “Making Gradle builds faster”. Although you can win back seconds and maybe even minutes, yet some bottlenecks will still remain in your build.
One thing you can try is JRebel for Android. It takes a different approach by not introducing a new apk after each change. Instead apk gets installed once and delta packages are shipped over to the device or emulator and are applied during runtime. This logic is nothing new and has been present in the Java EE/SE with JRebel for more than 8 years.
In computing, microlibraries is a software architecture style in which complex applications are composed of small, independent libraries communicating with each other using language-specific APIs. These libraries are small building blocks, that are tightly coupled and focused on doing a small task well, facilitating a modular approach to system-building.
The world is becoming more and more modular every day. With the pressure of existing systems to be modularised under the hype of microservices, architects want to compose their system architecture of bite sized modules with well defined edges. The microservices architecture is the first software architecture style that has begun to make use of microlibraries.
Once again I have the pleasure to provide you with a recap of the latest Virtual JUG session. This time we’re going to talk about Garbage Collection, GC, the automatic memory management facility that makes us and our applications believe that there is infinite amount of memory so long as we don’t consume too much of it at once.
As usual, we’re bringing you a short recap of what the latest Virtual JUG session has been about. Virtual JUG is the online Java User Group, which you can join from anywhere over the world. So there’s absolutely no excuse not to join. Here’s a link to the meetup site where you can register yourself and become a part of the community that brings you the most exciting sessions about Java in the world.
The session we’re talking about today was all about dependency injection. Our speaker Sven Ruppert took us through multiple libraries for DI and explained the differences in their approaches and when you might want to prefer one over another.