13 ms·

Android platform engineer on application architecture

220 points by EddieRingle 10y ago

jwatte 10y ago
I worked with Dianne fifteen years ago, and she was good. However, hearing from others who were involved in early Android, and then left in disgust, the designers who set out the initial form did boot have extensive application framework/developer experience, and we're still hiring to this day because of it. Let's say it all together: Implementation inheritance is a mistake, and interface based design is a clearer option.
- thrownaway2424 10y ago
  It's not just that. Hackborn spent many years denying that Android was janky as fuck, or making excuses for it (e.g. https://plus.sandbox.google.com/105051985738280261832/posts/2FXDCz8x93s https://plus.sandbox.google.com/105051985738280261832/posts/...).
  - RomainGuy 10y ago
    You must be mistaking me with someone else.
    - thrownaway2424 10y ago
      Deleted, then. Perhaps I have conflated the memory of being at javaone and being told all about the wonders of javafx, and the contemporaneous wonders of "filthy rich clients".
twotavol 10y ago
Eschewing the traditional application architecture has made for both a terrible development experience and poor quality applications in general. The application lifecycle is convoluted with even the Android developers joking about how confusing it is. Everything about the model has made it far more difficult to port existing software to, and native development for me personally has been an absolute nightmare. No clean exit strategy for applications, half the methods in the lifecycle don't even get called, etc. I can't imagine the completely naive and oblivious thought process that led to the mess they created. Good thing Android is backed by Google though, so no matter how terrible it is it'll still be popular.
- lanestp 10y ago
  I agree. Android architecture is a mess. Activity life cycling is actually impossible. There are certain actions the OS takes that will cause crashes no matter how well architected the app is. My main quibble with Android is that since everything is tied to the activities it is impossible to build an MVC style app. You are better off using the NDK or an engine. Then you can build your software correctly.
  - steplee 10y ago
    How would the ndk help, doesn't it run within an activity?
    - lanestp 10y ago
      I use the NDK a lot because you can kind of ignore the Android nonsense and structure your code properly. My approach is to have it build out the main activity then fire out into my app code. That code is beautifully MVC and for the most part ignores Activities, Fragments and Intents. For me it was faster to develop in than Android Java because I wasn't so strongly tied to the view code.
  - EddieRingle 10y ago
    Do you mind expanding on some of your statements? Especially: > Activity life cycling is actually impossible. There are certain actions the OS takes that will cause crashes no matter how well architected the app is.
    - lanestp 10y ago
      I work on a very popular app in Latin America. That means we get to experience every single edge case in the eco system. My favorite quirk has been that for some reason I will never understand when an app goes into a full screen ad it can make your main activity eligible for GC. That means that you don't get any of your Activity life cycle events. Just a lone finalize and your app is gone. Then when the video ad is done you get a truly spectacular crash! Sadly, I have a half dozen different ways activities have found to explode themselves. It makes me sad!
zzalpha 10y ago
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.
- userbinator 10y ago
  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.)
  - bigiain 10y ago
    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...)
  - aphexairlines 10y ago
    26min into the 2014 Google I/O Android fireside chat: https://youtu.be/K3meJyiYWFw?t=26m https://youtu.be/K3meJyiYWFw?t=26m 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.
shruubi 10y ago
After developing a few Android apps as an agency dev, we settled on a common structure that helped keep our code relatively clean. Each activity would have an associated fragment, the idea was that the activity would be responsible for loading the fragment as the current view and other lifecycle functions as well as being the entry-point for any external data-loading (through creating and calling of services). The fragment would initiate with a reference to the parent activity as a context, and would be responsible for view-centric things like displaying content and adding event handlers, which would more often than not use the context reference to call some remote API. I suppose you could think of it in terms of Model/Controller/View-Controller but I'm sure there is a more correct model for thinking about it (and it probably is more straight MVC anyways). The problem I've found with Android is that Google has created almost it's own language when it comes to Android app architecture, which creates a lot of confusion, especially for developers who just assume that all frameworks use the MVC concept (laugh if you will, but this is a thing). Even though google is quite behind when it comes to the app market, I think there is still time for them to come out with a new set of documentation which outlines the "correct" (the "Google-blessed" one at least) structure for Android apps so that we as a development community can start moving away from the "everything-and-the-kitchen-sink goes in the current activity" style of Android development.
- jc4p 10y ago
  What you described sounds a lot like what I used to do for years. It works fairly well, and you can tack a headless Fragment onto it for things that you don't want directly connected to an activty's lifecycle (rotating the screen mid user sign-up shouldn't restart the HTTP call, etc). This works well, and I'm at the point where I develop it without thought while creating new apps, but I've been playing with a less constrained DI flow instead using Dagger 2. The more business logic and multiple copies of shared UI elements in different Fragments are directly connected to their parent Activity, the harder it is to re-arrange and re-use them. I've been working on migrating all core elements of our application into a shared library project, and that would've been impossible with a closely tied codebase.
  - jwatte 10y ago
cnbuff410 10y ago
One thing platform engineer should do is to rotate into app engineer role and experience it for a couple month at least, without doing it you don't really understand all the pains the app engineers are suffering due to platform design. At very least you can make your doc so much better by knowing which part you absolutely want to cover in details. This is especially true for Android platform team, to be honest.
- dlkfsdflkfj 10y ago
  卡上就放假了SD卡分解开连锁店
- dlkfsdflkfj 10y ago
  sldjfklsdflksdf离开的时间发来看上对方
- taneq 10y ago
  Dogfood, you say? I concur. I've only dabbled in Android development but (while a lot of things do feel well designed) there are some ridiculous design choices in there. The one thing I've found really annoying is instability of the API as new versions are churned out. New features are added, deprecated almost immediately, and replaced with entirely different things (looking at you, NotificationListenerService!) It feels like they're thrashing trying to hit feature quotas or something.
- spriggan3 10y ago
  What a platform engineer needs to do is to listen user's feedback early and often in order to improve the API. An API is a product,and like every products there should be usability concerns. I wouldn't say Android SDK is bad, it's just so convoluted it doesn't feel like it was written in this century. It's like someone wanted to impose something regardless of its usability, a lot of design decisions seem to have been taken unilaterally because of one engineer's ego.
johndifool 10y ago
I remember her name. Wasn't she the one who vehemently was defending activity lifecycle and other broken multi-threaded API, something every Android developers I talked to would consider totally broken? To be fair, developing on Android has become so insane releases over releases that her crazy write up about no engineering design hardly comes as a surprise... Shame on Google for forcing us to use that POS.
- logcat 10y ago
  Shame. Shame. Shame.
- ocdtrekkie 10y ago
  I met her once at Google I/O, and it wasn't a pleasant interaction. I was lamenting how the recent (at the time) switch from USB Mass Storage to MTP made file transfers to and from computers very iffy. (And it's still pretty iffy today.) I was asking why the change was made, and if there was a chance at the option for it being restored, as devices used to allow both. A lot of times, files on the Android device don't show up properly in Windows Explorer. She asked what I was doing, and I said copying APK files. (I regularly used to backup APKs so I could revert software updates which degraded the experience.) She immediately stated that they "didn't support piracy" and walked off. As if the process of sideloading APKs or transferring them to and from a PC was somehow automatically illicit activity, rather than... something a lot of developers probably do regularly.
  - ffiw 10y ago
    I see Android guys lack commonsense and I am not surprised. How did they think you are pirating apk's after attending I/O event that costs fortune to enter ?
