Skip to content

Conversation

@pronebird
Copy link
Contributor

@pronebird pronebird commented Nov 15, 2020

Should solve #245 and remove the requirement to have PURELAYOUT_APP_EXTENSIONS defined to use PureLayout in app extensions.

The reason why I resort to runtime check boils down to the fact that @available(iOSApplicationExtension 8.0, *)) didn't work as expected:

  1. It didn't fix the compilation error when building against the framework. I.e the same sharedApplication is unavailable.
  2. Unit tests would gladly enter the branch with if (@available(iOSApplicationExtension 8.0, *)) { even though it looks like they run as normal apps.

Based on my tests, application extensions have appex extension. Masking the call to sharedApplication helps to avoid the compilation error.

Further thoughts:
I think that leveraging UIView to determine the effective layout direction is probably a better way to solve that, we have a common superview which can be used for that.

@pronebird pronebird force-pushed the remove-app-extensions-macro branch from 2ebf640 to 3ae7347 Compare November 15, 2020 20:19
@pronebird pronebird changed the title Use @available instead of PURELAYOUT_APP_EXTENSIONS macro Use runtime check for app extensions instead of PURELAYOUT_APP_EXTENSIONS macro Nov 15, 2020
@pronebird pronebird force-pushed the remove-app-extensions-macro branch 2 times, most recently from 94b5d1b to 32510f9 Compare November 15, 2020 20:35
@pallzoltan
Copy link
Contributor

While you're at it, you should enable "Allow app extension only API" so projects using this fwk in extensions won't display an extra warning.
Also I think an extra check for the existance of sharedApplication would be nice before calling it.

@toohotz
Copy link
Member

toohotz commented Jan 12, 2021

@pallzoltan allowing the app extension only API makes sense to my understanding but I don't quite believe the check to sharedApplication existence is needed as within its own definition its summarized stating:
"Returns the application instance, creating it if it doesn’t exist yet."

With this I would say it is safe in its usage unless you feel there is a need that the call to -[performSelector] should check beforehand that it exists.

@pallzoltan
Copy link
Contributor

pallzoltan commented Jan 12, 2021

I think you're reading the AppKit documentation. This block of code you've changed is wrapped in #if TARGET_OS_IPHONE.
To be honest, only today I've found out that share extensions also have access to an UIApplication object (if they manage to call sharedApplication) but I'm suspecting that's the application that started the share extension. So yeah, ignore the extra condition, the App Extension API flag would be very nice tho .)
Cheers!

@pronebird
Copy link
Contributor Author

pronebird commented Jan 14, 2021

@pallzoltan

While you're at it, you should enable "Allow app extension only API" so projects using this fwk in extensions won't display an extra warning.

Can you elaborate please? I am not sure I understand what part of code you refer to, or maybe to external configuration, please point me where. I am using CocoaPods so maybe we can add that flag to pod spec?

Also I think an extra check for the existance of sharedApplication would be nice before calling it.

App extensions can't access sharedApplication while GUI apps can. I don't see why we should check for its existence.

@pallzoltan
Copy link
Contributor

Can you elaborate please? I am not sure I understand what part of code you refer to, or maybe to external configuration, please point me where. I am using CocoaPods so maybe we can add that flag to pod spec?

It's just a flag (in Xcode UI it's under General). Checking this box makes the framework safe to use in an extension. Basically you're saying that you're not calling unsafe API from the extension (such as sharedApplication).
Without this flag, using the framework in a share extension causes a build-time warning, which is not very nice.

Screenshot 2021-01-14 at 12 44 20

Screenshot 2021-01-14 at 12 46 41

App extensions can't access sharedApplication while GUI apps can. I don't see why we should check for its existence.

It's more of a safety net after the "appex" extension check. If that ever changes (maybe a new target type which isn't an extension per se), it would catch any calls to a method that might not exist.

@pallzoltan
Copy link
Contributor

@pronebird Any luck updating this PR?

@pronebird
Copy link
Contributor Author

@pallzoltan I don't know how to implement what you suggest. Feel free to open a follow up PR.

@pallzoltan
Copy link
Contributor

If you merge my PR, we're ready to rumble .)

@pronebird
Copy link
Contributor Author

@pallzoltan nice! I have merged your commit into the PR's branch.

@pallzoltan
Copy link
Contributor

@mickeyreiss Would you be so kind and re-trigger Travis and have a look at this PR?

@toohotz
Copy link
Member

toohotz commented Mar 2, 2021

@pallzoltan the Travis build is failing due to Slather's argument option changes. I'm going to update it separately via the .yml file and get this merged in once the build is passing again.

Edit: Once PR #254 is merged in, I'll get this one taken care of.

@toohotz
Copy link
Member

toohotz commented Mar 18, 2021

@pallzoltan you can choose to rebase on top of the master branch now and it should resolve the CI build test.

@pallzoltan
Copy link
Contributor

cc @pronebird, thanks @toohotz

@pronebird pronebird force-pushed the remove-app-extensions-macro branch from 57687f9 to 53dd24c Compare March 21, 2021 16:19
@pronebird
Copy link
Contributor Author

@toohotz @pallzoltan I have rebased the PR & it should be ready to go.

@pallzoltan
Copy link
Contributor

Great, I'd merge this but don't have write access, maybe @toohotz can.

@lwdupont lwdupont merged commit ff8c235 into PureLayout:master Mar 21, 2021
@lwdupont
Copy link
Contributor

Merged it for you.

@pallzoltan
Copy link
Contributor

Merged it for you.

@lwdupont Could you do a v3.1.8 release? I'd send a PR but can't create the tag.

@toohotz
Copy link
Member

toohotz commented Mar 22, 2021

@pallzoltan no worries, just released it.

@pronebird pronebird deleted the remove-app-extensions-macro branch March 22, 2021 13:46
@pronebird
Copy link
Contributor Author

@toohotz seems like you forgot to release on CocoaPods.

@lwdupont
Copy link
Contributor

lwdupont commented Apr 8, 2021

@pronebird Just released it a few minutes ago, sorry about that. @toohotz if you want me to add you to the cocoapods.org group who can release, let me know? (or are you in the list?)

@toohotz
Copy link
Member

toohotz commented Apr 8, 2021

@lwdupont feel free to add me on, don't believe I currently have access. 👍🏾

@lwdupont
Copy link
Contributor

lwdupont commented Apr 8, 2021

@toohotz I added you with the email github lists on your last checking (g----x@gmail.com) . That the correct one? You should have access now according to cocoapods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants