Android Northstar Development Stack

Programming Language

Kotlin

Pros

• Extension functions/properties
• Similarity to Swift for maintaining iOS parity
• Help with developer brand
• Coroutines
• Null safety
• Delegation patterns for composition over inheritance situations
• Data classes
• Inferred type, more concise

Cons

• No Package Private, are there any alternatives? Internal doesn't necessary work.
  • Could we use an "internal" package to get around semantic versioning requirements.
  • Could we have a internal extensions?
  • Less noise with autocomplete.
  • Internal functions on public classes?
  • Internal modules -> use implementation over api for these with gradle.
• Java interop isn't as nice, have to be aware of specific annotations.
  • @JvmOverloads for example

Java

Coding Standards / Best Practices

Pros

• Package Private

Bulid/Deploy

• Version 0…
  • Can release v0.x.x to allow for breaking changes until we get to 1.0.0
• Where is the SDK being deployed to?
  • MavenCentral – Cardinal?
    • Let's assume we won't need Cardinal.
• How often will we release new versions of the SDK?
  • Target: end of each sprint, but reserve the right to not release if we aren't quite ready.
  • Sarah -> Braintree currently monthly, but working on large features.
  • Tim -> every two weeks if we are writing unit tests.
    • Long standing features, feature flags?
  • Steven -> If we can deliver value, deliver it. Regular cadence would be nice.
• Snapshot builds?
  • Used them in v3, not in v4.
  • Maybe?
• GitHub Actions for CI provider
  • Pull request hooks
• Static analysis?
  • Visible Metics ->
    • Surfacing test reports.
    • Reports should be easy to read & understand.
  • Android Lint -> Fail on lint warnings BUT if the rule isn't necessary we can discuss the rule and add it to an excludes.
  • Kotlin -> Detekt, open to other options as well.
• Testing
  • Steven -> rake test command helps with debugging tests locally.
  • Manual Testing -> Tokenization keys
    • Google Pay, Samsung Pay, Venmo Pay
    • Sandbox merchants useful for different scenarios, combining that with physical devices for e2e testing.
  • Unit Testing
    • Will practice TDD, no specific metric in mind (by default it will probably be a percentage of coverae)
    • Will use a coverage tool like Codecov to track this and provide it to merchants though our GitHub repo.
  • Integration Tests
  • End To End Tests
  • Browser Stack for physical device testing.

Quality Standards

Testing

• Unit
  • Robolectric -> Uri
  • Test Driven Development
• Integration
  • For time being we'll defer integration until we need to test specific edge cases.
• E2E
  • Start off with E2E tests to validate functionality.

Deprecation Policy

• Some classes will be exempt from the policy and we'll say which classes are and why.
  • This would allow us to use Kotlin and not have to worry about the lack of package private.

Third Party Libraries

• Jetifier -> needed for Cardinal 👎

  • Don't use libraries that aren't on Android X
    • Data Collector may need to be updated.
    • PayPal Checkout needs to be updated.
    • Auth SDK needs to be updated (why PayPal Checkout needs Jetifier).

• SDK Size?

  • Could we monitor this as part of CI.
  • Baseline on Braintree SDK size?
  • R8 for minifying output?

• Retrofit

• Serialization

  • GSON?
  • Jackson?
  • Moshi?
  • KotlinX Serialization Library?

• Coroutines

  • Could use Flow for RxJava-like code?

• Anything Jetpack 👍

• Dagger for dependency injection?

  • Can investigate to see if this will work for us.

• Navigation Component

  • Can investigate if we have UI specific code to work with.

• Data persistence?

  • Shared Preferences?
    • Could be used for most data?
  • Local Database?
    • Probably not needed.

• Work Manager

• ? mockk – possibly but need more info

• ? Robolectric – not great with powermock, when it works it works

• Device Automator

Architecture

• Extract business logic away from Android framework to promote testing.
• Can we make use of kotlin stdlib to avoid JsonObject, etc.
• Can revisit once we have some work scoped out.