Android Studio 4.2
android-developers.googleblog.com
android-developers.googleblog.com
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.
It's trivial to add Compose to mature apps, you don't need to convert the entire app immediately.
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.
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?
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.
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?
Thanks!
You can have your own opinions about Android vs iOS dev but IMO the Android Studio is less confusing and frustrating than xcode.
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.
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.
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.
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.
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 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.
[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.
- 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!
This is probably a startup idea, btw.
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.
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?)
And yet IntelliJ is at 2021.1. Does Android Studio always lag the IntelliJ releases like that?
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.
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” :(
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.
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.
Knowing Google it’d take more than months to fix their shit.