
Android Studio 3.2 Beta - el_duderino
https://android-developers.googleblog.com/2018/06/android-studio-3-2-beta.html
======
tabs_masterrace
The whole package this year looks pretty good. A great step towards
modernizing the clusterf*ck that has been Android Development.

JetPack is thoughtful collection of APIs along documentation, essentially
providing solid guidelines on "how to write a modern android app". Good to see
Google embarrassing Single Activity as well as reactive binding/view model
patterns, and providing a standard way to implement it.

Then you have Auto.. I mean ConstraintLayout replacing all the other layouts,
which is a good step forward too.

Android KTX looks good too, although it does seem to be a bit a odds with
Anko? Or maybe not at odds, but looks like it has the same goal as Anko, to
provide syntax sugar for Android Development in Kotlin. Could be interpreted
as a "no" from Google in regards to Anko. As I really like Anko I wish there
was more clear stance of what the future of Anko is.

~~~
izacus
ConstraintLayout is excellent in connection with TransitionManager APIs - so
easy to animate layout changes and data updates now.

------
ge0rg
I wish they would focus on backward compatibility of their IDE instead, every
time I upgrade I need to spend several days on SO to figure out how to work
around the newest breakage. This is from a part-time developer who doesn't
have the time to keep up with the CATD[0] development model of Android's APIs
and UIs.

[0] [https://www.jwz.org/doc/cadt.html](https://www.jwz.org/doc/cadt.html)

~~~
hawkesnest
Reminder, links to JWZ.org from HN will have NSFW results.

------
candiodari
Funny how android studio helps you develop in 1 way : developing non-native
java apps.

The two ways people develop apps seem to be going fully native, or using web
"masks" like react native, outright web directly, or something like apache
cordova. Neither of which seem to be the focus of android studio.

Curious.

~~~
jgaa
May be that is a good thing.

The worst possible IDE in any world + the worst possible build system in any
world = Android Studio.

~~~
w0m
I've been a fan of PyCharm - AS that much worse?

~~~
kyriakos
I dont think AS is the problem. Android SDK + Build System + Emulators are
just not good enough.

If it works the first time you are lucky, if it breaks you are on your own.

~~~
izacus
Anectodally, but most of the breakage around Android build system I see online
and with people I mentor is because they don't actually bother to read the
first thing about how their build system works.

It's like people would use npm without ever reading how the package.json file
is structured... and then complaining how everything is broken because their
copy-pasted internet text broke the build.

~~~
bitmapbrother
This is my experience also. People not fluent with Gradle or just don't want
to invest the necessary time in learning how it works just cut and paste stuff
into it and wonder why it doesn't work anymore.

~~~
vorg
Perhaps a build system shouldn't need people to invest so much time into
learning it. There must be a better way than all those Gradle API's and all
that Groovy syntax.

~~~
izacus
That's a nice sentiment, but you really can't be an engineer in any kind of
software development without having an understanding how your software is put
together. Especially if you want to do things like builds for different
flavors, customize branding or do any kind of changes in the build process.

Some minimal standard of competence and knowledge is required for you to
basically function.

~~~
vorg
I agree. I was talking about the needless complexity of Gradle and Groovy in
handling a build, not the inherent complexity of a build itself. Builds can
easily be described declaratively, as shown by Make and Ant, and this was a
major step forward for the science of build descriptions. Gradle and Groovy,
however, provide a procedural description of builds, with the apparent
intention of generating technical debt in user IT land, and then selling them
consultancy services and courses.

