The fact that an Android platform engineer doesn't know of design patterns beyond MVC, and only knows that vaguely by reputation, explains why it's so difficult to build well designed apps for Android.
Yes, technically the platform APIs don't "care" about what's going on in an app. But when the APIs are designed in such a way as to (inadvertantly) work against MVC or other design patterns, they make developer lives more difficult. And you can expect that to happen if your platform engineers aren't familiar with these concepts.
Actually I'd attribute the difficulty to the culture of "Java-ism" that emphasises huge, complex, design-pattern-filled "extensible" architectures which happen to be extensible only in very specific ways.
I wanted to take up casual writing of Android apps as a hobby, mainly because I think the little portable computer I keep in my pocket could become so much more useful, but the unusual API combined with the complexity and general baroqueness of the architecture was a big turn-off. I don't get the whole "design patterns" thing either, but I do have extensive experience with writing Win32 apps, and a little bit of X (which is not all that different.)
I wonder if Google's ultimate goal is to make "Android apps" all work on Native Client/LLVM.
It already seems to be the goal to make all Java apps work on Native Client on Chrome OS. But once that's done, couldn't they just allow anyone to write apps in Go, Rust, Python, etc for Native Client directly? (and thus eliminating what will probably be some performance penalty of running Dalvik apps on Native Client).
That way Google gets to deprecate Java apps in the next 5-10 years and be done with Oracle forever, and developers would have a choice of some really good and safe languages as well.
I've scratched that same itch - and ended up with a bunch of Python code on a server and using my pocket-computer just for it's web browser... For "casual apps in my pocket" it's often "good enough". (This just moves the playing field, but I'm comfortable in html/javascript and FE Dev, so it works for me...)
Q: So I was wondering if you guys at any point considered the support -- the official support -- of the Scala programming language. I'm asking this question especially now that we all saw that Apple released Swift after 4 years of work. And I think that Swift allows for things for iOS developers that we can't do in Java with the Android SDK. So my question was: have you ever thought about it before -- the release of Swift? Have you thought about it after that? Is there any plan?
Android answer 1: Well, so, I like Cocoa, but Objective-C is based on C, which is 40 years old, so I think Apple sort of had to, like, update it a bit. Umm, so, yeah [laugh], I don't know. Scala -- I don't know. Anyone want to take that? [Android team laughs]
Android answer 2: [loudly] No. [room laughs, claps] Alright, seriously, it's -- Java is the programming language for Android. I don't really think there's a lot of benefit to -- the entire framework is built around the Java programming language and I don't really -- I don't think there's much benefit for us to try to support another whole -- another different language.
Person from answer 1: What about Swift? [room laughs]
Person from answer 2: [jokingly] I'll think about it.
Person from answer 1: [mockingly] It's got optional semi-colons.
Person from answer 2: You have the NDK so you can throw something there. But the NDK -- it doesn't have access to the framework, and that's kind of the challenge. If you want to do a different language, if you want to have it as a first-class language equivalent to the current framework you've got to have either a whole new framework or some bindings to it, which is going to make it a really bad experience because it's going to be Java and this other language.
Q: I want to work with Scala because Scala is compiled to the JVM, so it can run on Android. So there are currently ways to do that -- to work with Scala -- but it's using third-party libraries. So you have classes -- that's what I meant by people to wrap their Java classes, but then it becomes tricky to integrate that cleanly with Android Studio. That also evolves quickly. I'm not sure if it's as complicated as creating a whole new language like Apple did, but my question was just if you guys were considering any...
Android answer 3: From the tool perspective, probably later this year or early next year, there are some changes going on inside Gradle right now that will make things easier to you to just have a module that's originally written in Scala that you compile down to bytecode and then we can just dex that and package that with your application. But it's not going to help you access the activity API through Scala code. It would be -- if you have some code that -- your business logic or whatever that you want to write in Scala because it's easier for you, you should be able to do that. Because as you said, it's compatible. It just generates regular bytecode and then just dexing it. But that's very different from saying "you can code Android in Java" where you have access to all the framework APIs.
I gave up on watching those Android Fireside chat sessions because of the horrible jokey way in which so many valid concerns end up getting dismissed, every time.
It's been interesting to see the emergence of the Android Developer-Advocate-Comedian in Fireside chats and at Google I/O sessions.
Maybe some of these folks are bored with their jobs, or just tired of trying to do the impossible: convince the developer community that the Android SDK is a great and well designed thing that makes creating great, robust, secure apps easier and faster.
"We know we can't give them world-class, visionary, insanely great engineering, but we can try to give them something entertaining."
She mentions that we should think of the android apis as a "system framework", and I remember a different Google Android engineer saying something similar about the RecyclerView, that right now the focus is on making the technical functionality and API solid and stable, even if not so developer friendly. Someone else, or future Google, can make a more developer friendly API on top of the awkward RecyclerView API. The problem with designing APIs that aren't really meant for app developers, but instead for higher level framework developers, is that those higher level frameworks don't actually exist, and even if they did, there's no clear message for developers to follow. Less choices, or at least a "recommended" approach, would be valuable.
Unfortunately, 18 months since its release, I'm not sure if anybody (certainly not Google) has come up with some nicer abstractions on top of RecyclerView.
It works well for basic lists, but out of the box it comes with very little — not even a click listener for items in the view.
Having written a custom LayoutManager for RecyclerView a year ago (and then a matching ItemDecorator), it was probably the most difficult (and frustrating) thing I've had to do in Android development.
At the time there were certainly zero code samples that correctly implemented a layout manager that worked in all cases. Indeed, I gave up on supporting various parts of the API. I don't imagine that has since changed.
Yes, technically the platform APIs don't "care" about what's going on in an app. But when the APIs are designed in such a way as to (inadvertantly) work against MVC or other design patterns, they make developer lives more difficult. And you can expect that to happen if your platform engineers aren't familiar with these concepts.