Skip to content
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

Closed
wants to merge 2 commits into from
Closed

Changed from v4 SupportFragments Native fragments and removed ABS #73

wants to merge 2 commits into from

Conversation

ImDevinC
Copy link

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.

@coreydowning
Copy link

+1 this should at least be a possibility.

@gathas
Copy link

gathas commented May 21, 2014

+1 I would prefer this approach

@trolik
Copy link

trolik commented Jun 4, 2014

+1

@TheClarkster
Copy link

+1 I would also prefer this.

@alopix
Copy link

alopix commented Jun 26, 2014

Why would you remove support for Android 2.3?
Even thought market share is declining, a lot of companies still need to develop for 2.3 and up (yes, it's horrible but still required).
At least API level 10 should stay supported!

@asgarddesigns
Copy link

@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.

@alopix
Copy link

alopix commented Jun 27, 2014

@asgarddesigns then I would suggest different branches and artifacts.
betterpickers 1.x which includes support lib and a new artifact 2.x + future branch with android 4+ support. I think using overloaded methods would just complicate things (just like support lib alone already complicates things ;))
hopefully in the near future android 2.3 will finally die a silent death ;)

@asgarddesigns
Copy link

@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!

@derekbrameyer
Copy link
Contributor

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...

@coreydowning
Copy link

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).

@fchauveau
Copy link
Member

Closing this PR as android.support.v4 is no more used in project

@fchauveau fchauveau closed this Sep 25, 2015
@ImDevinC ImDevinC deleted the native_fragments branch October 9, 2015 15:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants