Maybe I Can Live With Gradle...

I was reading a a tutorial about particle emitters yesterday during a search for how to get the effect of snow falling in the foreground.  I'm not quite done yet, and it's going to be a few days after that before I integrate an appropriately novice-friendly particle system into liblol.  But I had to write about this anyway, because I think I'm starting to become a Gradle convert.

To run the tutorial, you need the libgdx particle editor.  It's a standard libgdx tool, if you added it to your project.  Of course, liblol didn't have it, because I didn't see the need previously.

Back in the eclipse days, to get this to work, I'd have to download some new binaries (.jar files or .so files or both), put them in the appropriate folders, and push all that mess into the repository.  Not so with Gradle.  All I had to do was add one line to the dependencies of the desktop project section of the top-level build.gradle file.

 compile "com.badlogicgames.gdx:gdx-tools:$gdxVersion"

That's it.  Next time I opened Android Studio, it went and found all the binaries I needed.  Wow.

Aside: if your Android Studio is set up like mine was, then when "1: Project" is expanded (left side of screen), you'll have "Android" beside it.  You need to change that to "Project" or "Package" in order to find the ParticleEditor tool.  Here's a screenshot (before and after):

Android Studio vs. Eclipse

Yesterday, I made the switch from Eclipse to Android Studio.  I'm not sure how to feel.  As an educator, my goals with Android Studio aren't quite the same as your regular developer.  Sure, I want an environment where programmers can be productive, but I also want an environment that is easy to manage in a classrom with novice programmers and lots of disks that my sysadmin and I need to configure and maintain.

I'll probably be revisiting this topic in August, when I set up for my game development class again, but here are a few initial impressions:

Definite Good Things

First and foremost, I love that there's just one installer.  I don't need to install the JDK separately [Update: well, kind of...], and I don't need to manually create an Eclipse shortcut, since there's a proper MSI instead of just a zip file.  The install took a long time... much longer than unzipping from a Git Bash prompt... but I can live with that.

I have never been a fan of Eclipse workspaces, and I was glad to see that Android Studio doesn't have workspaces.  It's much easier for me to manage 32 games that come from the same source parent when I don't have to go and rename the projects, just to keep Eclipse workspaces happy.

Refactoring is build-aware.  When I refactored a package name, all of the build files, in all of the projects, were updated automatically.  It updated my manifest, too.  I used to need a script for this.  Now it's just a few keystrokes.

Reformatting all files is a breeze.  It's one click to reformat all files in a folder, as opposed to doing it one-at-a-time like in Eclipse.  This might not seem like a big deal, but I find myself doing a lot of reformatting.  When a student has a bug in their code, and they've mucked with 15 different files, it's nice to get things back to a sane format before I go digging.

Probably Good Things

Android Studio has an aggressive warning system.  It flags lots of correct-but-not-ideal code.  I'm not 100% sure I agree with all the recommendations.  Consider the following code:

    if (!mEnabled)
        return false;
    return onPan();

The warning system encourages me to refactor this to:

    return mEnabled && onPan();

Is that really more intuitive?  The two will produce the same bytecode, but the latter requires me to remember that Java has short-circuit evaluation.  I can remind myself of that fact, but the time it takes me to remember is more than the time it takes to read two extra lines.

Another issue I have with the warning system is that it encouraged me to make some changes that Gradle disliked.  For example, it encouraged me to use some Java 1.7 features, even though my Gradle files still used Java 1.6.  Sure, in the end it was just a matter of changing the Gradle files, but I sort of thought that Android Studio would do that for me.

Gradle also favors storing remote packages out-of-tree.  Again, I'm not sure how to feel.  It's nice to stop having .so and jar files in my repositories, but I'll have to see how it goes when I'm managing 128 disks.  I know it's going to be friendlier on my hard disk, since it'll take 1/32 of the space to manage the games from my class (they all use the same LibGDX libraries).  But what happens when a library changes right before class, and I have to patch code on 32 disks in real time to deal with a mismatch between my code and a refactored API?

Project and structure are separate.  I liked being able to quickly navigate to a specific function of a file from the Eclipse Project Explorer.  In Android Studio, I have to toggle between the Project and Structure tabs.  There are keyboard shortcuts for switching, so that mitigates things to some degree.  I'm sure I'll eventually get used to this.

Not Good Things

Build times are really slow.  Really slow.  It takes at least 10 seconds to get the desktop game running, even if I haven't changed anything since the last build.  I don't know how long it took in Eclipse, because it was so fast I didn't care.  In contrast, Android Studio reports how long the build took, which says to me that they know it's slow.  It's not really Android Studio's fault, it's Gradle.  But it's slow.

On-the-fly compilation doesn't give a list of all warnings.  This may or may not matter to you, but I loved the way that Eclipse would give me a single window with all of the errors (or at least the first 100) across all of the files in my project, and update it every time I saved any file.  Android Studio highlights files (or their packages, when the package is collapsed) when they have errors.  But it still means I have to go searching.

