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.
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.
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.
>Neither of which seem to be the focus of android studio.
I think the decision is a layer below "Android Studio" -- or -- it depends on how you slice & dice what Android Studio is.
If you look at the ancestor of Android Studio as being IntelliJ, Jetbrains (not Google) did make a version of that IDE (CLion) for C/C++ native.
However, if you look at the Android operating system philosophy, it seems like Google (Andy Rubin) decided that a Java-like (Dalvik) VM is the 1st class programming model with native C/C++ (NDK[1]) being 2nd class. The Android Studio being Java-focused is just a downstream side effect of that.
>, Android Studio actually has the CLion C/C++ module intergrated for NDK.
Right, but I was responding to gp's question about "focus" of the IDE and not just about the extended capabilities (plugins) for NDK.
The "focus" of Android Studio is Java and example of that is when you click "New Project", you will get "MainActivity.java" as the starting file. You don't get "MainActivity.cpp".
In the full Clion IDE (not the CLion plugin), the focus is C++ because the "New Project" auto-generated file is "main.cpp".
>I think the author of the post is complaining about lack of JavaScript
The gp used the phrase "neither of which" that seems to refer back to "two ways" and therefore it includes question about native C/C++ being a possible "focus" for Android Studio.
I'm saying that whether Android Studio evolves to write "MainActivity.js" (Javascript React/Cordova) or "MainActivity.cpp" (C++ native) -- it is a philosophical decision outside of Android Studio. In other words, the Dalvik/Java VM as the foundation seems to dictate the programming tools' "focus". Maybe if Google makes a drastic change to Android and make the V8 engine the underlying runtime instead of Dalvik, the "focus" of Android Studio would then switch to "Javascript".
Android is a Java based OS, the NDK is there to implement native methods just like we used to write inline Assembly on the good old days.
Even what is called a native activity isn't really one, because what Google did was standardize a common pattern many were doing before as android.app.NativeActivity, with a bunch of native methods that the .so is expected to expose.
And android.app.NativeActivity is pretty thin anyway, because it doesn't provide a good way to work with permissions or SAF from native code.
Given that they locked down the NDK on Android 7, require JNI for like 80% of the APIs and Brillo was rebooted as Android Things, that says pretty much how they see the NDK for general use.
Which is why most NDK users keep implementing their own versions of NativeActivity anyway.
Sorry, are you saying that Android Studio helps you develop in a way that is unused or unwanted?
Because if so that is quite wrong. The overwhelming majority of Android apps, existing and under development, are made as traditional byte code apps. Among more intensive games, things like game engines are more common (e.g. Unity, Unreal Engine, etc), but that's a specialized case.
As to the web apps, that remains kind of the worst of all possible solutions. People who are wed to the traditional web often ply that course, but it certainly isn't most common.
>Funny how android studio helps you develop in 1 way : developing non-native java apps.
How are Java/Kotlin apps non native in Android when they're first class languages that are compiled to native code? AS also supports Android C/C++ development if you need bare metal speed and complete control.
>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.
Last time I viewed the percentages of what frameworks Android apps were developed in these web based frameworks ranked extremely low.
Seriously, IDEA is absolutely fantastic. From it I'm a huge fan of their sibling products as well (GoLand, CLion, etc). I come from a hugely varied history of IDEs, including Visual Studio, NetBeans, Eclipse, and every one of the so-called light ones, and I would pick IDEA in a heartbeat.
People can shit on how Google integrates with it, but the IDE itself is top notch.
It's been a while since I've done much Android development, but from what I can recall, Android Studio/Gradle seem to be a major improvement over Eclipse/Ant(?).
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.
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.
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.
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.
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.
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.