Unfortunately the interface has strings built into it, so I used them as the source of truth.

Pigeon note: ObjC naming would be SharedPreferencesAPI.

Do you think Pigeon should mangle the names? That probably isn't possible. We could provide an option to override the generated name if they want something different that what is provided in the input.

Pigeon note: Couldn't we reduce the amount of generated boilerplate code by making this whole block a helper function, and only generate the block and name each time? (And the assertion I guess).

static void SomeHelper(
    id<FlutterBinaryMessenger> binaryMessenger,
    NSObject<SharedPreferencesApi *api,
    NSString *channelName,
    <insert correct block syntax here> methodHandler) {
  FlutterBasicMessageChannel *channel = [FlutterBasicMessageChannel
      messageChannelWithName:channelName
             binaryMessenger:binaryMessenger
                       codec:SharedPreferencesApiGetCodec()];
  if (api) {
    [channel setMessageHandler:messageHandler];
  } else {
    [channel setMessageHandler:nil];
  }
}

Then each code block here becomes just:

  NSCAssert(!api || [api respondsToSelector:@selector(removeKey:error:)],
            @"SharedPreferencesApi api (%@) doesn't respond to @selector(removeKey:error:)",
            api);
  SomeHelper(binaryMessenger, api, @"dev.flutter.pigeon.SharedPreferencesApi.remove",
      ^(id _Nullable message, FlutterReply callback) {
        NSArray *args = message;
        NSString *arg_key = args[0];
        FlutterError *error;
        NSNumber *output = [api removeKey:arg_key error:&error];
        callback(wrapResult(output, error));
      });

It wouldn't even need the scoping block.

Yea, that could be something we look into. It isn't boilerplate since it is generated and can be treated as a black box by the user. Boilerplate to me means code a user has to manage that has semantic meaning that is small compared to its verbosity.

Pigeon note: It would be nice to optimize the generator to not create these at all when there are no custom types.

Filed issue: flutter/flutter#97845

This is dead code.

done

Pigeon note: I think there's a potential red flag here that we've created over two hundred lines of generated code to make an 80-line implementation file 10 lines longer.

Strong typing is definitely good, but the tradeoff here is getting to be somewhat questionable. I think it's worth thinking about ways to make pigeon feel lighter weight for simple plugins.

I don't think lines of code is the correct way to measure the change because of objc formatting and the need to distinguish between compile time verified lines and runtime verified lines. Here's instead how the changes should be measured:

1. Every method went from ~6 operations to ~2.
2. Every method removed 2 casts
3. Conformance to the API is enforced at compile time
4. Error handling has been made available to the objc handlers

Another thing to note is that xcode generated most of this code so it didn't feel heavy weight when writing it. Once you implement a protocol xcode offers to fill it in.

The actual API passthroughs should be tested as well.

Done

None of these messages ever returns anything other than YES, so they should all just be void.

I don't think so, the platform_interface states that a bool should be returned from these methods. It should be the host platform that decides the value, not the glue code between the platform_interface and the host code.

I don't think so, the platform_interface states that a bool should be returned from these methods.

I'm not suggesting that the implementation of the platform interface—which is Dart code—violate that. This structure is not the implementation of the platform interface, it's a completely internal API boundary.

It should be the host platform that decides the value, not the glue code between the platform_interface and the host code.

shared_preferences_ios is "the host platform". It's all iOS code. Which parts of that iOS code are written in Dart and which parts in ObjC are up to us, as is defining the API between those layers.

There is no reason to put useless return value on an internal API boundary.

There is no reason to put useless return value on an internal API boundary.

Here's how you are looking at it:

(dart_platform_interface)->(dart_host_implementation)->(objc_host_implementation)

Here's how I think you should be thinking about it:

(dart_platform_interface)->(dart_glue)->(host_implementation)

It makes maintaining much easier since logic for implementing dart_platform_interface isn't spread across multiple files.

There is no reason to put useless return value on an internal API boundary.

Here's how you are looking at it:

(dart_platform_interface)->(dart_host_implementation)->(objc_host_implementation)

Not really, no.

I look it at as:

Dart platform interface
Adapter code
System API

More specifically:

Dart platform interface
Adapter code (Dart)
Method channel/pigeon API
Adapter code (Native language)
System API

Here's how I think you should be thinking about it:

(dart_platform_interface)->(dart_glue)->(host_implementation)

To the extent that I think we should have an abstract goal of minimizing the amount of adapter code on one side of the language boundary, I think it should be the native side, favoring writing adapter code in Dart, for the reasons laid out in https://docs.flutter.dev/go/platform-channels-in-federated-plugins (search for "Allows moving adapter code from native code to Dart")

Well it doesn't help that what those return values mean is never defined, so I can't even tell you if the values are correct or if they need to be generated from the native code. Imagine those return values actually meant something, they would have to be forwarded from the host platform to the plugin. It seems a bit silly to make a special case about where the return values come from in the case where return values mean nothing. I think it's just setting up the wrong example.

Well it doesn't help that what those return values mean is never defined

On Android the setters can fail, and the return values is whether setting succeeded.

A PR fixing the docs to say that sounds like a good idea.

so I can't even tell you if the values are correct

Setting a value can't fail on iOS, so unconditionally returning true is the correct implementation on iOS.

or if they need to be generated from the native code.

We know that they don't, because we know what the APIs on iOS are.

Imagine those return values actually meant something, they would have to be forwarded from the host platform to the plugin.

If there were meaningful return values that we needed from the native side on iOS, I wouldn't have made that review comment in the first place.

It seems a bit silly to make a special case about where the return values come from in the case where return values mean nothing.

