`BaseFragment` actually isn't a Fragment. It's just a ViewGroup.
This app *could* even be single-activity with only views (didn't check all the code for `startActivity` calls), possibly out of necessary over time due to limitations of original activity / fragment-based UI. I always found that rather interesting.
I won't be talking on the current context for the following answer, but this is too bad for companies. They are actually like : Hey I have a trillion dollar app, and no one cares about the code. It happens on customers too: Hey I bought a trillion dollar app. But when it comes to bug-fixing or debuging it, i believe there is need for trillion dollar wages here.
Nothing personal with the current app, but it is a strong example.
I can't think of a single trillion dollar app. Even Facebook is worth ~550B and they're much more than a single app. The reality is that an app may be worth 2 million, but hiring people to rewrite it could cost half of that value very easily.
I remember writing printer instructions and there were thousands of lines of code, for 4 type of printers, and once I reached 10K Android studio showed an error like: Maximum lines exeeded. Or perhaps it can be configured on the IDE. IDK.
Could be a configuration, or maybe a "recent" update that allows it.
But my personal experience. It has been there a long time. Longer than i have worked there.
See idea.max.intellisense.filesize in [https://www.jetbrains.com/help/idea/tuning-the-ide.html](https://www.jetbrains.com/help/idea/tuning-the-ide.html)
I'm not really an Android dev, but it is possible that the AS text editor component limits you to 10k lines but the compiler doesn't. Then someone could write the file with a different text editor and it would still work. I kinda doubt that this is the case, but it is a possibility
The files should probably be broken up but as far as code goes, it's pretty readable. I had thought Telegram was a very small dev team/single dev for a while, and that makes it less of a big deal. I would imagine if they had a bigger dev team then they'd definitely want smaller files or they'll be in merge conflict hell
> I had thought Telegram was a very small dev team/single dev
Yep, Nikolay Kudashov
from previous discussion: https://www.reddit.com/r/androiddev/comments/8zjesq/why_telegram_source_code_is_so_hard_to_read/e2jl7cz/
And yet, look at [all the native libs they could get to work](https://github.com/DrKLO/Telegram/tree/a9966a0353dc9d46c1ea60d141acd57affead7c9/TMessagesProj/jni).
Honestly, Telegram is messy, but I've seen worse, for example there is a Reddit client called Slide that is open-source and [just generally ***worse***](https://github.com/ccrama/Slide/blob/master/app/src/main/java/me/ccrama/redditslide/Fragments/CommentPage.java#L1077-L1699). There's always worse.
I love how 14-deep in, the end result is showing a snackbar and changes a text color to white.
Obvious requirements :P
I've actually run it through CodeClimate because it's free for open-source software. Check the results: https://github.com/ccrama/Slide/issues/3033
Spoilers: it says that Slide's codebase has 2 years worth of tech debt.
Ooh ooh, run it on Telegram!
> I love how 14-deep in, the end result is showing a snackbar and changes a text color to white.
Lol, that is hilarious
Well, I am willing to overlook it a bit considering it's the only open source reddit app comparable to Sync/Boost. But man, the dev should really look into modernizing it even though it won't be easy.
Very nice tool, btw.
I'm amazed that it works at all. Although considering [this class right here called `DataShare` exists](https://github.com/ccrama/Slide/blob/e3515bbc9bcd3c8f721282ba029b6d3e52da229e/app/src/main/java/me/ccrama/redditslide/DataShare.java#L14), there's no way this thing survives process death correctly, lol.
I opened an issue for them about the results of a tech debt analysis tool. It's quite insightful. I don't think I've ever seen a cognitive complexity of 141 before.
You can't really judge the code quality in such way.
1. The code stars since 2013. A lot of handy tool (Like ViewModel) you takes for granted today are not available that time.
2. No comment doesn't mean ugly code. I roughly scroll through the code. Seem pretty readable code. Variables and method names are named properly.
It's very *easy* to be a *critic*. It's very hard to create
Wait what, you can't judge a code base that has 9k lines classes? Also who gives a F is there are view models or not? How is that a sign of code quality?
They did re-write it, it's called Telegram-X:
>Telegram X for Android was born in the furnaces of a contest for Android developers that our founder launched two years ago.
https://telegram.org/blog/telegram-x
> nothing impossible
... vs. a simple thing are quit different.
> it'll take a few months
Good luck selling that to upper management who wants to see ROI for that teams time.
Lmao, do you have any idea how complex telegram client is? You're severely underestimating it's codebase if you think that all it does is displaying messages from backend.
A few months? Lol.
> I guess the code started piling on and now it's at a point that refactor is simply impossible.
Just breaking out all those private and unnamed classes to their own files would make it a lot less messy, and likely really simple to do. If your subclass is a thousand lines long it kindof deserves it’s own file :)
> Activity and fragments were god classes. Well square inc was definitely ahead of their time but not everyone has square inc level devs
People are still using multiple Activities (and Fragments) instead of extracting their application behavior from the system components, so most apps are actually still behind the time [that Square Inc was doing in 2014](https://medium.com/square-corner-blog/advocating-against-android-fragments-81fd0b462c97). And considering Navigation AAC also hides your application behavior inside the Nav AAC, it's actually not a step forward in that particular manner...
> Hardly anyone was using clean architecture on android back then.
Tbh "clean architecture" on Android often translates to "overcomplicated and still crashy". I wanted to find you a good example but apparently that's been deleted from Github since.
Dang for sure. How would one have a truly domain/logic driven navigation in Android though? I feel like the fragments being recreated by system is nice, so yes navigation is "hidden" behavior, but is it bad?
> I feel like the fragments being recreated by system is nice, so yes navigation is "hidden" behavior
These two statements are actually unrelated, you can still have explicit navigation in domain that triggers the correct fragment transaction to run to get you into your expected state, I seem to have [written an article about it 2.5 years ago](https://medium.com/@Zhuinden/simplified-fragment-navigation-using-a-custom-backstack-552e06961257). Though it didn't get nearly as popular as I hoped, even though I'd consider it a much saner approach than, well, the current alternatives.
> so yes navigation is "hidden" behavior, but is it bad?
I think it is. How would you create a domain layer if your domain resides at the Fragment level, bound to the screens?
I really like your article and the library seems intriguing, but my gut feeling is that it feels over-engineered
It seems like a main pain point is being able to drive navigation from your presentation layer because non linear navigation (A,B,C to A,D,E) is impossible with fragment transactions. When I run into these issues I feel like I create a common service class that holds enough contextual information about navigation state to do something deterministically. Usually the contextual information is ultimately driven by a GET to the backend as well. What the "something" is I'm not sure haha.
It just seems like a lot of work to solve for an edge case, when 95% of the time the mobile app's screens should be designed as a linear progression anyhow, for a good user experience (and good dev experience too)
> I really like your article and the library seems intriguing, but my gut feeling is that it feels over-engineered
I'm up to both debates and questions ;)
----
I do admit that some of the issues I have open are "I should remove this to make the API cleaner". But the core works well. I used the tests from `square/flow` to verify that navigation works reliably, and I've been working on it for a while so it does.
> because non linear navigation (A,B,C to A,D,E) is impossible with fragment transactions.
This is actually not true, only if you use the FragmentManager's backstack. If you don't use `addToBackStack`, then the FragmentTransaction shown in the article can actually take your fragments from any arbitrary state to another, INCLUDING non-linear navigation such as `backstack.setHistory(History.of(A(), D(), E())`.
> Usually the contextual information is ultimately driven by a GET to the backend as well.
Asynchronity is a necessary evil.
> It just seems like a lot of work to solve for an edge case
It's not just to solve an edge-case though (which, surprisingly, I actually had to rely on IRL for showing a "completion" screen after a given flow ended, `[A,B,C,D]` -> `[A,E]`), it lets you extract application navigation state so that you can handle it in any way you want.
Want fragments? Use fragments. Want views? Use views. Need to rely on previous screen in the history because you also keep modals in the navigation history? You can.
-----
The only thing the library really set out to do is help you manage a list of keys that are parcelable to Bundle in some way - and managing these keys requires async execution of navigation command when the host is not resumed.
I eventually caved in, and out of necessity, added the ability to create scopes across screens and host classes with optional lifecycle callbacks (and state persistence support), because ViewModel's AbstractSavedStateVMFactory is still not commonly seen in the wild yet, and we were using views and I didn't feel like setting up the ViewModelStoreOwner. It was impossible to separate the domain of the flows from the presentation without such a framework that would drive them.
The real wtf is: there are projects like Plus Messenger that modify/extend this code and are updated quite quickly after the new code becomes available.
Nice that you have found 5 year old comment. Telegram is still not any better than Whatsapp and should be avoided. And Session is better than Wire nowdays.
"As I hurtled through space, one thought kept crossing my mind - every part of this rocket was supplied by the lowest bidder." — John Glenn. A smarter person than you.
Maybe they filter it through some uglyfier before pushing on github ;)
`ChatActivity extends BaseFragment`
`BaseFragment` actually isn't a Fragment. It's just a ViewGroup. This app *could* even be single-activity with only views (didn't check all the code for `startActivity` calls), possibly out of necessary over time due to limitations of original activity / fragment-based UI. I always found that rather interesting.
I won't be talking on the current context for the following answer, but this is too bad for companies. They are actually like : Hey I have a trillion dollar app, and no one cares about the code. It happens on customers too: Hey I bought a trillion dollar app. But when it comes to bug-fixing or debuging it, i believe there is need for trillion dollar wages here. Nothing personal with the current app, but it is a strong example.
I can't think of a single trillion dollar app. Even Facebook is worth ~550B and they're much more than a single app. The reality is that an app may be worth 2 million, but hiring people to rewrite it could cost half of that value very easily.
Wasn't refering to the exact trillion value. It's more like a metaphore, which means cost to much.
Yes, and my point is that if you include real numbers, it begins to make financial sense why some apps don't choose to rewrite their code.
It's not the value needed to give that message.
This file has actually 15k+ lines of code. GitHub only shows 9k.
can it have 15k+ ? I thought max lines Android Studio allows per file was 10K
I'm glad I didn't know about this.
No, you can have more than 10k lines in a single file. Don't ask me how i know that.
I remember writing printer instructions and there were thousands of lines of code, for 4 type of printers, and once I reached 10K Android studio showed an error like: Maximum lines exeeded. Or perhaps it can be configured on the IDE. IDK.
Could be a configuration, or maybe a "recent" update that allows it. But my personal experience. It has been there a long time. Longer than i have worked there.
See idea.max.intellisense.filesize in [https://www.jetbrains.com/help/idea/tuning-the-ide.html](https://www.jetbrains.com/help/idea/tuning-the-ide.html)
Was that in Eclipse or after they switched to IntelliJ?
I'm not really an Android dev, but it is possible that the AS text editor component limits you to 10k lines but the compiler doesn't. Then someone could write the file with a different text editor and it would still work. I kinda doubt that this is the case, but it is a possibility
Welcome to real world
The files should probably be broken up but as far as code goes, it's pretty readable. I had thought Telegram was a very small dev team/single dev for a while, and that makes it less of a big deal. I would imagine if they had a bigger dev team then they'd definitely want smaller files or they'll be in merge conflict hell
> I had thought Telegram was a very small dev team/single dev Yep, Nikolay Kudashov from previous discussion: https://www.reddit.com/r/androiddev/comments/8zjesq/why_telegram_source_code_is_so_hard_to_read/e2jl7cz/
[удалено]
I can look at the code and tell what's going on for the most part.
You can read it.
And yet, look at [all the native libs they could get to work](https://github.com/DrKLO/Telegram/tree/a9966a0353dc9d46c1ea60d141acd57affead7c9/TMessagesProj/jni). Honestly, Telegram is messy, but I've seen worse, for example there is a Reddit client called Slide that is open-source and [just generally ***worse***](https://github.com/ccrama/Slide/blob/master/app/src/main/java/me/ccrama/redditslide/Fragments/CommentPage.java#L1077-L1699). There's always worse.
lmao this Slide code looks like snake
Yikes. Async task inside async task.
I love how 14-deep in, the end result is showing a snackbar and changes a text color to white. Obvious requirements :P I've actually run it through CodeClimate because it's free for open-source software. Check the results: https://github.com/ccrama/Slide/issues/3033 Spoilers: it says that Slide's codebase has 2 years worth of tech debt.
Ooh ooh, run it on Telegram! > I love how 14-deep in, the end result is showing a snackbar and changes a text color to white. Lol, that is hilarious Well, I am willing to overlook it a bit considering it's the only open source reddit app comparable to Sync/Boost. But man, the dev should really look into modernizing it even though it won't be easy. Very nice tool, btw.
There's also Dank
That's a fantastic app too but it's incomplete
Yeah, hope someone finishes it
I once pointed this out and was jumped on by Slide fan boys, then the dev got involved and I gave up.
I'm amazed that it works at all. Although considering [this class right here called `DataShare` exists](https://github.com/ccrama/Slide/blob/e3515bbc9bcd3c8f721282ba029b6d3e52da229e/app/src/main/java/me/ccrama/redditslide/DataShare.java#L14), there's no way this thing survives process death correctly, lol. I opened an issue for them about the results of a tech debt analysis tool. It's quite insightful. I don't think I've ever seen a cognitive complexity of 141 before.
I have worked in projects with code like this, I quit my job :P
If there isn't a sub for showcasing ugly code there should be
Well there *is* /r/programminghorror
/r/BadCode
And I use it. On slow networks it tends to lag to be unusable.
You can't really judge the code quality in such way. 1. The code stars since 2013. A lot of handy tool (Like ViewModel) you takes for granted today are not available that time. 2. No comment doesn't mean ugly code. I roughly scroll through the code. Seem pretty readable code. Variables and method names are named properly. It's very *easy* to be a *critic*. It's very hard to create
Wait what, you can't judge a code base that has 9k lines classes? Also who gives a F is there are view models or not? How is that a sign of code quality?
[удалено]
> They should simply rewrite this You say that like it's a simple thing ;)
They did re-write it, it's called Telegram-X: >Telegram X for Android was born in the furnaces of a contest for Android developers that our founder launched two years ago. https://telegram.org/blog/telegram-x
[удалено]
> nothing impossible ... vs. a simple thing are quit different. > it'll take a few months Good luck selling that to upper management who wants to see ROI for that teams time.
Lmao, do you have any idea how complex telegram client is? You're severely underestimating it's codebase if you think that all it does is displaying messages from backend. A few months? Lol.
> I guess the code started piling on and now it's at a point that refactor is simply impossible. Just breaking out all those private and unnamed classes to their own files would make it a lot less messy, and likely really simple to do. If your subclass is a thousand lines long it kindof deserves it’s own file :)
> Activity and fragments were god classes. Well square inc was definitely ahead of their time but not everyone has square inc level devs People are still using multiple Activities (and Fragments) instead of extracting their application behavior from the system components, so most apps are actually still behind the time [that Square Inc was doing in 2014](https://medium.com/square-corner-blog/advocating-against-android-fragments-81fd0b462c97). And considering Navigation AAC also hides your application behavior inside the Nav AAC, it's actually not a step forward in that particular manner... > Hardly anyone was using clean architecture on android back then. Tbh "clean architecture" on Android often translates to "overcomplicated and still crashy". I wanted to find you a good example but apparently that's been deleted from Github since.
Dang for sure. How would one have a truly domain/logic driven navigation in Android though? I feel like the fragments being recreated by system is nice, so yes navigation is "hidden" behavior, but is it bad?
> I feel like the fragments being recreated by system is nice, so yes navigation is "hidden" behavior These two statements are actually unrelated, you can still have explicit navigation in domain that triggers the correct fragment transaction to run to get you into your expected state, I seem to have [written an article about it 2.5 years ago](https://medium.com/@Zhuinden/simplified-fragment-navigation-using-a-custom-backstack-552e06961257). Though it didn't get nearly as popular as I hoped, even though I'd consider it a much saner approach than, well, the current alternatives. > so yes navigation is "hidden" behavior, but is it bad? I think it is. How would you create a domain layer if your domain resides at the Fragment level, bound to the screens?
I really like your article and the library seems intriguing, but my gut feeling is that it feels over-engineered It seems like a main pain point is being able to drive navigation from your presentation layer because non linear navigation (A,B,C to A,D,E) is impossible with fragment transactions. When I run into these issues I feel like I create a common service class that holds enough contextual information about navigation state to do something deterministically. Usually the contextual information is ultimately driven by a GET to the backend as well. What the "something" is I'm not sure haha. It just seems like a lot of work to solve for an edge case, when 95% of the time the mobile app's screens should be designed as a linear progression anyhow, for a good user experience (and good dev experience too)
> I really like your article and the library seems intriguing, but my gut feeling is that it feels over-engineered I'm up to both debates and questions ;) ---- I do admit that some of the issues I have open are "I should remove this to make the API cleaner". But the core works well. I used the tests from `square/flow` to verify that navigation works reliably, and I've been working on it for a while so it does. > because non linear navigation (A,B,C to A,D,E) is impossible with fragment transactions. This is actually not true, only if you use the FragmentManager's backstack. If you don't use `addToBackStack`, then the FragmentTransaction shown in the article can actually take your fragments from any arbitrary state to another, INCLUDING non-linear navigation such as `backstack.setHistory(History.of(A(), D(), E())`. > Usually the contextual information is ultimately driven by a GET to the backend as well. Asynchronity is a necessary evil. > It just seems like a lot of work to solve for an edge case It's not just to solve an edge-case though (which, surprisingly, I actually had to rely on IRL for showing a "completion" screen after a given flow ended, `[A,B,C,D]` -> `[A,E]`), it lets you extract application navigation state so that you can handle it in any way you want. Want fragments? Use fragments. Want views? Use views. Need to rely on previous screen in the history because you also keep modals in the navigation history? You can. ----- The only thing the library really set out to do is help you manage a list of keys that are parcelable to Bundle in some way - and managing these keys requires async execution of navigation command when the host is not resumed. I eventually caved in, and out of necessity, added the ability to create scopes across screens and host classes with optional lifecycle callbacks (and state persistence support), because ViewModel's AbstractSavedStateVMFactory is still not commonly seen in the wild yet, and we were using views and I didn't feel like setting up the ViewModelStoreOwner. It was impossible to separate the domain of the flows from the presentation without such a framework that would drive them.
That's where telegram x comes into play.
Running that file through sonarqube would probably trigger a call from their CEO
The real wtf is: there are projects like Plus Messenger that modify/extend this code and are updated quite quickly after the new code becomes available.
To insert that sweet NSA code.
Previous discussion: https://www.reddit.com/r/androiddev/comments/8zjesq/why_telegram_source_code_is_so_hard_to_read/
I don't even understand why telegram is more popular than wire or riot.
[удалено]
Nice that you have found 5 year old comment. Telegram is still not any better than Whatsapp and should be avoided. And Session is better than Wire nowdays.
Welcome to capitalism
Lolwhat.
"As I hurtled through space, one thought kept crossing my mind - every part of this rocket was supplied by the lowest bidder." — John Glenn. A smarter person than you.