Hacker News new | past | comments | ask | show | jobs | submit login
Android Studio 4.2 (googleblog.com)
43 points by ingve 10 days ago | hide | past | favorite | 51 comments

Open Android Studio once a week and it will each time ask you to install something new. I am not against progress and small, iterative updates. That's what agile promises us and that's how we get quick feedback from customers, especially when building an MVP. But Android and Android Studio should become mature products at some point in time. Given they are constantly changing Android APIs and requiring multiple layers of compatibility classes, Android Studio will continue to remain a powerful teenager in its puberty still for a long while.

Are you confusing AndroidX & gradle updates with Android or Android Studio updates? Android & Android Studio, the core platform, doesn't update very often at all.

Gradle does update regularly, as does AndroidX, and a typical Android app will usually have half a dozen dependencies all on their own update schedule. Plus the build tools & emulator get regular updates. All in all there's probably a dozen different individual components.

But none of this is the result of "immaturity" nor does it make any sense to create a big huge monolithic update schedule.

Android studio has a couple of minor or patch updates per month (https://androidstudio.googleblog.com). Every now and then when you open the IDE you are asked to update. Every Android developer knows that, it is almost a meme.

Why doesn’t it update itself?

Ha, I wish. 10 years, and Android still doesn't have a good way to accomplish navigation, view models, state retention, or anything. 10 different support libraries, everything deprecated once a year, etc. The entire platform is a mess.

I haven't done Android dev in a few years, but last time I did the best advice a new dev could get was, "ignore any best-practice or how-to element of Google's Android docs. Ignore the old, official way of doing [thing]. Definitely ignore the new, official way of doing [thing]. Instead, use Square's Android libraries, read their blog posts, and do exactly what they do."

Sounds like a very Open-Source approach. Ignore the documentation, ignore the tutorials, grab the Repo of a working project close to what you want and read the code, until you can modify it.

Kinda, but Square actually had an alternative way of managing UI flow, enabled by a couple libraries they wrote, and a bunch of other support libraries for basic stuff like making HTTP requests, all of which was so much saner than Google's standard way(s) of doing things. You'd end up writing Square/Android, in the sense of GNU/Linux, if that makes sense. Why Square, of all places, straight-up killed it on that particular platform, I have no idea (no shade intended to folks at Square, it's just unexpected situation). It's not like they just had a really good project template or something.

> but Square actually had an alternative way of managing UI flow

Are you talking about Flow/Mortar? Those were pretty much abandoned and were, imo, overly complex.

That said, the Android UI flow was pretty bad before. Hopefully Compose makes it better.

IIRC Square had a technical manager (maybe CTO level?) who came from Android at Google, which may have helped. Square also open sourced early iOS tools like PonyDebugger which were ahead of the game when they came out. When they hired Jake Wharton they got a stellar champion of open source software creation whose focus was Android.

This has pretty much stopped a few years ago, most of the community has now standardized on AndroidX set of Google helper libraries for UI, UI state management, on-device storage and async code.

Jetpack Compose subsumes many of those and in a very elegant, coherent way, much like Swift UI, but IMHO better because it's based on pure composable functions.

All well and good, but only if you're just starting to build your app literally today. If your app was built more than ~6 months before the current iteration of Jetpack/AndroidX/etc, you'll never finish catching up with converting your code to the latest new patterns that they introduce.

We regularly update our apps when these libraries update, even for projects 5+ years old. You don't need to switch to the latest "architecture" all the time.

It's trivial to add Compose to mature apps, you don't need to convert the entire app immediately.

Well sure, thankfully all these myriad ways of doing the same thing coexist without much issues, since they're all just wrappers around findViewById(). But I just wish they'd settle on a pattern that will endure for more than a single major version of the library.

That’s the problem. Once you’ve started adding Compose to your app and are finally midway through it there will this new shiny toy and the entire herd will be playing with it. Then what? Finish compose or leave it there and start with the new toy?

While there’s always a fundamental way of doing it - you just need the damn view! But no! To avoid even writing exactly 3-4 lines of findViewById per class on an average someone decided it’s revolutionary to add Butter Knife to the project and so on.. Or maybe there’s some one who gets kicks from seeing so many annotations in the classes!

Android ecosystem is really plagued by this fad culture imho.

PS. Nothing could make me an iPhone user. But finally being an Android developer did that! Really that’s the reason.

I seriously don't understand this reasoning - why do you need to follow the herd?

Even on iPhone you're so happily plugging away here - we're still using ObjC with their views instead of new SwiftUI hotness because it still makes sense there. What makes you run after every single shiny thing for no reason? Who's paying for all that developer time?

iOS has similar issues but the tools are much worse and backporting is nigh impossible.

Android dev is doing pretty well from my perspective - Compose works on Android versions years old while SwiftUI barely functions on iOS 13 and does not work on iOS 12.

How does the Android Studio compares with Xcode?

On Xcode, it comes with SwiftUI and UIKit libraries for interface building. Does Android Studio comes with a standart UI library? Does it support design tools to help you with building the IU through these libraries or is it code-first?

How straightforward is the environment setup? On Xcode, building your first app is as complicated as creating your first CV on Microsoft Word. i.e, click new, choose a template and build from there or deep dive from scratch if you know what you are doing. Click run and in runs in the simulator, if you put your developer account you can run it on the real iDevice. Pretty hassle-free. Did Android Studio achieve similar level of hassle-free development?

Xcode comes with some asset management tools where you can build libraries of images, colours etc. that will automatically adapt to things like device color theme, language or size(In your code, you refer to a resource in the asset manager and the correct asset is used depending to the parameters you set there). What is the situation with Android Studio?

On Xcode, the default language is Swift and comes with all kind of other libraries that are targeting the latest iOS/MacOS releases. What is the state of art for Android development in therms of the language and OS support? Is everyone building on the native libraries that Google provides using Kotlin?

iDevice simulators run with acceptable performance even on 5 years old Macbook Air. Last time I tried a to run the "hello world" app through Android Studio many years ago on the simulator, the performance was miserable. Is the performance at acceptable levels now?


Android Studio deliver the full experience of android development!:

- Is slow

- It have a slower emulator

- But, not as slow as it UI builder! Being so useless you learn to do things with code instead!

- And also 2 different ways to do gradle builds, now with Kotlin!

- It have gradle, the #1 build manager! (when you do sorted().reversed())

- Is the same experience you have know for years! But with more and more features! That you hope will work for real this time!

It have a nice icon!

And the mysterious gradle/build errors that you keep looking at for hours trying to understand why in the name of mother nature the tool will not tell you what exactly went wrong in 2021 and then finally cluelessly trying different suggestions from clueless people on SO and you’re lucky if one of them works. Then you go home hoping everything works and swearing you’ll fix the gradle dependency nightmare your app has and then letting a helpless sigh that no it’s not your app’s fault.

Honestly, I think the biggest thing google(or who?) could for for android is put gradle in the rear mirror and do(or use? which?) a cargo-like build manager instead...

This is probably a startup idea, btw.

Android Studio is way nicer. It has all the same WYSIWYG features with the added support of a polished Java IDE at its core. There's much less signing, archiving, provisioning madness to deal with and there are no magic "fix this?" buttons that need to be found and pressed.

You can have your own opinions about Android vs iOS dev but IMO the Android Studio is less confusing and frustrating than xcode.

Very YMMV in my experience.

Coming from an iOS codebase that had eschewed XIBs and storyboards entirely in favor of pure code views, I was disappointed to find that it's very difficult to write pure code UIs with Android Framework. Everything is geared toward XML layouts with many things being impossible or impractical to access from Java/Kotlin, which is extremely frustrating.

And in place of code signing troubles, Android brings new challenges with things dependency management and ProGuard silently snipping out big pieces of required code if you don't tell it exactly what to do.

> Everything is geared toward XML layouts with many things being impossible or impractical to access from Java/Kotlin, which is extremely frustrating.

Compose has been available for awhile now and the views are done in code (and is much more functional than SwiftUI - it even gets bug fixes and works on older versions of Android)

> Android brings new challenges with things dependency management and ProGuard silently snipping out big pieces of required code if you don't tell it exactly what to do.

iOS has similar problems, eg mixing SPM with Carthage or Cocoapods, having to strip symbols from fat frameworks, libraries that don't ship xcframeworks or do but don't support the arch you need, bitcode, etc.

Compose is nice, but as noted elsewhere in the comments it's not of much help unless you're starting a new project. It won't be worth it to rewrite existing views for a few more years at minimum.

Re: dependencies, take-up of SwiftPM has been lightning fast and a lot of projects can move to it already. It still has a few rough edges but for my use case it's a massive improvement over Cocoapods/Carthage as is.

We've been integrating Compose into older projects without many issues at all. What have you run into?

Re: SPM - it is a huge improvement! But it has some issues (behaves differently on the CLI vs Xcode, Xcode support is basic and lacks control) and not every dependency has moved to it yet, especially proprietary SDKs. Combining it with Carthage/Cocoapods is a pain - worse than dealing with ProGuard imo.

Again, I think these fall under Android vs iOS and not Android Studio vs Xcode. Although it does get fuzzy when Xcode is the only way to do something in the iOS stack.

> How does the Android Studio compares with Xcode?

Android Studio is a massively better IDE (being based on IntelliJ) with significantly better code inspection, refactoring and linting tooling.

Android itself has a better build system, being based on (kinda) industry standard Gradle which can be more easily automated and plugged into a CI. Doing automation based on Xcode is pure hell. It also has a better dependency management system with scriptable and pluggable components which you can use to improve you build.

Xcode is also seriously behind on testing with seriously buggy and problematic test runners which also love to fail with random code signing dialogs on CI nodes.

Where Android Studio lags behind is in performance (Gradle tends to be a dog) and the emulator (which is still slower than iOS Simulator, but more correct in its functionality). It can also be more buggy (especially when it comes to using tools like profilers) and can lag QoL features (like a good clickety click UI designer).

In general, for larger projects run by companies, Android Studio has been a better experience than Xcode. For pure beginners, Xcode is more friendly until you hit the wall of trying to automate things.

There are lots of different ways to compare these tools, but code navigation and refactoring support is way better in Android Studio than Xcode, IMHO.

(Information somewhat out-of-date, especially on the Android side)

Android's official libraries are often weirdly bad and seemingly incomplete. You'll do a lot of DIY and work-around and looking incredulously at 8-year-old bug reports to which someone submitted a damn patch to fix the bug two years ago, yet they're still sitting open with the last "me too" comment three weeks ago and a bunch of folks begging Google to apply the patch. True story, seen more than once, and you'd be surprised how non-obscure the developer facing functionality has to be when you start running into those.

Once I had to resort to meta programming to change (IIRC) a color of part of a stock Material Design input field, as the implementation had been half-assed by the Android team's interns, is all I can figure. Changing your typeface app-wide used to require (again, IIRC) modifying every single view-related class, or else importing a 3rd-party library (which library existed because obviously that's an insane design). There existed a 3rd party library to shim in the Javascript maps API, because the official Java Google Maps library on Google's own damn OS could only provide an address as one string, not broken up into house number and street and such, while the Javascript one could provide the address elements separately (you can tell where their real priorities are).

Lots of Google's advice about how to handle UI flows or data in one's app is just bad and will make your app brittle while wasting your time, compared to alternatives people who aren't developing the damn thing as their full-time job have come up with.

This was all like 3-4 years ago, not back in the stone ages of 2.x/3.x, or even 4 or 5. 2.x/3.x was a special hell that I wouldn't wish on anyone.

All of the above is relevant to stuff like UI building in Android studio, or your question about whether everyone uses native libs or what have you (you shouldn't, even for basic stuff like HTTP communication, at least as of 3-4 years ago, if you value your time and sanity). If you're not doing something very simple with stock styles, you'll hit some pain, and even then you might. Not insurmountable, obviously, but it's there.

As for AS itself, it's about as heavy as Xcode on system resources. Emulator used to be so slow it was useless, but it's somewhat better now. Still wouldn't develop for Android without an Android device with me 100% of the time, unlike iOS, but they have made big improvements. It probably doesn't crash as much as Xcode. Both are full of arcane bullshit in their interface to keep builds happy, and I actually think Xcode might be a little ahead of AS now that most provisioning difficulties can be auto-fixed. They do have a WYSIWG UI builder but I vaguely recall it being net-harmful last time I tried it, though not completely terrible. Probably useful for some apps. Otherwise it's an IDE and does normal IDE stuff. One "fun" part is that you manage a bunch of Android platform deps through the IDE, separately from AS itself—or you figure out how to do it from the command line while still making the IDE happy, for better repeatability, onboarding, and sanity.

This maps pretty closely to my own experiences with android development. So many seemingly basic tasks that would've been a breeze in Cocoa Touch under iOS 6, probably even without third party libraries, are weirdly difficult with modern day Android Framework.

Developing for Android definitely made me a lot more understanding of quirks and brokenness in apps on my personal Android phones (developing for Android and iOS, and so being exposed to many examples of both kinds of devices, ended up converting me to being an iOS user anyway, though)

>8-year-old bug reports to which someone submitted a damn patch to fix the bug two years ago, yet they're still sitting open with the last "me too" comment three weeks ago and a bunch of folks begging Google to apply the patch.

This isn't only something developers dealt with, there were user facing bugs like this.

I'm so glad we're finally getting real Linux phones because Android was awfull.

I liked the ones that had been auto-closed then manually re-opened like 5 times because it'd survived that many major versions. Entirely not kidding about more than once seeing that someone had pasted a patch file for like a 1-2 line fix in the bug thread and been begging Google to look at it for years.

[EDIT] To Google's credit, it was possible to write a patch for their OS, unlike iOS. Working against them is the fact that they don't seem to give a damn, so it hardly matters.

I recently had to do a quick proof of concept in Android. To my very surprise there does not seem any „right“ way to do anything. Especially overlapping and competing concepts everywhere. „Activitiy“ vs „Fragment“, Camera, camera2, camerax, kotlon, java, rxjava… The official android architecture repo illustrates this perfectly. https://github.com/android/architecture-samples

It is ridiculous how frustrating this aspect is. The pattern of deprecating stuff doesn't help. :(

There's no "right way" of doing things on the web either - but there's plenty of ways to choose that fit your organization and the way you work.

Why is that a problem? That is - why do you need Google to tell you how to do your job well?

(You also listed a bunch of orthogonal concepts and even 3rd party libraries. Are you seriously criticising the ecosystem for having good 3rd party libraries?)

> "Android Studio 4.2 includes all the major features and updates found in IntelliJ IDEA Community Edition 2020.2"

And yet IntelliJ is at 2021.1. Does Android Studio always lag the IntelliJ releases like that?

Might be a similar situation to the IntelliJ Bazel extension by Google which is consistently 6-12 months behind the latest release. That extension just jumped to 2020.2 as well.

My guess is that the lag is a consequence of the single version policy in the monorepo. Meaning, you need to upgrade all dependencies on IntelliJ without breaking Google engineer workflows.

Every single release of this abomination makes me hate it more and more.

So much that I stopped being excited about it.

And every Android SDK/OS release changes everything in your face. I think there are people at Google who need something to do so they go around changing APIs for the kicks and because they can.

Then there are “the followers” in the Android developer world who would amplify every new fad and follow it like an excellent herd.

Unfortunately transitioning to backend seems quite difficult. Design, whiteboard rounds all go well, “but you don’t know about that backend specific library” :(

An empty hello world project (a simple TextView with a string resource) created from the new project dialog still creates an apk of more that 1MB size. And 99.99% (more or less) of all the data inside are unnecessary Google libraries and assets.

Isn't that badly configured defaults rather than a reflection on anything significant (i'm not saying there aren't real issues - just that "size of the default project" might not be a good heuristic)

Quite impressed with the level of scepticism and experience of the android devs on hacker news.

In my experience it's not the norm - the android world seems to have more than it's fair share of cool juice drinking newbies that hang on Google's every word (with disastrous results). Present colleagues accepted of course. Ahem.

I haven't done Android development in years, but I do use IntelliJ Idea Ultimate edition for a bunch of Java and Kotlin stuff.

If I want to do Android stuff, is there any reason to use Android Studio in favour of IDEA? It seems AS is based off of an older version of IDEA, so why not use use IDEA?

> If I want to do Android stuff, is there any reason to use Android Studio in favour of IDEA? It seems AS is based off of an older version of IDEA, so why not use use IDEA?

Mostly because IDEA is far behind on Android features and it takes awhile for it to merge in Google patches. You'll have issues with most cutting edge support like UI editors, Compose, new Gradle features, etc.

Does it work natively on Apple M1?

M1 support was just added in the latest canary version https://androidstudio.googleblog.com/2021/04/android-studio-...

It's based on IntelliJ IDEA Community Edition 2020.2, and M1 support was released only for the very recent version of IntelliJ. So my sort-of educated guess is that no it doesn't.

The bigger issue is the Android emulator, which AFAIK still only kind-of works on M1.

Please don’t use that. I am in the process of returning my M1 and asking for a 32GB previous Pro model from my IT team.

Knowing Google it’d take more than months to fix their shit.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact