Android Studio, and in turn, Jetbrain's IDE are an absolute godsend for productivity. Quick actions, macros, shortcut egornomics, etc. are top notch and make me a happy developer. I would even dare to say, it's a better IDE than Visual Studio.
Could you elaborate? VS Code is faster/leaner than WebStorm, that's for sure, but are there any specific workflows that you feel VSCode is better than WS?
I found WebStorm a bit overwhelming when I first tried it (I was fairly new at the time), which made any workflow a little difficult for me out of the gate.
That, and I remember Staples of the JS ecosystem (eg ESLint) being somewhat difficult to set up. Maybe they were simple if one knew the Jetbrain workflows, but for me, esp. compared to VS Code, it seemed a huge undertaking just to get ESLint to work.
Actually, here's an SO question I posted awhile back about ESLint in WebStorm (well, intelliJ). This was shortly before I made the switch to Code.
> But lately I've been using Datagrip for SQL stuff,and geez, did Jetbrain crush the competition w/ this product.
For me, "the competition" is the MySQL CLI. Is there and advantage to Datagrip assuming that one is reasonably proficient in SQL (at least the MySQL dialect)? Serious question. After running \# I've got table and field completion, and all the readline (pseudo-emacs) shortcuts work.
Almost every release of Android Studio has succeeded in breaking every single Android app I wrote. I have always had to cut and paste every class, resource, layout, one by one into a new project in order to get it to compile. I always fear pressing the "update" button.
What kind of ridiculous project structure do you have? I have never in my ~5 or so years of using Android Studio have had to do something as drastic as that.
I have occasionally have had issues with updating, but this has required a tweak in the gradle file and an update of build tools, at most.
My experience (full-time Android dev) falls somewhat in the middle.
This sort of compatibility breaking was fairly common back in the AS 1.X/early 2.X days. As of now, it's really rare, and usually resolves automatically.
> What kind of ridiculous project structure do you have?
Obviously one that was supported in every preceding version of Android Studio. When making consumer-facing tools, it is the job of the tool maker to make sure that it doesn't break.
If something works in a version, and breaks in another, guess who is to be blamed? (hint: not the user)
Let's see, I just upgraded to Android Studio 3.1, opened one of my previous ridiculously simple apps, and voila:
Could not find com.android.tools.build:gradle:3.0.1.
Searched in the following locations:
https://jcenter.bintray.com/com/android/tools/build/gradle/3.0.1/gradle-3.0.1.pom
https://jcenter.bintray.com/com/android/tools/build/gradle/3.0.1/gradle-3.0.1.jar
Required by:
project :
Add Google Maven repository and sync project
Open File
Okay, I hit the "Add Google Maven repository and sync project", and now we have:
Could not GET 'https://jcenter.bintray.com/org/ow2/asm/asm/5.1/asm-5.1.pom'. Received status code 502 from server: Bad Gateway
Enable Gradle 'offline mode' and sync project
I don't know what the hell any of this means -- I'm not a Java/Gradle/etc. person at all, just forced to use this pile of mess for Android -- so I cluelessly hit "Enable Gradle 'offline mode' and sync project" hoping it will resolve the error, and now:
No cached version of org.ow2.asm:asm:5.1 available for offline mode.
Disable Gradle 'offline mode' and sync project
Created a new project and it compiled successfully. Cut-and-paste classes, here we come!
On another note, creating a blank Android app results in nothing short of 87 files. Does it really have to be this complicated? Do we really have to use this gradle nonsense? (90%+ of the errors I get hen upgrading Android Studio say something about gradle). Most frameworks on other platforms are simple and elegant enough that it is possible to memorize the minimal "hello world" example and implement it with vim, and the IDE is just there for convenience, not out of necessity.
Okay. That's almost crazy. In my almost 3 years of maintaining our app that was originally written in Eclipse, we never had to face any single issues like this. There were some minor issues but never like this. It makes me wonder if the your project structure or the way project is written is crappy.
Well, the rule of thumb is that if you need stability, never upgrade on the first day of release but rather wait for 1 week or two. I personally have faced and upgraded my apps through many of these upgrades and there was rarely an earth-shattering issue that I was not able to solve. YMMV.
Well, yes, it always happens to someone - I mean, every upgrade will break some stuff for some devs. After all, the userbase of Android Studio is quite sizeable.
What I find hard to believe is that these problems would hit the same bunch of people every time, and on the top of it, affecting every project they work on. Come on.
And this is what dheera claimed ("almost every release of Android Studio has succeeded in breaking every single Android app"). If it's really so extreme, I'd say that he - or she - is not unlikely to be alone, or close to that.
The crazy part is, while I have the same issues with every release of Android Studio – the same project in IDEA works just fine, without any trouble, ever.
In fact, JetBrains quality and reliability has been much higher than the piece of shit IDE Google has been producing.
I imagine Android Studio will switch to Bazel sometime in the near future. Every other non-Android Java shop seems to be rewriting their Gradle build files as Bazel configs nowadays. Gradle and Apache Groovy just don't scale.
Android Studio has such a fat ass. Every release it, and gradle, want more memory to do the same thing. I'm hoping that the tools devs improve or review the resource usage of the gradle plugin, etc. VS Code and the flutter tooling are svelte in comparison.
Seriously. I've gone back to vim completely (from my previous mix of Studio and vim). Browser tabs and gradle, alone, max out my laptop's 8gb ram. If I were to throw Studio into the mix, I'd have to close Firefox!
The official documentation is worse - everything seems to be a mess of contradictions and constantly changing ways of doing things, with the documentation never catching up.
Yes it's a dirty world overall, but Android Studio - all its issues notwithstanding - is a great improvement over Eclipse regardless, and an awesome IDE. At least in terms of software design as such.
I hope the memory enhancements show considerable improvements. I've seen people with >32 GB memory complaining that AS eating enough RAM to affect productivity.
Tip: If you have dual GPU system try launching AS, android emulator, Idea, WS, Pycharm, with the discrete GPU i.e (Linux/ATI in my case).
I have seen considerable improvements in productivity for the same codebase with 3rd gen corei5 with ATI 7400M series GPU vs 7th gen corei5 with intel integrated gpu both having same memory. The OS setup is same.
Obviously, java by itself isn't using the VRAM; I assume the visual rendering of IDE's & emulators use it and leaves enough RAM for the AS to gulp.
I've found that giving IntelliJ (or Android Studio) too much memory can actually backfire. The Java process ends up using all the memory you give it, but this also results in long GC pauses past a certain point. If you're curious, turn on the memory inidicator in the app with Settings -> Appearance -> Appearance -> Show memory indicator. I've found 2gb - 4gb to be the sweet spot depending on project size.
I am surprised Google have not acquired JetBrains by now. Android Studio being based on their IntelliJ platform and Kotlin getting first class support in Android is investing a hell of a lot in a relatively small foreign company. Kinda strange as Google have acquired larger companies for less (less reliance not value).
If I trust any company with JetBrains it would be Microsoft. But they already have top notch products...I'm using PyCharm and Visual Studio Code side by side now and it's like VSC has like 10% of the menu options yet does everything I want it to do. Something like macOS versus Windows in terms of simplicity vs features.
I’m an iPhone and Mac user. Can’t say I gave the Android emulator a good chance for me to like it. But just a couple of tries had me reaching for the Samsung J30 I picked up for on-device debugging. The emulator was pretty slow is why. Sounds like they worked on that for 3.1 though.
42 comments
[ 11.1 ms ] story [ 2570 ms ] threadruns for cover
But lately I've been using Datagrip for SQL stuff,and geez, did Jetbrain crush the competition w/ this product.
...once I switched the shortcuts to match VS Code's, that is
That, and I remember Staples of the JS ecosystem (eg ESLint) being somewhat difficult to set up. Maybe they were simple if one knew the Jetbrain workflows, but for me, esp. compared to VS Code, it seemed a huge undertaking just to get ESLint to work.
Actually, here's an SO question I posted awhile back about ESLint in WebStorm (well, intelliJ). This was shortly before I made the switch to Code.
https://stackoverflow.com/questions/34700062/intellij-plugin...
For me, "the competition" is the MySQL CLI. Is there and advantage to Datagrip assuming that one is reasonably proficient in SQL (at least the MySQL dialect)? Serious question. After running \# I've got table and field completion, and all the readline (pseudo-emacs) shortcuts work.
If anyone uses Resharper, I highly recommend trying Rider.
I have occasionally have had issues with updating, but this has required a tweak in the gradle file and an update of build tools, at most.
This sort of compatibility breaking was fairly common back in the AS 1.X/early 2.X days. As of now, it's really rare, and usually resolves automatically.
Obviously one that was supported in every preceding version of Android Studio. When making consumer-facing tools, it is the job of the tool maker to make sure that it doesn't break.
If something works in a version, and breaks in another, guess who is to be blamed? (hint: not the user)
On another note, creating a blank Android app results in nothing short of 87 files. Does it really have to be this complicated? Do we really have to use this gradle nonsense? (90%+ of the errors I get hen upgrading Android Studio say something about gradle). Most frameworks on other platforms are simple and elegant enough that it is possible to memorize the minimal "hello world" example and implement it with vim, and the IDE is just there for convenience, not out of necessity.
The dheera is not alone.
What I find hard to believe is that these problems would hit the same bunch of people every time, and on the top of it, affecting every project they work on. Come on.
And this is what dheera claimed ("almost every release of Android Studio has succeeded in breaking every single Android app"). If it's really so extreme, I'd say that he - or she - is not unlikely to be alone, or close to that.
In fact, JetBrains quality and reliability has been much higher than the piece of shit IDE Google has been producing.
Android Studio's performance made me loose interess on JetBrain products.
Xeon class CPU, SSD and at least 16 GB RAM should be written on the box.
It's even using less memory than chrome lately.
and with it, type hints.
This should be very useful in kotlin with rx. map calls are often hard to follow without explicitly writing types.
This sounds like the best of both worlds.
Tip: If you have dual GPU system try launching AS, android emulator, Idea, WS, Pycharm, with the discrete GPU i.e (Linux/ATI in my case).
'DRI_PRIME=1 ../studio.sh'
bash -c "LD_PRELOAD='/usr/lib/libstdc++.so.6' DRI_PRIME=1 ../android-sdk/emulator/emulator -avd Nexus_5X_API_27 -gpu host"
I have seen considerable improvements in productivity for the same codebase with 3rd gen corei5 with ATI 7400M series GPU vs 7th gen corei5 with intel integrated gpu both having same memory. The OS setup is same.
Obviously, java by itself isn't using the VRAM; I assume the visual rendering of IDE's & emulators use it and leaves enough RAM for the AS to gulp.