• Home
  • Events
  • About
  • The Best Groovy Inspections You're Not Using

    January 18th, 2012

    Many, many tools perform static analysis on code. There are all sorts of automated ways to look through your code and tell you if there are likely errors or not. FindBugs, PMD, and CheckStyle are some of the big names from the Java world. On the Groovy side we have two real options: IntelliJ IDEA and CodeNarc.

    This post highlights my favorite static analysis rules for Groovy in IDEA that are not enabled by default. Groovy in IDEA 11 has well over 100 rules, but less than half of them are activated when you install the product. To turn these rules on you’ll need to go into Settings (Ctrl+Alt+S) and enable them under Inspections.

    So here are my favorites that I think you should turn on:

    Threading
    Threading comes first because these inspections have saved my butt in the past. None of them are enabled by default, so do yourself a favor and enable a few. These ones are all must haves:

    * Access to static field locked on instance data – Reading and writing a static field from multiple threads is not thread-safe. It needs to be done within a synchronized block. Do you know what happens when you synchronize on instance data, like this:

    The object ‘lock’ is an instance field, not a static field. So this assignment within the synchronized block is not thread-safe. It is possible that the static field is accessed from multiple threads, which can lead to unspecified side effects.

    * Synchronization on non-final field – If you are accessing a variable within a synchronized block then your synchronization token must be final. Consider this code:

    The field ‘lock’ is not final, so different instances of MyClass may have different values for lock. The result is that different threads may be locking on different objects even when operating on the same object. Make your locks final.

    * Synchronization on variable initialized with literal – Do you understand the problem with synchronizing on a primitive literal? Consider this code:

    Strings are interned by the JVM, so the string ‘my lock’ may also be used by another class. Numbers are even worse because they can be assigned from a cache. Some other object in the system may be initialized with the same literal, and could create an accidental (or malicious) dead-lock situations.

    * Unsynchronized method overrides synchronized method – In some limited circumstances you may actually want to override a synchronized method with an unsynchronized one. But probably not. More than likely you don’t even know and you are accidentally creating a subtle bug. If the parent is synchronized then the child should be also. Or better yet, make the parent final.

    Probably bugs
    * Named arguments of constructor call – This inspection warns you when something like the following happens when using named arguments, which is almost certainly a bug:

    See the problem? The field is named ‘orderId’ with a big ‘I’ and the constructor call uses ‘orderid’ with a small ‘i’. RuntimeException if you run this code. This is a type of bug that CodeNarc cannot find because the type information of the classes is so limited. IDEA keeps track of types much better and can do nice things like this.

    * Access to unresolved expression – There has been a lot of talk over the years about adding static compilation to Groovy. Some people want to be warned by the compiler or in the IDE if their Groovy code is referencing an object that does not exist. For example, they’d like this to produce a warning or error:

    See the problem? The closure parameter is named ‘parm’ but the closure references the parameter by the standard name ‘it’. The access to unresolved expression inspection turns this into a warning or error in the IDE. IDEA is quite smart about it too and knows all about delegate/super and the other Groovy dynamic variables. If you like this sort of thing then be sure to read up on Grumpy mode in Groovy 2, coming soon.

    Control Flow
    There are many features in Groovy that simplify standard and verbose Java code. Two of these are the Elvis operator and the Null-Safe Dereference. IDEA contains inspections to help you migrate to the new way of writing code with these features.

    * Conditional expression can be elvis – This inspection migrates you from code like this:

    And suggests you rewrite it into the equivalent Groovy:

    Is it always safe to make this transformation? (Think about it for a few seconds). GroovyTruth means it is not. Technically speaking, the two code snippets are not equivalent: value != null may be true while value is false, such as when value is an empty String. Overall, I like the inspection but you need to be careful with it.

    * Conditional expression can be conditional call – This inspection promotes the use of the Null-Safe dereference. This following code produces a violation:

    … and you will be prompted to transform it ito:

    These two code blocks really are the same and this can be safely accepted as the correct way to write the code.

    * If statement (or conditional) with identical branches – I periodically refactor code and accidentally leave an if or conditional statement with identical branches. These are of course redundant and can be cleaned up by removing the if expression. If you have good unit tests and use automated refactorings then this sort of things happens from time to time. The cleanup reminder is nice.

    Error Handling
    * Unused catch parameter – My favorite Error Handling inspection is ‘Unused catch parameter’. Consider this code:

    What happens to the stack trace in this scenario? It gets eaten up, never to appear in a log. You shouldn’t have any unused catch parameters. If you really don’t care about the exception then name it ‘ignore’ or ‘ignored’ to suppress the warning.

    Validity issues
    * Duplicate switch case – Groovy has Switch on Steroids, meaning you can put almost any object in the case statement, including regular expressions:

    See the problem? The same regex appears twice. The second case will never be executed, even if it would match. As long as your case statements have literals in them then IDEA can verify that there are no duplicates.

    Naming Conventions
    Lastly, there are a whole bunch of naming convention inspections that you can activate and configure. If you’re not using CodeNarc (why not?) then you should at least activate some of these. Standards, on a whole, are good to adhere to.

    IDEA Inspections of CodeNarc?
    So which should you use, IDEA or CodeNarc? These two tools complement each other. There is good reason to use both CodeNarc and IDEA together. CodeNarc does have more inspections than IDEA, but the IDE integration in IDEA is better. Pressing Alt+Enter typically rewrites the offending code, and the speed of the actions are much better in IDEA. Also, the static analysis rules do not overlap between the products because the CodeNarc developers (that’s Chris Mair and myself) already use IDEA and made a conscious effort not to duplicate anything.

    And if you do want to use CodeNarc and IDEA, then you might try out the CodeNarc IDEA plugin.

    If you like this then you might check out some of my other IDEA related posts: The 10 Best Inspections You’re Not Using (in Java), or the IDEA archive on my blog and the Canoo blog.

    And remember if you need Groovy and Grails help, then give us a call or drop me an email at hamlet.darcy@canoo.com


    Android Testing in IntelliJ IDEA

    January 12th, 2012

    Google’s Android site has some fairly detailed instructions for testing Android applications… from Eclipse. They were nice enough to supply a “Testing from Other IDEs” page, but that is nothing more than instructions on using Ant and the command line. Well, if you are using IntelliJ IDEA then you already believe the IDE is going to be a better tool than Ant for this. It’s easy to set up a test project in IDEA and get your tests running. Here are some simple instructions.

    Prerequisites

    This tutorial assumes you have installed IntelliJ IDEA and an Android SDK, and also created an Android project. If you haven’t yet, then you should read Testing Fundamentals accessible from Google’s Testing Home page.

    Creating a Test Project

    Your Android tests are going to be placed in a separate module from your main Android application. Remember: an IDEA project is composed of several modules. We’re going to have the main application module and the test module. Each module has it’s own set of dependencies and classpath. (Eclipse users confused about the terminology should read this). Here are the steps to follow to set up a test project:

    1. Have your main project open in IDEA
    2. Create a new module using the menu File->New Module
    3. Select “Create module from scratch” and click Next
    4. Select “Android Module”, give the module a new name, and click Next. You should put the module in a directory called “tests” that is in your project root. That way your project will follow the same naming conventions that Ant expects, making the project easier to set up in a CI server later. Here is what your wizard screen might look like:

    Adding an Android Testing Module

    Adding an Android Testing Module

    5. On the next wizard step just click Next to create a source directory for your files.
    6. Finally, on the last wizard step select “Test” under Project properties. Make sure it is going to test your module. Then Finish.

    Select Test as Project Type

    At this point your two modules exist: the production module and your test module. If you look in the Project View (Alt+1) you will see both modules. Mine are named “android-testing-in-idea” and “tests”. You’ll even be given a template test for your main activity. It’s pretty slim so you will certainly want to write some of your own tests. IDEA isn’t smart enough to automatically create the test content for you… at least yet.

    Running Tests

    Running tests is simple. A run configuration to run all tests was created for you when you added the project. Click the ‘run triangle’ to run the tests or the ‘bug triangle’ to debug the tests. You’ll be prompted to select an emulator if you don’t have one set by default.

    run all tests

    Click to Run All Tests

    There are other ways to run tests at a more granular level, too. To run all the tests in a package, right click the package and select Run (Ctrl+Shift+F10). To run all the tests in a class, right click the class and select Run (Ctrl+Shift+F10). You can also run individual test methods one at a time. Just right click inside the test method within the IDE editor and select Run (once again, (Ctrl+Shift+F10)).

    You may want to switch the emulator version from time to time in order to test across multiple devices. You can bring up the Run Configuration from the drop down menu highlighted in the screenshot above. It opens a screen like this where you configure the run target:

    Configure the Test Run Target

    Configure the Test Run Target

    You can switch the emulator here to a different version. Be sure to check out the other tabs as well. The Emulator tab allows you to configure the network speed and latency, and the Logcat tabs lets you configure one or two things about Logcat. Handy.

    Viewing Results

    So you want to view the test results? Well results window probably popped up on screen after you ran the test. Anyway, if you’re still confused you can click the Run (Alt+4) or Debug (Alt+5) drawer and see the JUnit results. There is also a Logcat drawer to click (sorry no shortcut) to view the logs.

    Viewing Test Results

    Viewing Test Results

    Other Tools

    The last thing you need to know is a little about the other tools. You can manage your emulator ROMs using the AVD Manager. The menu option for that is Tools -> Android -> AVD Manager. Also, you can change the project compatibility to be a different version of Android OS. It’s under File->Project Structure (Ctrl+Alt+Shift+S) then click Module SDK. Finally, if you want to set the project up for continuous integration then head on back to the Ant command line guide from Google. It’s best not to have the IDEA project file drive your builds.

    You made it to the end. Thanks for reading! And remember, Canoo is here to help with your Android and Mobile needs. Email me directly (hamlet.darcy@canoo.com) or give us a phone call. Thanks.


    The Art of Groovy Command Expressions in DSLs

    December 8th, 2011

    Domain Specific Languages (DSLs) are often littered with the accidental complexity of the host language. Have you ever seen a supposedly “friendly” language expression like “ride(minutes(10)).on(bus).towards(Basel)”. The newest version of Groovy contains a language feature that aims to eliminate the noise of all those extra periods and parenthesis, so that your DSL looks more like “ride 10.minutes on bus towards Basel”. This article shows you step-by-step how to use Groovy Command Expressions and plain old metaprogramming to write just this DSL, and also offers advice on when, and when not, to use this new language feature.

    The State of the Art with DSLs

    Domain Specific Languages (DSLs) have been in vogue for a long time, and the topic has featured regularly at No Fluff shows for years now. The value proposition of a DSL rests in the idea that programmers and users benefit from expressing their desires in a language closer to English than to Java, using words suited to the problem domain rather than the programming language. The goal is not to create an entire new language, but to create a small language just big enough for users to capture their commands and intents in a more natural way than is typically possible in code.

    Different languages support DSLs in various ways. Some languages make it easy to write nice, readable natural language-ish code and others do not. Over the next few pages we’ll explore the state of the art with Groovy DSLs, starting with looking at some unimaginative Groovy code, seeing how to convert into a better fluent interface, transforming it further using metaprogramming, and finally showing the full power of Groovy Command Expressions. As a sample problem, imagine trying to specify directions on how to get somewhere. By the end of the article you’ll understand how the Groovy code in Listing 1 works even though to looks almost like plain English sentences.

    Listing 1: A DSL for giving Directions

    The Canvas

    We’ll use the same running example through all of the exercises. So let’s start by painting out a few primitive ideas. Think of these basic building blocks as the undercoat to our DSL canvas. Thinking about your domain is always a good place to start if you’re considering writing a DSL. Think, analyze, and compare the domain to see how it should be naturally organized. If you read the example in Listing 1, you may notice a few similarities between the different lines of code. There are actions, such as ‘stand’ and ‘ride’. There are vehicles, such as a ‘bus’ or a ‘tram’. And there are locations, such as the ‘bus stop’, ‘Basel’, and ‘Birsfelden’. We’ll model the actions as methods later, so let’s skip those for now. Vehicles and Locations are fairly straightforward, so we’ll model those as Java enums, as shown in Listing 2. I’ve put them in a package so that I can do a static import on them later.

    Listing 2: Modeling Locations and Vehicles

    There is also something else in common between all of the instructions from Listing 1. They all have a duration or distance, such as ‘7 minutes’ or ’10 stops’. A duration is a little bit harder to model, but not much so. For sake of simplicity, we’ll just define a Duration class that represents either a unit of time or a unit of distance, as shown in Listing 3. I applied the TupleConstructor annotation to generate a set of constructors on the object, making it a little easier to work with.

    Listing 3: Modeling a Duration

    The last bit of undercoat to apply to our canvas is the Instruction object itself. Listing 1 creates a list of Instructions behind the scenes, so we’ll need to model those as well. Similar to Duration, it’s a simple data type with a few properties and is shown in Listing 4.

    Listing 4: Modeling an Instruction

    An Instruction has an action (stand or ride), a location (bus stop or Basel), a duration (five minutes or three stops), and optionally a vehicle (a bus or a tram). Now that the undercoat is applied, let’s look at some different ways to construct these Instruction objects.

    Cave Paintings

    The most primitive way to create Instructions is to call the constructors of objects directly. This is hardly a DSL but at least it is an improvement over the Java equivalent. There’s not much here to be proud of, and list literals like [] and the leftShift operator to add list elements is only a slight improvement over the alternative. At least Listing 5 is rather short.

    Listing 5: Creating Instructions Explicitly

    The problems with this code sample is that there is a lot of accidental complexity: pieces of the underlying programming language bleed through and obscure the intent. In the first instance, only the words ‘stand bustop 5 minutes’ are essential to the problem of creating instructions. The other 59 of the 79 characters are non-essential complexity. A 25% signal to noise ratio is pretty poor. The classical solution to this problem (in a sense that it can be applied to Java code as well) is to create a fluent interface around Instruction objects so that the end user is shielded from these implementation details.

    Classicism

    A fluent interface is a way to chain method calls together in order to eliminate a lot of the noise associated with configuring data. Fluent interfaces can be created with statically compiled languages as well (like Java) and requires no special metaprogramming facilities in the host language. The trick is to be creative with method return types. Listing 6 shows the result of improving our signal to noise ration after refactoring to a fluent interface.

    Listing 6: A Fluent Interface for Instructions

    This is a big improvement and raises or signal to noise ratio from 25% all the way up to 75%. The only noise left in this example is the parenthesis party nestled between all the interesting bits. Hmmm, looks like someone invited a few periods along as well. We’ll do better in the next example, but let’s look at how to implement this fluent interface first.

    As I said, the trick is to be creative with return types. For example, the code ‘minutes(5)’ actually instantiates a Duration object for us (Listing 7), which is then passed into the ‘stand’ method as an argument.

    Listing 7: A minutes Method

    The trick is to make all of the method calls chain together. So the ‘stand’ method needs to return something that has an ‘at’ method on it, and that in turn needs to accept a Location parameter and create the actual Instruction. Technically speaking, stand is a higher-order function: it is a method that returns to you a method. Groovy’s dynamic typing and map-implemented interfaces make this a pretty simple task, as shown in Listing 8.

    Listing 8: The stand Method returns another Method

    In Groovy, an object can be created as a Map literal using the [key: value] syntax. If the keys are Strings and the values or Closures, then that object can be treated as an object and have methods invoked on it, which is what Listing 8 shows.

    At first, fluent interfaces often seem complex to implement. But after writing one or two you’ll often find it is really not too difficult. You have to think differently about how you craft an API, but in the end you can get a lot of usage and nice APIs using a fluent interface instead of metaprogramming. Let’s turn now towards bouncing some of those pesky parentheses out of the party using a little Groovy metaClass magic.

    Impressionism

    In our tour of DSL art, I’m calling the next technique impressionism. Like impressionist paintings, it does a slightly better job of capturing the intent than the previous example, but if you examine it closely it doesn’t seem to be much clearer than the alternatives. The motivating code is in Listing 9, can you spot the difference?

    Listing 9: Five Minutes not Minutes Five

    There are two less parentheses, but an added period. ‘minutes(5)’ became ‘5.minutes’. The signal to noise ratio improvement is marginal; the advantage here is that the code more closely resembles the away we speak. Nobody sticks their head over the cube wall at 12:05 and asks, “Do you want to go to lunch in minutes 5?” Instead, they say “5 minutes”, which is exactly what this code says. This is a small change to implement, and listing 10 shows that making the language support singular and plural words is just a few lines of code.

    Listing 10: Metaprogramming the Duration

    What’s happening here is that we’re adding a method called ‘minutes’ and ‘minute’ onto the Integer class, and this method is creating the Duration object for us. Other than replacing the old ‘minutes()’ method with these four lines of code, there is no change to the previous example. The code all just stays the same.

    The combination of fluent interface and metaprogramming is powerful. Sure, there are some issues with periods and parentheses, but overall it is a pretty big improvement over trying to call constructors and wire objects together in Java. Groovy 1.8 takes things a little bit further and leaves us with the best example yet.

    Expressionism

    The last example is the best. It contains a minimum of accidental complexity and Groovy bleed-through and looks almost like the English language equivalent. For fun, I encourage you to compare Listing 11 with the cave paintings listing in Listing 5. It’s quite a bit improved.

    Listing 11: Command Expressions

    I call this final version Expressionism, not because it relates very well to the 20th century art movement of the same name, but because it uses a new feature called Command Expressions and is the most expressive of all the examples.

    So what are the code changes? You might notice that there are no more listings in this article. That’s right, command expressions are just the way code may be written now. Listing 11 showing the command expression usage and Listing 9 without the usage are functionally equivalent. ‘Stand’ and ‘ride’ are still method calls that return the ‘at’ and ‘on’ methods. As long as the code follows the follows the pattern ‘method parameter method parameter method parameter’ then it gets converted into ‘method(parameter).method(parameter).method(parameter)’. You can chain as many together as you like; Groovy won’t complain. The result is a nice readable chain of expressions without any additional effort. At the time being, Command Expressions are the state of the art when it comes to DSLs in Groovy.

    Art Criticism

    There are a couple of pitfalls to be wary of. Command expressions are shown here in the best possible light in order to display their power. In reality, they are also a little fragile. Any code not following the ‘method parameter method parameter’ rhythm doesn’t easily fit into the command expression pattern. The result is that you might have to twist your words a little to make them fit into this pattern, which moves it away from natural language and towards accidental complexity. Also, there is always the Groovy grammar and keywords to look out for. For instance ‘for’, ‘native’, and other keywords cannot appear in your DSL, a problem which other languages do have solutions for.

    Also, it is probably best to avoid command expressions outside of DSLs. The code ‘list.collect{ … } each { … }’ looks like a syntax error to most Groovy programmers because there is a period missing before the each method call. However, it isn’t wrong and works just fine. Confusing, but correctly functioning. Currently, Groovy programmers are used to some parentheses and periods, and it’s confusing to leave them out unless you have good reason.

    Create Your Own Art

    Thus concludes the tour of the state of the art with Groovy DSLs. To start, Groovy fluent interfaces are a great way to organize an API and make it easy to use. While not a true domain specific language, in a low ceremony language like Groovy they can go a long way towards increased expressiveness and better signal to noise ration without resorting to programming trickery. For more power, start to use metaprogramming to fine tune the the exact API you need, and use Groovy Command Expressions when you need them. How go forth and make your next DSL a true work of art.

    Need help with Groovy? Canoo is ready to tackle any challenge. Contact info@canoo.com to learn more about Groovy Training and Consulting.


    Android and IDEA for the Eclipse Refugee

    October 18th, 2011

    Earlier this month I switched from writing my Android projects in Eclipse to writing them in IntelliJ IDEA. Overall the experience has been great, and I much prefer using IDEA to Eclipse for Android development. And now that IntelliJ IDEA 11 EAP (Early Access) has a visual layout window, there is almost no reason for me to write my Android apps in anything else. I wrote this post to help other users along their way when converting between the IDEs.

    Why IntelliJ IDEA for Android?

    There’s no need to ask why if IDEA is already your favorite IDE or if your company is forcing you to use it. But just in case you’re not already a raving fanboy, here are some of the features specific to Android that made me want to switch.

    Find usages (Alt+F7) is aware of Android XML resources (and the semantic meaning of their content), so searching across project assets is easier. Plus, I just find IDEA’s search capabilities a little saner than Eclipse’s. Below you can see what happens when I search from within my layout XML file for a certain widget ID:

    01. Find Usages

    Find Usages in IDEA

    Because IDEA knows about the Android XML resources, refactorings like Rename (Shift+F6) work across Java code and XML. You can rename a widget’s ID from the XML file and have the Java code updated, or rename from the Java code and have the XML updated. Here I am renaming a widget ID in XML. Nice. In general, I do not search within comments and Strings because it is a little too aggressive.

    02. Rename Refactor

    02. Rename Refactor

    There are several Android specific intentions that make life easier in IDEA. Intentions are the quick-fixes that are activated in Eclipse with Ctrl+1. In IDEA you use Alt+Enter. For example, if there is a static String referenced from your code then you should make that String a resource by moving it to strings.xml. Put your cursor into the String, press Alt+Enter, accept the name suggestion, and you’re ready to go. Ctrl+Z for undo on refactorings work great, too. One of the big differences between IDEA and Eclipse is refactoring support. In IDEA, the source files do not need to compile in order for refactorings to work. It is quite common to have a broken file and fix it through a couple automated renames or refactors.

    03. Move Refactor

    03. Move Refactor

    Finally, before IDEA 11, the killer feature for Eclipse Android was the visual editor for XML based layout files. Personally, I don’t often use drag and drop layout editors but I do value seeing my code changes immediately without recompiling and redeploying. Eclipse had the better feature set. But IDEA 11 now has a layout “Preview” mode. Make a change in the XML and see it immediately updated in the preview. You can also quickly change the theme, preview in landscape and portrait, switch to night mode, and select different screen sizes. If you absolutely need a visual editor, then Eclipse is the way to go. Otherwise, the Preview in IDEA 11 is good enough. More info available on the IDEA blog.

    04. Visual Preview

    04. Visual Preview

    Let’s get started with a tour of IDEA.

    Getting Oriented in IDEA

    The basic layout of IDEA is not all that different from Eclipse. You have a main code window (right, in image below), you have a Project View (upper left), and you have a Structure View (lower left). If there is a window for it in Eclipse, then there is probably a window for it in IDEA. A good way to get started and get familiar with IDEA is to read the DZone IDEA RefCard I wrote a few years ago. It is still relevant today. I highlighted the image to show the relevant details.

    05. Project View

    05. Project View

    At any time you can jump to the code window by pressing Escape, and you can close any open tool window with Shift+Escape. On thing that IDEA does not have is perspectives. Maybe you love Eclipse perspectives. Maybe you love when your code view shrinks up into a postage sized porthole whenever you launch a debugger. Who knows, perhaps this is useful to you somehow. I am trying very hard to be positive here, and the nicest thing I have to say about perspectives is that I hate them. Another thing IDEA does not have is a “Team Plugin”. There is no single “Team” abstraction that somehow fits on top of every version control system. Instead, when you enable Subversion then you use Subversion features. Git uses Git Features. Version control systems are enabled using the Tools->Enable Version Control menu item. Then the Alt+9 shortcut brings up the Version Control View.

    Running, Debugging, and the Android Tools

    Running and Debugging an application is slightly different in IDEA than in Eclipse. You manage your “Run Configurations” using your Run/Debug dropdown menu at the top of the screen:

    06. Run/Debug Configurations

    06. Run/Debug Configurations

    You can create temporary and permanent run configurations. Right clicking a test and choosing Run creates a temporary run config. If you want to run the target repeatedly then just save it so it is permanent. And you Maven users: you can right click a goal in the Maven view and create a run target, such as a run:jetty goal. The Maven support is amazing in IDEA, so you are actually lucky to be a Maven user in this case.

    The features of the debuggers are fairly close between the two products. Set a break point by clicking in the gutter (Ctrl+F8), select and right click a reference to add to the watch window. I’ve noticed that Eclipse users love to enable and disable breakpoints rather than just set and remove them. Well, you can press Ctrl+Shift+F8 to manage all your breakpoints if that’s the sort of thing you like to do. Also, notice the Logcat tab on the debugger, which shows you the Android log. If you are Running (and not debugging), then the Logcat output is in the “Android Logcat” view that you see on the bottom toolbar:

    07. Debug Window

    07. Debug Window

    The main Android Tools from the SDK are available under the Tools->Android menu. You can export a signed package this way and also launch the AVD to manage your emulators and environments. If you need the other SDK tools like “hierarchyviewer” or “monkeyrunner” then you’ll have to launch them from the command line. There is built-in Android testing support in IDEA, and when you run a unit test then the IDE will ask you whether to run it as a JUnit test or an Android test. It remembers your answer, so if you make a mistake then just delete the run configuration and start over. It will ask you again.

    Managing Your IDEA Project

    The two hardest parts of switching IDEs is Project configuration and Web Server configuration. Luckily we avoid the latter in an Android tutorial. But you still need to set up the project. First, some terminology. An “Eclipse Workspace” is an “IDEA Project”. An “Eclipse Project” is an “IDEA Module”. An Eclipse Workspace is composed of several projects. An IDEA Project is composed of several modules. If you have Eclipse project files then IDEA should be able to import them with no problems, and this is the fastest way to get started.

    The Project is configured using the File->Project Structure menu item. You can also open the window using the Ctrl+Alt+Shift+S shortcut, which I call the Paw Mash because holding your left hand like a bear paw and mashing the keyboard usually suffices to open the window. This is where you specify your source folders, your SDK version, and your dependencies. If there is no Project SDK selected in the dropdown list, or if the list shows an error, then click on the SDKs item in the left side pane to create a new one.

    08. Project Configuration

    08. Project Configuration

    Configure the modules by clicking the module entry on the left side. Here you can mark certain folders as source or as tests. By default, a fresh IDEA Android project has no “tests” folder, so you should add the folder and then come in here as mark it as Test Sources. You can also change some of the Android compiler settings by clicking the Android facet shown in the middle.

    09. Module Configuration

    09. Module Configuration

    One last thing to configure before leaving the window. If you are writing JUnit tests then you’ll need to add JUnit to your project dependencies. If you just annotate a method as @Test then IDEA prompts you to add the junit.jar to your classpath. The problem is that they add it as the last dependency, which causes the test to fail with the error “java.lang.RuntimeException: Stub!”. Come into this window and move JUnit up in the dependency list. Or configure Ivy/Maven/Whatever to do this automatically for you.

    10. Module Dependencies

    10. Module Dependencies

    That’s the quick tour of Project Structure… lets move on to Settings. Settings are the options not directly related to compiling the project. Things like code style, version control, plugins, and much more. Open Settings using File->Settings or use your Claw Attack to hit Ctrl+Alt+S. I call this shortcut the claw attack because if you pinch your left hand into an eagle claw and swoop it down on your keyboard then the Settings window usually opens right up. It helps to let out a mighty, “Ka-KAW” when you do it.

    There are thousands of settings in here. I heard the advice recently that new users of either IDE should spent a few hours just clicking around the settings page, and I honestly think that is pretty good advice. If you know what you’re looking for but can’t find it, then enter your search term in the upper left side search box and the settings list dynamically displays only those pages with matching entries. For instance, if you know you want to show line numbers, then type in Line or Line Numbers and click through the resulting pages. In this case, the highlighting you see in the image was created by IDEA and is used to point you to the correct setting.

    11. Settings Configuration

    11. Settings Configuration

    You most definitely want to change some of the default settings. Showing Line Numbers is under Editor->Appearance. Changing your tabs and space settings are done on a per-file type basis, and is accessed from Editor -> Code Style. By default IDEA allows you to place the cursor past the end of the line in a text file, and you turn this off under the Editor page. And Version Control is something you really must configure as well, which is under Version Control. GitHub integration in IDEA is tip-top and goes beyond just Git support, but lately I’ve been using and recommending BitBucket for free, private git hosting. In general I find myself using the IDE to make local commits and manage changelists, and the command line to perform pushes.

    Links

    That’s it! There are tons of ways to learn more, and here are my favorite links:

    As always, feel free to keep in touch by leaving a comment. You can read more from me on my blog at http://hamletdarcy.blogspot.com/, see my YouTube channel for more screencasts, and follow me on Twitter: @HamletDRC


    Java 7 Small Language Changes Screencast

    July 14th, 2011

    This screencast demonstrates the small language changes that are part of Open JDK 7, which is available from the Open JDK website. It demonstrates multi-catch, try with resources, strings in switch statements, underscores in literals, and the diamond operator.

    If you have any issues watching the video below, then you may have better luck viewing it on the JetBrains.tv site.

    I’ve made a lot of screencasts and blog posts over the years. If you like this, then there are many ways to see the other stuff I’ve done: 

    The screencast was created with Ubuntu 10.04, PiTiVi, Audicity, gtk-RecordMyDesktop, IntelliJ IDEA, and LibreOffice. OS from top to bottom.

    Thanks for watching, and leave a comment!


    css.php