# 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](https://github.com/google/gson)?
- [Jackson](https://github.com/FasterXML/jackson)?
- [Moshi](https://github.com/square/moshi)?
- [KotlinX Serialization Library](https://github.com/Kotlin/kotlinx.serialization)?
- 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.