Fragments were way over engineered. Many people completely ignored them because you basically had to rewrite a significant portion of your app to support the type of flexibility they were supposed to give you. The lifecycle of apps is already complicated enough, and fragments added even more complexity. Like another poster mentions, completely ignoring fragments is a pretty reasonable choice.

It was around the time I started playing with fragments that I realized that the native Java android toolkit was a giant pile of crap.

Android, I think, is not even supposed to be a well-engineered system. It is not central to its purpose. Its purpose is to eat marketshare, collect data, and ensure there is an outlet for ads. It only has to work well enough to do those things :)

I get the sense that it was all slapped together as quickly as possible.

Well, yeah, that's the goal of everything commercial. Being well-engineered is a means, not an end.

iOS and UWP are both commercial and the quality of their tooling and OS frameworks runs circles around Android's.

Sadly it is hard to win over free beer.

Nah, tons of companies are incredibly passionate about quality in itself. Sometimes to a fault!

> I get the sense that it was all slapped together as quickly as possible.

It was, historically. Android was a startup that had to get to market as fast as they could. To make matters worse, once the iPhone came out they had to quickly switch from a Treo-like interface to a iOS-like one in order to stay relevant.

To Google's credit, they've been trying for years to clean it up, but there's only so much they can do…

I got the same impression, it's just filled with hacks to get proper behavior and don't get me started on the support libraries, oof how I hate those.

Sorry just got stuck and smiled over your first sentence "Fragments were way over engineered." and couldn't restrain myself of thinking about all Googlers that passed the whiteboard tests

True I don't think I have ever had an interview question that questioned my ability to keep simple. I think this is where experience comes in valuable, the ability to "keep things as simple as possible and no simpler".

I find the best approach to KISS is to write it as simple as possible under the assumption you'll have to throw it away. If it turns out you don't have to (after measuring), then all the better.

I host interviews for Google. A simpler design that solves a problem is definitely valued better than an unnecessarily-complicated one.

It has nothing to do with APIs.

Our app has a great tablet version, on par with iPad and we don’t use fragments at all. We just change things based on size.

It’s more that Google obviously stopped caring about tablets many major versions ago.

For what it's worth, there are Android tablet users out there like me that really appreciate the work you put into making the experience great :-)

See but that doesn't answer my question: What makes you think that they stopped caring about tablets?

Lots of Android system UI and first party apps had better tablet interfaces in ICS than they do in Nougat or Oreo.

This is a bit of a stretch. There was a lot of work done on improving tablet support in K, L and M, including work to specifically support the Nexus 9 and Pixel C. There was also the addition of multi-window, etc.

Keep in mind that Fragments happened while Rubin was still nominally in control of Android.

Once the civil war between him and Pichai had a clear winner (after all, for a while both ChromeOS and Android were poised to push into the same market), the tablet elements were depreciated rapidly as as Duarte was free to assert more control.