HillaryBriss 10y ago
This makes my head spin. Plenty of examples on developer.android.com use Activities, Services, BroadcastReceivers for things that go beyond what Dianne Hackborn is recommending here. It's like the Android SDK team want to have their cake and eat it too: "We've built a tremendously powerful and useful SDK. It really helps you build great apps quickly and easily." vs. "Oh, and, by the way, be careful not to misuse our main components. They were never designed to help you build great apps quickly and easily."
- saturn_vk 10y ago
  Well, d.android.com exists to showcase the core apis. They can't possibly show you how to create an app with 3rd party components on top of a single activity. Just take the bear necessities from there add your own stuff on top.
  - HillaryBriss 10y ago
    I guess I've been reading that documentation from the wrong perspective. I thought they were trying to show me the right way, or at least, a good way, to create apps and add features to them.
0xFFC 10y ago
Recently I was looking for one book desperately , a book that shows android (and its apps) architecture, form low-level to high-level, design decision which you should take when you design your app architecture. I hate how all books are kind of reference manual. If I want to see what an API doing , I will look at it documentation I don't need another book.But sadly most of books written about android is just talking about API details. p.s. If you know such book I would be grateful .
- ktRolster 10y ago
  You might consider this book: http://www.amazon.com/Android-Programming-Ranch-Guide-Guides/dp/0321804333 http://www.amazon.com/Android-Programming-Ranch-Guide-Guides... I've read some of their books before, and they have good understanding (and presentation) of architecture.
fighting 10y ago
They really should have stuck with int main. What's unfortunate is the quantum leaps they've been taking in terms of complexity to just get an app up and running on their platform. But I guess that's the only way their engineers can justify their salaries/bonuses. Same as with that horrific nightmare of an app Facebook puts out.
- mondoshawan 10y ago
  What would staying with the main entry point solve, aside from being familiar? Your application would still have to directly manage binder callbacks and register for lifecycle events. Re-using the old Java/POSIX entry point actually increases the complexity significantly.
vowelless 10y ago
Disclaimer: I am not an Android developer. I cannot seem to reconcile these two statements: > Should you use MVC? Or MVP? Or MVVM? I have no idea. Heck, I only know about MVC from school and had to do a Google search to find other options to put here. And > In Android, however, we explicitly decided we were not going to have a main() function, because we needed to give the platform more control over how an app runs. So this person claims to not know or care about design patterns; but then explicitly enforcing a design pattern? She does say: > Android could feel like it has strong opinions on how apps should be written. With its Java language APIs and fairly high-level concepts, it can look like a typical application framework that is there to say how applications should be doing their work. But for the most part, it is not. But after reading through the post, it does seem like a particular set of design patterns is being propagated.
- EddieRingle 10y ago
  Seems many people are missing the overall point of the post: The APIs Android provides that are listed here are intended to be used as the glue between your application and the rest of the system. However you want to build your application from that point on is up to you. In particular, Android Activities aren't simply a main() function because they are designed from a multitasking standpoint; users are going to be going in and out of apps, changing the state of the device (such as rotating the device), etc. In other application environments, you might register callbacks to fire when the window is hidden or gets resized. In Android those callbacks already exist and are set in stone to encourage apps to behave as a good citizen on a potentially resource-constrained mobile device. But as the post details, you don't have to do anything beyond properly managing heavy resources (like camera access) and saving and restoring state at the appropriate points if you don't want to.
kabdib 10y ago
You need only look as far as the large collection of flags involving the Intent object to realize how badly things went wrong.
- EddieRingle 10y ago
  Most Android developers I know (and even some iOS developers) consider the Intent system one of Android's diamonds in the rough. Could you perhaps explain how you would've designed it?
  - Benjamin_Dobell 10y ago
    The concept may be a diamond in the rough i.e. co-operative multi-tasking. The implementation, not so much.
    - tuukkah 10y ago
      The user interface concept might be called UI subroutines, along the lines of UI continuations of this paper from an MIT research project in 2003: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.2884 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.2...
    - georgemcbay 10y ago
      Speaking as someone who has been writing Android software for like 4 years now as my job (but who has been in the industry for much longer than that, as a 42 year old who has programmed in just about every major environment), I agree with what you wrote here. Intents are great in concept and they work out well for users, but the interface/API for using them to do anything can quickly become painful if you go even a step off the beaten path of "perform this operation with these parameters". A common recurring theme with Android (and this applies to all the major bits -- Activities, Fragments, Services, etc) is that you'll easily hang yourself if you don't have a really clear picture of how they actually work but you attempt to use them. Android almost completely fails, IMO, when it comes to the concept of "keep the easy things easy". There's a huge upfront cost to understanding the major components before you can start really using them at all safely, in my experience. As a bare minimum, if you don't have an intimate understanding of the Activity and Fragment lifecycles and a full understanding of what needs to be on the UI thread when (and when different callbacks from the OS are/aren't on the UI thread) you are likely to create a terrible mess of an app that kinda sorta works on most devices, usually, but is broken in some fundamental ways you aren't aware of. I don't personally know any day to day Android developers who haven't spent a considerable amount of time in the AOSP code trying to figure out exactly how some of these systems work because failing to understand them internally combined with lack of any sort of clear direction from the platform team (extremely open case of there being more than one way to do anything, which makes authoritative answers to the question "How should I do this?" nearly impossible without a long list of caveats) is the path to writing Android code which mostly works but has some fundamental mismatches with the operating system and becomes a complete mess to maintain.
Benjamin_Dobell 10y ago
Unfortunately, the contents of this post are no surprise to any seasoned Android developer. It's very clear the Android engineers haven't given a lot of thought to how applications are to be developed. I'm all for them not enforcing one methodology over another. However, in order to build an Android application (following whatever pattern) we do need core building blocks that have been well thought through on how they will be used. In general performing Async tasks (in particular networking) is excruciatingly convoluted on Android - well, at least to get it right. Many inexperienced Android developers simply get this wrong, and quite frankly I can't blame them. Such a common task should be trivial to perform and not require hours of background reading. The issue largely comes down to the fact the "system framework" has been designed to be simple (supposedly[1]) for system framework maintainers, and not developers writing applications. Destroying and recreating activities (so you can load different resources) may be simpler from AOSP's perspective, but it's not at all logical from the perspective of an application. Sure, there are several ways to work around this, but they're all stupidly convoluted. Frameworks should be written for consumers, not maintainers. [1] Okay, the system frameworks definitely aren't actually well designed / simple to work with for framework maintainers either, that was just the (missed) goal. If you want to see world's worst state machine (a stupid amount of booleans), check-out: http://stackoverflow.com/questions/17847775/nested-fragments-illegalstateexception-can-not-perform-this-action-after-onsa http://stackoverflow.com/questions/17847775/nested-fragments...
- bigtones 10y ago
  Yes, Dianne Hackborn was one of the main proponents and designers of the fragment system lamented in your StackOverflow question referenced: http://android-developers.blogspot.com/2011/02/android-30-fragments-api.html http://android-developers.blogspot.com/2011/02/android-30-fr...
- lern_too_spel 10y ago
  You've hit the nail on the head. It's not the system engineer's job to develop a useful application framework for common use cases any more than it is a Linux kernel developer's job to do so. Still, it has to be somebody's job, and it's clear that it isn't anybody's job on the Android team. For example, there's a hacky HTTP client library built by the Google Play Android client team (http://developer.android.com/training/volley/index.html http://developer.android.com/training/volley/index.html) that is promoted for general use for some silly reason, and to use it, you're supposed to copy the library's source code into your project. Pure amateur hour. There should be a team within Android building well-thought-out, properly versioned, and sanely distributed libraries to simplify Android application development. There should be, but there isn't.
petra 10y ago
If this is so terrible, why isn't there some Java framework on top of this that's designed to make sense for developers?
- ktRolster 10y ago
  I hear Oracle has something available for that.
- jmfayard 10y ago
  They do exist. Check out rxjava from netflix, dagger and butterknife and okhttp and retrofit and picasso (and and....) from square, MVP libraries, kotlin and anko from jetbrains What is truly holding back many developers is the above cargo cult that the path mentionned in android.developer.com is always the right one. There have been some harsh comments on Dianne Hackborn, but I find that she is actually doing us a great service here by dissiping this myth. I find she does a great job at explaining what is the scope they really care about, and the one where you are free to discover better alternative that do not have the "Google" label on it.
  - kodroid 10y ago
    I agree with your last two statements, but the idea the RxJava and Dagger make things _easier_ to understand for developers (I'm inferring this relates more to newcomers to Android as they are the once which have a hard time grokking this stuff) is a joke. RxJava and Dagger only increase ramp up time and the amount of stuff to learn, regardless of how useful they are. If someone came to me confused and I pointed them in that direction, Im sure they would get lost in the woods somewhere and Id never see them again.
    - jmfayard 10y ago
      Fair point. They make things simpler, not easier
  - HillaryBriss 10y ago
    > What is truly holding back many developers is the above cargo cult that the path mentionned in android.developer.com is always the right one. Yes. I sometimes think we need to embrace an "Android-free Android programming" approach where we use builtin Android components as little as possible and better written 3rd party components and libraries for everything else.
bengotow 10y ago
I think it's fine for the Android team to take this approach like so many framework authors before them. I think the problem is that Android developers are seeking patterns and prescriptivist documentation because that's what many other platforms offer these days. On iOS, the message has always been clear: "Use MVC, delegates & data sources, storyboards, etc. /We use them internally/ and you should too. Don't go re-invent UIViewController!"
hidro 10y ago
Rails is built on top of Ruby language, designed to be opinionated, following MVC. You like it, you use it. You don't like it, try another framework. Using the same analogy, Android is build on top of Java language, is 'opinionated': instead of designing with Model, View, Controller components, it's designed with 'unusual' components (as in not following any classic architectures) e.g. Activity, Service, ContentProvider. You like it, you use it. You don't like it, unfortunately you still have to use it. The real issue here is a lot of developers depend on Android framework, and many of them seem to struggle with the way it's structured, with no direct replacement (not taking into account hybrid frameworks here). The way I see it, architecture is an opinionated topic. Sure classic architectures like MVC, MVP, MVVC are proven ones, but they serve as a guideline at most. There is no right or wrong if you follow this and not follow that. You are not happy with any of them, you make your own architecture/pattern. Hell it's opinionated, you are allowed to have an opinion here! If you think MVC or some other pattern is the right way to go, then the author has the right to think her design is the right way. It just keeps going on.
- emidln 10y ago
  > You like it, you use it. You don't like it, unfortunately you still have to use it. You always have the option of falling back to OpenGL-rendered widgets and using a framework with MVC if you want to. Qt supports this, for instance.
grendozy 10y ago
Android noob here. I've been teaching myself Android programming for the past couple of months and I've found it overall a messy and unpleasant experience for the reasons many of you have already mentioned. So much, in fact, that I'm looking for alternatives. So what's the best option? Kivy? Python is slow, adoption seems non-existent, not suitable for every kind of app Cordova? Web apps are slow, JavaScript sucks big time Qt? Google discourages use of the NDK for developing apps, can't figure out anything from their crappy website Xamarin? C# doesn't look like a significant step up from Java, from Microsoft Delphi? Proprietary, Windows-only and costly Clojure/Kotlin/Scala? It seems you need to be a master Android developer to use them, still doesn't get you out of the horrible Android architecture.
- virmundi 10y ago
  Android is a messy process. Since you've effectively implied that you're excluding all of the options, you only have message Android. Web apps don't suck that much as long as each screen does one thing well. Xamarin is for getting a slightly more elegant language (since Java 1.8 isn't supported) into the mix while providing a reasonable cross-system platform. Clojure/Kotlin/Scala do require you to master Android first because they are built on top of it. Each provides is own abstraction, even if it's just a language. In the end it's about trade offs and acceptance. Raw Android is like working in a better assembly. It's got decade's old abstractions. It's powerful, but annoying. For everything else, there's the complexity of working with the various abstractions over a system that does not want to be abstracted.
- m_fayer 10y ago
  I spend a lot of time in Xamarin so I'm biased in that direction, here's why I think it might bring more of an advantage than you think. C# is IMO a significant step up from whatever Java is running in Android. It's a much richer language as far as syntactic sugar (see properties, type inference), and fundamentals - optional dynamic typing, better generics than Java, and gotcha-free lambdas. The biggest advantage though is async/await, which puts c# miles ahead of Java when it comes to concurrency, something that's oh-so-important in mobile land. And of course Xamarin opens up F#, which is a whole different story. Also, C# opens up some frameworks that will give you significantly more modern techniques than what can be easily done in vanilla native Android dev. Take a look at ReactiveUI and MvvmCross, and a recent favorite - https://github.com/RolandPheasant/DynamicData https://github.com/RolandPheasant/DynamicData Now that it's free and doesn't require Windows, I definitely think anyone trying to build significant native Android apps should at least take a look.
zebob123 10y ago
The great "Advocating Against Android Fragments" post on the Square Corner blog by Pierre-Yves Ricau highlights how horrible the Android lifecycle is. https://corner.squareup.com/2014/10/advocating-against-android-fragments.html https://corner.squareup.com/2014/10/advocating-against-andro... Also, if you are doing any substantial Android development, you are bound to run into many issues (say, for instance, it's horrible soft keyboard management system). Hackborn can be found on many of these issues trashing developers asking those questions. https://groups.google.com/forum/#!topic/android-platform/FyjybyM0wGA https://groups.google.com/forum/#!topic/android-platform/Fyj... Non productive vitriol is the norm for this person.
chickenbane 10y ago
One of the biggest challenges for building on Android is its complexity, and the team must successfully integrate with a lot of surface area conceptually (the fundamental building blocks Dianne explains is just the start). This unusually negative comment thread (for HN, I think) is probably illustrative of how frustrating Android development can be. On the other hand, it's been clear to me that Google is investing heavily in making Android an easier platform to develop for. First, the tooling: Moving to Gradle for the build system was a huge improvement. Making a repeatable, extensible build is the vital with teams moving towards the DevOps world with CI/CD. Android Studio has also been a welcome change; all of the separate components of the build being integrated together makes for a much better development experience. The best example of this is Instant Run, which is a great accomplishment for the tooling team. The Support Libraries are also a solid investment for implementing good patterns - particularly patterns that can be tricky to implement yourself like the separately sliding appbars. Getting more developers to adopt the support libraries also allows more compatibility, since Google can release the fixes independently from platforms. YouTube has also been a great resource for Android developers as Google has been constantly releasing content about how to build better apps. Jo and Ian are really great. Anyway, I would watch this space. It might be a coincidence that Dianne made this post, or the most recent videos ("concurrent tasks with multiple documents" and "tasks and back stack", respectively) were also about basic Android features. Maybe Googlers are reflecting on what Android is due to the current news of Oracle v Google. Or maybe it's because IO is this week. I'll be watching!
- HillaryBriss 10y ago
  I agree that moving to AS+Gradle was a net improvement (even though Gradle is not always so quick) because it let us exactly reproduce the individual developer's build on the CI server, as you say. OTOH, I wonder how many devs really grok the Android gradle plugin and feel comfortable just writing tasks themselves without carefully copying/pasting/modifying some magical incantation from somewhere. I feel like the verdict on Instant Run is still out though. We need to get used to the complexity of IR's choices to restart the Activity or stop the entire app and reinstall the apk etc and gain solid confidence that we can just trust IR to truly reproduce our code changes in its special, optimized way.
shade23 10y ago
Tldr: that's how the system interacts, you are free to do what you want and just use the framework for system interactions if you need them. I guess this is a late reply but I feel the need to add in here considering I began my career with Android devices and because of that have looked at everything from that perspective(I write code for web apps, analytics, devops too). What everyone seems to be focusing on is how broken the android platform is. But no one sees the main theme of the post being that your code is really not necessarily a part of the design. Take the entire Android environment , Android currently works on at least a million distinct devices which vary massively in configurations (I include tv/wear/auto and maybe upcoming platforms here too). This with a 6 month major release cycle (if you want to argue about the necessity of this, it's a another topic). You really cannot break everything in the next api level and neither can you make a simple framework for the comfort of the newer programmers or people from other environs. If you really want to get to the main bit of development, there are several starter packs which can help you in the same. This would also explain the sheer number of Android libraries available. this how the system works,not your app. And unless you are building a system app you are free to do what you want and interact with the system as it dictates, because more than the Android system is designed to cater to the end user. It's not a product for developers (I look at the ios development as a a product for devs and end users). Android development is frustrating and I have had my fair share of pointless arguments on bugs which the Android team refuses to recognize. But when you go through the AOSP code you see how much of can be done with the system. The bitmap provider implementation for example is my go to code for whenever I have to perform intensive processing. The new memory manager is also an interesting piece of code which Android devs should read. And all these were written while interacting with the same framework.

220 points by EddieRingle 10y ago

I worked with Dianne fifteen years ago, and she was good. However, hearing from others who were involved in early Android, and then left in disgust, the designers who set out the initial form did boot have extensive application framework/developer experience, and we're still hiring to this day because of it. Let's say it all together: Implementation inheritance is a mistake, and interface based design is a clearer option.

thrownaway2424 10y ago
It's not just that. Hackborn spent many years denying that Android was janky as fuck, or making excuses for it (e.g. https://plus.sandbox.google.com/105051985738280261832/posts/2FXDCz8x93s https://plus.sandbox.google.com/105051985738280261832/posts/...).
- RomainGuy 10y ago
  You must be mistaking me with someone else.
  - thrownaway2424 10y ago
    Deleted, then. Perhaps I have conflated the memory of being at javaone and being told all about the wonders of javafx, and the contemporaneous wonders of "filthy rich clients".

twotavol 10y ago

Eschewing the traditional application architecture has made for both a terrible development experience and poor quality applications in general. The application lifecycle is convoluted with even the Android developers joking about how confusing it is. Everything about the model has made it far more difficult to port existing software to, and native development for me personally has been an absolute nightmare. No clean exit strategy for applications, half the methods in the lifecycle don't even get called, etc. I can't imagine the completely naive and oblivious thought process that led to the mess they created. Good thing Android is backed by Google though, so no matter how terrible it is it'll still be popular.

