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

Kotlinize fragments #612

Merged
merged 2 commits into from
Dec 15, 2018
Merged

Conversation

cortinico
Copy link
Member

Please note that this PR contains breaking changes.
I've kotlinized all the Fragments in the library.

Moreover, I cleaned up the exposed Api for AppIntroFragment and AppIntro2Fragment. Now they expose only two methods:

  • newInstance(SliderPage) as before
  • A @JvmOverload-ed method like this
newInstance(
                title: CharSequence? = null,
                description: CharSequence? = null,
                @FontRes titleTypefaceFontRes: Int = 0,
                @FontRes descTypefaceFontRes: Int = 0,
                @DrawableRes imageDrawable: Int = 0,
                @ColorInt bgColor: Int = 0,
                @ColorInt titleColor: Int = 0,
                @ColorInt descColor: Int = 0
        )

This will cover the majority of the use cases. I saw that we had several @deprecated methods, plus other non deprecated newInstance methods with a permutation of those parameters.

I generally like the two classes now as they're smaller and cleaner. But I'd love to discuss how much aggressive we want to be with removal of old APIs

@cortinico
Copy link
Member Author

ping @paolorotolo 👋

@paolorotolo
Copy link
Member

Hey @cortinico sorry for the delay! I'm ok being aggressive on old APIs and have classes cleaner thanks to Kotlin features.
We just have to make sure to update all the needed docs before next release.

@paolorotolo paolorotolo merged commit b37c981 into AppIntro:master Dec 15, 2018
@cortinico cortinico added this to the 6.0.0 milestone Jan 23, 2020
@cortinico cortinico added the internals Issue/PR related to the refactoring or internals that are not exposed of the library label Jan 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internals Issue/PR related to the refactoring or internals that are not exposed of the library
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants