5 ms·

The only feature that really excites me is the Gradle support. Things like the 9patch editor seem horribly misplaced (you probably don't want your devs to be ed

by swanson 13y ago

The only feature that really excites me is the Gradle support. Things like the 9patch editor seem horribly misplaced (you probably don't want your devs to be editing those...) and others seem so situational (the autocompleting sdk version - a one line config value that you set once per project). Android Studio is not really usable as an IDE if you want to have a fully featured test suite because of the weird, half-implemented Gradle "auto-sync" magic (http://www.sep.com/sep-blog/2013/10/17/android-studio-not-ready-for-primetime/ http://www.sep.com/sep-blog/2013/10/17/android-studio-not-re...). Until then, it's still good ole' reliable Eclipse (I can't believe I just said that). Until a different IDE can support Robolectric and Robotium/Instrumentation tests in the same projct that can be run/debugged inside the tool and report results in a window (command line and html test reports don't count, sorry), I won't be switching.

lnanek2 13y ago
Weird, I know we have Robotium and Robolectric working fine in Android Studio at work. Although some versions do require a separate project, most versions are just sub-projects under a main folder with a shared build.gradle now. Not than any of us want to use it. You are just forced to if you want to use the latest features like AARs with Gradle. Eclipse is unfortunately obsolete and incapable of handling the latest stuff, even though we all used it for years and prefer it.
- swanson 13y ago
  Last I checked (October) I could not get the build.gradle to play nicely. Most of the other material online involved using instrumentCompile to trick Android Studio into running your unit tests and a custom runner/plugin: https://github.com/JakeWharton/gradle-android-test-plugin https://github.com/JakeWharton/gradle-android-test-plugin If you have gotten it working in Android Studio, I'd be very keen to see how (if you are willing to share).
  - ch0wn 13y ago
    I'd also be very interested in learning how to set up Android Studio to run Robolectric. Especially sinceone of the last releases removed the option to mark custom directories as test folders, so tat I now can't even use any Java features in the editor.
  - harpb 13y ago
    I followed: http://www.peterfriese.de/android-testing-with-robolectric/ http://www.peterfriese.de/android-testing-with-robolectric/ I can't get it to run a specific (gives junit 3.8+ required error), but am able to run the whole suit.
bestdayever 13y ago
Like maybe idea 13? That's how we do it at least.
- swanson 13y ago
  If IDEA 13 supports that, then great! Would love to see a blog post describing your setup.
fredgrott 13y ago
You probably know this already..if you hack up the build.gradle file you can get full android gradle builds in Eclipse, even testing and yes both ways..using regular android TDD with new espresso and Robolectric/Robotium. Yeah some blog posts are coming soon
paperwork 13y ago
I'm curious to know what you like about gradle. A few months ago I had a chance to work with gradle and it looked to me like it was a step away from declarative project descriptions, back to writing loops to iterate through files, etc. Possibly I was using it wrong, but I've heard great things about it and perhaps my expectations were just too high.
- zmmmmm 13y ago
  > a step away from declarative project descriptions Exactly why I like it. The delusion that build scripts are 100% declarative is one of those things that makes me hate tools like Ant etc. with a passion. Parts of build scripts can be declarative, but the ability to break out and put imperative logic in some section where you need it is crucial. And the nice thing about Groovy (which Gradle is based on) is that you can usually do it in a very declarative way (eg: files*.delete() rather than looping, etc.)
  - spullara 13y ago
    When you run into the cases it is much better to write a plugin than to put imperative code into your build. Gradle builds are IMHO a huge step backwards for others trying to use someone else's build.
    - zmmmmm 13y ago
      Really? You think someone will find it easier to go look at the source for my plugin rather than just a line of imperative code in my build script? I would agree it easily gets out of control, but I really don't think I would rather have to find and understand a whole plugin just to grok a one off piece of logic needed in the middle of a build script.
      - spullara 13y ago
        Generally, the imperative code isn't as flexible in different environments. For instance, if you look at the Gradle file for Gradle you'll find tons of stuff very specific to their actual computers they use to do the build. That is the opposite of what I want in a build file intended for third parties or even for medium teams.
barbs 13y ago
> Things like the 9patch editor seem horribly misplaced (you probably don't want your devs to be editing those...) Um, what? I can think of plenty of times when I've needed to edit 9patches myself. Mind you, most of those times were when I was working in a startup, and we didn't have a dedicated UI/UX person, but this feature would still be incredibly handy.

by swanson 13y ago

lnanek2 13y ago

Weird, I know we have Robotium and Robolectric working fine in Android Studio at work. Although some versions do require a separate project, most versions are just sub-projects under a main folder with a shared build.gradle now. Not than any of us want to use it. You are just forced to if you want to use the latest features like AARs with Gradle. Eclipse is unfortunately obsolete and incapable of handling the latest stuff, even though we all used it for years and prefer it.

swanson 13y ago
Last I checked (October) I could not get the build.gradle to play nicely. Most of the other material online involved using instrumentCompile to trick Android Studio into running your unit tests and a custom runner/plugin: https://github.com/JakeWharton/gradle-android-test-plugin https://github.com/JakeWharton/gradle-android-test-plugin If you have gotten it working in Android Studio, I'd be very keen to see how (if you are willing to share).
- ch0wn 13y ago
  I'd also be very interested in learning how to set up Android Studio to run Robolectric. Especially sinceone of the last releases removed the option to mark custom directories as test folders, so tat I now can't even use any Java features in the editor.
- harpb 13y ago
  I followed: http://www.peterfriese.de/android-testing-with-robolectric/ http://www.peterfriese.de/android-testing-with-robolectric/ I can't get it to run a specific (gives junit 3.8+ required error), but am able to run the whole suit.

bestdayever 13y ago

Like maybe idea 13? That's how we do it at least.

swanson 13y ago
If IDEA 13 supports that, then great! Would love to see a blog post describing your setup.

fredgrott 13y ago

You probably know this already..if you hack up the build.gradle file you can get full android gradle builds in Eclipse, even testing and yes both ways..using regular android TDD with new espresso and Robolectric/Robotium. Yeah some blog posts are coming soon

paperwork 13y ago

I'm curious to know what you like about gradle. A few months ago I had a chance to work with gradle and it looked to me like it was a step away from declarative project descriptions, back to writing loops to iterate through files, etc. Possibly I was using it wrong, but I've heard great things about it and perhaps my expectations were just too high.

zmmmmm 13y ago
> a step away from declarative project descriptions Exactly why I like it. The delusion that build scripts are 100% declarative is one of those things that makes me hate tools like Ant etc. with a passion. Parts of build scripts can be declarative, but the ability to break out and put imperative logic in some section where you need it is crucial. And the nice thing about Groovy (which Gradle is based on) is that you can usually do it in a very declarative way (eg: files*.delete() rather than looping, etc.)
- spullara 13y ago
  When you run into the cases it is much better to write a plugin than to put imperative code into your build. Gradle builds are IMHO a huge step backwards for others trying to use someone else's build.
  - zmmmmm 13y ago
    Really? You think someone will find it easier to go look at the source for my plugin rather than just a line of imperative code in my build script? I would agree it easily gets out of control, but I really don't think I would rather have to find and understand a whole plugin just to grok a one off piece of logic needed in the middle of a build script.
    - spullara 13y ago
      Generally, the imperative code isn't as flexible in different environments. For instance, if you look at the Gradle file for Gradle you'll find tons of stuff very specific to their actual computers they use to do the build. That is the opposite of what I want in a build file intended for third parties or even for medium teams.

barbs 13y ago

> Things like the 9patch editor seem horribly misplaced (you probably don't want your devs to be editing those...) Um, what? I can think of plenty of times when I've needed to edit 9patches myself. Mind you, most of those times were when I was working in a startup, and we didn't have a dedicated UI/UX person, but this feature would still be incredibly handy.