Why android gets itself so complicated, inconsiste...

# android

[calidion]

Why android gets itself so complicated, inconsistent and unstable?

[Ben Ayesu-Attah]

It is definitely quite the challenge and i love it!

[calidion]

But most developers like to invest in a platform that has a stable apis like unix/linux apis.

[czuckie]

First of all, this isn't really the place for such discussion, maybe look at the places linked in the topic.

Second of all, writing an application is hard, writing a library is really hard, writing a framework is near impossible and writing an OS and ecosystem is indescribably complicated.

There are inconsistencies and unstableness in every environment you look at, Android is no exception. Android is 15 years old at this point, the first devices that it targeted had sub Ghz processors and less than a GB of RAM.

Although the hardware could scale up quickly in the years following it, it's unreasonable to imagine that the software and frameworks could advance as quickly whilst maintaining support for older products.

Kotlin is a programming language, not a fix-it-all solution. The team developing Kotlin have provided mechanisms to make deprecation less of a probability by introducing Experimental annotations for new APIs, in the hope of getting feedback on new APIs such that there will hopefully be less revisions on them once they become stable.

You should try and use a pinephone if you think that Linux provides good APIs. You'll quickly learn that the experience isn't anywhere near as good as what you'd get with an iPhone or an android phone, even one that's 5 years old. And as Linux develops you'll find that plenty of APIs change and go away.

[calidion]

Unix basic apis almost has never changed since it's creation . New applications lack of good architecture and abstraction will always result in api changing and method deprecating. A good framework or platform should try to avoid it. To provide well abstracted, consistent, simple apis. To kotlin android it has the opportunity to make things much better. For example, Kotlin library can use events/messages to reduce Intent mass, code coupling and thread/handler/asynctask mass, make it simple to feed data to ui thread.

[czuckie]

I mean, I could say "for example we should cure all illnesses" but that doesn't make it any easier of a goal to achieve.

When you're designing a framework, you need to anticipate not just a single person's use cases, but everyone's. It's not possible to please everyone.

Comparing Android application APIs to Unix's or Linux's 'basic' APIs (whatever they are) is not the same as comparing them to what they more closely match, which is something like GTK+ or Qt.

These application frameworks have gone through massive transformations since their inception because the world in which they exist is evolving rapidly.

I used to be filled with fizz and vinegar too, but every time I moved from one big organisation to another, the more I realised that everything is held together with spit, chewing gum and best intentions.

At least Android is opensource and you can contribute back if you really wanted.

[calidion]

I don't think people should know everything, but software architects should have better understanding than others even for application frameworks. They should anticipate what will come and know the core logic that shall not change. That is their responsibility. Bad designs are not their excuses. If he or she can not design a good library or framework, they should not be on that place at all, especially for those are paid in big companies.
I deliver free and opensource frameworks too, but I don't think my frameworks should have big changes over time except to enrich new features. If their interfaces changes frequently, mostly it is because I made bad decisions, and I should take more time to think things thoroughly and expose the core logic to make interfaces stable, consistent, relative simple.
I can contribute to the android open source ecosystem, but I have other things to do as a independent client programmer of android platform. I am here because I frequently encounter problems because of the android inconsistency, instability, bugginess, lack of document and competent simple examples in developing android application.
These problems are all wasting of resources and efforts. I think these things should be taken into account when designing new frameworks and deliver new apis and publish documentations.
Almost all documents have no working examples, when you look into an example you many find out that they are not working at all, although that are documented to be workable.

[Zach Klippenstein (he/him) [MOD]]

I think you’re setting yourself up for disappointment with those expectations 😜 Most API design will eventually result in regret because it’s impossible to tell the future, even if you’re paid by a big company to do so. I doubt any of the problems you’ve enumerated were intentional, and the people who built those things would probably be the first to point out issues with them. I know I’ve never shipped a library API I was perfectly happy with.

That’s why things like AndroidX and Compose exist: they use Kotlin to present nicer APIs that abstract over inconsistencies and changes that have come up on the platform over time.

[calidion]

I don't think androidX will be a good framework because it even lacks it's fundamental architect chart. I don't know how it composed and it's principal and it's core logic. It just likes an assembling tools.

[calidion]

The official documentation for androidX or jetpack is really a nightmare.

[Zach Klippenstein (he/him) [MOD]]

Yes it’s a collection of tools, it doesn’t have a unified architecture because it doesn’t need one. Eg there’s a module that just provides alternative collection implementations.

[Zach Klippenstein (he/him) [MOD]]

Documentation can always be improved, thanks for filing those bugs!

[calidion]

I hope the android project create more smallest examples and test cases for every single api to verify if it works properly. and as a reference to client users to make then sure that they are workable and being fully tested.
It is shocked to know that after almost twenty years of development, Android platform apis are still in it's unstable status.😂

[Zach Klippenstein (he/him) [MOD]]

Which platform APIs are unstable?

[Zach Klippenstein (he/him) [MOD]]

Sometimes APIs get deprecated, and new ones pop up. That’s not unstable, that’s the reality of a living platform that evolves over time.

[calidion]

unstable means it changes. for example

if (android.os.Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
            temp = intent.getParcelableExtra(key, tClass);
        } else {
            temp = intent.getParcelableExtra(key);
        }

[calidion]

the addition of a class is useless only to add complexity to the code.

[Zach Klippenstein (he/him) [MOD]]

The docs (albeit on Bundle, not Intent) indicate it makes the method more type safe, which likely either prevents runtime errors or gives them better error messages.

That doesn’t seem useless to me.

[Alex Vanyo]

As general rule of thumb, anytime you might need to use a SDK_INT check in your code, you should check if there’s a version in androidx that does that logic and gives a single method to call across API versions.

In this particular case, there’s IntentCompat.getParcelableExtra from androidx.core that does that if check for you

[Peter]

@calidion I think the thing is, that Intent is bundled into Android OS. So depending on the Android version, it could have different implementation. So atm it's not possible for them to update it.

[Peter]

Though I guess, they could still make Intent wrapper, e.g. IntentCompat maybe?

[calidion]

@Peter I think they are lacking the ability to keep apis stable and extensible, build a simple and extensible architecture. just mix things up to deliver a messy stuff.

[Zach Klippenstein (he/him) [MOD]]

Buddy, if you consider adding one parameter to a method after 10+ years a mess, you’re in the wrong line of work.