I wrote an article about billion-dollar mistakeS. The good one from Tony Hoare, and the others that stay un-spoken https://dev.to/jmfayard/android-s-billion-dollar-mistake-327b

Not sure whether to laugh or cry at your post ….

Whatever please you the most

Thanks for the article! I really enjoyed reading it ☺️

The billion dollar mistake is not the existence of

null

, it’s languages that have null values but no support for it in their type system.

I heard (no reliable source) that it had something to do with the very resource constraint environment at the beginning of android (shitty phones from a right-now perspective). Is there something to it?

Absolutely

The billion dollar mistake is not the existence of

null

, it’s languages that have null values but no support for it in their type system.

Hello, I have updated my article, this merits to be said more clearly.

That benefit is largely theoretical, though. Not sure what such an admission would actually accomplish in practice.

Not sure what such an admission would actually accomplish in practice. @cedric

Look at the crap that the official Android documentation still produce today: https://github.com/android/camera-samples/blob/f555592364979f4005db0bea40753e0de52c8d86/Camera2BasicKotlin/Application/src/main/java/com/example/android/camera2basic/Camera2BasicFragment.kt#L60-L817 This, I can’t accept.

But again, what would be accomplished by saying such a thing? I just don't see it

Well, because if everyone can recognize that this burriton design pattern is a mistake, then they will probably stop doing it.

Already happening

@cedric you asked me a question. My answer is: I will be satisfied once the official Android documentation has been fixed. This is not the case today.

Fixed to say what?

Fixed to stop putting all the crap in a GodActivity or GodFragment that you cannot test and cannot maintain. Other companies follow the pattern and the Android world is piling up layers of technical debt because of that

That's not a documentation fix, it's an implementation fix.

I don’t get your point.

Thanks for writing this article on Dev, not Medium

@pavi2410 I always write on Dev first, and sometimes I cross publish on Medium. Also I added support for the Kotlin Playground on Dev, check out this article for example https://dev.to/jmfayard/with-configobject-language-kotlin-issparkingjoy-ic4

@cedric I think it would help the whole community a lot if the Android team would identify any mistakes which were made. And there is a lot to talk about…

@Sebastian Sellmair [JB] or the community can speak for itself, that also works. I started an epic thread here https://www.reddit.com/r/androiddev/comments/d822s8/which_areas_of_android_development_are_bad_and/

To add my two cents, the Android team has started making improvements to app architecture to avoid the “activity burritos”, most notable Viewmodels and other Jetpack components. The problem isn’t that the activity is a context and holds references to system resources, it’s just that there was no separation of concerns for the longest time. Data and UI were handled in the same class, be it a Fragment or an Activity, and that just made it very difficult to manage the lifecycle. Separating data into ViewModels and UI logic into view/databinding/livedata is exactly the solution that is needed to fix the problem, and it really does wonders for the overall maintainability/testability of an app

I agree with you @Casey Brooks

The mistake was in taking too long to stop treating that class as the place to handle data logic

But here you a bit too generous to my taste. This is still on ongoing issue as I have shown with this official Android sample https://github.com/android/camera-samples/blob/f555592364979f4005db0bea40753e0de52c8d86/Camera2BasicKotlin/Application/src/main/java/com/example/android/camera2basic/Camera2BasicFragment.kt#L60-L817 Maybe they should first fix their documentation and samples, and then we can give the Android team the benefice of the doubt?

I completely agree, they have a long way to go in fixing this mess, but they are starting to guide developers in the right direction

Funny, Thanks for sharing! Overall I would agree. The Framework API is not the best. Fortunately #squarelibraries has been helping since very early stages. However, besides of the some bad design APIs I love the nature of being Open where I can see whatever is written inside the framework. Apple API is bad too and you have no more option than going through their poor documentation. Flutter Framework API not great either. They force you to be a Widget. Android is very open in the sense that you can see your Activity as your main() function in other platforms and start building on top of that.

I don't understand the premise of this argument. Android was designed in such a way because that is what was best for the technology of the time. Claiming it was a "mistake" because technology would change in the future is just wrong. That's like saying Java was a mistake because Kotlin would come along later. Or that flip-phones were a mistake because smart-phones hadn't been invented yet. Or that the Aquaduct was a mistake because someday someone would think up indoor plumbing.

Good point

@fayssel I do see what you mean about promoting best practices may need to change with the times, but the article (and discussion here) still comes across as claiming it was a mistake cased by short-sightedness or carelessness.

Not even null was a mistake but rather the mistake was not including it in the type system like Kotlin, Swift and other modern languages do.

@Pablichjenkov That's exactly what I said above

Yeah I know, I was just re-confirmming it since the thread is a bit long 🙂