lanestp 10y ago
I agree. Android architecture is a mess. Activity life cycling is actually impossible. There are certain actions the OS takes that will cause crashes no matter how well architected the app is. My main quibble with Android is that since everything is tied to the activities it is impossible to build an MVC style app. You are better off using the NDK or an engine. Then you can build your software correctly.
- steplee 10y ago
  How would the ndk help, doesn't it run within an activity?
  - lanestp 10y ago
    I use the NDK a lot because you can kind of ignore the Android nonsense and structure your code properly. My approach is to have it build out the main activity then fire out into my app code. That code is beautifully MVC and for the most part ignores Activities, Fragments and Intents. For me it was faster to develop in than Android Java because I wasn't so strongly tied to the view code.
- EddieRingle 10y ago
  Do you mind expanding on some of your statements? Especially: > Activity life cycling is actually impossible. There are certain actions the OS takes that will cause crashes no matter how well architected the app is.
  - lanestp 10y ago
    I work on a very popular app in Latin America. That means we get to experience every single edge case in the eco system. My favorite quirk has been that for some reason I will never understand when an app goes into a full screen ad it can make your main activity eligible for GC. That means that you don't get any of your Activity life cycle events. Just a lone finalize and your app is gone. Then when the video ad is done you get a truly spectacular crash! Sadly, I have a half dozen different ways activities have found to explode themselves. It makes me sad!

zzalpha 10y ago

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.

userbinator 10y ago
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.)
- bigiain 10y ago
  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...)
- aphexairlines 10y ago
  26min into the 2014 Google I/O Android fireside chat: https://youtu.be/K3meJyiYWFw?t=26m https://youtu.be/K3meJyiYWFw?t=26m 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.

shruubi 10y ago

After developing a few Android apps as an agency dev, we settled on a common structure that helped keep our code relatively clean. Each activity would have an associated fragment, the idea was that the activity would be responsible for loading the fragment as the current view and other lifecycle functions as well as being the entry-point for any external data-loading (through creating and calling of services). The fragment would initiate with a reference to the parent activity as a context, and would be responsible for view-centric things like displaying content and adding event handlers, which would more often than not use the context reference to call some remote API. I suppose you could think of it in terms of Model/Controller/View-Controller but I'm sure there is a more correct model for thinking about it (and it probably is more straight MVC anyways). The problem I've found with Android is that Google has created almost it's own language when it comes to Android app architecture, which creates a lot of confusion, especially for developers who just assume that all frameworks use the MVC concept (laugh if you will, but this is a thing). Even though google is quite behind when it comes to the app market, I think there is still time for them to come out with a new set of documentation which outlines the "correct" (the "Google-blessed" one at least) structure for Android apps so that we as a development community can start moving away from the "everything-and-the-kitchen-sink goes in the current activity" style of Android development.

jc4p 10y ago
What you described sounds a lot like what I used to do for years. It works fairly well, and you can tack a headless Fragment onto it for things that you don't want directly connected to an activty's lifecycle (rotating the screen mid user sign-up shouldn't restart the HTTP call, etc). This works well, and I'm at the point where I develop it without thought while creating new apps, but I've been playing with a less constrained DI flow instead using Dagger 2. The more business logic and multiple copies of shared UI elements in different Fragments are directly connected to their parent Activity, the harder it is to re-arrange and re-use them. I've been working on migrating all core elements of our application into a shared library project, and that would've been impossible with a closely tied codebase.
- jwatte 10y ago

cnbuff410 10y ago

One thing platform engineer should do is to rotate into app engineer role and experience it for a couple month at least, without doing it you don't really understand all the pains the app engineers are suffering due to platform design. At very least you can make your doc so much better by knowing which part you absolutely want to cover in details. This is especially true for Android platform team, to be honest.

dlkfsdflkfj 10y ago
卡上就放假了SD卡分解开连锁店
dlkfsdflkfj 10y ago
sldjfklsdflksdf离开的时间发来看上对方
taneq 10y ago
Dogfood, you say? I concur. I've only dabbled in Android development but (while a lot of things do feel well designed) there are some ridiculous design choices in there. The one thing I've found really annoying is instability of the API as new versions are churned out. New features are added, deprecated almost immediately, and replaced with entirely different things (looking at you, NotificationListenerService!) It feels like they're thrashing trying to hit feature quotas or something.
spriggan3 10y ago
What a platform engineer needs to do is to listen user's feedback early and often in order to improve the API. An API is a product,and like every products there should be usability concerns. I wouldn't say Android SDK is bad, it's just so convoluted it doesn't feel like it was written in this century. It's like someone wanted to impose something regardless of its usability, a lot of design decisions seem to have been taken unilaterally because of one engineer's ego.

johndifool 10y ago

I remember her name. Wasn't she the one who vehemently was defending activity lifecycle and other broken multi-threaded API, something every Android developers I talked to would consider totally broken? To be fair, developing on Android has become so insane releases over releases that her crazy write up about no engineering design hardly comes as a surprise... Shame on Google for forcing us to use that POS.

logcat 10y ago
Shame. Shame. Shame.
ocdtrekkie 10y ago
I met her once at Google I/O, and it wasn't a pleasant interaction. I was lamenting how the recent (at the time) switch from USB Mass Storage to MTP made file transfers to and from computers very iffy. (And it's still pretty iffy today.) I was asking why the change was made, and if there was a chance at the option for it being restored, as devices used to allow both. A lot of times, files on the Android device don't show up properly in Windows Explorer. She asked what I was doing, and I said copying APK files. (I regularly used to backup APKs so I could revert software updates which degraded the experience.) She immediately stated that they "didn't support piracy" and walked off. As if the process of sideloading APKs or transferring them to and from a PC was somehow automatically illicit activity, rather than... something a lot of developers probably do regularly.
- ffiw 10y ago
  I see Android guys lack commonsense and I am not surprised. How did they think you are pirating apk's after attending I/O event that costs fortune to enter ?

