Android Studio 3.2
android-developers.googleblog.com
android-developers.googleblog.com
I have to say it's such a giant bloated thing that it really does not make me want to write native code.
Fortunately, there is a lot of great stuff going on with Progressive Web Apps now. I hope that they will be the future. Developing for the browser is so much leaner.
It’s pretty
It’s fast
It’s not stuttery-stoppy
I can swipe back and forth between pages without waiting 4 seconds for everything to display, and then inevitably move around right before I fucking tap
It’s on the app store
I can use it instantly.
I can remove it instantly.
I don’t know what sandboxing is
I don’t care about privacy
There are convenient share buttons
I can use it on the single device I use regularly
I can screenshot it
I can unfortunately change the style by updating
It can use my battery when it’s closed? Wait wha-
ooh notification
...
I’m gonna go use facebook now like a normal person, later nerds
Some kinds of things are just a better fit for the web.
Man .. don't even get me started .. ok, here we go:
I can use it instantly.
I can remove it instantly.
The sandboxing is much better.
The privacy is much better.
I can link to it from wherever I like.
I can use it on all my devices.
I can copy text and images.
I can change the style (I often enlarge the font for example).
It can not use my battery / camera / phone when it's closed.
...
I feel like I can go on forever.
I think the answer is some apps are better on web, others on native.
Videos / Music / Games / Email / Messaging are better native. For actual reading of content (HN / Reddit / Twitter / Facebook ...etc) I find better on the web.
This is on a Nexus 5X, using stock Android.
Web apps are a complete joke right now. Entirely useless. I always install native apps, if available — even if I know I’ll uninstall it 5 minutes later — because the alternative is entirely unusable on my device.
I've never had a browser crash a phone, but having the phone start to immediately feel sluggish after opening something like a moderately sized GitHub pull request--that's certainly a thing.
However making it more difficult to crash the device is a definite advantage, you're right about that. Although I very rarely have native apps crash my devices anyways. I can't remember a time it's happened on my phone, and on my desktop it's usually a device driver issue combined with a game that causes an issue. Definitely an edge case and not something I encounter with native applications in general.
If I open a site like cnn.com without an adblocker, all apps running in background (even e.g. spotify if I'm listening to music) are force closed because the phone runs low on RAM.
Every website or web app I've used so far has used > 100-200M RAM, while a well developed Android app stays below 20-50M.
My phone has 2GB RAM, 1GB is used by the OS, 500-800M are used by Google Play Services, and a web browser with 1-2 tabs takes another 200M of RAM.
As soon as I open a website any more complex than HN, everything feels sluggish.
On the other hand, JavaScript in a more constrained environment--React Native, for example--is a lot more reasonable. Still heavier than an Android app, but not so heavy that it kills processes except on very downmarket phones.
In what way? How?
Browser-based has the fast reload thing going for but it's not in the same universe as lean for a modern development stack, not in terms of RAM usage nor size on disk. So can you elaborate on this "bloated" vs. "lean"?
Why?
You can write (and compile, and test) native code without ever touching Android Studio. I would think any like/hate of IntelliJ (Android Studio) should have no bearing on whether you choose to write native Android code or not.
It would be like saying, "CLion is such a giant bloated thing that I never want to write C++ code". Or "RubyMine is so giant and bloated, I never want to touch Ruby on Rails again".
What would you say, for example, if someone told you they didn't want to write a Progressive Web App because they really disliked Atom and Visual Studio Code?
and that's very often if you are a Java/Android dev. Even features like auto complete (let alone with prediction) is very hard to get right elsewhere, let's say, somewhere like Vim. Not just the language, there's Android SDK itself and other libraries. But, if you count "not needing auto complete etc" as part of "know the language well enough" or that they trivial enough then, well, I rest my case.
I wrote substantial systems before there were any Java IDEs. Nothing hard about it. Write a lot of code and it's easy. If that disturbs you I'm sorry, but you should allow that there are people with more skill than perhaps you've been exposed to.
I used to write in Vim (C) when I worked for that South Korean giant. After that I moved to Java/Android and I wouldn't get back to those days of Vim/C for anything. So I think it comes down to choice. The thing is GP commenter mentioned "masochism" and now I see the point.
Giant? It's smaller than Xcode you know :)
Bloated? Yes, so bloated! As an Android developer this is my biggest complaint from the ecosystem after the fragmentation though Google is trying to fix that with Treble but they are just not enough for the Studio. It was amazingly frustrating and pathetic to work with it couple of years back and it still is.
My entire team is stuck on old Android Studio versions. I was the only one trying to live on the edge (and by that I mean stable channel) but for past few months I have just stopped upgrading Studio. It never fails to break the entire damn setup upon any upgrade. Like any release!
- Stable releases of Android Studio are usually followed by complaints of breaking left and right even though they take mounths to get out
- Stable releases of Android Support Library usually always have a couple of regressions
- Documentation and release notes always gets made available a couple of hours later
- Kotlin plugin usually breaks at every release
- NDK gets the attention level of a 20% project
Supported by VSCode and IntelliJ community edition. Hot reload is the cat's PJs.
It used to be an amazing experience, and when the news came out that Google was going to switch to IDEA for their official tools instead of going with that Eclipse I was thrilled. Finally everybody was going to able to know just how fast and efficient Android development can be.
How wrong I was. When Android Studio came out, it was incredible slow. Even today, after years of improvement to the developer experience it still isn't as efficient as plain IDEA was before Google created Android Studio.
I actually lay most of the blame on Gradle, which became mandatory around the same time. I never thought that someone would create a buid tool I dislike more than Maven, but it seems they succeeded.
Indeed ... most people don't know Groovy and hate Gradle whenever they have to fight with the build file. What's fascinating is that I really like Groovy and know it extremely well - but even I hate Gradle. It's amazing how shiny the documentation looks for how little it explains the underlying principles of what is going on. Most people are two steps removed from any hope of understanding it (first learn Groovy, then realize that Gradle is actually a DSL layered on top of Groovy, so you still have no clue what is going on until you learn that as well ...)
The Energy Profiler is a nice addition, but I wish there was some incentive for apps to be energy efficient (even an app store "badge" would be better than nothing), since people will continue to just blame Android for the battery performance and not the apps.
super-small-nit: It's Android Studio 3.2, but the installer's file name is android-studio-ide-181.5014246-mac.dmg. android-studio-3.2.dmg would of been just fine. I am guessing 181 is a build number, but as a user, I don't care about what build number it is.
While Xcode on the other hand 3-4 years ago it was liked developed by interns. But Xcode 9-10 has been very fast and less buggy on my 16GB.
Developing for Android is not fun anymore for me. It is getting bloated.
I've given up, and recently uninstalled it. I'm going to try and develop android apps using Xamarin in Visual Studio instead (as I have that anyway for Windows dev).
Either that or just live with mobile Web and its constraints.
How's your personal experience with Xamarin? How's the tooling compared to Android Studio?
I don't think it's possible to run the emulator with more than 5 FPS with this kind of set up. Let alone the editor itself which frankly runs like crap on low end hardware. The irony is that eclipse was much much faster in constrained environments. It's like IntellJ spends its time indexing and when it's done it's doing some more indexing just for kicks.
Android App Bundles, Integration with Hyper-V and support for AMD are very welcome.
Just wish using Android Studio required less ram and CPU, but to be honest, IIRC developing with Java has always been a little demanding when it comes to machine resources.
As far as I can tell it's not a technical reason why they ask for your key - bundletool [1] supports generating a set of signed APKs (.apks, APK set archive) in the same way the play store would from an app bundle. Android Studio's GUI could just as easily generate that to upload directly to the play store instead of an app bundle. This would net the same benefits to the end users and the same level of convenience to the developer, all whilst keeping your private keys private.
[1] https://developer.android.com/studio/command-line/bundletool
Microsoft's Hyper-V is the hypervisor platform built into modern versions of Windows and which shares/follows (for the most part) Microsoft's overall Platform APIs and Driver APIs, making for a better communication channel between Hyper-V and the usual Windows supervisors/kernels when hosting Windows virtual machines. (Similar to the integration services offered by other hypervisors like VirtualBox, with the "magic" that such services are easier because the OS and the hypervisor share very similar "languages" already.)
Microsoft's Hyper-V is also the base component for other systems such as the Windows Container Platform, some of Windows 10's more optional enterprise sandboxing systems, etc.