Thanks to visit codestin.com
Credit goes to github.com

Skip to content
This repository was archived by the owner on Feb 22, 2023. It is now read-only.

[in_app_purchase]: Add macOS Support #4313

Closed
wants to merge 41 commits into from
Closed

[in_app_purchase]: Add macOS Support #4313

wants to merge 41 commits into from

Conversation

Ahmadre
Copy link

@Ahmadre Ahmadre commented Sep 5, 2021 •
edited
Loading

At first: Many thanks goes out to the every Flutter Dev and the Flutter Team for all plugins that exists. They help me as a professional Software Engineer in Germany to release for all desired platforms for our customers. So thank you guys ❤️ and don't forget to take a break!

I encountered that macOS Support doesn't exist yet for in_app_purchase plugin. Then I followed a drafted PR here and saw a lot of things that were forgotten and furthermore that PR was already outdated on the codebase.

I did some research and catched the SwiftyStoreKit plugin at the first step. After that I saw that these are not necessary at all and the existing iOS implementation is a perfect fit here to just add symbolic links to them and prepare the codebase in objective-c for macOS platforms.

Some interfaces should be hidden for macOS and are just iOS specific (IPHONEOS), so that helped for the macOS implementation to just function like it should on macOS Desktops.

While migrating the existing iOS Code I encountered also that some implementations to interfaces where forgotten to check on the iOS 14 respectively iOS 13.4.

The most important checks were here:

- (void)presentCodeRedemptionSheet

and

- (void)showPriceConsentIfNeeded

After migrating the codebase in Dart, Objective-C and the Tests, everything worked like a charm.

Here's an example from a production app in Debug:

Screenshots

Buy

Bildschirmfoto 2021-09-05 um 16 33 48

Check Purchase

Bildschirmfoto 2021-09-05 um 16 34 04 Bildschirmfoto 2021-09-05 um 16 34 15

Completion

Bildschirmfoto 2021-09-05 um 16 34 21

Backend Apple Handler

Bildschirmfoto 2021-09-05 um 16 32 00

Related Issues

Additional important notes

Test results:

❯ flutter test
00:09 +51: All tests passed!

Build (pub run build)

❯ flutter packages pub run build_runner build --delete-conflicting-outputs
[INFO] Generating build script...
[INFO] Generating build script completed, took 326ms

[INFO] Creating build script snapshot......
[INFO] Creating build script snapshot... completed, took 9.3s

[INFO] There was output on stdout while compiling the build script snapshot, run with `--verbose` to see it (you will need to run a `clean` first to re-snapshot).

[INFO] Initializing inputs
[INFO] Building new asset graph...
[INFO] Building new asset graph completed, took 662ms

[INFO] Checking for unexpected pre-existing outputs....
[INFO] Deleting 5 declared outputs which already existed on disk.
[INFO] Checking for unexpected pre-existing outputs. completed, took 4ms

[INFO] Running build...
[INFO] Generating SDK summary...
[INFO] 2.9s elapsed, 0/16 actions completed.
[INFO] Generating SDK summary completed, took 2.8s

[INFO] 4.0s elapsed, 24/29 actions completed.
[INFO] 5.1s elapsed, 25/29 actions completed.
[INFO] 10.8s elapsed, 25/29 actions completed.
[INFO] Running build completed, took 11.1s

[INFO] Caching finalized dependency graph...
[INFO] Caching finalized dependency graph completed, took 44ms

[INFO] Succeeded after 11.2s with 10 outputs (63 actions)

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the relevant style guides and ran the auto-formatter. (Note that unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
  • I signed the CLA.
  • The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
  • I listed at least one issue that this PR fixes in the description above.
  • I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
  • I updated CHANGELOG.md to add a description of the change.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@google-cla
Copy link

google-cla bot commented Sep 5, 2021

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@google-cla google-cla bot added the cla: no label Sep 5, 2021
@Ahmadre Ahmadre mentioned this pull request Sep 5, 2021
Closed
@Ahmadre
Copy link
Author

Ahmadre commented Sep 5, 2021

@googlebot I fixed it.

@google-cla
Copy link

google-cla bot commented Sep 5, 2021

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@google-cla
Copy link

google-cla bot commented Sep 5, 2021

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@google-cla
Copy link

google-cla bot commented Sep 5, 2021

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@google-cla
Copy link

google-cla bot commented Sep 5, 2021

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@stuartmorgan-g stuartmorgan-g marked this pull request as draft September 5, 2021 17:44
@Ahmadre
Copy link
Author

Ahmadre commented Sep 5, 2021

https://github.com/flutter/flutter/wiki/Contributing-to-Plugins-and-Packages#changing-federated-plugins

You're totally right! I forgot that case 😅

I will copy the source files, remove the sym-links, test it again with my app and push everything again.

Thanks for the hint ✌🏼

@Ahmadre Ahmadre changed the title [in_app_purchase]: Add macOS Support (symbolic linking) [in_app_purchase]: Add macOS Support Sep 5, 2021
@Ahmadre
Copy link
Author

Ahmadre commented Sep 5, 2021

I also removed now a lot of unnecessary iOS interfaces. So thanks @stuartmorgan for making me aware again :)

