Fucking android framework. Sucks my huge ass balls. What is wrong with the people that wrote this?
You implement a fba and hide it when the recyclerview in the corresponding is scrolled down.
Then you change to API level 25 and they fucking decide it would be a good idea to refuse to send the onNestedScroll when the visibility for a fba is set to GONE which is itself not bad, but they also think setting the visibility for the fba when you call the hide() method to... yea you guessed it FUCKING GONE would be an amazing decision. Oh yea you smart ass nice decision I'm so glad you did it.

I wonder if Google released Flutter because they can't let Facebook have all the fun with react native. Or maybe they did it because they had fushia os in mind for a loooong time. Or maybe because they realized that the android api is overly complicated and the Dart way is easier. Or maybe they did it for the lolz.

IMAGE COMPRESSION QUESTION

lets say i upload a 100x100 photo from my android device. this image has a size of e.g. 2MB. not a lot. if i compress it then the size will be e.g. 300kB. cool. upload is thunderbolt for any internet speed.

lets consider this case. a random ass motherfucker decides it is cool to upload a 10000x10000 image that has a size e.g. 300MB. compressing this would be e.g. 150MB which is still a lot as fuck for one pic.

heres my question: where should the compression be handled? at backend (REST API server) or client (android image compression library)?

because if i try to send a 150MB pic to the server and their internet sucks but to be fucking honest even the best internet speed would take way too long to upload, is it better to do the compression on the backend or client?

or should i do compression in android? if i should do compression on client then should i;
1) do the compression on the main thread with a progress dialog to wait them until the compression + PLUS the fucking upload is done or
2) do the compression + THE upload in a background thread in which case it can be dangerous for verbose amount of fuckups (internet dies phone explodes etc) and the app crashes

which (one) option of the 2 suboptions from the second parent option branch?

of course this is an extremely unrealistic case, it is possible but thats not my point: my point is WHERE SHOULD THE COMPRESSION (as some kind of universal standard) BE HANDLED AT?

Spent days to setup a newer-Android version with reverse-proxy-HTTPS certificate in its CA store + one that'd support Google Play and signing in (old school man-in-the-middle).
FINALLY got the API calls of this 1 app whose unofficial client I wanted to make coz their main sucks ass. Just to get stuck on the phone-number-based OTP that they use for their login (:

They send a unique token for each OTP request, I assumed they're using some hard-coded string based function, which they decrypt on their backend to verify.
Downloaded their APK and decompiled. Went through dozens of weird-ass-named classes (coz decompiled). For the 2nd time I thought I had it!

But no -.- they call Google's Firebase messaging for the phone-num OTP n that function simply called firebase, looked into that service n ofc it's very tightly coupled with the calling API's backend

It was fun while it lasted I guess~~~

During my small tenure as the lead mobile developer for a logistics company I had to manage my stacks between native Android applications in Java and native apps in IOS.

Back then, swift was barely coming into version 3 and as such the transition was not trustworthy enough for me to discard Obj C. So I went with Obj C and kept my knowledge of Swift in the back. It was not difficult since I had always liked Obj C for some reason. The language was what made me click with pointers and understand them well enough to feel more comfortable with C as it was a strict superset from said language. It was enjoyable really and making apps for IOS made me appreciate the ecosystem that much better and realize the level of dedication that the engineering team at Apple used for their compilation protocols. It was my first exposure to ARC(Automatic Reference Counting) as a "form" of garbage collection per se. The tooling in particular was nice, normally with xcode you have a 50/50 chance of it being great or shit. For me it was a mixture of both really, but the number of crashes or unexpected behavior was FAR lesser than what I had in Android back when we still used eclipse and even when we started to use Android Studio.

Developing IOS apps was also what made me see why IOS apps have that distinctive shine and why their phones required less memory(RAM). It was a pleasant experience.

The whole ordeal also left me with a bad taste for Android development. Don't get me wrong, I love my Android phones. But I firmly believe that unless you pay top dollar for an android manufacturer such as Samsung, motorla or lg then you will have lag galore. And man.....everyone that would try to prove me wrong always had to make excuses later on(no, your $200_$300 dllr android device just didn't cut it my dude)

It really sucks sometimes for Android development. I want to know what Google got so wrong that they made the decisions they made in order to make people design other tools such as React Native, Cordova, Ionic, phonegapp, titanium, xamarin(which is shit imo) codename one and many others. With IOS i never considered going for something different than Native since the API just seemed so well designed and far superior to me from an architectural point of view.

Fast forward to 2018(almost 2019) adn Google had talks about flutter for a while and how they make it seem that they are fixing how they want people to design apps.

You see. I firmly believe that tech stacks work in 2 ways:

1 people love a stack so much they start to develop cool ADDITIONS to it(see the awesomeios repo) to expand on the standard libraries

2 people start to FIX a stack because the implementation is broken, lacking in functionality, hard to use by itself: see okhttp, legit all the Square libs, butterknife etc etc etc and etc

From this I can conclude 2 things: people love developing for IOS because the ecosystem is nice and dev friendly, and people like to develop for Android in spite of how Google manages their API. Seriously Android is a great OS and having apps that work awesomely in spite of how hard it is to create applications for said platform just shows a level of love and dedication that is unmatched.

This is why I find it hard, and even mean to call out on one product over the other. Despite the morals behind the 2 leading companies inferred from my post, the develpers are what makes the situation better or worse.

So just fuck it and develop and use for what you want.

Honorific mention to PHP and the php developer community which is a mixture of fixing and adding in spite of the ammount of hatred that such coolness gets from a lot of peeps :P

Oh and I got a couple of mobile contracts in the way, this is why I made this post.

And I still hate developing for Android even though I love Java.