@Ruckus I am repeating myself at this point, but the mistake is to not admit that this is a problem today. As a consequence, it’s still an issue today that the official documentation and samples put all the logic inside the God Activity+Context, and lots of un-neccessary pain and suffering ensue in the real world. This is what I learned from Tony Hoare: taking responsability for your mistakes is great for the common good.

I do agree on that. Most of the official documentation do not guide properly new developers in the platform. Unless you are surrounded by experienced folks that guide you in the right direction. I do really think the context inheritance cluster was a mistake, and Fragments too and the non-scalable storyboardy Navigation Component too and the fake ViewModel as well and I can make a book of Android bad designed APIs. However, I do also agree with the fact that calling them mistakes might sound harsh. Specially when it was the first created API and there was nothing to compare. But definitely we must admit our mistakes.

I think ultimately, calling something that Android made a “huge mistake” is immediately defeated by the fact that Android is a dominant force today and if anything had been done differently, we’d probably live in an iPhone monopoly world. Having said that, this argument should certainly not be used to exculpate Android from everything. Mistakes were certainly made, but a lot of these need to be put in perspective with their timing.

I couldn't agree more. I would call it the 100 bucks mistake not the one billion. Android just gets better!

Thanks to everyone who provided valuable feedback, whether they agree with me or not, cc Cedreic Beust 😛 I did my best to listen to the feedback and fix things that were misleading, because that was the whole point of the article, and I think it made the article better https://dev.to/jmfayard/android-s-billion-dollar-mistake-327b

@cedric You seem very focused on the decision of making

Activity

extend

Context

and what was the context back then (prevent a monopoly by Apple). It's perfectly understandable, and it's also understandable that can't change so easily and 10 years, this design hasn't changed. That said, all the samples that put everything in an Activity or a Fragment are serving the developer community very, very badly, and I say this after 5 years doing Android app development for a living. So it'd be great for Google to openly say that god activities and god fragments that are close to 1K lines of code or more are bad, and for that to be the start of composable samples that are actually more helpful than raw documentation. That is what we, including Jean-Michel are hoping for. We want Google to tell beginners and the community : stop doing this, it creates spaghetti code and unreliable products, here are better examples. I hope it's more clear to you now. Also, I know you no longer work for Google. @Adam Powell what do you think?

goodness, what a thread 🙂

I also find it interesting that even though in hindsight,

Activity

extending

Context

is today seen as an obvious violation of composition rules, I still think the overall negative effect is pretty mild. The god object argument is totally unrelated to that inheritance decision.

It's the difference between an unintentional listener capture having access to system services, configuration and resources vs. keeping hard references to the window and view hierarchy ¯\_(ツ)_/¯

true at Cedric, god objects is something a developer should prevent always. No matter if on Android or other platform. Fractioning big classes and big methods into smaller pieces is something out of Google Samples business.

it's true that we've made some stinker samples over the years when trying to make an unrelated point. The team is probably tired of me saying, "no more `ListActivity`" APIs that exist only to serve code samples and that clearly don't scale.

I think a sample is a sample and every developer should realize that. It just shows the minimum sellable points of an API. Now if you hired a developer that blindly copy and paste from stackoverflow post or clone a sample from Google Sample repo and start building on top of it. Then you should invest in a better hiring team.

that's easy for us to say but it's a reality 🙂

jiji, I have seen what Louis mentioned in some places. Usually every body is Super Senior developer there. 🧌

@Adam Powell @Pablichjenkov Thanks for being in this debate. There is one point where I completly disagree: "A sample is a sample and every developer should know that". No, I think you should start from the reality that people trying to learn things are using the documentation as a blueprint and be very careful at how you document things. The documentation is your chance to either guide them gently on a good path, or do the contrary of that. This is hard work and I am aware of this. But it is important work. In 2014-2015 I was a young inexperienced developer in a team of young inexperienced developer, we followed what the documentation taught us, and the result was painful.

Understandable, that's right in some cases there are no experienced Devs that could guide the new comers. Then maybe Google should start cleaning up the misleading documentation pages and place a link to a Github repo having the good practices. I think they have been doing that lately.

I also very strongly on "A sample is a sample and every developer should know that". All new developers are beginners and there's a period where you can't judge accurately, so you'll start by following half-blindly, and as Jean-Michel says, the result can be painful. Every sample from an extraordinarily big company like Google (or Apple, or JetBrains, or Microsoft, etc) should either be state of the art, because beginners will learn from it, or they should have ALL_CAPS_BOLD disclaimer about not being a good architecture example (and link to good examples, even if that's beyond the sample's purpose). With so many ways to become a developer, newcomers will take whatever is there, and the road panels are important for people to not all end up in hell road. I hope my message makes it well into Google sample committers @Adam Powell 🙂

