wax911
commented
9 months ago I believe this is a perfect opportunity to provide artifacts for serialization variants for the sole reason of simplification. Here's what I have in mind from a high level, we can discuss the implementation detail.
The idea is to split out the library into:
- core: Purely functional parts of emojify
- contract: Model as interface with default implementation for deserialization to avoid having to rely on AbstractEmoji and
serializer.decodeFromStream(inputStream).map { it.toEmoji() }This approach is slightly less efficient (.map) as you perform two passes of the model constructing it & iterating through each model to create an emoji, rather than the original implementation which does this in one pass.
In the original implementation
decodeFromStreamhas a time complexity of O(n), where n is the size of the input stream, the overall time complexity for the first case remains O(n) because it directly deserializes the data from the input stream into a list.
In your case decodeFromStream utilises .map , after deserialization, there's an additional map operation applied to each element, which has a time complexity of O(m), where m is the number of elements in the list. Thus, the overall time complexity for the second case would be O(n + m), considering both deserialization and mapping.
- deserializer: Essentially we implement the
IEmojiinterface into concrete implementation which will look very similar toEmojijust with the correct annotations (this way consumers only use what they need and can create their own if need be) - initializer: Also optional, and should work on the basis of the contracts and shouldn't care about which deserializer is used. e.g.
interface IEmojiDeserializer { fun decodeFromStream(inputStream: InputStream): List<IEmoji> }import java.io.IOException
abstract class AbstractEmojiInitializer : Initializer
@Throws(IOException::class, SerializationException::class)
fun initEmojiData(
assetManager: AssetManager,
path: String = DEFAULT_PATH,
): List<IEmoji> {
return assetManager.open(path).use { inputStream ->
serializer.decodeFromStream(inputStream)
}
}
yoobi
Description of Bug
Follow up of #179, after implementing the version 1.8.0 in my project we still need to add kotlinx-serialization
Reproduction Steps