Permissionsdispatcher: Rename generated method *withCheck to *withPermissionCheck

[UlrichRaab]

Hi i am using this lib for permission management and so far it works great. One thing that could be improved is the naming of the generated methods. If i want to show the camera i am calling the generated method showCameraWithCheck. In my opinion it would be clearer if the name of the method is showCameraWithPermissionCheck.

[hotchemi]

@UlrichRaab Thx!
I think it's more declarative but on the other hand not sure it's worth to change cuz it'd break current API compatibility. Let us consider a bit 🙇

[mannodermaus]

Call sites to PD's generated code are already pretty verbose & long, so I'm unsure if we should extend the length even more (I mean, just look at MainActivityPermissionsDispatcher.showCameraWithPermissionCheck() 😲). We could still rethink the names for our upcoming major version increment, though! I'd prefer a longer method name like you suggested, if we could cut down on the class name at the same time.

[shiraji]

Are we able to call the method without class name in v3.0.0 when we use Java?

[hotchemi]

Are we able to call the method without class name in v3.0.0 when we use Java?

Generally speaking if user do static import we can!

[hotchemi]

Tough problem...in Java each methods belong to XXXPermissionsDispatcher class so it's predictable that check stands for permission check I guess.
But as for Kotlin we just generate extension method so user may get confused what check actually means.

@UlrichRaab are you using Java ver? what do you think about my thought above?

[mannodermaus]

Yeah, Kotlin is not a problem here (in regards to the class name), it's the Java side that causes the verbose call site. In general, I do agree that we might change the signature format for 3.x.

[UlrichRaab]

@hotchemi I recently switched to Kotlin and PermissionsDispatcher v3. The Java naming is pretty clear but in Kotlin you can get confused what check means if you are not familiar with PermissionDispatcher.

[hotchemi]

@UlrichRaab ah then that makes sense...! didn't know many users are using Kotlin ver than we expected 😅
So I guess it's acceptable to change the name because we haven't released 3.x officially!

[UlrichRaab]

@hotchemi Sorry that was my mistake. I should have wrote this in my first post

[hotchemi]

@aurae Are you working this issue(just in case)?

[mannodermaus]

I haven't touched the generated method signatures yet while working on #350. Is the decision to migrate to xxxWithPermissionCheck() final?

[hotchemi]

OK! yeah we're going to change as xxxWithPermissionCheck() only in Kotlin! I'll take the issue~

[mannodermaus]

Only in Kotlin? Instead, we could encourage users to use static imports in Java, and change it for both languages. That would make the experience more consistent, even if users would make use of the interop between both languages, and call the Kotlin code from Java.

[hotchemi]

I basically agree with you, my only concern is it breaks API compatibility...but as you pointed out using different method name is absolutely weird...🤔 Do you guys think it's acceptable to change the method name?

[mannodermaus]

I feel like a major version increment is the best time to push through with an incompatible change like this, so I'd probably go for it! @shiraji what do you think?

[shiraji]

I agree with you guys. I think the user will confuse because of the differences in Java/Kotlin. I think v3.0.0 is the only time that we can make this big changes. I expect to change both Java/Kotlin method call *WithPermissionCheck. I'm not sure we should encourage users to use static import in Java. But we can write that in README for sure.