HillaryBriss 10y ago

This makes my head spin. Plenty of examples on developer.android.com use Activities, Services, BroadcastReceivers for things that go beyond what Dianne Hackborn is recommending here. It's like the Android SDK team want to have their cake and eat it too: "We've built a tremendously powerful and useful SDK. It really helps you build great apps quickly and easily." vs. "Oh, and, by the way, be careful not to misuse our main components. They were never designed to help you build great apps quickly and easily."

saturn_vk 10y ago
Well, d.android.com exists to showcase the core apis. They can't possibly show you how to create an app with 3rd party components on top of a single activity. Just take the bear necessities from there add your own stuff on top.
- HillaryBriss 10y ago
  I guess I've been reading that documentation from the wrong perspective. I thought they were trying to show me the right way, or at least, a good way, to create apps and add features to them.

0xFFC 10y ago

Recently I was looking for one book desperately , a book that shows android (and its apps) architecture, form low-level to high-level, design decision which you should take when you design your app architecture. I hate how all books are kind of reference manual. If I want to see what an API doing , I will look at it documentation I don't need another book.But sadly most of books written about android is just talking about API details. p.s. If you know such book I would be grateful .

ktRolster 10y ago
You might consider this book: http://www.amazon.com/Android-Programming-Ranch-Guide-Guides/dp/0321804333 http://www.amazon.com/Android-Programming-Ranch-Guide-Guides... I've read some of their books before, and they have good understanding (and presentation) of architecture.

fighting 10y ago

They really should have stuck with int main. What's unfortunate is the quantum leaps they've been taking in terms of complexity to just get an app up and running on their platform. But I guess that's the only way their engineers can justify their salaries/bonuses. Same as with that horrific nightmare of an app Facebook puts out.

mondoshawan 10y ago
What would staying with the main entry point solve, aside from being familiar? Your application would still have to directly manage binder callbacks and register for lifecycle events. Re-using the old Java/POSIX entry point actually increases the complexity significantly.

vowelless 10y ago

Disclaimer: I am not an Android developer. I cannot seem to reconcile these two statements: > Should you use MVC? Or MVP? Or MVVM? I have no idea. Heck, I only know about MVC from school and had to do a Google search to find other options to put here. And > In Android, however, we explicitly decided we were not going to have a main() function, because we needed to give the platform more control over how an app runs. So this person claims to not know or care about design patterns; but then explicitly enforcing a design pattern? She does say: > Android could feel like it has strong opinions on how apps should be written. With its Java language APIs and fairly high-level concepts, it can look like a typical application framework that is there to say how applications should be doing their work. But for the most part, it is not. But after reading through the post, it does seem like a particular set of design patterns is being propagated.

EddieRingle 10y ago
Seems many people are missing the overall point of the post: The APIs Android provides that are listed here are intended to be used as the glue between your application and the rest of the system. However you want to build your application from that point on is up to you. In particular, Android Activities aren't simply a main() function because they are designed from a multitasking standpoint; users are going to be going in and out of apps, changing the state of the device (such as rotating the device), etc. In other application environments, you might register callbacks to fire when the window is hidden or gets resized. In Android those callbacks already exist and are set in stone to encourage apps to behave as a good citizen on a potentially resource-constrained mobile device. But as the post details, you don't have to do anything beyond properly managing heavy resources (like camera access) and saving and restoring state at the appropriate points if you don't want to.

kabdib 10y ago

You need only look as far as the large collection of flags involving the Intent object to realize how badly things went wrong.

