From 8e2d6a0aa62d15b604dfc621a19ed1ef93a84aa7 Mon Sep 17 00:00:00 2001 From: Andrew Reed Date: Thu, 29 Aug 2024 08:43:53 +0000 Subject: [PATCH] Adjusted readme --- README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/README.md b/README.md index 71bb394dd..842a36cb7 100644 --- a/README.md +++ b/README.md @@ -329,4 +329,3 @@ More recently, with the official SDK for Android providing better support for Ko For contributors this means following these points when adding new code to the public API of this project: - **Match the [Android SDKs API](https://firebase.google.com/docs/reference/kotlin/packages).** When adding new API coverage use the Android SDK as the guide on what the public API should be in regard to naming, parameters etc. The goal here is *near binary compatibility*, meaning code consuming the Android SDK compiles *as is* with the Kotlin SDK after just changing the package imports from `com.google` to `dev.gitlive`. - **Follow our [Kotlin-first design](https://github.com/GitLiveApp/firebase-kotlin-sdk/?tab=readme-ov-file#kotlin-first-design) principles when needed.** If the API you are adding coverage for is new, and it's Kotlin-first in the Android SDK, then you can simply just match the Android SDKs API as described in the first point, but if it's an older Java-first API then ideally we would include an identical API for API compatibility *plus* a Kotlin-first overload. A good example for this is where the Builder pattern is employed in the Android SDK, here we can follow [this Kotlin-first design principle](https://github.com/GitLiveApp/firebase-kotlin-sdk/?tab=readme-ov-file#default-arguments) and provide both methods, one taking the options created with the builder and an overload with default arguments to avoid the builder boilerplate for developers not porting an existing android code base. -