The practical outcome of saying, "all samples must be perfect or not be published" is going to be a lot fewer samples being published and a lot more questionable accepted stackoverflow answers out there as a substitute. 🙂 see my prior comments on perfect as enemy of the good. If you take a look at something like the arch components github browser sample https://github.com/android/architecture-components-samples/tree/master/GithubBrowserSample there are more holistic app samples up there, but if you take this idea to mean that it's invalid to have isolated samples of a single idea without a whole supporting app architecture alongside it, I don't think that's a good state to be in either. Balance in all things.

Well, I prefer to be warned, especially if I don't have a driver's license yet, which is the case for beginners. Quality is better than quantity, but when you drop quality, it's good to make it obvious to everyone, including beginners, that this is not top quality. People remember their first experience, and that defines much of the rest and whether they continue, and if they suffer.

That's not true at all. Putting every possible warning everywhere is a sure way to ensure all warnings are ignored. It's a strange but well documented phenomenon. You could use the same argument to require every example include a BIG BOLD WARNING about not using the same variable names as the one in the sample (or same package names/structure, etc.). Pretty soon you end up with exactly California Prop. 65 as @Adam Powell said, and this warning will be lost in the sea of PROGRAMMING IS KNOWN IN THE STATE OF CALIFORNIA TO CAUSE CANCER, BREATHING IS KNOWN IN THE STATE OF CALIFORNIA TO CAUSE CANCER, THINKING IS KNOWN IN..., etc.

I am glad that you have found a straw man argument that you can easily refute @Ruckus I still think that stopping to mislead new developers with bad practices would be good

We've tossed around the idea of having developer.android.com itself more prominently (and more importantly, automatically) display the age of a particular guide or article for this reason for some added context and I think that could still be quite useful here. As for the docs of newer components like Room, yes, we're on the same team and that represents much more up to date thinking about this whole space that the team is agreed and aligned on. 🙂

@jmfayard Forgive me, I didn't mean to make it into a straw man argument. I only meant to refute the claim of "it doesn't hurt anyone" and throw a little levity in. I hope it didn't come across as condescending. My point was that, while it is important to this discussion, the warning isn't really intrinsically better than a warning such as "these are bad variable names" or anything else, and so requiring this warning everywhere would easily cascade into requiring every other warning that a new developer might not be familiar with, and you either end up with so many warnings no one reads them, or one vague "this is bad code" warning that would do more harm than good. Again, I'm not saying the code examples are good as they are, I was only pointing out why I didn't like that one idea.

Yep 🙂

If I may offer my (unpopular) opinion, I think expecting people to understand that examples of a concept are not examples of best practices in app architecture is reasonable. Of course it may confuse those with too little experience, but at some point you need to have an expectation of minimal experience. If you'll excuse the hyperbole, it isn't reasonable that every code example include a tutorial on on setting up Android Studio and an introduction to Java/Kotlin. I know that sounds ridiculously absurd, but that's really just because we assume some threshold. This isn't inherent to Android, either. Many JavaFX examples do the same thing (putting the entire example into a single

Application

class), despite the fact that it's considered just as bad practice there, but including a fully constructed app following all best practices just creates a significant amount of noise you have to fight through to get to the one concept you're looking for.

@Ruckus I don’t take this as an attack. But either the official android documentation service should not be used by beginners, and then fine, I will tell them to use other sources like RayWenderlich.com Or it is supposed to use by beginners, and then the status quo is a problem. And by the way, the documentation for writing JavaFX application with Kotlin is very good https://edvin.gitbooks.io/tornadofx-guide/

Just like everything, there's a sweet spot between nothing and too much. That means a sweet spot exists between no warnings and too many of them. What I see today in official Android developers materials is no warnings where there should be. IMHO, we're definitely on the not enough end, and that is causing harm to the community, starting from newcomers. That said, of course, we don't want to get too much warning as it'd become noise that people would just ignore. So, I hope to see more warnings on not ideally (i.e. poorly) architectured samples (like Camera2 samples and their 700+ lines of code fragments/activities), so people know to take the example as an "example" with grains of salt, and look for better things (CameraX, coroutines based libraries to cut the callback hell…), higher level use case focused libraries, etc in such cases.

Android was designed in such a way because that is what was best for the technology of the time.

Wasn't it designed to become another Blackberry and then was forced to scrap the prototype and play catch with iOS? 🙂 "Weird shit" in its DNA, not "best for the technology of the time".

Considering that Android came out with an SDK in 1.0 and iOS didn't and then introduced one later, I'd say it's iOS that played catch up with Android.

Considering iOS added pull down notification bar in version 5 of the OS, I'd not say "Android plays catch up with iOS". They just take on different things at different times.

Btw, small offtop, I had some eye opening experience recently. I witnessed our iOS project dependency file. It's like 4-5 libraries max, lol. Compared to my ~50 entries in gradle. I don't do iOS, so I don't have a good explanation, but I can't help but think that all this arsenal on our side is basically fixing the framework. Or, we just like libraries.

Its called modularity and freedom in companies creating their own libs. In iOS almost everything is given by Apple. There you don't code you basically follow tutorials 🧌

@ghedeon There is a lot of value in being very deliberate about what you put in the system. JetPack Compose is a good example of a framework which, by design, is a library and not embedded in the OS. This allows faster iterations and also makes it easier to correct mistakes and to adjust to the state of the art more quickly.

Splitties

from @louiscad is an also a great example of that 😛 https://github.com/LouisCAD/Splitties#all-the-android-splits Frankly it adresses a lot of the problems I had with Android. So I’m not saying that Android isn’t a platform where you can build good products. You can. It’s just that for historical path-dependent reasons, traditional Android programming were a rather dark age of programming as you can remember by vividly by having a look at older codebases. and then things did evolve in a globally positive way, but not quickly enough to my taste. There is still a lot of zombies ideas that plague the android community. The hard part is not to learn the new things but to unlearn the old

Lol just read your blog. Interesting, but I got to disagree with some of your points. Hungarian Notion wasn't a billion dollar mistake. It was about a big of mistake as using underscore to prefix private variables. It made sense at the time, and it simplified finding private variables in intelj. And you weren't force to use that syntax... I don't know if you can consider activity a "God Activity". When you think about it, most frameworks make you work off some kind of base class, one way or another.. The biggest issue with the actual framework design, was it being one big inheritance party, to the extent that component would inherit things that were impossible for them to use ... That and Lifecycle complexity. But I think all that has been improved upon. Documentation(developers.android.com) has pretty good documentation, of all there latest stuff. I think Documentation only gets complicated when your looking at older API's because somethings where not updated

The question was never about whether Hungarian Notation was the billion dollar mistake, I think you got things confused. The alleged Billion Dollar mistake is about the `null`value.

@rkeazor This is one part of the problem: "I think Documentation only gets complicated when your looking at older API's because somethings where not updated" The other part of the problem is that the Android documentation does not cover or cover badly all the excellent things that are not produced by the Android team but are super useful to build your own app. Retrofit, okHttp, RxJava, Gradle, Coroutines, better unit tests framework... are either not covered there, or covered badly. AsyncTask, Loaders, IntentService and lots of other bad things are covered there. Why? It's a simple but important point that beginners need to be aware of: - The Android team document their own stuff, whether there are good or not - The Android team generally do not document other's people stuff, whether there are good or not.

There's d.android.com/kotlin/coroutines, but it's not advertised well in the parts where

AsyncTask

and other stuff are still documented.

@jmfayard Why would they write documentation on things they didnt create or have ties to lol. Those open source libraries have there own documentation written by there own creators. They have documentation on coroutines because they joined up with Jetbrains. Them not having documentation on Retrofit and other open source libraries doesnt not constituent for having bad documents

@rkeazor “Why would they write documentation on things they didnt create or have ties to lol.” They don’t have to. It just means that - a lot of irrelevant things are present in https://developer.android.com/ and - a lot of relevant things do not appear on https://developer.android.com/ People need to be aware of this

@jmfayard they write documentation on things they create. Every Api they have , there is documentation for it. That's like saying IOS documentation is bad , because they dont have documentation on flutter lol. You may find some of it irrelevant, but somewhere someone on some project is using that same information in that you found to be irrelevant. There is a big difference between good documentation and hand holding. Good documentation clearly illustrates how a framework works. But if you want to understand how a open source library work it's your job as a dev to goto the project page and learn about it

The sad reality is, newcomers go to documentation, learn nonsence, go to real company, realize the real world operates differently in a harsh way (your senior peers: "Oh, tell me more about AsyncTask and Loaders"). Welcome to Android 😄.

@rkeazor I believe you are conflating two different points. The documentation being bad and the documentation not including third party libraries are two separate and unrelated points. As I understand it, he was saying the documentation is bad because it contains a large amount of out-of-date information. He also made the (separate) point that people may not realize there is more documentation elsewhere for other things (and should be made aware).

@Ruckus the thing is, those old APIs are still being used so there is still documentation for them. You cant just get rid of documentation, people work on projects that contains large amount of legacy code , that use those apis so you cant remove them . The most you can do is note that its depreciated... And no , they dont need to document about popular open source libs. It doesnt make sense to put that in the documentation. At most those are just suggestions. Now do I think they should adopt some libraries, sure. But until that happens no need for it to be in the documentation

I didn't suggest removing documentation or adding third party stuff to the official documentation (there is a vast difference between "people should be made aware" and "this needs to be in the official docs"). I also didn't say anything about old APIs. This article was about out-of-date information, such as code examples that are no longer considered best practices. (Frankly, I wasn't making any suggestions at all, just trying to clear up what I perceived to be a misunderstanding between what the article said and how you interpreted it.)