I have webview working fine for version less then ios9, but seems not working for ios9, and its shows me a blank page, but the url is passed.
You may want to check the order of updating url and rendering page. In ios9, url will not be changed immediately, even if you directly assign value to it.
So you can try to set a timeout to wait until url updated.
updateUrl();
window.setTimeout(function(){
renderPage();
},30);
sometimes set timeout to 0 would do the trick, because it forces the code runs in the next event loop.
Related
When sending a GET request in Safari, Safari is failing to send a valid request to the server. In fact, it isn't even reaching the server (I've checked this on the back end). Its also failing to provide all but two of the request headers and the response is null (which results in safari logging a kcferrordomaincfnetwork error 303 in the console). I've attached some screenshots below along with some additional findings. Can anyone provide any insight?
Screenshot of the request when it fails
Screenshot of the request when it passes
Issue is only reproducible in Safari on iOS devices.
Issue was happening on the MacBook previously. After clearing the website data once, we never saw the issue again
The call is intermittently failing
When setting a breakpoint before the product details call and manually calling it in the console, it fails the first time and then passes the second time.
Sometimes it isn’t the product details call that is failing (although it usually is)
Sometimes it is the create app or get product image call that fails.
Issue seems to go away after clearing website data, but comes back after one successful session.
When the call fails, we are getting the following error in the console: kcferrordomaincfnetwork error 303
Session storage is empty and issue persists
No exceptions are occurring (I enabled "break on all exceptions" in Safari)
Try running ng serve with the --no-live-reload option. We were seeing similar behavior, and WDS may have been interrupting the HTTP calls. So far, this has solved our problem.
EDIT: DEAR PEOPLE FROM THE FUTURE, trey-jones has fixed this issue by implementing setLoginBehavior, FBSDKLoginNative seems to have issues on FB's end not with the module.
Environment:
MacOS X 10.10.5
Ti SDK 5.1.1.GA - 5.1.2.GA
iOS 9.2
Ti.Facebook 5.0.0 - 5.0.1
My project settings (tiapp.xml) are fine (it works on every other case on both iOS and Android).
Code I'm using to invoke the login:
var fb = require('facebook');
fb.initialize();
fb.authorize();
If the Facebook app is installed to the device the fb.authorize() doesn't open up. I did not see any iOS system level messages when this happened either.
Has anyone else had luck using fb.authorize with the new sdk on iOS devices WITH the app installed. With no fb app on the system it correctly opens the browser based view.
EDIT: I have managed a workaround for this (it is not pretty) based on the fact that login works with AppC's KitchenSink.
The workaround is to add a Ti.FB loginButton to the code, doesn't matter if its not visible, initializing this will fix whatever is causing custom login's .authorize() to not work.
//Workaround button:
if(OS_IOS){
var fbHaxBtn = fb.createLoginButton({
readPermissions: ['email'],
visible: false
});
}
//It needs to be added to the window/doesn't need to be visible though
$.login_window.add(fbHaxBtn);
//Then in our custom button's code, we can fire as normal:
function doLoginClick{
fb.initialize(); //I was having unexpected issues dropping this line on Android, although the docs say its deprecated.
fb.authorize();
}
Will keep this ticket updated if/when this thing gets a formal fix.
This is my second answer on this question. I believe that my original answer offers some value to the conversation and that is why I am leaving it, but it still did not consistently solve the problem of the facebook authorization not working.
The consistent solution turned out to be modifying the official Ti.Facebook module. I will submit a pull request for this change (1 line), but for now, you can get the working module here:
Source
Pre-built
This consistently allows users to authorize by explicitly setting the login behavior to use the browser, rather than the native facebook app through fast app-switching. This is actually the intent of Facebook's developers.
I was unable to determine what is causing it to fizzle when trying to use the native app to login - it should try the next option, which is the browser - but this works, and doesn't require a TiFacebookButton either.
I hope it helps someone else!
EDIT: This answer does not solve the original question. I have left it here in case it helps with related difficulties using the Ti.Facebook module. See my other answer, to actually solve the problem. END EDIT
I commented above, but after doing so encountered some more strange behavior, with the result being that I could not reliably use the workaround given (fbHaxButton). I want to explain what was happening in my case, and show my own workaround (which is also not pretty). It's possible that the root cause is the same for both of us.
I have not bothered with Android yet, so this answer is specific to iOS.
When I started this process, I came to the conclusion that authorize was correctly opening the facebook website in safari to allow authorization, but was not firing the login event upon returning. To handle this I had already implemented the following:
facebook = require('facebook');
Ti.App.addEventListener('resumed', function (e) {
var launchOptions = Ti.App.getArguments();
if(!launchOptions.url) {
return console.warn('Ignoring resume event with no url argument.');
}
// this lib = https://github.com/garycourt/uri-js
var URI = require('vendor/uri'),
uriComponents = URI.parse(launchOptions.url),
expectedScheme = 'fb',
expectedHost = 'authorize';
// I would like to be more specific about the uri, but we are limited
// in Titanium, and this will allow us to pretty certain
// that FB is sending us back to our app
if(uriComponents.scheme.search(expectedScheme) < 0 || uriComponents.host !== expectedHost) {
return console.warn('Resume event received, but scheme is incorrect. Ignoring.');
}
// synthesize login event
facebook.fireEvent('myapp:login', {
success: 1,
token: facebook.getAccessToken(),
uid: result.id
});
});
facebook.addEventListener('myapp:login', function onFacebookAuth(e) {
facebook.removeEventListener('myapp:login', onFacebookAuth);
if(!e.success) {
// do fail action
}
// do success action
});
facebook.initialize();
facebook.authorize();
So, originally I was firing and listening for an event called 'login', which the facebook module supposedly (according to the docs) will fire after authorization is complete.
In my case, this event was being fired while my app was in the background, after authorize was called, but before the user actually clicked 'OK' in facebook. My listener would respond to this event (logging, etc), but seemed to occur in a separate thread, or somehow otherwise become disconnected from my app, as it never passed its result along to the UI. I am using Q.js (kriw-kowal) and I belive this is where the disconnect is occuring.
Ceasing to listen to 'login', and simply handling my own synthesized event has fixed my issue.
I felt that this was very difficult to explain. If you have feedback about that, and how I can be more clear about what I believe is happening, or if you believe that I have reached wrong or incomplete conclusion, let me know - I'll try to update this answer to be better.
I have a strange problem. After I logged in with the standard SPLoginViewController, I save the username and the credential. After I startup again, I try to call:
[[SPSession sharedSession] attemptLoginWithUserName:
existingCredential:
On the iOS Simulator (iOS 6.0), it works just fine. On my iPhone (iOS 6.0.1), it does not. SPSession is logging in exactly five minutes after I called the attemptLogin method. SPSession is also logging in when I put my app in the background.
Does anyone know more about this and maybe a solution?
Thanks
It appears there's a known bug in libspotify where sp_session_process_events() will sometimes return excessively high values in next_timeout. I've seen values such as 300100 and 300195 come out of the routine.
One workaround is to set your wait to the max of next_timeout and 50. (Or 100 or whatever your heart desires.) See https://github.com/spotify/cocoalibspotify/issues/140
I wish Spotify would start a known-issues list for libspotify. I wasted over a day trying to dig this one out. Hopefully this post will save someone else the same fate.
I have an app which uses forge.geolocation.getCurrentPosition. It seems that at times, the location does not refresh. I can open the iOS app in one position, and then an hour later 5 miles away, open the app again (either resume, or completely close the app from the tray, and re-open) and still the old location is returned.
I am using this form
forge.geolocation.getCurrentPosition({enableHighAccuracy: true}, function (location) {})
Note that when opening/resuming the App, the GPS icon at the top DOES show up however the location returned to the javascript code is incorrect.
The above bug was reproduced on iOS 6
After opening the Maps app, and going back to my app, the correct location is finally returned.
Any idea how to fix this?
getCurrentPosition returns the best data it has at that particular time - I'd recommend calling the method a number of times until the indicated accuracy is reduced to an acceptable level.
What we might do in the future is support watchPosition so that something like https://stackoverflow.com/a/8554835 would be possible through the forge API
In my app i am calling image from url,its working in simulator but in device it shows tunnel failure probelm. I then appended "deviceside=true" if i test it in simulator and "interface=wifi" if i test it in device both shows "Unexpected Response code 301" error. Why it is so ? Guide me.
301 is a "Moved Permanently" code. The actual body you receive will probably say where its actual location is. The browser gets this and can make sense of it, knowing to just forward itself to the new URL, but a normal connection is just grabbing the contents of whatever is at that location.
You can add some logic in there to follow the redirect, or just figure out what the actual URL is.