This document outlines development practices that we follow internally while developing this SDK.
The included demo app utilizes a test merchant server hosted on heroku (https://braintree-sample-merchant.herokuapp.com). It produces client tokens that point to Braintree's Sandbox Environment.
You can also host a locally running Gateway and/or merchant server.
All tests can be run on the command line with rake
. It's a good idea to run rake
, before committing.
If you are running tests on an emulator or need to point at a specific url, the following can be set in the top level gradle.properties
file:
// defaults to 10.0.2.2
systemProp.LOCALHOST_IP="URL_OR_IP_OF_YOUR_LOCALHOST"
// defaults to 10.0.2.2
systemProp.GATEWAY_IP="URL_OR_IP_OF_YOUR_GATEWAY"
// defaults to 3000
systemProp.GATEWAY_PORT="PORT_OF_YOUR_GATEWAY"
Please note: It is not currently possible to run tests outside of Braintree.
There are several components that comprise this SDK:
- BraintreeApi provides the networking and communication layer. Includes the PayPal Android mobile SDK.
- BraintreeData collects and provides data for fraud detection.
- CardForm is a pre-build card form view that can be used anywhere.
- Drop-In uses
BraintreeApi
to create a full checkout experience inside anActivity
. - Demo is the reference integration of Drop-In.
- FakeWallet is used to test the app switch portion of the SDK.
- TestUtils contains common test code used between modules.
The individual components may be of interest for advanced integrations and are each available as modules in maven.
- Android Studio >= 1.0.0 and Android >= 10
- Android 21 target SDK
- Gradle
- Host app does not integrate the PayPal Android SDK
- Host app does not integrate with the Kount SDK
- Host app has a secure, authenticated server with a Braintree server-side integration
- Commits should be small but atomic. Tests should always be passing; the product should always function appropriately.
- Commit messages should be concise and descriptive.
- Commit messages may reference the trello board by ID or URL. (Sorry, these are not externally viewable.)
- Code on master is assumed to be in a relatively good state at all times
- Tests should be passing, all demo apps should run
- Functionality and user experience should be cohesive
- Dead code should be kept to a minimum
- Versioned deployments are tagged with their version numbers
- Version numbers conform to SEMVER
- These versions are more heavily tested
- We will provide support for these versions and commit to maintaining backwards compatibility on our servers
- Pull requests are welcome
- Feel free to create an issue on Github before investing development time
- As needed, the Braintree team may develop features privately
- If our internal and public branches get out of sync, we will reconcile this with merges (as opposed to rebasing)
- In general, we will try to develop in the open as much as possible