Developer Experience #496
Replies: 3 comments 6 replies
-
|
Beta Was this translation helpful? Give feedback.
-
@Yongyong-Zhou this constructor will be available in the next release. |
Beta Was this translation helpful? Give feedback.
-
@sshropshire I really appreciate this approach of opening up this discussion and the promptness of it. I certain that it will be beneficial for braintree and consumers alike 🙏 ClientTokenProviderI think it would be nice if you give a bit more detail in the example code. The devil is in the detail so it would be nice to see how a Are we declaring a successful authorization or are we providing a token? It might that internally in the sdk you are using the token for authorization but do you need to expose these concepts to the consumer? In other words.. as a developer should I be writing authorization code? I guess not. I guess some of the concerns here are language (java/kotlin) and concurrency right? I presume you have that callback to give the consumer freedom of their concurrency model? But maybe it could be more simple...
This way the SDK would be responsible for calling this on a background thread. Consumers would throw if something goes wrong. I am curious to understand when you need to get that client token? Does the SDK need to be in charge of requesting it? Or can it just accept it as a parameter when the client is tokenising?
Or could it be part of the request object?
This way would make your SDK completely agnostic to token provision IntegrationAs mention in the other thread. I suspect most of your consumers do not want to write payment related code in an
This example would rely on my dependency injection setup to provide the I hope that help in someway. And thanks again for the initiative, it looks really promising 💯 |
Beta Was this translation helpful? Give feedback.
-
Developer Experience
We've recently received feedback on migrating from v3 to v4 of our SDK. In v3, the main entry point into the SDK was
BraintreeFragment
, an AndroidFragment
subclass. In v4, we extracted the core functionality from BraintreeFragment intoBraintreeClient
, a plain java object. This improves the modularity of the SDK, increases overall test coverage, and makes it easier to add new features.On the other hand, there was a slight advantage to subclassing Fragment – the SDK had its own lifecycle. This made integration simple, you could instantiate a
BraintreeFragment
in either an Activity or a Fragment and you would receive updates from the SDK via listener callbacks.We recognize how this integration pattern poses fewer architectural restrictions on merchant apps, and we would like to find a way to offer the same v3 experience in v4.
We've internally discussed possible enhancements to our API, and we'd like feedback to see if what we propose meets merchant needs before prioritizing work.
In short, we'd like to:
onActivityResult
in favor of the newregisterForActivityResult
Jetpack APIMaking these changes results in the following API (using PayPal as an example):
Then, you may choose to integrate the Braintree SDK into your applicatioin in either an
Activity
or aFragment
:Beta Was this translation helpful? Give feedback.
All reactions