I'd like to bring Safari to the front (switch to) but without using a URL, instead I'd like to see the "pages" view so the user can pick an already loaded page. Is this possible?
We open links in Safari and if the user returns to the app and selects the link again, I'd rather let them pick which Safari page to browse instead of opening a new one. I know that if the same URL is called it will open the correct page but the user may have navigated within the original site so the url no longer matches.
Thanks,
Rick
I don't think that its possible, i would use a UIWebView inside your app in order to get that experience you want, you can find the UIWebView apple docs here (http://developer.apple.com/library/ios/documentation/uikit/reference/UIWebView_Class/Reference/Reference.html) and also the equivalence of c# methods here (http://tirania.org/tmp/rosetta.html) hope this helps
Alex
Your app doesn’t get control of Safari’s UI. You might, however, be able to design your site so that it handles navigation via Javascript—AJAX and whatnot—so that the actual page URL doesn't change, and thus so that the page, re-opened from your app, brings up the existing Safari page. Of course that introduces further problems with your pages no longer being bookmarkable, but you might find that an acceptable tradeoff.
Related
I'm creating a SPA app using Durandal and I would like to include a credit card payment facility. The guys that I'm looking at requires you to give return URLs to success, cancel and a view other pages, is that possible?
To me it would be breaking the 'single page' part of SPA, but is it possible? Could I do it all in a window?
Disclaimer: I don't know Durandal, but you would solve this in an SPA using either "hashbang URIs" or actually re-serving the SPA in your webserver for the requested return URI and adjusting the content using the same technique as hangbash URIs but using history.pushstate/history.popstate instead, see here: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history
A more general article from Google is available here that covers the same principle: https://developers.google.com/webmasters/ajax-crawling/
This "works" because SPAs are SPAs only in that the browser requests a new HTML document from the server once (or in your case, twice), the SPA should still be updating the history and address-bar state of the UA as the user navigates the application, just as though it were a regular multi-page application.
A great example of this is GitHub's source navigator: Try here ( https://github.com/angular/angular.js ) and navigate the repository, observe that the contents of the file-listing change as does the address bar, but your browser doesn't reload the whole page... yet if you copy+paste the (modified) address bar address into a new browser window, you get the same page back.
I looked into doing credit card processing from a SPA and the best option I had found was Stripe. They supply a javascript file that looks like it would work, I never implemented it on my project due to time constraints so I can't confirm that it works but it looked very promising.
IFRAMEs are quite good for this sort of thing. You can use jQuery to hook an event handler to the page load event and this will tell you when the other end has responded. Load the 3rd party page into the IFRAME and serve response pages on the URLs you provide to the service provider. As mentioned by others you can use routes to identify the response pages. The IFRAME will stop the round-tripping from mucking up your application state and in fact it is possible to put script in your response pages that dot-notates its merry way up the DOM and into your app.
I've followed the instructions in here to add an embedded flattr button to my site but it's only being shown after reloading the page. This is the page: http://nipanipa.com/en/donations/new. Actually, if you visit that url directly, the button will be shown but if you visit it throught the "Donate" link in the header it will not! I get this behaviour in both Firefox and Chromium.
What am I missing? Probably this has something to do with my poor knowledge of javascript... :S
Thanks a lot!!
Your website (or framework if you are using one) is bundling all javascripts in to one neat package that is only loaded on the first page load. The flattr javascript is automatically triggered onLoad, but unless you are actually on the donate page during the initial page load, there will be no flattr button to initialize.
One way of solving this is to call FlattrLoader.setup() somewhere on the Donation page.
But since you are only interested in having one Flattr button for one url there is a much easier way to add it.
Remove all Flattr related code from your source code and then use the embed tool to generate the button specific html/javascript and paste that code where you want the button to appear.
Hope this helps :)
This is the first Facebook App i've created since the Timeline changes. Everything appears to be working the same, except for adding the app to my page's Timeline "Favorites"(?) (the boxes at the top near the About section). A large majority of the traffic to this app will come from visitors seeing the app tab on our page.
I'm attempting to add it using the following URL:
http://www.facebook.com/dialog/pagetab?app_id=MYAPPID&redirect_uri=MYAPPURL
Then I select the page, and click "Add Page Tab".
This works fine - I can then swap it's position, view the app, edit settings, etc.
I set up the tab how I want it, and then log out and visit my Facebook Page directly to view the app tab as a visitor would. The app is no longer there. Log back in, everything is fine, log back out, it's gone. It appears that if you do not already Like the page, you cannot see the app. If you do like the page, you can see it. I'd like the app to be viewable by people who do not like the page as well, as the app has a fan gate of it's own.
I've disabled Sandbox mode as well so i'm not sure what's left to do.
Any help is appreciated.
You mentioned in the comments that the app is restricted to US users:
Because your app is restricted, it won't be displayed to logged-out browsers - this is expected because unless the user is logged-in, their location and age can't be determined in order to check the restrictions you've set
If you must have the app visible to logged-out users, remove the API-level restriction and use the details passed in the signed_request to show or hide the app's content
{edit} I missed the edit to your question {/edit} - it may also be that your existing signed_request processing code is failing for logged out users
It seems that Google only offers code to embed the +1 button.
However, there are heavy privacy concerns (plus quite some load time) associated with it.
For some pointers about the privacy and legal issues associated with Facebook like and Google +1, see: Like button and privacy concern
A common workaround seems to be a two-click solutionGerman (also discussed on slashdotEnglish), where the first click enables the button (loading the javascript from Google), the second then is on the regular +1 button.
However, I do not want to implement this two-click solution either. Largely because the Google +1 button is ugly as hell, and doesn't fit to the page layout.
What I'm really looking for is a separate web page, where the user can essentially confirm that he likes the page. This page can live on google.com, and essentially this would be the second click. I'm not trying to trick people into +1'ing the page. The second click is all fine with me. I just don't want to force them to load the plusone button (and I don't like its looks).
There seems to be the option of
https://plus.google.com/share?url=<URL>
which however is a share on Google+, not a +1.
I've seen this URL, too:
https://plusone.google.com/_/+1/confirm?hl=en&url=<URL>
(see e.g. here: Adding a Google Plus (one or share) link to an email newsletter) but I cannot submit this form (i.e. doesn't seem to work).
The best working solutions seems to be the two-click approach. :-(
Update: the url, https://plusone.google.com/_/+1/confirm?hl=en&url=<URL> actually does seem to work. It was just my privacy proxy breaking it. Then it seems to be more of a "Google+ share" dialog. I'm not yet happy with this result (in particular, since this doesn't seem to be an advocated approach for Google, and they can at any point consider to ban the site, I guess)
The only officially supported method of +1'ing a URL is with the +1 button. Either always loading or loading it on a second click.
The approach that I'm now looking into is fairly trivial:
I've set up a Google Plus page for the web site, and the "plus" button sends user there. In fact just like the Facebook icon I'm using. Then the users get the full choice of interaction options, including +1, but also circling and sharing.
First of all, this obviously should not violate any g+ policies. Secondly, it is a fairly transparent behaviour for the users. The "plus" button takes them to Google plus, where they see the usual plus UI.
Secondly, it's still just two clicks to "+1". So it is not worse than any other data privacy compliant solution.
I found the solution here.
The problem is, social sites accepts your own "share" forms, but only if the link is URL encoded.
In Wordpress, a custom Google+ button that I'm using without the official API, and it's currently working, is this following code:
google+
Hope it helps, go to the link above for a list of the rest of the social sites links. :)
A user logs into my application in a tab in a browser
They get an email and click a link which opens a new tab in the same browser and logs them in under a different email say.
If they go back to the first tab they are no longer the same user and I want the page to automatically detect this and then reload or redirect them if they are unauthorized to view the page.
Anyway to do this?
Or, if you really want to know when user is switched the tab, try this library:
visibility.js
As stated by #Hck:
add javascript code to reload page periodically (for example once per 30 seconds) – Hck
JavaScript is pretty much the only way to make pages do stuff after they're loaded. Note that in pretty much any user authentication system, a given browser will only be logged in as one user at a time, so as soon as the second tab opens, that browser will be acting as the second user - they can still see the current content of the first tab, but links (for instance) will no longer work unless the second user was also authorized to use them.
There are some JQuery plugins that do this sort of thing, like PeriodicalUpdater, or you can write your own (an example).