Skip to main content

Overview

As already mentioned in the Introduction, Master Controller uses an event based communication to the app. In the following sections, we describe the setup of the framework for sending and receiving events and then the most important events and how to send or process them.

There are a few things that you absolutely MUST implement on your way to a working app, here is a short list of these decisive sections:

  • Bridging-Header (iOS/Swift): Without such a header, you typically lack easy access to some of the functionality of the MC SDK.
  • Initialization of the MasterController (iOS/Swift) and
  • Implement MasterController interface (iOS/Swift): The first step needed to establish a connection between your Swift app on iOS and the MC SDK.
  • Initialization of the MasterController (Android/Kotlin): The first step needed to establish a connection betweek youf Kotlin app on Android and the MC SDK.
  • Start Event: The first event that you need to send to MC SDK using the connection established in the previous step.
  • Activation, Login, ... in one of the server environments(KOBIL Digitanium, KOBIL Digitanium+,KOBIL Shift Lite-TWV or KOBIL Shift Lite-KssIdp) is bound to be the most important reason why you are using the MC SDK, so depending on which environment you use, you obviously need to activate your user accordingly and/or log in to the environment.
  • Handling Suspend and Resume properly is especially important in our environment, as the protection mechanisms implemented in the MC SDK tend to lead to crashes if your app is suspended or resumed without properly notifying the MC SDK about this change of state.
  • Finally, be prepared to handle the invalid state event in reply to any event you send. While this typically occurs during development when improperly using the MC SDK (so handling it right from the beginning should simplify your life...), it also might happen occasionally in "real life", e.g. when something went wrong on the server side or with your internet connection.

Now, on to some things that you do not have to implement to get a working app, but which you really SHOULD implement - either to simplify your own life or the life of the end users:

  • We strongly recommend to implement the needed functions to enable tracing as this greatly simplifies everyones life when something goes wrong or when you need support.
  • Similarly, support for exporting logs is very helpful when something goes wrong.
  • In the KOBIL Digitanium environment, users need a PIN to authenticate to the server, so implementing Reactivation (Forgot PIN) will be very helpful in real life.
  • While we do not specifically recommend to force end users to regularly change their PIN, giving them at least the option to change their PIN is recommended.

Finally, the following points CAN be implemented if you need/want them and can be safely omitted if you do not need the corresponding feature:

  • In KOBIL Digitanium and in KOBIL Digitanium+ it is possible to manage multiple users/accounts from the same instance of your app. If you want to use that feature, you can implement the functionality to add users (either in Digitanium or in Digitanium+ and to delete users.
  • You can use our transaction mechanism to send arbitrary messages to end users and optionally require them to confirm the message. This is useful e.g. for financial transactions.
  • You may also use push notifications to reach your users even when the app is suspended.
  • Your users might use multiple devices to access the same account. In such scenarios, setting a specific device name and getting information about a device as decribed in Set/Get Device Information may be helpful to identify which device is currently used.
  • Get SDK Information allows you to collect some details about the SDK version that your app is using. Once you have multiple versions or even multiple apps using different SDK versions, using this event can be helpful to understand which version of the SDK is being used where.
  • In many cases, a released app will work with on particular server or one particular set of servers. However in special circumstances or during development, it can be helpful to allow easily switching between different servers (e.g. to switch between a production environment and a test environment). If you wnat to do this, see our notes on server switching.
  • Finally, there is a whole bunch of events that are used much more rarely or that are even considered outdated, for a full list see the section Master Controller API.