The tooltips aren't on by default.  Part of the reason that I comment everything in JavaDoc format is because Eclipse would show me my comments when I hovered over any method or class.  Having that documentation on hand is a huge productivity enhancer.  In Android Studio, I can get to the quick documentation with ctrl-Q, or by enabling on-hover quick documentation.  But it should be enabled by default.  And the presentation of the information does not use space well.  Precious vertical space is wasted on buttons that seem to always be disabled.

The keyboard shortcuts aren't intuitive.  Ok, I'll admit that F3 being the Eclipse shortcut for "jump to definition" wasn't the most intuitive, but in Android Studio, it's ctrl-b.  Why 'b'?  And why ctrl?  I am a keyboard junkie.  I avoid using the mouse as much as possible.  And I try to stick to a scheme where ctrl is the prefix for in-document features, Alt is the prefix for app-wide features, and the control keys are for additional functionality.  Beyond that, there are many shortcuts that just don't make sense.  Ctrl-w, the almost universal shortcut for "close this subwindow", doesn't work.  I have to use ctrl-F4.  Alt-R takes me to the Refactor menu, not the Run menu (I run my code much more often than I refactor it).  And worst of all, shift-F10, which for the last 13 years has been the Windows shortcut for "show me the context menu, because my laptop keyboard doesn't have that nice extra button on it", is overloaded to mean "run".  So I am literally forced to use my mouse to do things (right click) that every other Windows application in the world has allowed me to do with the keyboard.

There seems to be a limit on the number of open files.  The UI silently closes files that are low in the stack, so I only have 10 open at any time.  Sure, it's annoying to have to tab through dozens of files, but since Android Studio has an awesome pop-up on ctrl-tab, you'd think they'd let me have lots of open files in it.

Wrap-Up

To be fair, I've been doing Android development in Eclipse for 4 years.  Some of my gripes are probably just growing pains.  Also, there are quite a few things I haven't tested at all.  I haven't used the emulator.  I haven't looked at my OpenCV apps yet.  Heck, I haven't even tried to use the Android Studio tools to design a UI.., I've only looked at liblol and game development, which in some ways is the most un-Android of any Android project I've worked on.

Android Studio definitely does some things better than Eclipse.  There are a lot of places (basic writing of code) where the two are equal.  I'll probably warm to Android Studio over time.  How about you?  Have you switched to Android Studio?  How do you feel about it, compared to Eclipse?

Setting Up Liblol

In order to make games using liblol, there are two programs you will need.  The first, Android Studio, provides an integrated development environment (IDE) for developing Android programs.  Android Studio lets you edit code, compile code, and debug running code.  The second, git, is a tool for managing source code.  Git allows you to track multiple versions of your code, so that you don't lose anything important.  It also lets you access code stored in public code repositories, such as github.  We'll need git in order to download liblol.

Setting up Android Studio

To set up Android Studio, visit the Android Studio page.  Make sure to download the appropriate installer for your platform.  The installation will take a long time, and use a lot of space.  When everything is installed, you should be able to run Android Studio, and see a window similar to the following:

Just close it for now... we need to install git and download the liblol code first.

Setting up Git

Many machines already have git installed.  We'll assume that you're on a Windows machine that doesn't.  If that's the case, visit the git homepage to install Git for windows.  Git for windows will provide a command line interface that is very powerful.

Once you have git installed, go to a command prompt ("git bash" in Windows), navigate to the folder where you want to store your code, and then type this:

    git clone https://github.com/mfs409/liblol.git

This will create a folder called 'liblol', in which you can find the starting point for your new game.

Importing Code into Android Studio

Now it's time to get the code into Android Studio.  Start Android Studio and choose "Import Non-Android Studio project".  Navigate to the liblol folder that you just created, and choose the build.gradle file.  Android Studio will take a little while, and then it will present you with the main Android Studio interface.  If you are asked to restart or install anything, choose "yes".

We need to do a few things before everything will work the way we want it to.  

First, turn on tooltips by going to the "File" menu and choosing "Settings".  On the left, choose "Editor", and then on the right, under the "Other" heading, choose "Show quick doc on mouse move".  This will cause Android Studio to provide helpful documentation about liblol when you hover your mouse over functions and classes in the code.

Second, we need to set up a "Desktop" run target.  This will make it possible to test your code without installing it onto a phone.  Go to the "Run" menu and choose "Edit Configurations".  From there, click the green "+" symbol in the top left corner, and choose "Application".  Then set the following fields of the screen that appears:

• Name: enter the text "Desktop"
• Main Class: enter the text "com.me.mylolgame.desktop.DesktopLauncher"
• Working Directory: navigate to your android/assets folder
• Use classpath of mod...: select "desktop"

In the menu bar, to the left of the green "run" triangle, you should now be able to choose between "android" and "Desktop".  Choose "Desktop" and then click the run triangle.  If everything is configured correctly, you should see your game start running after a few seconds.  It should look like this:

Going Farther

This setup will enable you to target Android, and to run your code on the desktop without connecting to a phone.  If you wish to add iOS support, you will need to do set up your project from scratch, using the LibGDX project setup guide.

Did it Work?

Hopefully I got everything right, and this tutorial will enable you to get started with liblol.  Please post a comment to report any errors you encounter.