[Closed] URL Scheme Suffix -- Sharing a single FB app ID across multiple apps

Social Media
#21

So… I decided to test this problem with my already released myapp and myapppro versions.  They were built with Corona daily build 1105 – and the result is totally different from what I’m seeing now with the updated version being built with Corona daily 1193.

With the already released versions, here’s what happens:

  1.  Install myapp and myapppro (directly downloaded from Apple App Store)

  2.  Launch myapppro, sign in to FB – which completes successfully, returning back to myapppro as expected.

  3.  Launch myapp, sign in to FB – which actually launches myapppro, which is not an expected behavior.

  4.  Delete myapppro, launch myapp, sign in to FB – which completes successfully, returning back to myapp as expected.

  5.  Install myapppro (downloaded from Apple App Store again)

  6.  While myapp is still installed, launch myapppro, sign in to FB – which completes successfully this time, returning back to myapppro as expected.

  7.  Launch myapp (while myapppro is still installed and active), sign in to FB – which completes successfully this time, returning back to myapp as expected.

  8.  Now, toggling back and forth between the two apps does not affect the FB sign in process and it always return back to the correct app.

Sigh.  I thought these two apps were able to share a single FB App ID when I released them – and I’d have to say they are working fine.  I only thought they were broken when testing the latest release candidates.  At this point, it seems more likely that latest FB SDK update might have caused something to break?  The latest versions of myapp and myapppro are not able to share single FB App ID like they used to.

What do I do now?

Naomi

#22

I’m going to ask you to try one last thing.  Just in case there is some weird substring matching going on.  Make your free suffix:  myappfree instead of myapp.  I wonder if it’s doing a “does the string start with myapp” type logic.  Everything I saw had unique names.

If not, please submit a bug report on it.  It’s probably something Facebook broke along the way.  The other thing you can try too is look at the facebook.publishinstall docs in the Daily Build documentation.  You will see the URL scheme’s are structured differently.  One of the examples showed a screen shot of a plist setting in XCode and it was structured like the way publishinstall is, not the way we normally say to do it.  Maybe this is Facebook’s broken changes?

#23

Thank you, Rob.  I really appreciate your help.

I changed myapp to myappfree (and updated FB dev site to show URL Scheme Suffix:  myappfree, myapppro), waited half an hour, and then tried again – and both myapp and myapppro still won’t sign in to FB (they both give me “Cannot Open Page.  Safari cannot open the page because the address is invalid.”)  FB sign in process definitely does not like the suffix there.

I looked at how build.settings work with facebook.publishinstall, and it does look a bit more like what I see on https://developers.facebook.com/docs/howtos/share-appid-across-multiple-apps-ios-sdk/ page.  So, I’ll give it a try – but does this mean I should remove this whole CFBundleURLTypes block:  

CFBundleURLTypes = { { CFBundleURLSchemes = { “fb123456789012345myapp”, }, }, }, – for myapp

CFBundleURLTypes = { { CFBundleURLSchemes = { “fb123456789012345myapppro”, }, }, }, – for myapppro

And replace it with [“URL types”] block?

[“URL types”] = { item = { [“URL Schemes”] = { [“Item 0”] = “fb123456789012345myapp” }, }, }, – for myapp

[“URL types”] = { item = { [“URL Schemes”] = { [“Item 0”] = “fb123456789012345myapppro” }, }, }, – for myapppro

Or do I keep both CFBundleURLTypes block and [“URL types”] block in build.settings?  (It feels like I probably should remove CFBundleURLTypes block, but I thought I should confirm.)  I should just give both a try, I suppose…

Naomi

 

#24

So, I tried both – that is, I tried adding [“URL types”] block only, as well as adding both CFBundleURLTypes block and [“URL types”] block – and tested myapppro, and they both failed:

  1.  When I add [“URL types”] block only, it behaves the same as having CFBundleURLTypes block only – that is, I get “Cannot Open Page.  Safari cannot open the page because the address is invalid.”

  2.  When I have both CFBundleURLTypes block and [“URL types”] block, it ends up with all of the display.newText objects becoming invisible on device (even though they look fine on simulator.)  Very strange, and definitely not a solution we could consider.  Despite not being able to see any text on screen, I still tried logging in to FB via the app, and it didn’t even bring up FB sign in screen or FB permission screen.  It simply resulted in failed FB login.

So, adding [“URL types”] block was not a solution.  At this point, I’d have to say this is a bug.

Naomi

#25

Thanks Naomi.  I guess at this point, a bug report is in order.  Please include a link to this thread in the submission.  I don’t know if its an “us” or “them”, but we will try to get to the bottom of it.

Rob

#26

Hi Rob, you know, I just put together a FBTest project file, and compiled PRO and FREE versions using Corona 1105, and they both behave as expected.  I then built PRO and FREE versions using Corona 1193, and then I’m seeing them both behaving just the same as the ones built with 1105.  In other words, it’s suddenly working correctly.  

I am now totally confused.  The build.settings I’m using for the FBTest project file is the same as the one I posted up top, meaning, I include both “fb123456789012345” and “fb123456789012345myapppro”.

I don’t get this at all.

And fortunately, I did keep the release candidates of myapp and myapppro that I generated back on August 20th, and I installed them both, and tested them again – and this time, they are both working as expected.

What is going on?  What went on?  Why are they working now, when they refused to work yesterday?  I really don’t get this.

But I suppose I can close this thread now, because, for whatever reason, the problem was only temporary.

Anyhow, thanks again, Rob, for being there for me and taking the time to work through this with me.

Naomi

#27

Facebook  can be fickle at times.  Glad it’s working for you.