[dmix]

Woah, that's some lazy code in ChatActivity.java. Functions with 30+ conditionals depending on tons of external state. That must be a nightmare to debug and impossible to test.

I've seen some huge Android java functions where everything gets stuffed into the Fragment creation/update/etc API functions... but this is one just stuffed everything in them.

It's just asking for bugs and security issues.

Edit: the commit history all comes the same developer, each titled with a generic "Bug fixes" commit and no description of the changes. Seems like a single guy is just cowboying the whole App, it's not a team project at Telegram. Which explains the above... https://github.com/DrKLO/Telegram/commits/master/TMessagesPr...

[kuschku]

Don’t worry, most current message apps have code that horrible.

Be it matrix simply writing a HashMap into a file as "database" replacement https://github.com/matrix-org/matrix-android-sdk/blob/master...

Or Signal simply taking apart Android system structs with JNI, to get a file descriptor’s owner https://github.com/signalapp/Signal-Android/blob/master/jni/...

There’s lots of suboptimal code in messaging apps. All of them.

[slowmotiony]

Why do you need a database over a serialized object like a hashmap file if there is only one user and one device?

[kuschku]

Because writing the entire dataset back out on every addition or removal is extremely wasteful.

The existing database implementations in the system do much less writes.

Doing such large, constant writes not only is slower, it also degrades the NAND.

[slowmotiony]

Thank you

[solarkraft]

However it feels very good to use. Cases in which something gets weirdly stuck (happens in other apps) are virtually non existent. It is fast and quite reliable. Perhaps surprisingly so.

[on_and_off]

I guess the point is that you can get away with such sloppy code as long as it is a solo project of a relatively small size.

I am not sure at which point it becomes too big and new features and bugs are just impossible to handle.

It might have been the right choice for Telegram though. Their app feels snappy, so the 'only' big downside is that now it looks like they are going to have to thrown away this entire code base and replace it with the one from Telegram X (a third party client they bought)

[dmix]

I'd be more concerned about the developer side, particularly new developers and OSS contributors, the wide attack surface introduced by such complexity, long-term inflexibility, impossible to track down bugs, etc more than anything. I'm sure they have plenty of people to QA from the user perspective, just clearly not the code.

Maybe the developer was pressured to focus on releasing quickly over code quality...yada yada. The typical startup developer story. But not a story that I like to find in my security-focused software.