[danogentili]

This dude has absolutely no right to say anything about the quality of the source code of the android app, because:

1) His libtgvoip code, previously used for audio calls, is the worst code I have ever had the displesaure of touching, it caused all kinds of issues ranging from instability to segfaults, and thankfully it was completely replaced by webrtc.

2) The android app is literally the smoothest and most responsive android app I've ever used.

Grishka, please stop being so salty. VoIP is hard to do right, but not impossibly so. VoIP being hard is still not an excuse for writing garbage C/C++ code (and I don't mean to offend personally here, but the code was really a mess, please stick to Java development on your own personal projects).

[g15jv2dp]

Speaking as an outsider... Your comment reads as a blatant ad-hominem attack and does nothing to support your point. You should consider toning it down if your goal is to convince anyone.

[foundthebeef]

Some of us have trod this path before, and recognize righteous anger when we see it.

[golergka]

That's just a cultural difference. I've seen Russian developers getting into physical fights over code more than once.

Thankfully, western (and especially american) corporate culture is much more conflict-awerse.

[grishka]

1) Which version are we talking about? Segfaults were exceedingly rare either way. Especially so when I stopped using raw pointers. But yes, to no one's surprise, early versions were a mess. I can agree with you on that. I can't agree about the same about the last versions though.

It was replaced by WebRTC that would sometimes just suddenly disconnect your calls, right.

> I managed to improve the situation after weeks of refactoring and testing

Did you submit any PRs with your improvements? I used to review and merge those, unlike the Android app devs.

2) It might provide the best UX in the entire universe, but that still doesn't justify having a two-megabyte Java file with over a hundred anonymous inner classes that gaslight you because it's often a `new FrameLayout(activity){` that overrides onLayout and does something completely different. So you see a FrameLayout, you assume it behaves like one, you add views to it, then it doesn't work the way you expect. You start questioning your sanity and only then do you realize that it's one of these stupid things.

Oh and did I mention that even just editing ChatActivity.java is an exercise in frustration? At the time, I had a 2012 MacBook Pro that worked fine for everything I did on it, except editing 2-megabyte Java sources in Android Studio. It would sometimes take a solid 10 seconds for keystrokes to register.

In other words, it might be the best Android app in the world, but it blows up in your face nearly every time you try to add a new feature.

[nurumaik]

> but that still doesn't justify

No, that really justifies anything. Programs should be pleasant for users to use, not for developers to work on them

[grishka]

One does not exclude the other.

And, honestly, these things are connected. It takes more needless work from the developer to maintain the user-visible pleasantness while adding new features. The code is much more fragile than it could've been which means bugs are much easier to introduce and much harder to diagnose and fix.

And I'm not asking for a complete rewrite. Just losslessly restructure the existing code, extract all those custom FrameLayouts and ViewGroups into separate classes, split those 2000-line if statements into separate methods, make some things (like ChatMessageCell) into sensible class hierarchies, introduce constants or enums to replace magic numbers, all that sort of stuff. This will not affect the UX, but it would make bugs harder to introduce and easier to deal with.

I'm generally not a fan of the developer-experience-focused approach to software development (Electron, React, and the web dev "trust me bro" attitude should not exist), but sensible code structure is where I draw the line.

[greenthrow]

Tell me you're not a professional software engineer without telling me you're not a professional software engineer.