Pricing Request a Demo
Home / Android Studio
Enjoy the best mobile SDKs news, tips & tricks, sent to you by mail

3 Tips to Help You Migrate to Android Studio 3.0

September 5, 2017 2:27 PM

After a long period of expectation, Android Studio 3.0 is almost here.

It’s been quite a journey getting here. After 7 alpha versions of Android Studio 2.4, it was announced at Google I/O last May that changes are far too great and will be incorporated into Android Studio 3.0. And then 9 alphas later, the new and improved Android Studio was born. So overall, there are quite a few changes.

And with every truly major version update, upgrading is a little tougher than just the click of a button. In this case, your project would not compile. So before you start googling your way just to end up where you started before the migration, I’ve assembled some tips that helped me getting from a project that compiled on Android Studio 2.3 to a project that compiled on Android Studio 3.0.

Continue Reading

Hello, Kotlin! Converting an Android Project – Part 2

January 24, 2017 10:37 AM

I was trying to convert an Android project to Kotlin in Android Studio via the Kotlin plugin. If you haven’t read part one (you can always do it now), then I’ll briefly tell you that it’s up to you to choose how many classes to convert. I chose them all. The conversion caused numerous compilation errors and practically swayed me to convert one/two classes at a time. Even though solving compilation errors was a great way to learn, I still had an ambition – convert my MVP example project from Java to Kotlin code.

Therefore, I decided to attack it from another angle. My second approach was less messy – one or two compilation errors per conversion, albeit it took me a couple of hours to get everything working.

In the following post I will cover:

  • Adapter’s getView() runtime error, caused by the conversion
  • Kotlin pros/cons for Android developers
  • Verbosity comparison of Java vs Kotlin

TL;DR Conversion might cause errors but Kotlin will reduce NullPointerExceptions, and minify your code into a much more readable version.

Continue Reading

Hello, Kotlin! How to Convert an Android Project – Part 1

January 17, 2017 5:13 PM

I’ve been hearing about Kotlin everywhere. It’s the new big thing in the Android world. So big that Gradle themselves are talking about incorporating it.

So I set out on a journey to see what the hype is all about.

What is Kotlin? Well, simply put it’s a statically-typed language from the house of JetBrains that compiles to Java’s bytecode and therefore can be run using a JVM. It’s got lots of interesting features and full compatibility with Java.

The following post is not a conventional Hello World tutorial on Kotlin, rather it’s an experiment with a big bold “don’t try this at home” warning. It’s risky and code might break because I’m going to convert a whole project of a mid-level complexity (30 classes) at the click of a button, or rather 4 buttons (ctrl + alt + shift + k). If that won’t work out (spoiler alert: it didn’t), I’ll switch to plan B and convert my project one class at a time.  I’ve decided to see if they’re making good on their promise, as well as teaching myself a new programming language upside down. From big concepts to the finer details.

Because I’m going to mess with lots of code and it might not end up pretty I chose to convert one of Android’s google-samples projects which I forked. I chose the todo-mvp branch: If you are unfamiliar with different styles of Android architecture (MVC, MVP, MVW) or their implications I highly recommend going over them anyway if you haven’t yet.

TL;DR: we’re converting a TODO List app.


IDE = Android Studio 2.1.2. There’s a plugin for Eclipse too.

Kotlin version = 1.0.4

The before photo (before tinkering):

Hello, Kotlin! How to Convert an Android Project – Part 1

Continue Reading

Key Notes from Google IO’s Keynote

May 19, 2016 7:17 AM

Google IO is the ComicCon of devs. Being there is being square and damn proud of it! The three-day hoopla was kicked off this morning with the much anticipated two hour keynote speech at Shoreline Amphitheatre in Mountain View and I am glad to say I was there for every syllable of it.

I’ll be honest – when Sundar Pichai took the stage, I was giddy as a schoolgirl, ready to throw my shirt on the stage like your common average groupie.

