[HN Gopher] Android Studio 4.2
___________________________________________________________________
Android Studio 4.2
Author : ingve
Score : 36 points
Date : 2021-05-04 19:05 UTC (3 hours ago)
(HTM) web link (android-developers.googleblog.com)
(TXT) w3m dump (android-developers.googleblog.com)
| erdo wrote:
| 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.
| halotrope wrote:
| 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
| taeric wrote:
| It is ridiculous how frustrating this aspect is. The pattern of
| deprecating stuff doesn't help. :(
| blumomo wrote:
| 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.
| kllrnohj wrote:
| 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.
| la_fayette wrote:
| 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.
| nailer wrote:
| Why doesn't it update itself?
| matchbok wrote:
| 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.
| myko wrote:
| 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.
| intergalplan wrote:
| 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."
| PicassoCTs wrote:
| 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.
| intergalplan wrote:
| 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.
| cromwellian wrote:
| 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.
| dmitrybrant wrote:
| 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.
| myko wrote:
| 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.
| dmitrybrant wrote:
| 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.
| javajosh wrote:
| _> "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?
| sa46 wrote:
| 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.
| TrianguloY wrote:
| 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.
| andybak wrote:
| 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)
| mrtksn wrote:
| 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?
|
| Thanks!
| mamcx wrote:
| 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!
| jayd16 wrote:
| 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.
| kitsunesoba wrote:
| 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.
| myko wrote:
| > 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.
| kitsunesoba wrote:
| 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.
| myko wrote:
| 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.
| jayd16 wrote:
| 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.
| gwright wrote:
| 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.
| intergalplan wrote:
| (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.
| kitsunesoba wrote:
| 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.
| intergalplan wrote:
| 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)
| swiley wrote:
| >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._
| intergalplan wrote:
| 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.
| broersa wrote:
| Does it work natively on Apple M1?
| drampelt wrote:
| M1 support was just added in the latest canary version
| https://androidstudio.googleblog.com/2021/04/android-studio-...
| jefft255 wrote:
| 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.
| intergalplan wrote:
| The bigger issue is the Android emulator, which AFAIK still
| only kind-of works on M1.
___________________________________________________________________
(page generated 2021-05-04 23:02 UTC)