EddieRingle 10y ago
Most Android developers I know (and even some iOS developers) consider the Intent system one of Android's diamonds in the rough. Could you perhaps explain how you would've designed it?
- Benjamin_Dobell 10y ago
  The concept may be a diamond in the rough i.e. co-operative multi-tasking. The implementation, not so much.
  - tuukkah 10y ago
    The user interface concept might be called UI subroutines, along the lines of UI continuations of this paper from an MIT research project in 2003: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.2884 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.2...
  - georgemcbay 10y ago
    Speaking as someone who has been writing Android software for like 4 years now as my job (but who has been in the industry for much longer than that, as a 42 year old who has programmed in just about every major environment), I agree with what you wrote here. Intents are great in concept and they work out well for users, but the interface/API for using them to do anything can quickly become painful if you go even a step off the beaten path of "perform this operation with these parameters". A common recurring theme with Android (and this applies to all the major bits -- Activities, Fragments, Services, etc) is that you'll easily hang yourself if you don't have a really clear picture of how they actually work but you attempt to use them. Android almost completely fails, IMO, when it comes to the concept of "keep the easy things easy". There's a huge upfront cost to understanding the major components before you can start really using them at all safely, in my experience. As a bare minimum, if you don't have an intimate understanding of the Activity and Fragment lifecycles and a full understanding of what needs to be on the UI thread when (and when different callbacks from the OS are/aren't on the UI thread) you are likely to create a terrible mess of an app that kinda sorta works on most devices, usually, but is broken in some fundamental ways you aren't aware of. I don't personally know any day to day Android developers who haven't spent a considerable amount of time in the AOSP code trying to figure out exactly how some of these systems work because failing to understand them internally combined with lack of any sort of clear direction from the platform team (extremely open case of there being more than one way to do anything, which makes authoritative answers to the question "How should I do this?" nearly impossible without a long list of caveats) is the path to writing Android code which mostly works but has some fundamental mismatches with the operating system and becomes a complete mess to maintain.

Benjamin_Dobell 10y ago

Unfortunately, the contents of this post are no surprise to any seasoned Android developer. It's very clear the Android engineers haven't given a lot of thought to how applications are to be developed. I'm all for them not enforcing one methodology over another. However, in order to build an Android application (following whatever pattern) we do need core building blocks that have been well thought through on how they will be used. In general performing Async tasks (in particular networking) is excruciatingly convoluted on Android - well, at least to get it right. Many inexperienced Android developers simply get this wrong, and quite frankly I can't blame them. Such a common task should be trivial to perform and not require hours of background reading. The issue largely comes down to the fact the "system framework" has been designed to be simple (supposedly[1]) for system framework maintainers, and not developers writing applications. Destroying and recreating activities (so you can load different resources) may be simpler from AOSP's perspective, but it's not at all logical from the perspective of an application. Sure, there are several ways to work around this, but they're all stupidly convoluted. Frameworks should be written for consumers, not maintainers. [1] Okay, the system frameworks definitely aren't actually well designed / simple to work with for framework maintainers either, that was just the (missed) goal. If you want to see world's worst state machine (a stupid amount of booleans), check-out: http://stackoverflow.com/questions/17847775/nested-fragments-illegalstateexception-can-not-perform-this-action-after-onsa http://stackoverflow.com/questions/17847775/nested-fragments...

bigtones 10y ago
Yes, Dianne Hackborn was one of the main proponents and designers of the fragment system lamented in your StackOverflow question referenced: http://android-developers.blogspot.com/2011/02/android-30-fragments-api.html http://android-developers.blogspot.com/2011/02/android-30-fr...
lern_too_spel 10y ago
You've hit the nail on the head. It's not the system engineer's job to develop a useful application framework for common use cases any more than it is a Linux kernel developer's job to do so. Still, it has to be somebody's job, and it's clear that it isn't anybody's job on the Android team. For example, there's a hacky HTTP client library built by the Google Play Android client team (http://developer.android.com/training/volley/index.html http://developer.android.com/training/volley/index.html) that is promoted for general use for some silly reason, and to use it, you're supposed to copy the library's source code into your project. Pure amateur hour. There should be a team within Android building well-thought-out, properly versioned, and sanely distributed libraries to simplify Android application development. There should be, but there isn't.

petra 10y ago

If this is so terrible, why isn't there some Java framework on top of this that's designed to make sense for developers?

ktRolster 10y ago
I hear Oracle has something available for that.
jmfayard 10y ago
They do exist. Check out rxjava from netflix, dagger and butterknife and okhttp and retrofit and picasso (and and....) from square, MVP libraries, kotlin and anko from jetbrains What is truly holding back many developers is the above cargo cult that the path mentionned in android.developer.com is always the right one. There have been some harsh comments on Dianne Hackborn, but I find that she is actually doing us a great service here by dissiping this myth. I find she does a great job at explaining what is the scope they really care about, and the one where you are free to discover better alternative that do not have the "Google" label on it.
- kodroid 10y ago
  I agree with your last two statements, but the idea the RxJava and Dagger make things _easier_ to understand for developers (I'm inferring this relates more to newcomers to Android as they are the once which have a hard time grokking this stuff) is a joke. RxJava and Dagger only increase ramp up time and the amount of stuff to learn, regardless of how useful they are. If someone came to me confused and I pointed them in that direction, Im sure they would get lost in the woods somewhere and Id never see them again.
  - jmfayard 10y ago
    Fair point. They make things simpler, not easier
- HillaryBriss 10y ago
  > What is truly holding back many developers is the above cargo cult that the path mentionned in android.developer.com is always the right one. Yes. I sometimes think we need to embrace an "Android-free Android programming" approach where we use builtin Android components as little as possible and better written 3rd party components and libraries for everything else.

bengotow 10y ago

I think it's fine for the Android team to take this approach like so many framework authors before them. I think the problem is that Android developers are seeking patterns and prescriptivist documentation because that's what many other platforms offer these days. On iOS, the message has always been clear: "Use MVC, delegates & data sources, storyboards, etc. /We use them internally/ and you should too. Don't go re-invent UIViewController!"

hidro 10y ago

Rails is built on top of Ruby language, designed to be opinionated, following MVC. You like it, you use it. You don't like it, try another framework. Using the same analogy, Android is build on top of Java language, is 'opinionated': instead of designing with Model, View, Controller components, it's designed with 'unusual' components (as in not following any classic architectures) e.g. Activity, Service, ContentProvider. You like it, you use it. You don't like it, unfortunately you still have to use it. The real issue here is a lot of developers depend on Android framework, and many of them seem to struggle with the way it's structured, with no direct replacement (not taking into account hybrid frameworks here). The way I see it, architecture is an opinionated topic. Sure classic architectures like MVC, MVP, MVVC are proven ones, but they serve as a guideline at most. There is no right or wrong if you follow this and not follow that. You are not happy with any of them, you make your own architecture/pattern. Hell it's opinionated, you are allowed to have an opinion here! If you think MVC or some other pattern is the right way to go, then the author has the right to think her design is the right way. It just keeps going on.

emidln 10y ago
> You like it, you use it. You don't like it, unfortunately you still have to use it. You always have the option of falling back to OpenGL-rendered widgets and using a framework with MVC if you want to. Qt supports this, for instance.

grendozy 10y ago

Android noob here. I've been teaching myself Android programming for the past couple of months and I've found it overall a messy and unpleasant experience for the reasons many of you have already mentioned. So much, in fact, that I'm looking for alternatives. So what's the best option? Kivy? Python is slow, adoption seems non-existent, not suitable for every kind of app Cordova? Web apps are slow, JavaScript sucks big time Qt? Google discourages use of the NDK for developing apps, can't figure out anything from their crappy website Xamarin? C# doesn't look like a significant step up from Java, from Microsoft Delphi? Proprietary, Windows-only and costly Clojure/Kotlin/Scala? It seems you need to be a master Android developer to use them, still doesn't get you out of the horrible Android architecture.

virmundi 10y ago
Android is a messy process. Since you've effectively implied that you're excluding all of the options, you only have message Android. Web apps don't suck that much as long as each screen does one thing well. Xamarin is for getting a slightly more elegant language (since Java 1.8 isn't supported) into the mix while providing a reasonable cross-system platform. Clojure/Kotlin/Scala do require you to master Android first because they are built on top of it. Each provides is own abstraction, even if it's just a language. In the end it's about trade offs and acceptance. Raw Android is like working in a better assembly. It's got decade's old abstractions. It's powerful, but annoying. For everything else, there's the complexity of working with the various abstractions over a system that does not want to be abstracted.
m_fayer 10y ago
I spend a lot of time in Xamarin so I'm biased in that direction, here's why I think it might bring more of an advantage than you think. C# is IMO a significant step up from whatever Java is running in Android. It's a much richer language as far as syntactic sugar (see properties, type inference), and fundamentals - optional dynamic typing, better generics than Java, and gotcha-free lambdas. The biggest advantage though is async/await, which puts c# miles ahead of Java when it comes to concurrency, something that's oh-so-important in mobile land. And of course Xamarin opens up F#, which is a whole different story. Also, C# opens up some frameworks that will give you significantly more modern techniques than what can be easily done in vanilla native Android dev. Take a look at ReactiveUI and MvvmCross, and a recent favorite - https://github.com/RolandPheasant/DynamicData https://github.com/RolandPheasant/DynamicData Now that it's free and doesn't require Windows, I definitely think anyone trying to build significant native Android apps should at least take a look.

zebob123 10y ago

The great "Advocating Against Android Fragments" post on the Square Corner blog by Pierre-Yves Ricau highlights how horrible the Android lifecycle is. https://corner.squareup.com/2014/10/advocating-against-android-fragments.html https://corner.squareup.com/2014/10/advocating-against-andro... Also, if you are doing any substantial Android development, you are bound to run into many issues (say, for instance, it's horrible soft keyboard management system). Hackborn can be found on many of these issues trashing developers asking those questions. https://groups.google.com/forum/#!topic/android-platform/FyjybyM0wGA https://groups.google.com/forum/#!topic/android-platform/Fyj... Non productive vitriol is the norm for this person.

chickenbane 10y ago

One of the biggest challenges for building on Android is its complexity, and the team must successfully integrate with a lot of surface area conceptually (the fundamental building blocks Dianne explains is just the start). This unusually negative comment thread (for HN, I think) is probably illustrative of how frustrating Android development can be. On the other hand, it's been clear to me that Google is investing heavily in making Android an easier platform to develop for. First, the tooling: Moving to Gradle for the build system was a huge improvement. Making a repeatable, extensible build is the vital with teams moving towards the DevOps world with CI/CD. Android Studio has also been a welcome change; all of the separate components of the build being integrated together makes for a much better development experience. The best example of this is Instant Run, which is a great accomplishment for the tooling team. The Support Libraries are also a solid investment for implementing good patterns - particularly patterns that can be tricky to implement yourself like the separately sliding appbars. Getting more developers to adopt the support libraries also allows more compatibility, since Google can release the fixes independently from platforms. YouTube has also been a great resource for Android developers as Google has been constantly releasing content about how to build better apps. Jo and Ian are really great. Anyway, I would watch this space. It might be a coincidence that Dianne made this post, or the most recent videos ("concurrent tasks with multiple documents" and "tasks and back stack", respectively) were also about basic Android features. Maybe Googlers are reflecting on what Android is due to the current news of Oracle v Google. Or maybe it's because IO is this week. I'll be watching!

HillaryBriss 10y ago
I agree that moving to AS+Gradle was a net improvement (even though Gradle is not always so quick) because it let us exactly reproduce the individual developer's build on the CI server, as you say. OTOH, I wonder how many devs really grok the Android gradle plugin and feel comfortable just writing tasks themselves without carefully copying/pasting/modifying some magical incantation from somewhere. I feel like the verdict on Instant Run is still out though. We need to get used to the complexity of IR's choices to restart the Activity or stop the entire app and reinstall the apk etc and gain solid confidence that we can just trust IR to truly reproduce our code changes in its special, optimized way.

shade23 10y ago

Tldr: that's how the system interacts, you are free to do what you want and just use the framework for system interactions if you need them. I guess this is a late reply but I feel the need to add in here considering I began my career with Android devices and because of that have looked at everything from that perspective(I write code for web apps, analytics, devops too). What everyone seems to be focusing on is how broken the android platform is. But no one sees the main theme of the post being that your code is really not necessarily a part of the design. Take the entire Android environment , Android currently works on at least a million distinct devices which vary massively in configurations (I include tv/wear/auto and maybe upcoming platforms here too). This with a 6 month major release cycle (if you want to argue about the necessity of this, it's a another topic). You really cannot break everything in the next api level and neither can you make a simple framework for the comfort of the newer programmers or people from other environs. If you really want to get to the main bit of development, there are several starter packs which can help you in the same. This would also explain the sheer number of Android libraries available. this how the system works,not your app. And unless you are building a system app you are free to do what you want and interact with the system as it dictates, because more than the Android system is designed to cater to the end user. It's not a product for developers (I look at the ios development as a a product for devs and end users). Android development is frustrating and I have had my fair share of pointless arguments on bugs which the Android team refuses to recognize. But when you go through the AOSP code you see how much of can be done with the system. The bitmap provider implementation for example is my go to code for whenever I have to perform intensive processing. The new memory manager is also an interesting piece of code which Android devs should read. And all these were written while interacting with the same framework.