Description

All (or at least, the most used and problematic) public properties used for binding the ViewModels on UIView extensions are now prefixed with "trikot".

Motivation and Context

This prevents naming conflicts with host applications.

How Has This Been Tested?

Tested in my application. A simple rename in all UIViews did the trick :).

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to change)

Description

Update Trikot to Kotlin 1.7.20!

We did not move to 1.7.22 due to some missing dependencies around Jetpack Compose that were blocking us, forcing us to split the dependencies into each version because we could not use 1.3.2 based on the RUNTIME as expected.

Motivation and Context

A few other projects using Trikot were already using 1.7.20 with great success. It's our time to shine and move forward as well!

How Has This Been Tested?

It got integrated as a Maven local dependency within our project that uses almost all platforms, including Javascript.

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

Bump:

• AtomicFu from 0.17.0 to 0.17.1
• Jetpack Compose from 1.2.0-alpha03 to 1.2.0-alpha07
• Kotlinx.Coroutines from 1.6.0 to 1.6.1
• Ktor from 2.0.0-beta-1 to 2.0.0
• Kotlin to 1.6.20

Description

Provide coroutine interop with Publishers This is a fork of https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/kotlinx-coroutines-reactive/ with the following modifications:

• It is now published as a KMM module, except for js target where there are some unbound symbols.
• Removed JVM specific code and Reactor lib specific code.
• Removed deprecated functions

Motivation and Context

This should serve as a bi-directional bridge between our reactive publishers and coroutine flows and channels.

How Has This Been Tested?

It hasn't been tested yet and will be a bit later. Unit tests from original codebase weren't ported either.

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

It was not possible to manage accessibility with our viewModel. While doing it in our project I took the opportunity to bring it in trikot.viewModel.

Bonus : I also fixed the sample app that had a cell reuse problem on iOS.

Motivation and Context

• isAccessibilityElement: Publisher<Boolean> : Return true if it should be exposed as an accessibility element.
• accessibilityLabel: Publisher<String> : String that identifies the accessibility element.
• accessibilityHint: Publisher<ViewModelAccessibilityHint> : Describes the result of performing an action on the element.

How Has This Been Tested?

In the sample app

Android

https://user-images.githubusercontent.com/6673075/152240065-bfa50493-1563-4805-aef9-b352c4c0b64a.mp4

iOS

https://user-images.githubusercontent.com/6673075/152240098-8d47557c-699a-418c-93f8-a69801701494.mp4

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

This provides a DSL in order to create common VM components, we can use it as follows:

text("My label")
localImage(ImageResource.MY_IMAGE)
buttonWithText("My button" action = {}) 

Instead of:

VMDComponents.Text.withContent("My label", cancellableManager)
VMDComponents.Image.local(ImageResource.MY_IMAGE, cancellableManager)
VMDComponents.Button.withText("My button", cancellableManager)

Motivation and Context

Most of the time when creating view models we are already inside a VMDViewModelImpl context, so we should be able to create components view models easily without passing the cancellableManager  / coroutineScope everywhere. Using an interface we can easily extend the DSL with custom definitions inside each projects if needed. Also if we are in the context of a "content" class or anything other than a view model we just need to implement the interface in order to be able to use the DSL.

How Has This Been Tested?

This has been tested locally in other projects

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

This new module is a Gradle plugin that uses annotation processing to generate the boilerplate code needed when using Trikot ViewModel Declarative (or its -flow variant).

Motivation and Context

Boilerplate code writing should be kept to a minimum. Code generation is sometime the solution.

Adding a simple @Published annotation to a view model field will automatically generate a base class that contains all the code needed to make this field properly "published".

How Has This Been Tested?

The "stream" version of the plugin is used in a production project and has been battle tested. The Flow variation is more recent, and should be considered as "early alpha", since no project has actively used it yet.

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

Removed the fillMaxWidth() from VMDLabeledComponent to give more control to the app

Motivation and Context

VMDSwitch and VMDCheckbox were forced to take the fullWidth when it's not always needed.

How Has This Been Tested?

The changes were tested in both sample apps

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to change)

*** Projects need to add fillMaxWidth to the modifier like it was added in the sample projects

Description

This PR provides an engine to drive animations from common code.

It supports all the basic types of animations:

• Ease In
• Ease Out
• Ease In/Out
• Custom Cubic Bezier
• Spring

This PR also:

• Refactor sample's Home Screen to include sections
• Adds a SwiftUI utility to use ForEach directly with VMDIdentifiableContent
• Adds AtomicStackReference in trikot.foundation

Motivation and Context

Using the MVVM pattern it is pretty hard for a view to perform a change animated because the view layer don't have any insight on the type and context of a change. To alleviate that, we introduce the concept of animations in the view model layer.

There is basically two ways to perform an animated change:

Closure based

