Feature/mob 3434 entry widget poc

[andrews-moc]

Project plan (draft)
Simplified way of using Glia Widgets SDK

Please have a look and share your early feedback. 🙏

What was implemented in this POC?

• Entry Widget class with Bottom sheet (POC)
• Entry Widget is created using constructor EntryWidget(Navigator)
• Navigator object is responsible for starting engagement (chat, audio call, video call, messaging)
• Navigator is obtained through GliaWidgets.getNavigator(queues, contextAssetId)
• So, integrators will have to pass params to Navigator or explicitly pass null, and create EntryWidget using the Navigator
• CallActivity becomes internal, CallActivity can now be started only through Navigator instead of Intent
• At the moment POC is only for CallScreen

Screenshots:

[DavDo]

I think we can also simplify and remove a lot of stuff related to Activity creation and intents since this stuff becomes fully internal.

[andrews-moc]

I think we can also simplify and remove a lot of stuff related to Activity creation and intents since this stuff becomes fully internal.

Yes, I will just need to go through that stuff and refactor.

[EgorovEI]

contextAssetId is visitor context id?

[andrews-moc]

Yes, exactly.

[igorkravchenko]

Overall looks good. Left some questions regarding alternative method to start interaction using enum.

[igorkravchenko]

@andrews-moc @DavDo
While having dedicated method like startToChat, startAudioCall , startVideoCall , startSecureConversations is totally acceptable approach, an alternative way could be to have singe method someting like start(InteractionKind) where InteractionKind could enlist all possible kinds to start interaction.

In Swift it would be something like this:

enum InteractionKind {
case videoCall
case chat
case secureConversations
}

func start(interactionKind: InteractionKind, context: Context) { 
...

Having dedicated enum for all possible interactions seems more appealing to me, because we avoid having several very similar public method declarations.

Does it make sense?

cc: @EgorovEI @rasmustautsglia

[andrews-moc]

Thank you for sharing this idea. It makes sense to me overall.

At the same time, I think that POC approach with separate functions has several advantages as well:

• it's more readable and closer the the way we think about it in real life
• anyway we would need separate functions, the difference is that with a single start(InteractionKind) method these methods would be private
• although these functions have some common things, their implementation is different

I'm not against start(InteractionKind), let's hear other opinions.

[DavDo]

IMHO, this solution is not acceptable for this situation because I see a couple of issues.

1. It is not enough flexible — in the case when some of the underlying methods (starting chat, video, or secure conversation) require additional parameters, we will have to deprecate this function and replace it with a new function/functions.
2. It breaks the single responsibility principle - every InteractionKind type has its nature and will launch a completely different unit of our SDK, so it might be clearer if every single function was responsible only for starting one kind of interaction.
3. With SC V2 we will have additional functionality inside each of these functions. This is to choose the right screen based on an ongoing SC + unread messages combination, so even if we repeat some functionality (that actually can be moved to some internal function), it is better to have separate functions to reduce complexity.

[Pelkar]

I would like to point out that the public access methods will be the main interaction point for integrators who will not be using the Entry Widget. So three defined functions seems less confusing even if I personally like the suggestion Igor proposed.

[igorkravchenko]

@DavDo

1. In this case enum case will have associated required parameter so it's not a problem, at least in Swift. However if this is not possible in Kotlin, or will drastically differ, than it makes sense to use separate methods instead as it is now.
2. Still enum with associated values allows singe entry point and we do not expand surface area for change/deprecation in future when all those methods will start to require additional parameters, so there would more to deprecate. I agree that it will grow complexity on the single method though.
3. Agree totally.

I do not enforce the enum usage, especially because it may be problematic to have similar interface on both platforms. The goal is just to understand if it can bring some advantage. I'm fine with using separate methods.

[DavDo]

1. It is also possible in Kotlin. I agree that this way we can avoid deprecation and make it more flexible.

Yes, I agree with @Pelkar. I like this kind of modern solution, but for public interfaces, I would prefer to have functions that are as straightforward as possible.

[DavDo]

@andrews-moc If I'm not mistaken, we can use application context from configuration properties, so most probably no need to explicitly pass it here.

[andrews-moc]

@DavDo I was not able to find a way to use it so far. Context is available for Glia core init only, as far as I see.