Grishka wrote very low quality code (an extremely buggy and segfaulty mess of C and C++), combined with little testing in not-so-edge case network conditions.
I managed to improve the situation after weeks of refactoring and testing for my library, and thankfully now it was completely replaced by webrtc.
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).
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.
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.
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.
This is also supported by Telegram, as well as sending codes via email (in select countries), see https://core.telegram.org/api/auth#code-types for the full list of authentication methods (which are chosen by the server, depending on the country of the user and some other heuristics).
If a 2FA password is configured, it is still required in order to login with a future auth token; however, even if it isn't set up, the fact that you have a future auth token means you have already logged in and then logged out on this specific device, so it's not a real issue (i.e. it's as if when logging out, you didn't actually log out but rather just hid the account in the UI, the future auth token is stored safely, in the same place as normal auth keys are + re-entering the 2FA password is still required).
Yes, cloud services have inflated both bandwidth and amortized hardware costs to absurd levels. You pay for not having to know what to do in order to run something online. Until it breaks.
I manage my own ASN, I've been thinking of branching out, experimenting by creating my own eSIM.
Given the huge number of virtual ISPs offering eSIMs at various prices, I mistakenly assumed it would be relatively easy to find documentation on how to do that (perhaps via some ISP selling traffic bundles to virtual ISPs); maybe someone can recommend any resources?
You have highlighted my issue with this whole DMA situation. Every Android phone I have used has felt like privacy invading garbage (except maybe the nexus 4), yet I don't think they should be off market. I simply use an iPhone instead.
Instead of the DMA being pro-consumer, I read it as anti-business (probably US business). It feels created out of EU jealously of the US tech industry, and secondarily a way to help EU companies. Consumers will likely end up worse off, which I reminded of every time I visit the EU have to dismiss cookie banners on every damn site.
There are a good number of "Android devices" which I can unlock the bootloader (or comes already unlocked from factory) and install another ROM. Done, no more "privacy invading garbage".
That is virtually impossible to be done with any Apple product.
> It feels created out of EU jealously of the US tech industry
If it feels like that for you I recommend checking your emotional state, the EU has a different approach to regulating businesses than the USA, it's not jealousy but different principles aiming for different outcomes than what the USA aims for.
> Instead of the DMA being pro-consumer, I read it as anti-business (probably US business).
You've criticised the DMA twice about being: a bad implementation, and now as anti-business. Yes, it is anti a specific case of business which in the EU's view is not aligned to the outcomes it wants in the economy, calling the EU anti-business is, at best, naïve, since it's an organisation focused first and foremost to deal with commerce and business in general. It is against business using leverages against citizens, something that the USA does not seem to care about, and that's fine for the USA just don't try to apply the same principles you live under to a different culture regarding businesses.
You could make the same (unconvincing) argument for apps on third-party stores, teaching the same dangerous things or doing even worse things like (gasp) allowing pornography :P
Generally speaking, Apple has maintained rigid control over apps and have banned everything you mentioned.
If EU app stores fill up with pornography and terrorism apps, you can imagine their move will be decried as a debacle and used by Apple to demonstrate how the EU failed by forcing them to open up
