https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
s

Sylvain Patenaude

11/21/2019, 4:19 PM
From an SDK consumer viewpoint, would it be preferred to return an
array
of strings or a
collection
of strings? Potential consumers (other than Koltin itself) could be Java, Swift, Objective-C, React Native, Xamarin, etc.
k

Kris Wong

11/21/2019, 4:21 PM
that depends on how the data is intended to be consumed
or stated another way, what use cases the API is optimized for
s

streetsofboston

11/21/2019, 4:41 PM
Use a type, for the return-value, that is an interface/protocol that is as small as possible. If the returned ‘collection’ just needs to be iterable, the return-type should be a Collection. If it needs to be accessed by index, the return-type should be a List or Array (but not a particular implementation/sub-type of List or Array), etc. It depends, but make the return-types interface/protocol as small as possible but large enough to be functional for your SDK consumers, decoupling your SDK’s API from its implementation.
k

Kris Wong

11/21/2019, 4:43 PM
☝️
s

Sylvain Patenaude

11/21/2019, 4:46 PM
To give a little more context, one function of the SDK would return a collection (or array) of UUIDs (or GUIDs) as strings (since there's no Kotlin
Guid
type). For now I don't know all the potential usages, but I guess that would possibly include: • Iterating through them to convert them in true GUID types in the consumer programming language • Iterating through them to combine them with another bunch of UUIDs So consumers shouldn't access them by index I think.
So that would point to using a Collection. However, if I want to make the interface/protocol as small as possible, that would point me to? Array<String>?? Seems that I may have conflicting factors.
Not that thrilled to represent GUIDs as Strings but at the same time, I think most languages that support a
Guid
type have a constructor that builds a Guid from a valid string.
s

streetsofboston

11/21/2019, 5:12 PM
The return type would be
Collection<String>
(or
Collection<Guid>
if that is possible) based on your use-case (no need to access them by index). If you want to make sure that the Strings and Guids are unique, and convey that to your SDK consumer, use
Set<String>
instead.
s

Sylvain Patenaude

11/21/2019, 5:39 PM
Indeed,
Set<String>
would be an option. In the end, I don't think the specific type of "collection" (
Array
,
Collection
,
Set
,
List
) I will use in Kotlin will matter that much for my SDK.