Braintree Android 3.0

What’s New in Braintree Android 3.0

In May 2018, Google announced several changes to the Android developer ecosystem aimed at improving and securing the Android ecosystem. The changes ranged from streamlining the support libraries to requirements for updates to target up-to-date versions of the platform.

Among the announcements was that the Android P release would deprecate the Android framework version of Fragment. The Android framework rarely deprecates features, so this announcement surprised many developers.

Google has consistently maintained support libraries so that new components can be run on older Android versions and devices. This is a key reason why our Braintree Android SDK now relies heavily on the framework version of Fragment: BraintreeFragment

What is a Fragment?

Before Fragments, Activity was the only high-level UI component offered in Android. Apps had one Activity per screen. Switching between Activities was a heavyweight task, and often time-intensive. Having one Activity per screen also made maximizing screen real estate across various device sizes an issue. For example, a vertical phone layout is stricter on screen real estate than a tablet in a horizontal layout.

Behold the Fragment — a UI component that acts as a modular section of an Activity. A Fragment has its own lifecycle, receives its own input events, and can be reused across different Activities. A Fragment is hosted in an Activity and its lifecycle is directly affected by its host Activity’s lifecycle. When a host Activity lifecycle state changes, the attached Fragment receives a lifecycle event. For example, when a host Activity is created, started, resumed, paused, stopped, or destroyed, the Fragment’s corresponding onCreate, onStart, onResume, onPause, onStop, and onDestroy methods are automatically invoked. The Activity also provides callbacks for such events to enable the Fragment to handle UI elements based on the Activity’s current place in its lifecycle. In this way, a Fragment allows for operations and persistence outside individual Activity lifecycles — key for a network-driven library like the Braintree SDK.

What is BraintreeFragment?

Before the Fragment pattern, Android SDKs typically had issues with state management, needing delegation from an Activity to keep track of lifecycle. Fragments allow SDKs to save and restore data, and prevent method invocations on an Activity that is stopping.

We introduced BraintreeFragment starting with our Android v2 SDK. We gained a ton of benefits when moving to Fragments:

• Now we no longer need those delegation methods, since we have access to the Activity lifecycle via the BraintreeFragment. For example, the BraintreeFragment lifecycle is notified of the Activity resuming, and can automatically attach any Braintree listeners that the Activity implements. Likewise, when the Activity is pausing we can remove those listeners so a merchant’s Activity doesn’t get callbacks from Braintree as the Activity is shutting down.
• We can save/restore Braintree state to prevent unnecessary initialization requests on resuming. The first time a merchant invokes BraintreeFragment#newInstance, we make a configuration request to Braintree to figure out what payment methods they can process. If the Activity goes into the background, we can cache this using the Fragment’s onSaveInstanceState and have this data available next time BraintreeFragment is created.
• When working with our third party payment providers, the BraintreeFragment can launch a payment providers Intent using startActivityForResult. This allows BraintreeFragment to access the result from that payment provider directly without any extra implementation steps.

When we first switched to a Fragment-based design, we chose to use the Android framework’s version of Fragment (android.app.Fragment). While the Android Support Library had a support Fragment (android.support.v4.app.Fragment) readily available — and Google recommended the support Fragment — we wanted to minimize the amount of dependencies we require in the merchant’s app. So we opted to subclass android.app.Fragment.

What are we doing now that Fragment is deprecated?

We’re simply moving to a support Fragment! Given our current design of BraintreeFragment, we don’t require the integrator to know BraintreeFragment subclasses Fragment. We have helper methods like newInstance that attaches the Fragment to the merchant’s Activity. This design of BraintreeFragment makes the transition from the deprecated Fragment to the recommended Support Fragment a no-brainer.

This is a subtle breaking change since we handle all the Fragment transactions inside of our BraintreeFragment#newInstance method, but due to the fact that merchants may be interacting with our BraintreeFragment directly, this change could introduce build breakages, warranting a major version change.

Around the time that we made the decision to migrate Fragments, AndroidX was made available. Since we were planning a new major version, switching from the Android Support Libraries to AndroidX at the same time made sense as well.

So BraintreeFragment is now a subclass of an AndroidX Fragment (androidx.fragment.app.Fragment).

Other changes

AndroidX

AndroidX is a new iteration of the Android Support Library. Like the Android Support Library, AndroidX continues to ship separately from the Android OS to provide backward compatible new features to older versions of Android. Some extra quality-of-life benefits that AndroidX offers include semantic versioning and consistent namespacing with the androidx.* package.

The Android Gradle plugin has a build tool called Jetifier that automatically rewrites library binaries that depend on the Android Support Library to use AndroidX. Since Braintree Android has migrated to AndroidX, it does not need to be Jetified during the build process.

minSdkVersion to 21

Last year Braintree started requiring HTTPS connections to be TLSv1.2, so this update bumps the minimum Android SDK version to one that fully supports TLSv1.2. Android 21 is the first available Android version that has enabled TLSv1.2 by default.

Modernizing for You

Google’s changes to Android are targeted toward reducing malware, expanding backward compatibility, and generally improving the developer experience. The changes we’ve incorporated into our 3.0 release are meant to keep our developers on the cutting edge of the ecosystem and to take advantage of what’s coming in Android Q and beyond.

How do I update?

We’ve aimed to make this an easy update for most existing integrations. Even though it is a major version bump, we’ve kept API changes to a minimum. In fact, if you are up to date with Android development, not currently using any deprecated code from Braintree Android, and using Braintree Android the way we recommend in our docs, you may not experience any breaking changes when migrating from 2.0 to 3.0.

For a detailed list of changes we’ve made for this release, see our migration guide from Braintree Android v2 to v3.