@Ahmadre
Copy link
Author

Ahmadre commented Sep 5, 2021

@stuartmorgan

As mentioned I removed now iOS specific apis & interfaces on the dart and objective-c side.

I also removed the tests that depends on iOS.

It works now like before and I tested it locally.

I would be grateful if you can review it.

Thanks :)

@Ahmadre Ahmadre marked this pull request as ready for review September 5, 2021 20:37
@stuartmorgan-g
Copy link
Contributor

I will copy the source files, remove the sym-links

This is not at all what I was suggesting. Apologies for not being clearer; I assumed from your PR description that you had read the discussion in the other PR, in particular #2708 (comment)

We do not want to maintain two copies of this code. Having macOS and iOS share a package and implementation—under a new name—is the approach we would accept within this repository.

@stuartmorgan-g stuartmorgan-g marked this pull request as draft September 6, 2021 00:14
@Ahmadre
Copy link
Author

Ahmadre commented Sep 6, 2021 •
edited
Loading

I will copy the source files, remove the sym-links

This is not at all what I was suggesting. Apologies for not being clearer; I assumed from your PR description that you had read the discussion in the other PR, in particular #2708 (comment)

We do not want to maintain two copies of this code. Having macOS and iOS share a package and implementation—under a new name—is the approach we would accept within this repository.

You're totally right. Sorry, I didn't read the history of the other PR fully 😄.

But that sounds great :)!

That would be more clean and I also wouldn't maintain duplicate codebases.

I'll do that tomorrow and thank you so much for clearing this up :).

One question to the comment you've linked:

How am I going to "export" like it's explained here:

Making the _ios plugin a temporary passthrough for compatibly, using export

@stuartmorgan-g
Copy link
Contributor

How am I going to "export" like it's explained here:

Can you elaborate on what the question is? I'm not sure what specifically the issue you're encountering is.

@Ahmadre
Copy link
Author

Ahmadre commented Sep 6, 2021 •
edited
Loading

How am I going to "export" like it's explained here:

Can you elaborate on what the question is? I'm not sure what specifically the issue you're encountering is.

Bildschirmfoto 2021-09-06 um 04 24 24

I mean like here in the main in_app_purchase plugin: It it correct to also provide in_app_purchase_ios as a dependency? Is this what you mean wiht export?

@stuartmorgan-g
Copy link
Contributor

I mean the Dart keyword export. There is user code that directly imports and uses in_app_purchase_ios as part of using in_app_purchase, and it must continue to work exactly as-is or the rename becomes a breaking change.

@stuartmorgan-g
Copy link
Contributor

Since this is marked as a draft and hasn't been touched in a few months I'm going to close it to clean out our review queue. Please don't hesitate to submit a new PR if you decide to revisit this. Thanks!

If you (or someone else) decides to revisit this, based on recent experience with moving plugin implementations the best way to proceed would be:

  1. An initial PR to move (not copy) all the files from the _ios version to the _storekit version (with necessary minor changes, such as the podspec name), changing _ios to export. That would need to make all referencing packages temporarily use path-based references, and make those packages as temporarily unpublishable. See [path_provider] Federate mobile implementations #4465 for an example of this
  2. A follow-up PR to restore the referencing packages to normal references and publishable state
  3. A PR to add macOS support to the _storekit package.

That avoids the problem of having a giant set of file copies, which makes review extremely difficult and destroys git blame.

@stuartmorgan-g stuartmorgan-g mentioned this pull request Nov 16, 2021
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@cyanglaz cyanglaz Awaiting requested review from cyanglaz

@LHLL LHLL Awaiting requested review from LHLL

Assignees
No one assigned
Labels
cla: yes p: in_app_purchase platform-android platform-ios platform-macos
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@Ahmadre @rebarah @stuartmorgan-g