Hacker News Reader

This will only break the user experience if the app happens to have a bad experience in this mode and if the user happens to request to use it in this mode. It is hard to know for how many apps this would be the case.

There is no way that they could guarantee that the experience would be perfect for every scenario, so that left them with two options:

1. Make the feature only work for apps that declare support for it. This would significantly degrade the user experience for some apps that would work just fine but have not been updated.

2. Make it work for everything with reasonable defaults that every app should be able to handle. Leave it up to the user to accept the degradation for the ones that don't (or to just not use those applications in those modes).

From a user perspective, it isn't clear to me that option #1 was the wrong choice.

Along your point, it's pretty easy to reverse the logic on the last sentence and still have it be a sane argument:

> This feature should be turned on for all apps; you shouldn't make every user wait for every app ever made to be updated because three people on the Android developer team made a new feature and were too afraid to break things, so they turn it off by default for legacy (pre-Nougat targeted) apps.

EDIT: I should read the whole thread before posting. GrinningFool made the same argument:

https://news.ycombinator.com/item?id=12338639

I was very confused until I realized that I had a typo. I actually meant for that last line to say "Option 2". :)

Apple went with option 1 for split screen and picture-in-picture video support on iOS, and a year later many major apps still don't support those features. Option 2 is definitely the way to go.

I actually agree with this. I implied otherwise due to a typo and now it is outside of the edit window. Oops. :)

My uninformed guess would say that a sampling of a significant number of apps showed that they rendered fine, and they deemed it worth the trade-off that some may not.

The logic probably went along the lines of: it's better for the user to have this feature that works with X% of what they already have installed than to force them to wait for the developers of each and every app to decide if/when they want to get around to updating.

> a sampling of a significant number of apps showed that they rendered fine

The problem is they break the API all the time, and this leaves Google Play strewn with broken apps. This may break 1% of apps, the next release breaks another 1%, after 10 releases, 10% of the apps not updated are broken.

Here's an example, I go to Google Play and search for "ringtone maker" ( https://play.google.com/store/search?q=ringtone%20maker ). The #3 result for me (which can vary by location) is https://play.google.com/store/apps/details?id=com.anbu.ringt... . So I download the app, click the microphone, say something, hit stop and - "java.io.IOException: Unknown file format".

This is their 3rd result for ringtone maker, has over 5 million downloads and yet their record feature is broken. It used to work but Google changed the API. You can look at the app source code ( https://github.com/malizadehq/ringdroid ) to see where this app broke if you want. This is just one example which comes to mind, I can think of many.

They claim they don't break the API going forward but they do all the time.

How is the split screen breaking the API when the app works like ever has worked in the main screen?

> the app works like ever has worked in the main screen

If the app always works like it ever has worked in the main screen, why do they say:

> If your app does not declare a fixed orientation, you should launch your app on a device running Android 7.0 or higher and attempt to put the app in split-screen mode. Verify that the user experience is acceptable when the app is forcibly resized.

To check if it is displayed fine in a split screen, nothing mire

It looks like the app tries to do its own audio file parsing and (wrongly) assumes .aac files are always MP4 containers [0] rather than as ADTS.

So perhaps not the best example of what you're trying to say.

[0] https://github.com/malizadehq/ringdroid/blob/master/src/com/...

Multi-windowed mode can be found hiding in the options (which can only be edited with root) in 6.0.1, and it works well enough right now with just a few graphical bugs on very few apps. I'm guessing you're right, and if it does break the app then all the user has to do is turn off multi-windowed mode.

If I recall, it also displays a simple toast for apps that do not target the API, saying "App may not work with split screen"

This also lets the user know it's not the Apps fault. I feel it's a pretty good way to enhance the experience where possible and move apps forward even if they're old.

If your app doesn't work on smaller screens or in landscape, you should be declaring that. Otherwise, your app is probably already running on devices with tiny, landscape screens and giving users the same experience as those with larger split screens.

Yeah if people have followed the UI guidelines for Android that has existed since day one, their app will have the required resources for Android to resize and reshape it to fit whatever screen shape the split view will create.

Sadly the way you do things has changed since then though. I remember doing android development in the 2.3.1 days, and the method of doing dialogs has transformed into fragments since then, so although my old code I wrote back then will run and work, it isn't the recommended way. Nor are the UI guidelines I followed back then.

I appreciate that things change (like the UI guidelines every year apparently!!) but if a clear roadmap was laid out back then, it would have saved a lot of time.