Android Studio 3.0 Release Notes
developer.android.com
developer.android.com
Once I find a good replacement for jump-to-usage in VSCode I'll probably ditch it for good.
Looks like an IDE to me.
That means "Find Usages", "Jump to Implementors/Overriders", "Show Substypes", etc all work correctly. When you ask for code completion, it's far above what IntelliSense does. IntelliJ will actually understand all of the variables and types that are reachable in scope, as well as those that are reachable by calling methods or accessing fields on those types two or three levels down. This is not the same as just examining what's reachable via 'this' or what's to the left of the '.' character.
https://www.jetbrains.com/help/idea/auto-completing-code.htm...
The autocompletions are also ranked and sorted properly most of the time. Think of it as the difference between a shitty search engine and one that shows the most probable autocompletions first. Even Eclipse IMHO is pretty bad at this, and will often try to suggest meaningless classes somewhere on my classpath that I'm obviously not going to use, including internal sun.* implementations.
IntelliJ's refactoring and code analysis is also far above what XCode and VSC do. I've been using IntelliJ since the first version, and to me XCode and VSC aren't much of a step above Emacs as an IDE.
Syntax Highlighting, VCS integration, Debugger, and Jump to Symbol Definition are table stakes that even basic text editors have.
Better search ranking seems like a feature that could easily be added (though it has to be done for each language).
I'm happy to see competition in this space. The end user might not see it, but IntelliJ internals are pretty horrible from a plugin developer's point of view and haven't improved in many years. Moving language smarts to editor-independent servers (with VS Code's Language Server Protocol) seems like the right architectural move.
Consider that IntelliJ can syntax color and autocomplete multiple language grammars at once, e.g.
String aJavaString = "<someHtml onFoo='someJs.style=\"color: red\"; var regex = new Regex(\"someRegex\");'">
Does VS's language server protocol handle the ability to deal with nested language grammars each with nested contexts?
My issue is false negatives: IntelliJ usually just "works", especially with Java, it's near perfection and almost never gives a wrong completion. I've never encountered another IDE whose code understanding was as complete. Even a 2-3% false completion rate is super annoying.
Plus, the refactoring, structural search, and callstack analysis stuff is beyond reproach. Can VS tell me all possible reaching expressions to a given method? I've used that before to figure out what kinds of subtypes or nullability a given parameter has, but it requires global code understanding.
I feel like the kind of functionality that grok style code indexing provides is just the baseline, and what's important is what's built on top of it. VSC has a long way to go to reach IJ in that regard.
While agree that IntelliJ is pretty great the Android Studio implementation of it is nowhere near perfect. I've had false lints, incorrect flags and a whole class of issues where intellisense goes wrong.
I'll agree that for Java VSCode isn't up to par yet but for many other languages it's easily at an equal level.
Same regarding RAM, I know of companies that a standard developer machine is 8 GB, while everyone else gets 4 GB.
Getting something like 16 GB is unthinkable unless that is a business related change request.
So basically making the life miserable for those developers.
I interned on Chrome in 2013, and at the time all Chrome engineers got a computer with an SSD (which I was told wasn't standard at the time), since they had to build Chrome on their desktops (whereas most other engineers could use Google's distributed build system).
At the time you could see them on stuff but could only apply if on one of the approved teams. Not sure if that's still the case.
The low clock speed of the Xeons (plus NUMA) means that for most things the machine isn't actually that fast, though, unless you can put the all the cores to use.
I don't think I've ever used a machine with more than 32GB.
In many parts of the world having access to a 8 GB and SSD drives is still considered a luxury.
Always better to be more conservative to get a better sense of end user experience.
Obscure build errors, very slow builds, all kinds of device connection failures, gradle wtfs, (un)necessary manual config edits .....
not much has changed :(
I know, the above bug can be circumvented by unchecking "Instant Run"
That's enough for today
OK, just one more:
Error while uploading slice_4.apk : java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String android.os.SystemProperties.native_get(java.lang.String)
Last RC did not even update on Macs.
Are slow builds AS-specific? I think it's more related to the Android build ecosystem and not the IDE.
The migration experience was even worse for those of us using the NDK.
Three reboots for the build system, no migration path until CLion was developed, debugging features only available to Java code,...
Although they have made major improvements, I always ask myself if they had spent all that money improving the Eclipse based IDE, how much better the overall experience would be.
But Android Studio actually managed to break builds on non-US locales because they used String.format using the system locale (which means %02.f renders with a ,)
I've ran this version for going on 3 months now and pretty happy. I've run into some issues with Kotlin builds and preprocessors (can't see the build errors in the Gradle console, have to run a command line build with --debug flag) and every once in a while the emulator and IDE stop talking with each other (ADB needs a reset every so often).
C# + Visual Studio, the build will just work. The fact that editing the MSBuild XML is not really necessary for 90% of developers helps with this a lot.
Your app is structured the same as a native one (Activities, Receivers, Services, Layouts, etc) and the XML for your layouts is identical, but you get to work in C# and don’t have to deal with Gradle etc.
I like it.
But from my (little) experience on it, getting to an app running and start working on it is way mire easy than with the Java approach. Give it a try :)
But overall it's much better. And you get:
Shared models with your web api, reusable business for iOS and Windows, great tools like ReSharper, and so on.
This year: Expo/React-Native and VS Code.
Also, Flutter's install instructions say: "Flutter requires Android Studio to be installed and configured" [2].
The Flutter SDK hides this away nicely, but Gradle runs when you launch a Flutter app during development (on Android).
[1] https://github.com/flutter/flutter/blob/master/packages/flut...
Similarly, if you want to run on iOS you need a Mac with xCode installed.
(It's rather weird to me that you need to install entire other IDE's as developer dependencies to build mobile apps, but that seems to be how it is.)
I don't remember the details, but a couple years ago there was a way to install just the Xcode build tools without installing the entire IDE. I'm sure there's a similar process for the Android SDK. (Though, of course, none of that is officially supported, so you're on your own for the most part.)
Edit: Turns out Google provides downloads for just the SDK without Android Studio[1], so it looks like the separation is unofficial only for Xcode.
First there were SDK and NDK links.
Then there where SDK Tools that autoupdate and downloads the SDK.
Now there is only links to studio, an IDE that contains the auto update tools that downloads the SDK.
But if you want to jump all the hops, you might be able to download just the SDK. For now some old convenient links might still be up.
(On very lean teams that don't have the resources to build bespoke UI for every platform, even with Xamarin or React Native, and the web platform is a good compromise for the simple data collection apps we are building.)
We need to deploy to desktop/mobile/chromebook and we don't have the budget to develop native UI for each one.
The be honest the only problematic platform has been iOS and its crappy UIWebView / WkWebView, and Windows but only because we are using Squirrel for the installs.
The biggest headache for my users is that the app is not added to the start menu, and the .exe is buried in some deep bizarre folder. Maybe there is a way to solve this, but I haven't been able to find it. There is an option to add a shortcut to the desktop, but if the user deletes it then the exe is lost forever.
I've had other bizarre problems for a few users and the only solution was to reinstall the app from scratch. Tech support is not very happy about that.
Maybe it all stems from my Windows ignorance but Electron-builder, one of the most important projects for packaging Electron apps, is moving away from Electron to NSIS. The problem is that AFAIK NSIS doesn't work with Electron updater.
I'm seriously considering moving away from Electron and replacing it with a UWP JS app and distribute it via the Windows Store.
[0]: https://github.com/electron-userland/electron-builder/issues...
My only reason to support an Electron app on Windows is a need to import ancient Access MDB files. I've been meaning to explore deeper the possibility of using the desktop bridge for my Access reader component and call it from the Cordova UWP JS app. It's on my TODO list to explore, but I think just having a single UWP app (with a desktop component that lights up as available) would be the best distribution plan on Windows.
https://github.com/Microsoft/vscode/blob/master/build/gulpfi...
This is for C++ code, which is kind of a special case. Android Studio now has C++ support but I tried it and wasn't impressed. Among other problems, the build process seems to be extremely slow.
in typical Google being evil fashion, using their central authority on Android they now discontinued android sdk and made the sdk a piece of android studio. for no reason other than forcing everyone to beta test their "version 3" (ha) studio. so much so that you now have to download the whole studio, and pick the sdk from within it. there are still some ways to find the sdk directly, but they are going away.
disclosure: I work on the Android Studio team.
Why does flutter tells to download android studio, open it, run the sdk downloader, close it forever and move to another IDE?
A lot of developers were already using kotlin before google announced anything.
As a user of Android and a developer I want something that enhances the user experience of the apps I use and I create, I want the apps to feel and behave as smooth as iOS, the team at Google should focus on that and not on fragmenting the already fragmented community, right now they are solving a problem that doesn't exist.
I wonder if I would ever see 120/240 FPS apps in the future or if I could offload UI work and animations to a different core because you know your 7 cores are sitting idle and you can do nothing about it.
Kotlin is great in that it brings Java 8 features to Java 6(lambda expressions, functional programming, etc.) and more. It's a boon to productivity and makes programming in the Java ecosystem fun again.
There is a sometimes increase in compiling speed but it's very marginal and the method counts increase with the transpiling but it's not noticable until the app get's on the larger side.
Unfortunately those changes do mean a few breaking changes for build.gradle files.
yes, the newish build model is modular, allowing to only compile what needs to. Still not perfect but a huge improvement.
>general smoothness
Just as before, give enough ram to AS. Generally if it is slow it is because it is constantly trashing the memory.
Hmm; I have been running extremely large projects on AS with a good but not out of this world machine.
Compilation times are too slow for my taste (ie even clean should take less than 5 seconds ideally), but the IDE itself is pretty smooth.
Again, the trick is to monitor its memory usage. It is a pity that it's up to the user to configure this, but for large projects I had to allocate more memory to AS and it makes it go from unusable to lag free.
No, no, your English is fine, it's AS that's the problem. :-) I assumed that it was probably a typo of some sort, but I would truly have believed either usage. Though AS has gotten better about not trashing memory.
That said, I agree that with a properly provisioned machine, AS does well. And it's a vast improvement over its predecessor.
So if you were using the timing data previously you were basically just looking at random numbers that would send you on wild chases into things that weren't real. The new one fixes that by not showing bogus data :)
Yes, instrumentation adds overhead. The absolute numbers cannot be used to determine peak performance but that's never the intention when profiling code.
Instrumentation rarely modifies the execution profile to the point that the numbers are 'worthless' or 'random'. My rule of thumb is that self times near the leaves of the callgraph are more accurate than self times further up the graph but having some indication of timing is important.
Furthermore with something like the call chart in AS3 you are often looking for outliers that you can't see when looking at an aggregated view of the profile. A function that has an average of 1000us might be running alternately at 500us and 1500us and you want to see that. It may indicate an unknown performance bottleneck, maybe a call to OpenGL is causing a GPU sync for some reason. It's rare that the instrumentation overhead would dominate major effects like that. Having a number available is important for this as you may be comparing invocations/looking at different parts of the graph at different zoom levels etc. Having a number available is the only solution.
Furthermore, where do you think the instrumented profiler is getting numbers from in the aggregated views? Answer: exactly the same place that the callchart gets it's numbers from. In essence you are saying all instrumented profilers are inaccurate and reporting bogus numbers, demonstrably untrue.
I was only talking about the instrumentation system on Android, not the one anywhere else. It forced ART to fall back to interpreted mode, so no JIT at all, which massively balloons the cost of certain things like single-line getters or JNI calls. It was actually useless as a performance tool of any kind, which is why the recommendation for years has been to ignore the numbers it produced. It's great at answering questions about what a given function ends up doing, but that's it.
If you want low-overhead timelines with duration numbers that actually have meaning that's the job of systrace ( https://developer.android.com/studio/command-line/systrace.h... ).
I didn't know you could install Android on Virtualbox, thanks for the tip!
is it faster than emulator properly configured to use KVM or Haxm with x86 image?
While I'm all for smaller applications, this seems backwards.
Are some portions written in native (c?) code ?
Is that similar to Kotlin's buildSequence/yield/... implemented with coroutines? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.coroutin...
What I like about them both is that you can very often intuit how something is likely to work.
Kotlin + Anko makes Android development much less painful indeed.