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
Changed from v4 SupportFragments Native fragments and removed ABS #73
Conversation
+1 this should at least be a possibility. |
+1 I would prefer this approach |
+1 |
+1 I would also prefer this. |
Why would you remove support for Android 2.3? |
@alopix You are quite right, but some companies are only targeting > 4.0, which means they aren't using supportFragmentManager; Don't want to use the support libs just so we can use a 3rd party library! I would suggest overloaded methods so you can use either... if that's not possible, 2 separate build artifacts. |
@asgarddesigns then I would suggest different branches and artifacts. |
@alopix It depends - what I have seen, it probably would be easy enough to overload, but I have only had a quick look. separate versions would certainly be easier, but can be painful to maintain! |
Hi everyone, I'm going to pick BetterPickers back up over the next couple of weeks and this is definitely on my radar. My first goal is to address any current bugs and issue a point release, still pointing to support-v4. Following that, I'll take a look at how to either remove v4, or package two different branches. I am tempted to go full minSdkVersion 15 following a point release... |
I've discovered other reasons to use support fragments even in a min SDK 14 app such as child fragment support (fragments inside of fragments). |
Closing this PR as android.support.v4 is no more used in project |
Updated app calls to API11 to utilize native fragments and the native action bar. v4 Support is still needed for some of the ViewCompat, ViewPager, etc.