https://kotlinlang.org logo
Join Slack
Powered by
I wrote an article about billion-dollar mistakeS. ...
# feed
j
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
👏 7
👍 7
s
Not sure whether to laugh or cry at your post ….
😁 1
j
Whatever please you the most
😁 3
s
Thanks for the article! I really enjoyed reading it ☺️
🙂 1
c
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.
👍 2
Kotlin’s fix is not to remove 
null
but to support it in a type safe manner
👍 2
As for your more specific point, I was part of the decision that led to make 
Activity
a 
Context
, there is a lot of history behind it
d
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?
c
Absolutely
We made similar shortcuts in other areas (e.g. views and layouts in one class instead of being composable)
j
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.
@cedric I don’t know if I was clear, but although they are painful today, I do understand that shortcuts were made in a given historical context. It’s the same story with JavaScript whose design was rushed in, and then shipped in Netscape 1.0. My real point is the benefit of admitting clearly a mistake like Tony Hoare did
c
That benefit is largely theoretical, though. Not sure what such an admission would actually accomplish in practice.
At the end of the day, Android today has 80% market share and it killed Apple as a potential mobile monopoly. Any criticism you can throw in its direction will be laughed right out of the room.
➖ 1
"Sure we might have designed Android differently but if we had, you and I wouldn't be having this conversation right now because Apple would have 95% of market share and Android would have died ten years ago".
➖ 1
j
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.
c
But again, what would be accomplished by saying such a thing? I just don't see it
j
Well, because if everyone can recognize that this burriton design pattern is a mistake, then they will probably stop doing it.
c
Already happening
Doesn't matter whether a team that designed an OS 13 years ago says "We made a mistake".
Totally irrelevant, really.
(and personally, I don't think we made a mistake and I stand by the compromise we made)
j
@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.
c
Fixed to say what?
j
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
➕ 2
This is just one example, in general if the official Android documentation would stop misleading people in wrong directions, I would be very happy.
➕ 1
c
That's not a documentation fix, it's an implementation fix.
j
I don’t get your point.
I don’t say “please stop having Activity implements Context”, I say please stop preaching bad practices that make the problem much worse. This is possible to do today.
p
Thanks for writing this article on Dev, not Medium
j
@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
s
@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…
➕ 1
j
@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/
👍 2
c
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
To reiterate my point: the billion-dollar mistake was not making an Activity a Context. The mistake was in taking too long to stop treating that class as the place to handle data logic
j
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?
c
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
p
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.
r
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.
🤔 1
➕ 1
👍 1
p
Good point
r
@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.
p
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.
c
@Pablichjenkov That's exactly what I said above
p
Yeah I know, I was just re-confirmming it since the thread is a bit long 🙂
j
@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.
p
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.
c
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 use the same argument to justify that Java’s choice of having primitive types (
int
instead of 
Int
) was not a mistake and actually, probably instrumental to its success.
p
I couldn't agree more. I would call it the 100 bucks mistake not the one billion. Android just gets better!
j
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
l
@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?
a
goodness, what a thread 🙂
regarding 
Activity
extending 
Context
, I know the person who committed that change and it was in direct response to the app teams at the time complaining loudly and over time that they had to call 
getContext()
all over and why can't they just pass their 
Activity
instead - it is indeed looked on by that person and others with the benefit of hindsight as regrettable
but it's that benefit of hindsight that @cedric is referring to - thousands and thousands of these decisions made by many people over ~15 years now targeting very different circumstances. The kinds of apps people write today are far different from the apps people wrote in 2008, 2010, or 2012 and it's kind of easy to forget that
app teams were like, 1-5 engineers, tops. Now you have top apps with hundreds of active committers
you simply need different architectural patterns once you cross two full orders of magnitude in team size
as for, "don't make monolithic activities," that's been a topic of discussion over the years too, and one we cite rather frequently whenever we talk about the android architecture components libraries. Dianne's G+ post is lost to time now but the gist was that things like Activities were meant to be entry points to app code, just like 
main()
in other environments. It didn't occur to much of the team that readers would see the equivalent of,
Copy code
int main() {
  printf("Hello, World!")
}
and take away, "oh, I should put my entire app in 
main()
!" 🙂
Again, hindsight.
c
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.
(and actually, instead of "composition rule", I should say "composition best practice". I don't like dogmatic rules)
a
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 ¯\_(ツ)_/¯
the practical implications are pretty nasty
but again - this predates code styles that involve lambdas or even really extensive use of anonymous inner class reference capture. "best practice" at the time was separate and explicit listener classes so it came up far less frequently
p
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.
a
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.
we have an ongoing debate that still continues today around the perfect being the enemy of the good when it comes to docs, samples and API surfaces alike
p
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.
a
that's easy for us to say but it's a reality 🙂
The debate around when to show some more complex patterns that scale well vs. omit them in an appeal to YAGNI certainly still continues. Most recently that I've been involved in is a question of when to teach and encourage state hoisting for #compose
p
jiji, I have seen what Louis mentioned in some places. Usually every body is Super Senior developer there. 🧌
Its all part of the Software Lifecycle. Api v1 is released, dev build on top of it, App v1 ships to production, management celebrates. Then Api v2 is released, dev realized Api v1 was bad, takes more time to integrate b/c the changes, then hire new devs, App v2 ships, celebration again. Api v3 ... same process. Bottom line, this called "mistakes" are part of the industry, keep it busy and vital for the evolution of it. Are we gonna called "mistake" too all the unstructured concurrency existing out there in many languages that offer Threading APIs.
j
@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.
p
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.
l
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 🙂
a
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.
That said a huge value prop of compose is to make those minimal samples a lot more focused without encouraging janky sample harnesses as a side effect, so there's that at least!
I'm not super interested in creating the California Prop. 65 of code sample warnings to plaster everywhere though 🙂 best case it becomes noise to ignore, worst case it becomes conspicuous by its absence somewhere someone forgets to add it
➕ 1
l
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.
Warnings are not hurting anyone. They are honesty.
r
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.
😆 1
j
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
I’m not a perfectionist either @Adam Powell You have a point since the bad samples and documentation are published it’s too late to un-publish them. But I see nothing wrong with adding a warning like This sample and its documentation was written years ago and do not match our current standards. We are working on it. In the meantime, don’t put your logic inside activities and fragments. In the future though, I find documentation to be a good help for the design process. If it’s too hard to publish a good documentation for that new library, that probably means we need to think more about its design before we release it For example the documentation written by @Florina & cie on Room (Sqlite) is a pleasure. Probably because they put a lot of care of producing good API design and good documentation for Room, and both process re-inforced each other. That’s a blueprint you may want to follow.
a
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. 🙂
r
@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.
@Adam Powell The date idea is interesting, and it could be very useful, but I don't think it addresses the issue at hand. This is a discussion about new developers, and how is a new developer supposed to know how old is too old? It would be easy if there was a documented cutoff date, but some APIs go out of date very quickly and others are still the way to do it from 10 years ago.
a
Yep 🙂
r
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.
(@jmfayard I know this is still hardly related to your article, so don't take this as an attack on that, it's only for the immediate discussion.)
j
@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/
l
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.
I think expecting people to understand that examples of a concept are not examples of best practices in app architecture is reasonable
I think otherwise because with so many entry points, people won't even think about the importance of architecture until they encounter problems after following "simple" samples that don't scale well.
g
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".
c
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.
l
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.
👍 1
g
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.
p
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 🧌
c
@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.
j
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
😸 1
☝️ 2
r
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
c
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.
j
@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.
l
There's d.android.com/kotlin/coroutines, but it's not advertised well in the parts where 
AsyncTask
and other stuff are still documented.
r
@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
@cedric that's what he wrote in the blog.
🚫 1
j
@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
☝️ 3
r
@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
g
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 😄.
r
@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).
👌 1
r
@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
r
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.)
13 Views
Open in Slack
PreviousNext
Powered by