API Compatibility

[ZacSweers]

Forgive me if this is already mentioned elsewhere, I couldn't find any discussion in existing issues.

Since a lot of developers are looking to this project as a yard stick for how to implement material design and meaningful interaction, would you be open to PRs backporting some of the components to earlier API versions? Would be nice to see the support libraries do some of the heavy lifting.

Example: InkPageIndicator can be backported(ish) to API 15.

[nickbutcher]

Hi, i've been meaning to write up my thinking on this so thanks for bringing this up. I very intentionally created this with minSdk 21 as I wanted to see what I could create un-encumbered by backwards compatibility. I know that this is unrealistic for most real apps but as a major goal of Plaid is to inspire developers I wanted free reign here.

Now that features have more or less stabilized, I'm very open to backporting. It's not the highest priority on my backlog (persistence! tablets! cleaner code architecture!) but I would definitely accept PRs if they don't add significant code complexity. As a sample app I want it to remain easy to learn from and any backport efforts will become decreasingly relevant as the market moves on.

I'd also like to break out reusable components into more focused libs or possibly into the Design Support Lib; these would definitely need to be backward compatible.

I've already seen a couple of backports of InkPageIndicator which is great!

• https://github.com/Commit451/InkPageIndicator
• https://github.com/DavidPacioianu/InkPageIndicator

[ZacSweers]

Great!

[ZacSweers]

Hey Nick, wanted to get your thoughts on this. I started going down the road of backporting what I could with minimal functional changes. These were the results/observations:

• I targeted API 15 compatability. Most of the compat issues could be avoided by targeting API 19 IMO.
• Even abiding by the minimal functional changes, the diff still looks immense just due to the shear amount of API-specific code. Most of it is still drop-in replacements fortunately, I'd just be uncomfortable opening a PR that big.
• Some things are harder than others to manage, particularly with XML. While the support libraries give us a lot, most of it is programmatic and doesn't take care of non-theme/style-XML for us. Things like transitions, animated vector drawables (though that's coming soon I hear), ripples, and all the various attributes don't have easy drop-in replacements. In light of this, I would go as far as saying that backporting isn't worth it unless AppCompat's next release has some serious XML magic planned. They could be handled, but it would not be trivial and requires a decent amount of restructuring to stuff shared xml into base styles and expanding from there. I would rather set things in code using compat-friendly code.
• There are some backports that aren't currently handled by the support libraries. I took a crack at these in the util.compat package.
• I didn't touch the Path Union ops in InkPagerIndicator. One of the linked backports above tried just adding paths, but I found that to be buggy and maybe not the most accurate. See Issue on pre-lollipop DavidPacioianu/InkPageIndicator#1
• Using a null listener for setOnApplyWindowInsetsListener actually blows up the support library, so we have to use an unfortuante no-op implementation instead: https://code.google.com/p/android/issues/detail?id=197492

Here's the branch: https://github.com/hzsweers/plaid/tree/z/compat

It's a WIP, but mostly complete. There are some things, mainly around transitions and custom views that depend on Lollipop APIs, that aren't done. The former is just some more work, the latter however would require a custom CircularImageView implementation I think.

What are your thoughts? Would you want a PR that big or prefer to have smaller contributions? Do you still want to backport at all in light of what I've mentioned?

[nickbutcher]

Hi Zac, sorry for the slow response but I'm just back from paternity leave & getting back up to speed.

Firstly wow, this is a heroic effort. I understand your concern about such a large PR, perhaps we could break it down a feature at a time e.g. 1 PR for Transitions, 1 for AppCompat themeing etc?

Can you expand on the issues you've had with XML? I had thought that would be one of the easier parts to handle, e.g. no-oping like `transitions-v21/foo.xml

I've not gone through the whole fork in detail yet, how complete do you estimate this is?

Again, thanks for all of this work!!

[ZacSweers]

No worries, and congrats on the new member of the family!

As far as breaking it up into smaller pulls, I'm going to look at it this week but not sure it'll be easy to pull apart at the point. The appcompat portion alone would be most of it. Really comes down to how much you're willing to review at once :)

XML is troublesome mainly for transitions, since you can't really do non-v19 transitions that simply no-op due to them not existing pre-KK. After having recently done some stuff at work along these lines though, I don't think it would be too bad. You're right though in that the rest should be easy to manage with -v* dirs. I havent dug too deep into this yet since my initial goal for a PR was just to do *Compat drop-ins and not have any major structure/functional changes. Perhaps that could be a separate PR in the name of splitting things up? Themes and vectors are another question mark, but I'll have to dig into them more. Same for custom views, some likely require a little more than no-op-ing on older APIs jd we still want to keep the same UI (such as circular image view).

I would estimate that it's maybe 80% complete. I'm sure there's still some things to iron out that I haven't come across yet, but I think the remaining work is largely restricted to XML/themes and transitions. In its current state, it works seamlessly on Lollipop+ devices with no noticeable UI difference.

[nelsonkam]

Hello, in the latest update of the Android Support Library, the Transitions Framework was backported to API Level 14.

The new android.support.transition package backports the Transitions framework to API levels 14 and higher. For more information, see the android.support.transition reference.
[https://developer.android.com/topic/libraries/support-library/revisions.html](Support Library Revision History)

Hope this helps.