A closure based version suitable when the change occur as a result of the press of a button or a specific lifecycle event. All the published properties updated within that block will be animated.

withAnimation(VMDAnimation.Tween(duration = 1.seconds, easing = VMDAnimationEasing.Standard.EaseInEaseOut)) {
        // Perform the change here
}

Binding based

If the change is introduced as part of a binding on a reactive chain, we also have the possibility to bind a value animated. Instead of providing only the value, we have to supply a pair of the value and an optional animation object. The exemple bellow animates the alpha value but does not animate the initial value and animates only the visible -> hidden transition while performing the hidden -> visible change without animation.

bindHiddenAnimated(
    hiddenPublisher.withPreviousValue().map {
        val previousValue = it.first
        val value = it.second
        if (previousValue == null) { // No animation if its the first value received
            Pair(value, null)
        } else { // Optionally animate only some changes
            Pair(value, if (value) VMDAnimation.Tween() else null)
        }
    }
)

Usage in native code

SwiftUI

Since SwiftUI is able to automatically infer the updated properties and interpolate between them, there is no further step required for the animation to be effective. It is the equivalent of performing a change for a @State or an @ObservedObject within a withAnimation closure.

Jetpack Compose

It is a bit more effort on the Jetpack Compose side because the animation engine requires that we specifically declare an interpolator for a property to be animated.

Example for animation of the alpha value

val animatedHiddenProperty by viewModel.textField.observeAnimatedPropertyAsState(
    property = viewModel.textField::isHidden,
    transform = { hidden -> if (hidden) 0f else 1f }
)
val alphaAnimationProgress by animateFloatAsState(
    targetValue = animatedHiddenProperty.value,
    animationSpec = animatedHiddenProperty.animationSpec()
)

Notes

The previous animation mechanism that was iOS only and that would animate all the changes no mater the type of change have been completely removed as it is nearly unused internally and it has just been introduced.

Result

iOS

https://user-images.githubusercontent.com/291573/158255503-7b985480-776b-4c66-9726-54281c2c8c48.mp4

Android

https://user-images.githubusercontent.com/291573/158255555-3de5c3e2-fd39-43fd-b163-4797747620f5.mp4

How Has This Been Tested?

An animation showcase screen was added in the sample app.

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

Having the VMDButtonViewModel actionBlock as a var was causing freezing exception if the ViewModel was freeze before setting the action. The ViewModel was frozen more often than we imagined, only binding a property on the ViewModel is freezing the ViewModel and all of the objects around 😬

Motivation and Context

A regression was introduce in a previous modification and that regression was generating crashes everywhere 😬

How Has This Been Tested?

Tested in VMD sample project

Types of changes

• [X] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Because setAction perform a subscribe on a publisher, setting an action on a large number of items becomes an expensive operation. If possible, refactor this so there is no unnecessary subscription for buttons that are not tapped.

fun setAction(action: () -> Unit) {
    actionPublisher
        .observeOn(VMDDispatchQueues.uiQueue)
        .subscribe(
            cancellableManager,
            onNext = {
                action()
            }
        )
}

We should add a string that represents the current value of the accessibility element.

From the documentation

The value is a localized string that contains the current value of an element. For example, the value of a slider might be 9.5 or 35% and the value of a text field is the text it contains.

Use the value property only when an accessibility element can have a value that is not represented by its label. For example, a volume slider’s label might be “Volume,” but its value is the current volume level. In this case, it’s not enough for users to know the identity of the slider, because they also need to know its current value.

When using a simple ViewModel instead of a ButtonViewModel, we don't see any of the buttons being described as "button", because the view model is bound to plain views. One way to fix this is to force the accessibility role or trait.

On iOS, you simply add the UIAccessibilityTraitButton trait to the accessibilityTraits value: view.accessibilityTraits |= .button

On Android, it's a bit more complicated, you have to use an accessibilityDelegate to force the class name, or override view.onInitializeAccessibilityNodeInfo

ViewCompat.setAccessibilityDelegate(model, object : AccessibilityDelegateCompat() {
    override fun onInitializeAccessibilityNodeInfo(host: View, info: AccessibilityNodeInfoCompat) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.className = android.widget.Button::class.java.name
    }

This wouldn't be necessary it the button view model were attached to actual button views.

Thanks @dominiclabbe for the proposition!

Assigning an ImageViewModel to a UIImageView does not cancel the subscription to the viewModel's imageFlow when the UIView is deallocated.

class MyView: UIView {

    private let myImageView = UIImageView()

    var myViewModel: MyViewModel {
        didSet {
             myImageView.imageViewModel = myViewModel.imageViewModel
        }
    }

    override init(frame: CGRect) {
        super.init(frame: frame)

        addSubview(myImageView)   
    }

    deinit {
        // We need to manually set the image's viewModel to nil, otherwise the subscription to the imageFlow is never cancelled
        myViewModel.imageViewModel = nil
    }
}