Why is Android Studio always so embarrassing? – TechCrunch


About twice a year, I get involved in a project that asks me to do Android development; so, about twice a year, I relaunch Google’s so-called integrated development environment, Android Studio, with my fingers crossed… the simplicity of a Rube Goldberg machine.

Let me hasten to point out that I am not an OS supporter, or, as far as I am, I am Google inclined. All of my own smartphones have been androids. I’ve been writing Android apps, both professionally and for fun, since 2009 when I first bought an HTC Magic. Since then, all my phones are also Android: Galaxy S2, Nexus 4, Moto X and my brand new Pixel.

But I Also write iOS and tvOS applications; and despite my abstract disapproval of Apple’s hegemonic attitude to software, every time I launch its XCode IDE, I breathe a little easier. It’s quick. It is slippery. And even when it is not useful, it is rarely in fact gets in my way – something which as far as I know is the foundational core skill of Android Studio.

For example: I never managed to use his visual tools to arrange things on a screen. I’m sure that’s theoretically possible; but every time I tried I got so frustrated that I just gave up and wrote some raw XML layout files instead. I know in good faith that I am not the only one in this case. In XCode, on the other hand, I drag and drop with abandon and glee.

Out of the box, Studio doesn’t automatically import Java classes for me; the framework for doing so is buried deep in its impenetrable labyrinth of menus. Out of the box, Studio doesn’t tell me how to load the zillions of support libraries I probably need, or how to get the (still painfully slow) Android emulator to work. Believe it or not, the secrets of these two things are buried in the “Android” submenu of the “Tools” menu. Think about it for a moment. Why does Google’s flagship Android developer tool have a “Tools / Android” menu? Is not the the totality an Android tool? Shouldn’t these key elements be first class citizens?

One problem, of course, is that Android Studio was not built from the ground up; it’s based on the IntelliJ IDEA platform, a Java IDE… well, you can tell. This feels like fifteen-year-old software, and it’s all too obvious that it was adapted rather than designed for Android development. (Again: “Tools / Android.”) And, of course, it’s written in Java, which makes it cross-platform… but slow.

It’s true that the Android ecosystem itself is clunky and complex, fragmented into a dizzying plethora of versions from various libraries and SDKs. It is true that, for example, the Gradle build tool is notoriously hostile to developers. (Although building is just tough; Apple’s building tools don’t exactly fit your hand, either.) But a better-designed IDE could at least mitigate this. It is true that XCode should only run on one operating system, that of Apple, while Android Studio should be cross-platform. But Google, of all companies, surely has the resources to support native code on multiple platforms.

It’s truly remarkable that a hypermonized giant the size of Google has decided to take this slow, clumsy, and ugly path for a flagship development environment for its mobile platform with far more than one billion active installations. The negative effects are numerous. Better tooling is one of the reasons iOS development is faster and more efficient. Developers comfortable in both ecosystems prefer iOS over Android because it is easier to use, and so we are helping to influence a lot of smartphone software to be iOS first, with Android as second class after some thought. . Android apps tend to be more buggy than iOS, and it’s hard to believe the IDE has nothing to do with that.

But above all, although very selfishly, if Google’s IDE was better, it would push Apple to improve. XCode is far from perfect. He crashes. It hangs. But even with these flaws, iOS development is so much less painful than Android development that there really is no comparison. (Well, until you try to deploy. Then Android is painless; Apple’s improved but still too often Kafkaesque process to create, sign, upload, submit, and wait for approval for even test builds. beta is one that often inspires deep resentment and resentment in every iOS developer I know.)

Lately, however, I say with a sort of skeptical anticipation, for the first time in years, there is is real competition. This has long been true for .NET programmers, thanks to Xamarin, recently acquired by Microsoft, which allows you to write .NET code and build native apps for Android and iOS. But these days, Facebook’s React Native is becoming a realistic solution to building native cross-platform apps without having to write (a lot) of native code… and, therefore, without having to use Android Studio or XCode.

I’m not saying that either will go away. But it’s nice to at least see someone trying to force their way past Apple and Google’s de facto developer guardians. They, especially the latter, have become complacent due to a lack of competition. Let’s see how they react to React.


Comments are closed.