Just to be on the safe side before starting to code: Are there any problems with embedding activeX in FB app?
10xs,
Nahum
Your FB app won't work on any browser except IE (I think there might be extensions for other browsers that might let you run ActiveX controls). If you're okay with that limitation, it should work, since it will be running as an iframe.
Related
I'm looking to link to a sign up page on an external webapp via a chrome app. The simplest way to manage this seems to be to open a new tab in the chrome browser (not a new webview in a new window of the app).
Tabs seem deprecated and a webview appears very unofficial and unsafe. Basically, is there a way to effectively do this:
Sign up
And the bigger question of course: is there a better way to approach what seems like a simple problem?
Your conceptions, "Tabs seem deprecated and a webview appears very unofficial and unsafe", seem very strange. tabs is simply not enabled for Apps, and <webview> is alive and well.
But if you must open it in the browser, window.open will do the trick. See also this question.
Edit: Also, upcoming is the chrome.browser.openTab API. Leave your feedback if you have use cases for this feature.
I have a php facebook application that requires that you like the page before getting access to photos Free Cover Photos. The problem is after liking it not all browsers take you to the application. It requires you to refresh the browser to view. Any suggestions?
IE worked ok
FF needing refresh
Chrome needing refresh
Tested on several systems.
It looks like Chrome is working for me. Maybe you have an older version of Chrome or some non-default setting turned on. Try turning off all the plugins in Chrome and see it that helps...maybe one of them is getting in the way.
So, I use the same fb-like plugin (fbml based one) code on 5 different pages on the website. The only difference is the different data in meta description and type of content. All pages were checked through the fb linter and it says everything is okay. All the buttons work alright in Chrome under Mac OS, but in Firefox, Opera (Mac & PC) and Chrome on PC (Windows) 3 of these buttons do not appear and none of them work in Safari on Mac. I can see that fb scripts are working some way, you can see the code with built-in developer tools in Opera or Chrome, and the element does occupy the space, but the button is not shown...
I've tested all the code in the pages including html, js and css line by line and it looks like it doesn't affect the fb-likes. I've also take the code from the page with the problem fb-like and make the new page with the only difference in fb-like href property - and it works. But when I change the href to the address of the page where like button didn't work - it stops working. So as I understand the problem is not on the website side, but since the fb-linter doesn't show any errors the problem is not on fb side either. But where is it then?
I've contacted the fb developers team, but I guess it may take them extremely long to answer , so I'd like to know if sombody had such a problem before. Any opinions or thoughts are appreciated!
Here's the website.
Thanks in advance everybody(:
~
I have a fairly standard ASP.Net web application which is used via mobile safari on the iPhone.
Some users who have a link to the web application placed on their desktop via profile are reporting that when navigating between pages (which I do on the server with Response.Redirect after specific events or via standard anchor tags in other cases (no target specified)) that Safari opens a new window instead of reusing the existing window.
Because of this, any login token/cookie etc (i'm using the built-in ASP.Net membership stuff), is now gone for that new browser window and the login prompt is shown.
The problem doesn't happen every time, and I can't seem to replicate it on my device (but i'm not deploying the shortcut via profile)
As you can probably imagine, it's quite frustrating for the users to have to log in every time, and you can't fix an issue you can't replicate.
My question is, has anyone heard of this issue and/or know a workaround?
The app is NOT iPhone specific, that is, it is used in a full desktop browser as well, and the logins stay like you'd expect there - and the same window is reused repeatedly.
I've considered a few possibilities, but have been drawing a blank as far as what might be causing this or how I can resolve it.
Do you have any iPhone meta tags set (to remove the url bar or the toolbar, for instance?) If you do, the phone will assume it's a native web app, and urls will open in a new safari window, like they would for any other native app.
If you are taking advantage of using the web app in full screen mode (where it is bookmarked to the launch screen next to native apps) you can prevent it from jumping out of fullscreen mode by and in to safari replacing type links with javascript.
location.href = '/yourPath';
This is a nifty trick which even works if you are linking to an outside URL, like doing an OAuth to Facebook and back.
I have a blog post on this here: http://www.aaroncoleman.net/post/2011/07/29/Keeping-iPhone-Web-App-in-Fullscreen-mode-from-Homescreen-Launcher.aspx
Can we build an Application using UIWebView that will entirely mimic the Safari Browser?
Are there any cases where UIWebview can not do what that can be done in Safari?
For one thing, you have a separate cookie storage per app. So if a user has some preferences at site X within Safari, it won't have those preferences at site X within your browser, and vice versa. Apart from that a UIWebView is very much like the real thing.
You cannot easily build an application that mimics the Safari browser using the public API exposed by UIWebView component. For one thing, please look at the UIWebView delegate methods. When you have frames inside the page you want to load, you may have a hard time telling if a user has clicked inside an iframe/frame or clicked on a link in the main document.
Dealing with authentication to site with invalid certificates is also hard with the UIWebView component, especially when the site with invalid certificate is reached by clicking a link inside an iframe.
Rendering content in UIWebView will be much slower than it is in Safari.
Safari's Javascript engine uses a "just in time" compiler. It takes the incoming Javascript code and transforms it on the fly into machine code that can run directly on the iOS device's ARM CPU. This allows Javascript code to run at a speed similar to a native app's code.
The problem is that Apple doesn't trust third-party developers with this power. If a third-party app had the power to convert Javascript into machine code and run it, that app would also have the power to download and run other pieces of machine code—and Apple would never get the chance to review that code. Once App Review approved it, (developers/hackers) can change the downloaded code into something that logs your passwords or something. And there's no way to grant this power only to UIWebView and not to other parts of an app, because UIWebView runs in the same process as the developer's code.
So basically Apple forbids this because allowing it would break the security provided by the App Store and make iOS more vulnerable to attack. They can allow it for Safari because they control what Safari does, but they can't trust others not to abuse that ability.