-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API Compatibility #47
Comments
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 |
Great! |
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:
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? |
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!! |
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. |
Hello, in the latest update of the Android Support Library, the Transitions Framework was backported to API Level 14.
Hope this helps. |
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.The text was updated successfully, but these errors were encountered: