Crash when using system inputs about flicktypekit HOT 11 CLOSED

Fixed in 3ba87b3

@Reiszecke this is SwiftUI specific, but note that the .completionType function now returns an optional, with nil implying that the user chose one of the system input options (dictation, scribble, emoji) instead of FlickType.

from flicktypekit.

No need to apologize! Software can't be verified, it can only be tested so unless you anticipate a possible error, it's impossible to know there is an error, don't be sorry!

from flicktypekit.

Whoops, my bad for not testing this. Looking at it, it’s an easy fix but I wonder:

• Should there even be a completionType when FlickType wasn’t used?
• Should the onCommit() get called when FlickType wasn’t used?

One thought is to return nil for completionType, and perhaps rename to flickTypeCompletionType to better explain why it might be nil sometimes.

Another thought is when FlickType wasn’t used, always return .action so that the onCommit() gets called, assuming this is the desired behavior in general.

The first option seems more flexible...

from flicktypekit.

Sorry I'm late to the party. What I did back then to avoid the crash was to do the following:

... items in if let text = items?.first as? String {
    if(items?.count ?? 0 > 1) {
        if let completionType = items?.completionType {
            if(completionType == .action) {
                . . .

There probably is a nicer way to handle this but that was my quick fix for people reporting crashes and required my immediate attention.

Basically afaik since the completionType is an overload of NSArray, checking on its value when it's not present causes a nil crash (like trying to access the n+1th element of an array with a length of n)

I never understood why Apple's text input callback was an array to begin with but since I have never seen any other combination than

A) [text]
B) [text, completionType]

I simply decide by the array's length whether or not I can expect a completionType. If I'm not mistaken, completionType is basically the same as items?[1] but I have never tried that, not sure

from flicktypekit.

@Reiszecke your fix makes sense.

Apple’s callback is an array because there are/were some cases with multiple return values, where one of them might not even be an String! Can’t recall when that happens/happened exactly, but I think it could sometimes even be an Image and maybe had something to do with the “Digital Touch” feature. In practice, the return value is a single-element array with a String.

The completionType is strictly a FlickType addition. In order to preserve the Apple callback signature, FlickType will simply inject a completionType in the array. The implementation is the first object that is of the appropriate type:

var completionType: FlickType.CompletionType {
    return compactMap { $0 as? FlickType.CompletionType }.first!
  }

I’m leaning towards just changing the return type to an optional, and let the caller decide what to do when a completionType isn’t present - which would indicate that FlickType wasn’t used.

from flicktypekit.

I did NOT know it can be something else, interesting! But what you say about the digital touch makes sense. I think Apple should've separated these features so all text input calls most not return anything but a String.. Apple being Apple I guess?

I'd agree to your "optional" idea, this would clear up some confusion

from flicktypekit.

@Reiszecke in your opinion, should FlickTypeTextEditor.onCommit() get called when FlickType wasn’t used?

from flicktypekit.

Haven't used the SwiftUI implementation yet, onCommit() is SwiftUI-specific, right?

from flicktypekit.

• Should there even be a completionType when FlickType wasn’t used?
• Should the onCommit() get called when FlickType wasn’t used?

If it helps, from my perspective the intent for adding onCommit was to make it easy to replace aTextField that performs some action upon the user tapping Done after dictation/scribble with a FlickType compatible one. So I’d see it as advantageous to still run onCommit if a user chooses to use dictation or scribble instead.

One option might be to add an unknown or notFlickType (I’m sure there is a better name) completionType that’s more explicit about what the keyboard choice was, and then the SwiftUI text editor can test for that or .action before calling the closure?

from flicktypekit.

Although I guess testing for .action or nil and then calling the closure probably makes more sense technically. That just seemed a bit odd to me at first.

from flicktypekit.

Amazing, thanks Kosta 🙏
(and sorry I hadn’t tested this part of the flow as I tweaked the PR)

from flicktypekit.