There is, and will only ever be, one implementation of the API you are defining with this pigeon file. When there is only one case, "special case" isn't meaningful.

I think it's just setting up the wrong example.

This isn't an example. It's a specific, concrete case.

The methods that just use setValueForKey can all be collapsed together.

I think it's better to match the Dart interface as closely as possible instead instead of trying to be smart in the glue code (as per other comment).

You do?

And specifically, my point here is not just that you are putting logic in the Dart code there, but the purpose of that logic is to maximally fragment the calls by value type. You've created an API layer that not only has more calls than the underlying host API (which is what I suggest matching), but far more than the Dart interface. Your argument against reducing the number from five setters to three is that you want to better match the side that only has one...

Yep, I'd say that's matching the Dart interface. The interface is weird in that case because it's defined in the comments and in the code not just in code because Dart lacks the ability to express it in code. There is no computation or branching in the dart file, just dispatching.

I know it's late there, we can hash out the last mile of this conversation on Monday, over vc if we have to.

We definitely need non-null generics; this is ugly.

flutter/flutter#97848

You've changed the semantics; this used to be a platform error, and now it just returns false. I think the error is a much better option here.

Done.

This is incredibly slow and inefficient relative to doing it on the native side. Moving things to Dart is a general goal, but we shouldn't do it at the expense of the quality of the plugin.

Yea, I wanted to take the code to the logical extreme of what we are saying we wanted to see how it looked. If our goal is to move logic from host to dart that's often going to incur a performance cost.

I moved it back to the native side.

Fortunately logical extremes are not the only options available to us. As with all code, we can balance performance against other design goals, favoring the general goal in the general case, and adjusting for performance in specific cases where it will obviously have a significant impact (like here, where moving a few lines of code puts a potentially large number of cross-boundary calls in a tight loop).

The filtering logic has to stay on the native side. It's there in case people want to store non-Flutter prefs (e.g., in add-to-app) and there's no guarantee that the things with other keys can be handled by our codec since we didn't write them.

Done. That one didn't occur to me, but raising the idea it would be nice if we did lazy serialization / deserialization. That could help with some of the performance issues we are seeing.

Renaming the class is a breaking change.

It's also still not actually clear to me what the correct capitalization is. The relevant Dart rule says that two-letter acronyms are capitalized in Dart. "i" isn't part of the acronym; the acronym itself, OS, is two letters. So there are two possible interpretations:

• It's a single letter ("i"), which is capitalized because it's the first letter, followed by a two-letter acronym, which is also capitalized, giving IOS.
• We pretend it's a normal three-letter word (or a three-letter acronym-like thing?), giving Ios.

Dart appears to use the former (ref), and I only just realized that that there's an explicit mention in the Flutter style guide saying it should be the latter (although that section is itself somewhat wrong since it says Dart rules would give macOs, which isn't correct). Given the existing inconsistency in the ecosystem, I haven't caught one vs. the other in reviews.

I'll make sure to apply the Flutter rule going forward now that I'm aware of it, but it's not worth a breaking change here to fix.

Sure, done.

Why is Pigeon annotating this as nullable? It's non-nullable in the Dart specification; that seems like a significant Pigeon bug. (Or is this stale?)

It's not stale. It was probably done because of error handling. If there is an error you don't want people to artificially return some value.

Yea, reading through the code, that's what it's for. If you return nil and set an error, it will throw a PlatformException on the dart side. That's what we want. If you return nil and don't set an error, you'll get an exception when it is cast to a non-null type before returning. I think that's what we want as well.

That means that it's currently impossible to distinguish in the context of the native code between a nullable and a non-nullable return value, which is definitely not great. We can't do anything compiler-enforceable I guess, which is unfortunate, but it seems like we should at least have pigeon put a comment on methods like this that says:

/// This may only return nil if 'error' is set.

so that there's clear information within the context of the generated native code what the required behavior is.

If you return nil and don't set an error, you'll get an exception when it is cast to a non-null type before returning. I think that's what we want as well.

It looks like that's only on the Dart side. Shouldn't we be validating in ObjC code that either error or the return value is non-nil, in the case of non-nullable return values? Otherwise mistakes will look like they are on the Dart side rather than in the native implementation.

Yea, those are improvements we can do when we implement nullable return types. I'll add a note to that issue: flutter/flutter#98452 (comment)

Shouldn't we be validating in ObjC code that either error or the return value is non-nil, in the case of non-nullable return values? Otherwise mistakes will look like they are on the Dart side rather than in the native implementation.

It doesn't necessarily have to happen on the objc side. The end result will look the same to a user, an exception on the Dart side. I think generating a PlatformException about a null value instead of a null value exception will be more clear though.

it seems like we should at least have pigeon put a comment on methods like this that says:

Yea, it's a good idea. I don't know how helpful it will be in practice because it won't show up where people are actually implementing the logic.

The end result will look the same to a user, an exception on the Dart side.

Right, I wasn't thinking of the end user, but the plugin developer(s). Especially if multiple platforms share method channels (which is still overwhelmingly the common case in the ecosystem). If the exception is in the Dart code, it points someone investigating in the wrong direction; probably not a huge effect, but anything that makes it harder for people to root-cause bugs isn't ideal.

Let's add a:

// Must not return nil unless "error" is set.

here, so that we have an explicit flag at the implementation point.

done

pedantic should not be re-added.

done

The flutter. prefix should be on the key here, not the type string.

While in practice it doesn't matter since both are unknown values, having it be wrong is needlessly confusing.

done

This naming doesn't make it clear why it expects to throw. How about 'setValue with unsupported type'?

done