From the end-user perspective the API is now pretty close to the final state: the API consumer creates a CheckoutClient (mandatory), a FormCustomizer (optional) and calls initialize() on the PaymentForm with these objects. This achieves a clear separation of the ApiClient (CheckoutClient), the UI (PaymentForm) and the object to set defaults for the form (FormCustomizer).
I simplified the levels of view hierarchy: TouchlessViewPager and CustomAdapter are gone; instead PaymentForm hosts two views (CardDetails and BillingDetails) and I implemented the animations to transition between these two views so that it looks like it did before (SlidingViewAnimator). I chose this solution because it allows easy customization of transitions (simply drop in new transition xmls like slide_out_right.xml), it keeps the view hierarchies quite simple, and it avoids making any assumptions about where the library consumer hosts the Form (they can be using Activity / AppCompatActivity / Fragment / SupportFragment).
Types of changes
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Refactor
Checklist
[x] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)
Proposed changes
Quite a lot of structural change in this PR:
From the end-user perspective the API is now pretty close to the final state: the API consumer creates a CheckoutClient (mandatory), a FormCustomizer (optional) and calls
initialize()on the PaymentForm with these objects. This achieves a clear separation of the ApiClient (CheckoutClient), the UI (PaymentForm) and the object to set defaults for the form (FormCustomizer).I simplified the levels of view hierarchy: TouchlessViewPager and CustomAdapter are gone; instead PaymentForm hosts two views (CardDetails and BillingDetails) and I implemented the animations to transition between these two views so that it looks like it did before (SlidingViewAnimator). I chose this solution because it allows easy customization of transitions (simply drop in new transition xmls like
slide_out_right.xml), it keeps the view hierarchies quite simple, and it avoids making any assumptions about where the library consumer hosts the Form (they can be using Activity / AppCompatActivity / Fragment / SupportFragment).Types of changes
Checklist