Android Studio 3.1 Stable
android-developers.googleblog.com
android-developers.googleblog.com
runs 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)
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.
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.
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.
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.