And then they proceeded to blow my mind. If you thought Google was seeing and hearing everything before, the announcement of Google Home, as well as the new messaging app Allo (or the counterpart video chat app Duo and its knock-knock feature to let you see the caller’s video before answering), emphasized that Natural Language Processing is the future and what Google is all about in 2016. This was definitely not one for the paranoids who worry machines are about to rise up against us J

The second hour of the keynote focused on advances regarding mobile, which is really what caught my attention. Those devices that have become the center of our universe are what drew me to IO in the first place, and there were some interesting notes to take from this particular keynote.

Continue Reading

The Holy Gradle: Setting Up Your Android Build on a Build Server – Part 2

July 15, 2015 8:11 AM

In my previous post I went over some basic terms used by Gradle and the Android build system, and over the flow of the build. With these understandings at hand, we are now ready to go over concrete steps and set up our build server, without Android Studio, or in fact without any GUI tools at all.

For the sake of this post I will assume you are setting up your new build environment on a Linux server, and you don’t have the Linux GUI at your service, only the command line. Of course, it can all be set up on a Windows or Mac machine just as well.

Let’s also assume that your user on the build machine is called “user”, and therefore your typical home directory would be /home/user.

Now let’s go step by step:

1. Download and install the JDK

First download the JDK you work with. I have downloaded JDK7 from Oracle’s site. If your Linux environment doesn’t support rpm – you will need to download the tar.gz version and extract it, for example to /home/user/.

2. Download and install Gradle

You can download Gradle’s latest release from here. The binary distribution will do, no need for the complete distribution. I chose to use Gradle 2.4.

By the way, There is the option of avoiding the explicit installation of Gradle if you are using the Gradle Wrapper, but let’s leave this topic aside. Personally I think that if you are setting up your build server, the better approach is to explicitly download the Gradle version you want. Once downloaded, extract the zip file, for example under /home/user.

Continue Reading

The Holy Gradle: Setting Up Your Android Build on a Build Server – Part 1

July 7, 2015 10:47 AM

If you are using Android Studio, then you’ve seen Gradle in action. Yep, Gradle is the engine behind the build system used in Android Studio, which is, together with Google’s Android plugin for Gradle, responsible for building your Android application and producing the final .apk files.

Gradle is a powerful build tool, written in a simple script language called Groovy. It takes care of a lot of the plumbing related to building an application – resolving dependencies, downloading artifacts from repositories and determining which tasks need to run in order to build your app. Gradle then runs the tasks that compile, merge, handle resources etc until your app is ready. Gradle is also simple to configure. Typically, with a few declaration lines in your build.gradle you are ready to go.

But this is exactly what makes Gradle somewhat complex to understand, because a lot of the work is done under the hood, typically by plugins, some built-in (like the java plugin), and some being 3rd party plugins, like the Android plugin and the SafeDK plugin. If you are someone like me that likes understanding what’s going on behind the scenes – it’s not always that easy.

There’s of course a lot to tell about Gradle and the Android build system. So much, in fact, that this is just the first out of a two-part story (part 2 coming next week). In these couple of posts I’ll focus on a specific topic – I’ll try to guide you through setting up an environment where you can compile an Android application using Gradle, but without the Android Studio IDE. Why would you want to do that? Well, it has to do with buzzwords like “build server”, “continuous integration” etc. While you can build and deploy your app in Android Studio, if you have multiple people working on the app, you may want a central build server with a consistent environment, where you continuously integrate, run automated tests, produce versions for your QA team and produce the final versions. This is btw one of the nice things in Android Studio – the fact that you can completely decouple the build system from the graphical IDE.

Here I’ll go over some terms and mechanisms which are essential for part 2, where I’ll detail the steps to set up your independent build server.

OK, so let’s dive in.

Continue Reading

Reducing Your Method Count: The Google Play Services Edition

June 30, 2015 3:50 PM

