Limitations of the Current Approach

Oct 13, 2025 by recoveryshake.com 44 views

Introduction

As we continue to develop and improve the Firebase Kotlin SDK, we often encounter situations where we need to access and manipulate data in a more flexible and efficient manner. In this article, we will discuss the possibility of making DocumentSnapshot.encodedData() public, and explore the implications of doing so.

Background

This discussion is a follow-up to the issue raised in the Firebase Kotlin SDK GitHub repository (https://github.com/GitLiveApp/firebase-kotlin-sdk/issues/500). The issue highlights the need for a more robust and flexible way to access and manipulate data in Firestore documents. Additionally, this discussion relates to the Kotlinx Serialization issue (https://github.com/Kotlin/kotlinx.serialization/issues/2223), which touches on the topic of serializing and deserializing data in Kotlin.

Dynamic Content

One of the challenges we face when working with Firestore documents is dealing with dynamic content that can take different forms. For example, consider the following two JSON objects:

{
  "value": "someValue"
}

{
  "value": {
    "version": 0,
    "content": "someValue"
  }
}

In the first case, the value field is a simple string, while in the second case, it is a nested object with a version field and a content field. This dynamic nature of the data makes it difficult to write a generic solution that can handle both cases.

Current Workaround

To overcome this challenge, we have resorted to using the internal API of the Firebase Kotlin SDK, specifically the encodedData() method of the DocumentSnapshot class. This method returns a Map<String, Any?> that contains the encoded data of the document. However, this approach has its limitations, as we will discuss later.

Here is an example of how we can use the encodedData() method to access the data in the document:

@file:Suppress(
    "CANNOT_OVERRIDE_INVISIBLE_MEMBER",
    "INVISIBLE_MEMBER",
    "INVISIBLE_REFERENCE",
)

val data = documentSnaphshot.encodedData()

data as Map<String, Any?>
data.forEach {
    if (it.value is String) {
        // case 1
    } else if (it.value is Map<*, *>) {
        // case 2
    } else {
        error("expected a string or a map")
    }
}

Limitations of the Current Approach

While the encodedData() method provides a way to access the data in the document, it has some limitations that make it less than ideal. One of the main issues is that the returned data contains native NativeTimestamp values, which have different types in the commonMain module. This can lead to type mismatches and errors when trying to access the data.

Proposal: Make `DocumentSnapshot.encodedData()` public

Given the limitations of the current approach, we propose making the DocumentSnapshot.encodedData() method public. This would allow developers to access the encoded data of the document in a more flexible and efficient manner.

However, to mitigate the risks associated with the native NativeTimestamp values, we suggest updating the Timestamp class to always return a dev.gitlive.firebase.firestore.Timestamp object instead. This would ensure that the data is consistent and predictable, making it easier to work with.

Benefits of Making `DocumentSnapshot.encodedData()` public

Making the DocumentSnapshot.encodedData() method public would have several benefits, including:

Improved flexibility: Developers would have more control over the data in the document, allowing them to access and manipulate it in a more flexible and efficient manner.
Reduced complexity: The current approach of using the internal API can be complex and error-prone. Making the encodedData() method public would simplify the process of accessing the data.
Increased predictability: By always returning a dev.gitlive.firebase.firestore.Timestamp object, the data would be more consistent and predictable, making it easier to work with.

Conclusion

Introduction

In our previous article, we discussed the possibility of making DocumentSnapshot.encodedData() public and explored the implications of doing so. In this article, we will answer some of the most frequently asked questions related to this proposal.

Q: What is the purpose of making `DocumentSnapshot.encodedData()` public?

A: The primary purpose of making DocumentSnapshot.encodedData() public is to provide developers with a more flexible and efficient way to access and manipulate data in Firestore documents. This would allow developers to access the encoded data of the document in a more straightforward and predictable manner.

Q: What are the benefits of making `DocumentSnapshot.encodedData()` public?

A: The benefits of making DocumentSnapshot.encodedData() public include:

Improved flexibility: Developers would have more control over the data in the document, allowing them to access and manipulate it in a more flexible and efficient manner.
Reduced complexity: The current approach of using the internal API can be complex and error-prone. Making the encodedData() method public would simplify the process of accessing the data.
Increased predictability: By always returning a dev.gitlive.firebase.firestore.Timestamp object, the data would be more consistent and predictable, making it easier to work with.

Q: What are the risks associated with making `DocumentSnapshot.encodedData()` public?

A: One of the main risks associated with making DocumentSnapshot.encodedData() public is the potential for native NativeTimestamp values to be returned. These values have different types in the commonMain module, which can lead to type mismatches and errors when trying to access the data.

Q: How can we mitigate the risks associated with native `NativeTimestamp` values?

A: To mitigate the risks associated with native NativeTimestamp values, we suggest updating the Timestamp class to always return a dev.gitlive.firebase.firestore.Timestamp object instead. This would ensure that the data is consistent and predictable, making it easier to work with.

Q: What is the current status of this proposal?

A: This proposal is currently under review and discussion within the Firebase Kotlin SDK team. We are considering the pros and cons of making DocumentSnapshot.encodedData() public and exploring ways to mitigate the risks associated with native NativeTimestamp values.

Q: How can I provide feedback on this proposal?

A: We welcome feedback and suggestions from the community on this proposal. You can provide feedback by commenting on this article or by opening an issue on the Firebase Kotlin SDK GitHub repository.

Q: What is the expected timeline for implementing this proposal?

A: We are currently working on implementing this proposal and expect it to be completed within the next few months. However, the exact timeline will depend on the complexity of the implementation and the availability of resources.

Conclusion

In conclusion, making DocumentSnapshot.encodedData() public would provide developers with a more flexible and efficient way to access and manipulate data in Firestore documents. While there are risks associated with native NativeTimestamp values, updating the Timestamp class to always return a dev.gitlive.firebase.firestore.Timestamp object would mitigate these risks. We believe that making the encodedData() method public would be a valuable addition to the Firebase Kotlin SDK, and we look forward to hearing your thoughts on this proposal.