crisp-im / crisp-sdk-android

:package: Crisp Android SDK, add a chat in any Android app and communicate with your users.
https://docs.crisp.chat/guides/chatbox-sdks/android-sdk/
Other
56 stars 17 forks source link

Undocumented limitations of session events' data #177

Closed gekylafas closed 4 months ago

gekylafas commented 4 months ago

Through much trial-and-error, I (think I) have found some limitations about session events which, as far as I know, are not documented anywhere:

So, are those limitations true? Are there any other we should know about? Could you please document them somewhere so that we can avoid the guesswork?

eliottvincent commented 4 months ago

Hello @gekylafas :)

Yes those are real limitations. While they are not actually documented, they are explicitly returned by our API in case your data would be in conflict with one rule. Although I have to admit that if you use RTM, or any SDK, your data will be silently dropped.

Please find below the full list of limitations regarding events:

gekylafas commented 4 months ago

Hi @eliottvincent! Thank you for you answer!

I assume that "text: max length 80" refers to the name of the event, i.e. the first paramater of SessionEvent's ctor, right? Also, what about the value of each property? Is it true that its max length is 120?

Finally, should those limitations be added to the Android (& iOS) SDK's Wiki documentation or just left here in this issue?

eliottvincent commented 4 months ago

I assume that "text: max length 80" refers to the name of the event

Yes true, it's the text property referred here: https://docs.crisp.chat/references/rest-api/v1/#add-a-people-event

Also, what about the value of each property? Is it true that its max length is 120?

Yes, each value can either be a number, string or boolean, with a 120 length limit.

Finally, should those limitations be added to the Android (& iOS) SDK's Wiki documentation or just left here in this issue?

Ideally yes, but we need to find a way to maintain these values up-to-date (in case of a change on our side) and that's why they are not documented right now :) We can't afford to maintain every validation rule, by hand, in multiple docs (JS SDK, iOS SDK, Android SDK, REST API, RTM API)