Purchases used to be a typealias on each platform, which prevented us from accessing its companion object to call static functions (such as configure()). This meant it was necessary to have a separate object to hold these functions, which was named PurchasesFactory. This is however very inconsistent with the other SDKs.
This PR refactors Purchases to be a thin wrapper around the platform implementations instead. This way it can also expose the static functions in its own companion object, making the public API consistent with the other SDKs.
A note on PR size
The most important change is in Purchases.kt, and perhaps PurchasesCommonAPI.kt. Lots of changes are in the .api files. Another big chunk is updating references in documentation.
Background & motivation
Purchasesused to be atypealiason each platform, which prevented us from accessing its companion object to call static functions (such asconfigure()). This meant it was necessary to have a separate object to hold these functions, which was namedPurchasesFactory. This is however very inconsistent with the other SDKs.This PR refactors
Purchasesto be a thin wrapper around the platform implementations instead. This way it can also expose the static functions in its own companion object, making the public API consistent with the other SDKs.A note on PR size
The most important change is in
Purchases.kt, and perhapsPurchasesCommonAPI.kt. Lots of changes are in the.apifiles. Another big chunk is updating references in documentation.