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.
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.
Today, I’m excited to announce a significant milestone in the development of JRebel for Android. JRebel for Android has reached the 2.0 status. This is the first major release we have introduced since the release of JRebel for Android v1.0 in December last year.
We have been listening to your feedback and turned it into features that will help JRebel for Android make your development process faster and simpler. Literally, hundreds of fixes and improvements have been added in the v2.0 release.
In this post, I want to shed some light on the main features we’ve added since v1.0 and why we think it’s a really big deal.
Since we launched JRebel for Android last year, we’ve learned a lot about the Android build system, how it behaves in real-world projects, and where actual build time bottlenecks occur. Most of this invaluable feedback came from our JRebel for Android users and provided us ideas on how to make it even faster!
Today, I’m pleased to announce that the JRebel for Android now includes an incremental compiler that makes the performance of code and resource updating even snappier.
When you use the default toolchain, specifically Android Studio and Gradle, there are two major tasks in the build process of an Android app that are not entirely incremental. First is the compilation of Java source files and the other is resource packaging. In this post, I wanted to share some details about the compilation aspect and how we made it incremental, what challenges still exist and where it can take you performance wise.
Architecting an Android application is a fascinating task. Besides designing how the component of you app will interact, you need to take care of the common functionality that any application needs. Typically that includes the requirements that go span across the functionality, like logging, managing users and credentials, metrics and analytics, and so on. Since you cannot always store all the necessary data on the device, you’ll need to think about some sort of a backend service.
When you are just starting a project you might be reluctant to build a backend service from scratch. One option you should consider is Firebase. A platform that contains a lot of the common functionality for you and offers features like notifications, file storage, analytics, remote config and so one as a service. At the moment it has eleven services that help you to develop, grow and earn money from your applications.
In this getting started with Firebase on Android post I’ll walk you through setting up an Android project with the Firebase platform. We make our project implement its application analytics and send events to the Firebase console.
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.
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.
Long story short I’m on a journey to write an Android application after a break. As I’m in the middle of picking my image loading library I thought about writing a short summary of my journey. Maybe you are new to Android or just haven’t done it for a while, I hope you’ll get some ideas and help from here.
Here is a quick recap of what I’ve been doing with these image loading libraries and how I intend to use them in the application.
My criteria for picking the image loading library is pretty simple:
- Simple API that should be easily wrappable behind an interface so I can replace it anytime.
- Ease of image manipulation: rotating, scaling, blurring, mirroring and so on.
- Caching — the library should store the images on the device and avoid pulling more data than needed.
Google recently announced that the next version of Android, dubbed Android N, is ready for a developer preview. The preview gives us, as developers, a chance to test our code against the next release before it’s launched, including the new APIs and report any behavioral changes that break us. This release has only been baking for a couple of months, but some of the amazing features are starting to smell great already and we’re very excited about them — you should be too!
I wrote my first Android application about 5 years ago, using Eclipse, Ant and loads of old school stuff — no fragments, barely any 3rd party libraries to choose from. I’ve since moved to Android Studio and Gradle, but it has been a year and a half since I’ve sat down and actually written something from scratch to the end. Nowadays, I’m the product manager for the JRebel for Android tool, by ZeroTurnaround, that enables you to reload your application code on your Android device or any emulator without needing to repackage or reinstall the app — you know, those things that take an annoyingly long amount of time. I’d be delighted if you tried it and would gladly hear your feedback on how it improves your productivity as an Android developer.
Having said that I’m still involved with application development on Android and I have a pet project I want to implement, but first I’ve been lurking around the scene to understand what’s hip. I know that I will have to load images, do network requests, cache some data – pretty common stuff I’d say. Today I’m picking my image loading library!