I'm thinking of using APPMobi to push to the IPhone. APPMobi allows you to code in html and javascript and tap into your phone's functions.
This opens up the obvious desire to code an ASP.NET MVC app that calls these javascript methods.
I wondering if this behavior would violate Apple's TOS because they wouldn't have control of how we update our site.
No it does not. Ignore the person about about "downloading code at runtime" - it doesn't pertain to html/javascript/css.
The issue is if your page does a redirect to your site only. You're best bet is to design the UI in html/javascript and let that live in the app bundle, then use web services to make calls to get data.
Apple will deny your app if it's just you're mobile website embedded.
you can't download code at runtime, except for html/css/javascript.
this means you can have a webview showing pages from your site. of course if it's just a view on your site maybe someone in Apple could argue you should do a webapp instead...
i mean: if they don't allow you to dowload web pages they should ban safari, but if your "app" works perfectly from a browser you risk they refuse it.
hope this help.
Related
I am building a HTML5 based mobile web app for iPhone. I need to check whether user has specific application that I suggest. I heard that each iPhone application has unique URL scheme to detect their app indentity.
Therefore, I've read this article to get an idea.
Is it possible to register a http+domain-based URL Scheme for iPhone apps, like YouTube and Maps?
However, this is not perfect answer to make what I am trying to make.
here is what might happen
User clicks a recommendation app on mobile web browser.
Check with application iTunes URL and URL scheme.
If the user has the installed application, it returns 'installed'
==> In this case, the screen returns back to mobile browser.
If the user does not have the installed application, it returns 'uninstalled'
==> In this case, the screen moves to App Store.
I am running mobile web app with PHP language.
Thank you.
this is not possible I'm afraid. To be honest I'm glad, as there are real privacy concerns if any old web page can detect which apps I have installed.
That's definitely not a good thing!
UPDATE: If you're happy to go native, this library will do what you want.. http://www.cocoacontrols.com/platforms/ios/controls/ihasapp
If you know that a url scheme for the app exists then you can open it via a web link like this, "myapp://". With this there are some round about ways you can effectively check if a certain app exists.
See this related stackoverflow post
I used to develop a few FB apps in the past (using the old rest-ased api), and now I'm considering to make them actually usable again by porting them to the new 3.1 API.
Sounds nice, but for some reason this is way harder than I should be...
So here are few questions:
Is there any example of a canvas app using the 3.1 API? Google did not give me anything useful
Is there still a difference between iframe and FMBL canvas applications? In my app settings, I checked the fmbl-option, but when I'm back at the app overview page, it still says it's an iframe app.
The SDK mentions the getUser() function to get the user-id, but how do I request the necessary permissions for my app? When I do some googling, I find even another solution which calls a specific url and then performs a callback. This solution however doesn't seem to php sdk at all!
Where is the documentation of the php-api? The only usable thing I find is this: https://github.com/facebook/php-sdk which consists only a few lines of code. And I suspect this is for having a fb login-button on your own website, not for a canvas app.
Firstly, good luck, and best wishes - you'll need it. Maintaining Facebook apps is way harder than it should be, because Facebook doesn't believe in legacy support, changes things all the time, and deprecates things quickly and completely. As a (former) Facebook app dev myself, I can tell you there is only one constant: apps will die if you leave them alone. As an app developer, Facebook owes you no favors, and it is vicious when it comes to breaking apps.
As for specifics: as of June 2012, Facebook has deprecated and removed FBML and the REST API, and there is no longer any difference between canvas apps and iFrame apps. This isn't a soft, "you shouldn't use it" deprecation - it's a hard, "your apps are now broken" deprecation. All apps are now iFrame apps, as there is no longer any other way to build them. The docs on how to build a canvas/iFrame app are here, and there's an auth migration guide that may be helpful in conversion. Oh, and you'll need to get your app running on HTTPS too, if you haven't already.
As for the rest of it, it sucks, but the only way you're really going to be able to maintain and get your application working is using the Open Graph API. Using the PHP SDK, you just run $facebook->api('/graph/url/here') - for instance, to get user information, run $facebook->api("/$userid"). You get the URLs off of the Open Graph docs - just grab everything after the graph.facebook.com bit and pass it to api(). It's another learning curve, and (depending on the complexity/modularity of your code) is anywhere from a lot to a nightmarish mountain of changes, and there are no drop-in replacements. Sometimes you can use the old REST api, but I doubt that will last very much longer either. It's painful, but that's how it goes. You're at the mercy of Facebook, because it's their data.
Upgrading apps involves a shift in thinking: apps are now literally just webpages surrounded by the Facebook chrome. There is now no difference between an external website that uses Facebook's api to pull in information and an app that runs inside of Facebook. It's for that reason, personally, that I've shifted to just that for my own app - an external website that just happens to use Facebook for most of its posting/sharing/user info needs.
For authorization, you request permissions via OAuth, using any number of methods. There are docs on how to do that over on Facebook as well. Specifically for the PHP api, you generate a URL using getLoginURL() and then redirect to it. Facebook eventually redirects back to a URL you specify with info about whether they authorized your app and such, after which you can do a getUser(). If you want fancy/slick/user-friendly popup dialogs without a bunch of redirecting, the Javascript SDK is your friend.
I have an iPhone application with Tabbar. One of the tabs is UIWebView which opens a link to a website in which you can login and do some tasks.
So the question is,
Is it legal to have an iPhone application which allows you to login into website as part of application? I am not quitting the iphone application while visiting the website.
Thanks
DPatel
As far as you don't do any money transactions (i.e. eBay) in the website it is legal. If your intention is to use eBay or something like that inside the webview just open it externally in safari.
Yes. However, if the website allows unfiltered access to the web - ie has a google search, or external links, or a URL bar, note that your app will have to be rated 17+ due to the ability to find adult content on the web. As long as the website only has internal links, you should be fine.
However, Apple does sometimes have a cow about web interfaces not following Apple's UI Design guidelines, so make sure the buttons in your web page are big enough to be finger-touchable.
I am building a mobile app with jQueryMobile and I intend to deploy it onto iPhone thanks to PhoneGap.
My question is : how can I authenticate myself with Foursquare using the OAuth2 protocol in my jQueryMobile app ? One solution would be to use the useragent flow of OAuth2 but this would force the iPhone to launch Safari and thus not stay within the app. Are there any better solutions than this ?
For an iPhone-based or client-side application like you would have in PhoneGap,
Foursquare recommends one of these methods.
If you have no substantive server code, you can embed a web browser and use the token flow, redirecting the user to a dummy page on your domain. You can then grab the token off of the URL and close the browser. We have sample Android and iOS code for your reference.
If you have a server as part of your application, you can use the server flow above, possibly in an embedded browser. Similar to the Facebook API, you can add display=touch to your authorize or authenticate URLs to get a mobile optimized interface.
An alternative to the above is to use the server flow and an external browser, but redirect to a custom URI handler that brings the user back to our application. You can embed the secret in your application and exchange the provided code for an access token. PLEASE take steps to obfuscate your client secret if you include it in released code, and be prepared to rotate it if needed.
https://developer.foursquare.com/docs/oauth.html
This could probably be handled with the ClientBrowser plugin for PhoneGap or just adapting the sample code they have provided into PhoneGap plugins.
One of the core intentions of OAuth2 is to not allow browserless authentication flow like we did with XAuth in the past. Service providers want consumers to see what permissions they are signing off on, and want control of that process.
I'm not very experienced with Phonegap, as I'm a native developer, but if there's a way of instantiating a UIWebView and showing it to the user, you could at least keep the web interaction 'inside' of the application. Given phonegap is basically showing a UIWebView this should be possible. It is possible to examine the source of the html within a UIWebView using
- (NSString *)stringByEvaluatingJavaScriptFromString:(NSString *)script
I'm building an iPhone webapp (using JQTouch at the moment). It's a fullscreen app, you know, the ones installed on the home screen without the Safari chrome. If you tap a normal link (without AJAX that is) the link opens in Safari, taking you out of the webapp.
Is there a way to build non-AJAX webapps for iPhone?
The problem is AJAX isn't always a feasible solution. I would like to implement OpenID for this particular webapp for example but it means you have to redirect to an OpenID provider which links back to your URL but... without AJAX off course...
PS: I know you can build "real" apps with PhoneGap (and others) and I even built native apps before but, to be honest, I'm tired of paying €70/year for building free apps (it's for a hobby project, nothing professionally).
I think you can open OpenID links in iframe. OAuth, Facebook Connect, etc, all can work in that way.