UX SDK 5.0 Overview

Table of Contents

• UX SDK Framework Architecture
• Widget Architecture
  • Widget Model
  • Widget Model Binding
  • Widgets
  • Sub Module
    • Using a Sub Module in your custom WidgetModel
    • Creating a custom Sub Module
• Panels
• Alerts
• Hooks
• Other Information

UX SDK Framework Architecture

During the beta period, some classes may be moved around as we evolve and refine the new UX SDK architecture. We look forward to your feedback on this initial structure and any subsequent changes.

Widget Architecture

UX SDK Beta Widgets are to be built in a Model View View Model architecture. If you are not familiar with this architecture or need some refreshing here is a reference.

For the purpose of our implementation we can view the SDK as the model and thus are mostly concerned with the implementations of the view model as well as view.

Widget Model

In UX SDK Beta our view models are referred to as Widget Models, this is just a naming convention and as such they act as our view models. The widget model's role is to collect the required data from the SDK and combine it or expose it in a useful way for the view to react. To implement a widget model there are a couple steps that need to be followed:

• Subclass DUXBetaBaseWidgetModel
• Import the following 3 headers:

        #import "DUXBetaBaseWidgetModel+Protected.h"
        #import "NSObject+DUXBetaSDKBind.h"
        #import "NSObject+DUXBetaRKVOExtension.h"

• After this, override the - (void)inSetup and - (void)inCleanup methods, which are called as part of the lifecycle of the base widget models. Inside of the inSetup method is where we will bind the widget model to the SDK and inCleanup is where we will unbind from the SDK.

When exposing the public properties on the widget model that can be bound to it, it is important to make them readonly so that they can only be changed through the implementation rather than from the widget or outside sources.

Widget Model Binding

In order to get the data from the SDK we created a BindSDKKey macro which takes in any DJI key and a property name - the Objective C runtime unwraps and assigns the key's value to the property. The majority of the work for key to value mapping is done in NSObject+DUXBetaMapping, if you are looking for how this works. A sample binding inside of inSetup looks like this: BindSDKKey([DJIProductKey keyWithParam:DJIProductParamModelName],productName), where we are are binding the product name key to an NSString property.

If after setting up all your bindings to SDK Keys you need to perform some cleanup on the data or combine the data from multiple keys to generate some state we have another bind macro called BindRKVOModel which takes in a target, selector, and comma separated list of properties that you want to bind to. This macro binds to a list of properties and when any of them get updated the selector will be called. If you need to use the old value of the property inside of the selector have the selector take an argument of type DUXBetaRKVOTransform which will tell you which property was updated as well as its old value and new value.

The last thing that needs to be done is inside of inCleanup we need to call UnBindSDK and UnBindRKVOModel(self). This tears down the bindings we made and keeps our object from leaking.

Widgets

When building the widget there are a couple things that you need to do as followed:

• Subclass DUXBetaBaseWidget
• Import the following header: #import "NSObject+DUXBetaRKVOExtension.h"

Once this is done we can setup the widget to react to changes in the widget model. In order for the widget model to function we need to call the DUXBetaBaseWidgetModel's method -(void)setup. This will trigger the widget model to call its inSetup method.

After this we need to bind our widget to the public properties of its widget model. To do this we use the BindRKVOModel macro as well. An example binding in our widget would look like this:

BindRKVOModel(self.widgetModel, @selector(updateAPASImage), apasState);

The last thing the widget needs to do is tell the widget model when to cleanup so in viewDidDisappear we call the cleanup method on the widget model and the UnBindRKVOModel(self.widgetModel) macro in order to keep leaking from occurring.

Sub Module

A Sub Module is an abstraction of data from the SDK which is compiled into common logic that can be used by multiple widget models.

Using a Sub Module in your custom widget model

To use a Sub Module in your custom widget model, just call addModule:(DUXBetaBaseModule *)module during initialization in order for the Sub Module to be included in the widget model's lifecycle. For example, if you would like to include the unit type Sub Module in your custom widget model, you can use the following code:

open class MyWidgetModel : DUXBetaBaseWidgetModel {

    public var unitModule = DUXBetaUnitTypeModule()

    public override init() {
        super.init()
        add(unitModule)
    }
}

Creating a custom Sub Module

To create a custom sub module, the class must extend the base DUXBetaBaseModule class. These are the methods that need to be overridden:

• - (void)setup - This is where the sub module's properties bind with the SDK keys. (See Widget Model Binding for more details).
• - (void)cleanup - If the sub module needs to do any cleanup to avoid memory leaks, it should be done here.

@objc public class MyModule: DUXBetaBaseModule {

    public override func setup() {
      // Set up the module by initializing all the required resources
    }

    public override func cleanup() {
      // Clean up the module by destroying all the resources used
    }
}

Panels

Panels are a cluster widgets designed to contain collections of widgets. The panels types available for use are Bar, Toolbar, and List. See the following wikis for more information on the panel architecture: base panel widgets, list panel widget and bar panel widget.

Alerts

The Alerts Architecture is designed to implement a highly customizable alert that displays a message to the user. Currently, these alerts are used to within the system status list widgets that need to have the user's acknowledgement of certain messages. The system encapsulates a layout controller responsible for positioning the alert, a stack controller that keeps track of the visible alert and a mask alert acting as the alert backing view responsible for handling the user interaction and responsible for displaying a custom background of the alert.

Modules

UX SDK 5 Beta is split into multiple modules. See UX SDK Modules Wiki .

Hooks

The Hooks system is designed for developers to install callbacks which are called when widgets or widget models experience changes, either from aircraft updates or user interactions. It can be used to for adding analytics or making dynamic interface changes based on currently active widgets.

Other Information

We have categories for loading assets as well as colors and fonts. When loading assets, using colors, or using fonts please use the values defined in the categories instead of the values from UIKit so we can standardize the appearance across UX SDK Beta.