---
# System prepended metadata

title: Android Northstar Development Stack

---

# 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.