But this is exactly what makes being a Javascript developer a miserable experience.
And I can give Javascript some benefit of the doubt since it's a multi-vendor language with complex standardization processes and all the stakeholders have their own interests and limited financial backing. By contrast, Android is a single vendor platform with practically infinite financial and labor resources behind it.
It's just a mess. I'd expect a relatively painless experience: install dev tools, start a new project, build and go! But no, it's jumping through hoops, requires understanding a myriad of different SDK/platform versions and a constant churn in keeping your apps up to date with new versions while trying not to break backwards compatibility.
And a big part of this mess comes from the fact that device manufacturers and mobile operators are unwilling to keep old devices up to date (and Google can't force them, while I think they should with some kind of licensing contracts), leaving customers exposed to security flaws while keeping the developers churn high with multiple versions to be supported.
I also have no idea why are you mixing the device updates into the developer tooling argument. New apps are (should be - and the tutorials tell you so) developed with API 19+ in mind which means that you'll have to work for quite a while to get any problems with fragmentation and updates. You can even start development on API 21 and ditch support libraries all together and STILL not shed significant amount of userbase.
I tried this after their 1.0 release and it crashed. Mileage varies from person to person
I agree it was abysmal at first - when it didn't crash, every new update would break compatibility and your projects wouldn't build anymore etc.
Right now it's pretty decent, considering, although I'm not a fan of Gradle either.
By the way, even though it's a fork of IntelliJ Idea, it's ultimately shaped by Google which has sort of a tradition of realeasing alpha-stage software into the world. Remember first releases of Chrome? I do; they crashed like crazy and lacked basic functionality such as printing.
> And a big part of this mess comes from the fact that device manufacturers and mobile operators are unwilling to keep old devices up to date (and Google can't force them, while I think they should with some kind of licensing contracts), leaving customers exposed to security flaws while keeping the developers churn high with multiple versions to be supported.
Is it only me or there are tons of similarities to C# and the .Net environment?! More and more I feel Google just ends up with the same solution MS came up with in order to handle the diversity of vendors using its platform and their conflicting interesse.
(That said, I'm very glad that this is the top-voted comment, since it looks like a very valuable resource for lurkers who want to get into the topic.)
The only exception is Kotlin as a language, which is pretty new and the tooling is still improving. You're not going to hurt TOO much if you stay with Java6 though.
Remember, we at the end of the day we're all just old Java farts and we like our stability ;)
Which speaks a lot about the quality of work provided by the platform owner, when the community needs to step up.
I mean, yeah, in perfect world we'd all have neatly packaged by Google, we'd write 6 lines of code and have the greatest app ever. But software development never kinda worked that way for me and I have a feeling it never will :/
Python's biggest strength that lead to its adoption was being a language with "Batteries Included".
I'm fine with Javascript development these days because I built my fundamentals years ago. I am not sure how comfortable I would be otherwise and when I meet people who are where I used to be, they often look lost.
I am also thinking about learning Android development and don't really know where to begin.
So everyone suffers when anything more complex than hello world already required third party libraries, specially ones that aren't even acknowledged by Google.
Also the Android operating system isn't a language.
If a company wants to vet all of their software, good on them! But that doesn't mean that anything that's not vetted by them is somehow worse for the majority of users, just that they haven't vetted it yet. So any arguments about how "library x" isn't usable by them won't apply to the vast majority of people, because most don't have that issue, or have no problems vetting that library as well.
Somewhat off topic. Is there a word that encompses the langauge, platform, runtime, etc...? I hate the word "ecosystem", but it seems like the best bet. And using any one of the others brings out comments of "well it's not a language" or "it's not a framework it's a library" or something else.
If you assume a roughly logarithmic intersection of shared dependencies that's O(N^2 log n) chances for a bug. But in some communities I'm sure even that is optimistic.
When you have a more complicated project it's fine to rely on repo packages (Python does as well for eg. web frameworks like Django aren't in the core). In fact python std lib is hugely inconsistent stylistically as a result of needing to keep it stable over the releases as people expect it to be backcompatible and package versions are tied to language versions. If it had proper versioned dependencies doing breaking refactoring over the years would be really easy and non-intrusive.
Apple didn't come up with dependency/package managers like Carthage or Cocoapods, the community did. There's just enormous amounts of OSS libraries provided by the community too, with ones like Alamofire smoothing out the rough edges of iOS's networking APIs.
I have multiple personal Obj-C/Swift projects on iOS and macOS that don't use any kind of dependency management and use very few third party libraries and working on them has never been an issue or source of pain.
Thats not a bragging point.
Rememember that Google has been advocating AsyncTask in the past. You could use something else or roll your own, but it doesn't make sense to do that when AsyncTask is being communicated as the way forward. They should've embraced third-party libraries, but instead they still communicate how to use AsyncTask. Example: last March 2016 they published a video on how to use AsyncTask [0]. They do highlight the red-flags around it, but do not mention any of the third-party libraries that are considered standard for a lot of Android developers already.
The same goes for Fragments. It is still being advocated as the right way, but I have some doubts. I imagine they will be advocated against in a couple of years. They help at the time, but are far from logical/simple when you don't know all of the crooks and crannies (and there are quite a few).
Another API that needs serious work is the Storage Access Framework (SAF). Previously Android applications could use the Java File API to access files. With recent Android versions this has been closed off with good reasons and intentions. Instead of using the File API directly, you now need to use SAF. SAF doesn't support all operations you could do with the File API. I would say this is a regression and existing applications that relied on these features are now broken and unrepairable. In addition, applications now needed to explicitly ask the user for permission to specific directories or files. This was so badly implemented that every file manager needed to instruct the user on how to use the directory picker of Android using screenshots before showing the picker. This is still a problem and even if it is fixed, it will still be a problem for years due to phones being unable to update.
To give you an impression on how those APIs are designed: many calls of SAF will return null to indicate something went wrong. No exceptions or error-codes. There is often no indication why a certain file cannot be retrieved. It could be non-existing, it could be denied permissions, it could be some strange behavior in the rom. There is sometimes a way to find out why this returned null and that is looking through Androids global log. I've implemented this in the beta of my app so that I could find out why files weren't accessible on some devices.
Also, because of the slow adoption of Android versions, your application needs to support both SAF and the Java File API. The support library has wrappers for Java File API that works like SAF, but it's still a downgrade to use this API as exceptions from the Java File API are just ignored [1].
For me Gradle is actually a step in the right direction. Builds seem to be more reproducible and do not fail randomly compared to the Eclipse/Ant days. The performance is however awful. Incremental builds take 30 - 60 seconds. When comparing this to building pure Java projects it shows that it is an Android-only issue and not one with Gradle.
[0] https://www.youtube.com/watch?v=jtlRNNhane0
[1] https://github.com/guardianproject/android-support-library/b...
The author states pretty plainly the biggest reason for leaving Android development was he didn't have time to keep up with all the developments in both Android and iOS communities.
Multidex ? it is far from perfect but it is not a day to day issue. I work on a 200k methods app and multidex actually makes it almost entirely painless.
Gradle ? Nobody can seriously say that builds have gotten worse with gradle. Before it, we had no way to hook up libraries with resources (aar). Now we just have to 'import libname:version' The complaint on the build times is very fair though. The solution is easy though .. just use an high end computer
I use a mid 2015 mbp, it can handle an huge android app without any issue (except that build times are only acceptable, not great).
It really looks like he has been submerged with having 2 platforms to learn at once and has not been able to tackle the basics.
For kotlin, no book needed. Go to the language website, read the introduction, maybe a couple of pages on the language features and then complete the kotlin koans. It will give you an overview of most of the language features.
After that, find an android project written in kotlin. Here is one : https://github.com/LostInContext/LostContext-App (there are many others) . Configuring an android project in kotlin the first time can be painful, especially if you have some code generation (dagger, databinding, ...) , so it is way easier to have a working sample to work with.
Cost benefit also is probably lot better on the iOS side ($$$ you get to develop an app / time to develop it).
gradle --daemon is a hack, I guess, but I always use it for my builds (even aliased gradle to gradle --daemon). It's far too slow otherwise.
On newer gradle releases I believe the daemon is enabled by default.
Incidentally, our Kotlin-based app actually has a completely custom one that an opinionated product guy wrote that works reasonably well, but it still needs a lot of work and probably to be fully extracted for an OSS release. We also have some Kotlin delegated properties and other magic for cutting down on lifecycle & state management boilerplate.
I think that's kind of his point. He was spreads too thin.
* and its management
* by its scripting language
If in 2016 you're still complaining about AsyncTasks and its management, you certanly have missed a lot of progress in the last few years. It's not unlike having people complain about JavaScript issues without ever looking at jQuery, React or newer tooling.
The most useful things you can do for yourself currently are:
* Adopt Kotlin as a language. It's not all that different from Swift, comes with IDE support, tiny standard library and really fixes the pain of Java 6.
* Use MVP patterns and its friends. There are a few libraries which take most of the pain of lifecycles away.
* Use RxJava, Retrofit, Glide, etc. libraries that make your life easier with concurrency. A lot of these tools are better and easier to use than what even exists on iOS. Using AsyncTask in 2016 is just silly, it was never a good API.
* Use Gradle! Driven by its scripting language, you can do so much to script and automatize your build.
Other than that, I agree, after years of development:
* Some Android APIs just aren't well thought out.
* Gradle badly needs performance improvement.
* State of NDK is just sad. Fixable, but sad.
* MultiDEX is a result of a very very dumb decision in Android 1.0 and it's going to hurt us for a long time :/
All-in-all, I honestly think the author didn't really look into Android all that much to have complaints that he had. The blog post is somewhere on the level of someone complaining about IE6 JavaScript bugs when we've already moved on to React and are dealing now with very different issues.
(And no I'm not saying Android is great or even a great platform. It's not. It's just that, just like on Web, you can do a lot to fix major pains.)