Avid Android developers have longed faced a headache-inducing problem with their apps. The number of methods an app can have is limited. Well, it used to be limited. At long last, the good folks at Google provided a solution last October, but it was far from ideal. Though very easy to implement, the multidex solution complicated and prolonged compilation time significantly. Not standing still, starting with Lollipop (Android 5.0), the entire Android virtual machine was revolutionized to offer a much more endurable solution, the kind that even improves on the regular compilation time.

However, for the time being, the Lollipop solution isn’t ideal too. It requires developers to develop against Lollipop only, which could be problematic since most apps want to be compatible with wider ranges of audiences and might fear using features that aren’t available in earlier Android versions. So right now, the Lollipop solution is a good future-Android solution, but might not have much impact in the foreseeable present.

So what can be done in the meantime? We all agree that you shouldn’t give up on features and capabilities, just to avoid reaching the 65K limit. But there is no doubt that the best practice would still be to reduce your application method count.

So how can you still try to reduce your method count without losing that little spark that makes your app special?

Continue Reading

Solving Android’s 65K Limit (Part 2): The Lollipop Generation

June 23, 2015 3:57 PM

If you’ve read my previous post about breaking Android’s 65K limit (and if you hadn’t, what are you waiting for?), you’re already pretty familiar with Android’s 65K limit, why it exists and how to solve it. Which means you’ve been itching to know what the future of multidexing has in store (and what does a tooth-fairy-supporting candy-on-a-stick has to do with it).

As small recap to start with, if you will:

Since its’ inception, Android ran a virtual machine called Dalvik. The Dalvik VM ran a compiled file called dex (Dalvik Executable) which has a tiny limitation – even though the file contains the entire code for the application, its id field was limited to 4 hexadecimal digits. So when an application had over 0xffff methods (=65,536 in decimal), the dex file simply could not be created, meaning applications with so many methods could not be created.

That posed a problem as applications became more and more diverse and complex, and as many developers looked to speed their development process by not doing everything from scratch, but by using more and more third-party libraries (SDKs) that help them achieve their goals faster.

Android released a support library which helps you create an application with over 65K methods. In a nutshell, the compilation process to of Java bytecode to dex was enhanced so that once the limit is reached, a secondary dex file is created. The support library then offered a static method Multidex.install which is called when the app is being launched and tells the class loader to look for methods in places other than the one dex file is expects.

However, we’ve seen the solution is not ideal. Issues ranging from prolonged compilation time to a static process repeating every single time the app is launched made the multidex solution a workaround compromise rather than something Android developers could truly trust. What might be the most burning issue is the lack of ability to predex (compile the not-likely-to-change parts of your app to dex only once; Again, for more information, take a look at part 1).

Continue Reading

Solving Android’s 65K Limit: The Unbearable Lightness of Multidexing

June 16, 2015 7:39 PM

If you’ve been developing for Android for some time now, you might have encountered a little thing called “The 65K limit”. You must have at least heard about it around the water cooler. There were times were Android developers dreaded it.

You see, the Android system put an almost arbitrary limit on the number of methods an Android application can have. A limit which may have sounded reasonable in the past but is near far-fetched in today’s terms. The limit itself, which stands roughly around 65,000 methods, may sound a bit excessive. “What are the odds I’ll ever reach that?” a novice Android developer may be thinking. However, applications are using more and more third-party libraries (otherwise known as SDKs – Software Development Kits). Just imagine writing your app and wanting a library to help you parse JSON objects, wanting to connect to a social network such as Facebook, or looking to make a profit for your effort by displaying ads in your app. All of these libraries add more methods to your app, and slowly that high limit doesn’t seem so unreachable.

Adding insult to injury, Google themselves contributed massively to the problem, with their Play Services SDK containing a whopping 29,000 methods! That number is almost inconceivable – that is nearly half of the limit (In an upcoming post, I will describe how you can reduce the number of methods you get from this SDK. Stay Tuned).

Today, however, things are different and solving the limit issue is quite simple. So simple, actually, that many apps found refuge in it. Today there are apps in the Play Store with well over 80K methods!

Continue Reading