Facebook graph API tells me I can get a profile picture of a user using
http://graph.facebook.com/100001225634061/picture?type=large
which works fine.
But If I used the same application in iOS devices this link is not working. For Hybrid applications, Graph url is not redirecting in iOS.
Any solution for this? Single solution should work on both the devices.
Thanks!
I had a similar problem recently where a Facebook profile picture wouldn't show up in my Ionic iOS app. I used a similar link you mentioned above.
Investigating the app in Safari showed an error saying:
The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.
Turns out, for security reasons you have to use https instead of http in your links. Changing the link like that solved the issue for me.
Related
following the microsoft examples as documented here:
https://learn.microsoft.com/en-us/xamarin/xamarin-forms/data-cloud/authentication/azure-cosmosdb-auth
Everything is fine up to the point where I run the xamarin forms app to log in using facebook to get a token.
The error from the emulator when I try to login is this:
For your account security, logging in to Facebook from an embedded browser is disabled. To continue, download and log in to Facebook app on your device and try again.
I have tried downloading the app on the emulator, but that makes no difference, my facebook app is in development state but even then it should at least get me to the login page and allow using a test user.
It seems that facebook stopped supporting android login using embedded browsers from 5 October 2021. See here:
https://developers.facebook.com/blog/post/2021/06/28/deprecating-support-fb-login-authentication-android-embedded-browsers/
Would it be possible to please update the sample with either b2c or with an alternate method or details of how to get facebook auth working again?
If anyone have examples that someone new to these concepts could follow that would be great.
Thanks in advance!
We're trying to implement deep links in facebook ads. Everything works fine when we open ad link in facebook app: if our app is curretly installed then facebook app launches our app and passes the deep link into it. Also if our app is not installed and we open ad link in facebook app then it redirects to AppStore and we recieve deferred deep link from facebook inside our app.
But when we try to reproduce all these scenarios using facebook browser version, none of the cases are working (neither deep link nor deferred deep link)
Is it possible at all to make deep links work in web environment?
Finally I've asked Facebook support and received the answer:
Deep link is designed to work in apps only. It doesn't work with a
browser. Please don't worry because it's working as expected!
https://developers.facebook.com/support/bugs/535030953629446/?disable_redirect=0
I have a standard facebook and twitter SLComposer that brings up a small saying and also attaches a link to the app on the message using the addURL: function. I'm testing it in iOS7 and whenever I brink up the composer I am immediately taken out of the app and to the attached link address (which in this case is the app store). It's only doing this in iOS7. 6 and under works just like before. Any Thoughts?
Try add image for share for preview of the url destination.
If SLComposeViewController doesn't have image for preview, it tries to get image from the URL of destination server.
In my project I've found redirection on server to AppStore from my server.
I'm seeing something similar, but only when adding URLs that redirect to the app store, such as bitly links. Regular links outside the App Store work just fine as do App Store links that are direct (e.g. do not redirect). Does this sound right? I think it's a bug in Apple's plumbing for catching loaded App Store URLs iOS wide...
The URL is fully loaded to generate the preview image that you see in the tweet/facebook. Reported as rdar://15228808.
The behavior of how the Social Framework works was changed in iOS 7. In iOS 6 my app would just show a dialog for posting to either Facebook or Twitter regardless of whether my device/simulator had an account setup with the respective service. In iOS 7 it will only show if I have an account setup. I think this is based on the method "isAvailableForServiceType:". Without seeing your code, I can't be sure this is your issue, but my guess is that it might be.
I have an iPhone app using facebook connection using FBConnect from github code.
It worked fine in the simulator, however when I installed it in the device with existing facebook app from facebook it didn't work. It opens the existing facebook app instead of returning to my own app.
Checkout this link.
Better you can go with the approach given in the link as it works fine. I have myself tried this code and it has worked for me.
Also the sample project (with Facebook API implemented in it) is given in the below link which will be helpful for you to while implementing the facebook API as per the method given in the below link.
http://www.raywenderlich.com/1488/how-to-use-facebooks-new-graph-api-from-your-iphone-app
Also you can test the sample project on your device before going for this approach
Hope this helps you.
EDIT:
Have you registered a URL handler to respond to return requests from the Facebook app? on iOS 4 the Facebook SDK uses fast app switching which is designed to let the app handle most of the heavy lifting and let the users just hit "Accept" instead of having to re-enter login/passwords
I'm working on integrating Facebook with my iPhone/iOS application and I want to know if I'm understanding the nature of the login procedure correctly.
With the old Facebook SDK ('Facebook iPhone SDK'), when we needed to request authentication permission from a user a UIWebView would be displayed with a login prompt. With the new SDK ('Facebook SDK for iOS'), the SDK uses Apple's fast-app-switching feature to temporarily place the app in background mode and then load the iOS Facebook app or Safari to authenticate. Is this basically the gist of it?
I've experimented with authenticating my app via the new SDK's technique and due to the nature of my app, it just can't support backgrounding. Does this mean I have to use the old SDK to launch a UIWebView-based authentication? I think this implementation is a lot cleaner anyway. Will I run into any major disadvantages from doing this?
Check out this question and my answer: Iphone facebook connect example calls safari. I don't want to use safari
You can make it use the UIWebView always. Facebook is trying to make it so the user only has to log in once per device (through either the Facebook app or in Safari) but I didn't like this flow (especially on the iPad). Though I'd rather not muck around with the Facebook code, I did find commenting out a few lines to be a quick way of getting the old behavior back.
I don't believe this is the case.
The Facebook SDK that I'm aware of, available at https://github.com/facebook/facebook-ios-sdk doesn't do anything like you describe. Is this the SDK you're using? I believe the last major update to this SDK from the "old" facebook SDK was to add support for OAuth-style authentication. With this change they broke code compatibility so apps were forced to make changes to incorporate the latest SDK.
When you call 'authorize' in this SDK you pass the app id, the desired permissions, and a callback delegate for notifications of errors or success (did login, did not login, did logout). You can also set any access token that you might have persisted from a previous session. Facebook validates this access token, and if it doesn't exist or is invalid it presents a modal login dialog. I believe the content of this dialog is a web page. The SDK authenticates the user using OAuth and makes the auth-token available for persisting between sessions.
At no time is the app exited to run the Facebook app or Safari. I'm curious - what led you to believe this was the case? (Or, perhaps there is some other SDK out there I'm unaware of?)
Take a look on this page: https://github.com/facebook/facebook-ios-sdk
And look at Single Sign-On. That describes the above scenario with fast switching.