I am trying to call a Objective-C method from Javascript. I am not using any libraries such as phonegap and I have also succeeded in calling the Objective-C method but for that I am creating a iframe each time before the call then only the shouldStartLoadWithRequest delegate is invoked I just followed the below links:
UIWebView Secrets
UIWebView JavaScript to Objective-C communication
But how to make a Objective-C method call without invoking the webview delegate shouldStartLoadWithRequest?
First of all, this is a pretty big problem. I'm developing a rather large hybrid solution right now, and it's important to understand how the native part of the hybrid app works on all your target platforms before you can make your js common to all platforms.
The shouldStartLoadWithRequest method depends on using custom URLs to communicate from the webpage to the native code. Clicking on a link, say hybrid://showMenu will try to open the link in the webview, and the delegate will intercept this call in shouldStartLoadWithRequest. At that point, you will recognize the call and perform whatever actions you want, eg show a menu and tell the webview to stop the loading.
There is an equivalent function on both BlackBerry (at least before v10) and Android, and most likely Windows Phone. PhoneGap is using this technique across the platforms. All of these functions will be able to catch the hybrid://showMenu call. They all behave in a different way and you'll have to do research on your own to get the code, but I can confirm that it is absolutely possible to use the same Javascript in different native shells.
You are correct to use iframes to speed up the Javascript, but there are other tricks you'll need to do to get the best performance. They differ for each browser, so if you want the best performance your Javascript will have to differ at least a little bit across platforms. Here's a good article on how to get good performance on iOS:
iOS Hybrid App primer from CocoaControls
Now, if you still want to avoid using the URLs and webview delegate to communicate between JS and native code, you could go with the much more complicated route of using WebSockets.
For this, you would have to include a WebSocket server library in each of your native wrappers that would listen to local connections. Then your Javascript would include a WebSocket client library that it would use to pass messages to the native code. Two way communication is possible. Your JS will be more or less the same across platforms.
I haven't implemented this method myself because it's overkill for what I need, but LinkdIn's hybrid app is using it. More info here:
LinkdIn's Hybrid App diary
If you go with (2) good luck and please share your results.
Related
I was wondering if it's good idea to intercept all internal links and load the target page with ajax.
The new history api from Html5 makes it possible to also change the url in the address bar.
are there any disadvantages between this way and the old traditional way that let's the browser load a new page (besides the increased complexity of the code)?
Many frameworks use the HTML5 History API to have client side routing. I don't think you mean that you should load the target page with ajax, but rather change the DOM without requesting the page from the server. There's a whole debate going on (and has been for the past several years) about which architecture is better and honestly it's all down to what you're trying to achieve.
Angular and Ember are client side frameworks that help build rich javascript applications (rather than the traditional website). Since JavaScript has gotten faster and more powerful in all the browsers, it has been possible to build more and more complex applications in the browser (opposed to desktop applications written in C++ or .NET/Java). The advantages of using this way of routing is that you get nice clean URLs, and you don't waste time going to the server for each request. However, you lose authentication (so if you want to protect content you'll need to go to the server anyway), and not all browsers are up and running with the History API yet (look at IE7,8,9). Consider your target audience and ask yourself if they will use these browsers or not. The frameworks I mentioned use fallback methods and implement the hashbang system instead. This has arguable problems with SEO however.
On the other side you have your server side frameworks like Rails (for Ruby) and Express (for NodeJS) that will serve the pages to the client using clean URLs. If we go further back you get into the realms of ASP.NET, PHP and plain old HTML that use the 'unclean' URL way of routing. The advantages of using the server to give you your content should be obvious - if you have protected content and the user should be authenticated then you can easily check this.
One final thing to note is the question of JavaScript. Ask yourself if your users are going to have JavaScript enabled and what will happen to your application if they have it disabled. Does this matter? How complicated is your application going to be? Do you need to use a big framework for your app, or will simply using a modern technology that gives you clean URLs be enough? Loading every bit of JavaScript takes time, and that time can be eliminated if the server is only giving the client the bare minimum of what it needs.
I have my own web app running in a browser. I want to trigger DOM events from a program running outside the browser. What is the best way to setup this interaction? Is my best bet to send keystrokes to the browser and handling these in my web app?
I prefer a generic solution, but if certain browsers (e.g. Chrome) have a specific facilities for this, I'm also interested in finding out.
You will run into tons of hassle, cross-browser problems, and security issues trying to send keystrokes from an app into the browser. I would not suggest trying it.
Your best bet would be to use something like AJAX polling or, better yet(if possible), sockets and setup your two apps to communicate with eachother via some type of service layer/API.
Check out socket.io for a nice way to do it on the web app side, the setup for your other app will depend on the language it is written in.
To simulate events from javascript use e.g. the Event.simulate
library.
To trigger the simulation from outside the browser
generically have your javascript use AJAX or COMET to poll/be notified by your external application.
I have a basic query while developing hybrid iPhone application
1) How can we access iPhone native functionalities like GPS from web UI javascript WITHOUT help of third party frameworks like quickconnect iPhone or PhoneGap
2) What is the flow , architecture for the same? i.e. how javascript communicates with the native code.
3) All comments, URL, information for the same are most welcome!
4) Can I upload my app on appstore using quickconnect?
5) I think using phonegap, we cannot upload on appstore, we have to upload on phonegap only. plz comment
Thanks
1) How can we access iPhone native functionalities like GPS from web UI javascript WITHOUT help of third party frameworks like quickconnect iPhone or PhoneGap
Check out the HTML GeoLocation API. Apple also exposes other cool stuff like accelerometer data via JavaScript APIs. So you don't always even need native code.
2) What is the flow, architecture for the same? i.e. how javascript communicates with the native code.
Actually, for some information, like location data, you do not need native code (see above). However, in general, if you want to communicate with native code from a WebView in an iPhone application, you would usually register a URL handler in the WebView's delegate, then do some fancy tricks with window.location to trigger the handler when needed. To send data back to the WebView, you just need to use the self-explanatory [webView stringByEvaluatingJavaScriptFromString:(String)] method.
For communication like this, I usually end up writing my own little library that allows me to call certain native handler methods from JavaScript and also register to receive messages from the native code. You'll probably end up doing the same. It's simple, intuitive, and fun. I recommend the experience.
3) All comments, URL, information for the same are most welcome!
See the links above.
4) Can I upload my app on appstore using quickconnect?
I've never used quickconnect so I can't answer that one.
5) I think using phonegap, we cannot upload on appstore, we have to upload on phonegap only. plz comment
I've never heard of people having trouble with posting a PhoneGap based application to the AppStore. Though I must admit I've never attempted it myself. I imagine that I would have heard if Apple had stopped accepting PhoneGap based applications. But Apple is pretty moody. So who knows?
(I'd check on my sources on that one if I were you, though)
Well, can they? Like jQuery using a fadeIn function for something on a C++ app, can it work?
I think you are confused about what runs where.
jQuery usually requires a browser with a Document Object Model to run.
While this is something a C++ application could probably, theoretically, provide somehow, it's not really practical.
You want to investigate UI and effects libraries native to C++ rather than JavaScript libraries.
What do you want do achieve and most importantly, on what platform?
It would require your C++ app to contain both a JavaScript interpreter and a HTML DOM (because that's what jQuery operates on to do things like fadein effects).
Such C++ apps exist - they're called web-browsers. I suppose you could embed an open source web engine like Webkit in your app, but at that point you'd basically be developing a webapp and might as well drop the C++ part altogether.
If your C++ application use WebBrowser control for example to display a web page which use jQuery.fadeIn then you can "combine" both technologies.
Nevertheless I would more see that jQuery.fadeIn will work parallel to your main application and they will not work really together.
I've seen a lot of stuff online that shows proof of concept tutorials of how Silverlight can be used to enhance web pages by handing tasks off to it to make use of threading, manipulate the DOM, achieve Comet-like functionality etc.
It all seems very interesting, however, has any one got any real world use cases to share as I can't seem to find many.
Sure. I have used the HTML DOM interaction for several reasons.
First, when migration an existing ASP.NET application to Silverlight. In the architecture we worked with, the application was very heavily AJAX-based with plenty of callbacks. Instead of reinventing the wheel for Silverlight, we were able to use the DOM interaction to provide a bridge so the Silverlight control could callback in a similar fashion. This meant using the ASP.NET security and viewstate information to fetch information from the server and pull into the Silverlight application. We were already returning data in a JSON format so it was straightforward to parse back into the Silverlight application.
Another example is interaction with third-party controls and services. For example, Google Analytics provides rich page tracking features. This project provides a prime example:
http://silverlightanalytics.codeplex.com/
Where the application can integrate and even though you are running in Silverlight, you are essentially tracking clicks, actions, and page views.
Another place I've used this is when Silverlight isn't used as an application, but instead more of a part or a control on the page. While Silverlight controls can communicate with each other using the local communication, this doesn't work with other non-Silverlight controls. By using the HTML-DOM bridge you can easily build JavaScript-based communicatin between the components. Maybe the Silverlight control, for example, is an interactive world map that allows you to browse to a region. When you select the region, it raises a JavaScript event that the other controls listen to and update based on that reason.
You can also use Silverlight as a control like a Captcha control where your form uses the DOM bridge to validate user input into the Silverlight application.
I've seen tag cloud applications where the Silverlight control uses the DOM interaction to walk the current page and then generate an animated cloud of tags based on this.
Hopefully those provide some real world examples.
One thing I've used the DOM-Bridge for is to raise events. The html pages that host my application subscribe to these events and react consequently.
For example, my application receives and displays sales data coming from a WCF webservice. When the data changes, an event is raised so that the rest of the page can display other things.
If you can't use ASP.Net, asking and receiving data from a webservice is much easier and less error-prone in Silverlight than in Javascript (and is also faster because you can use the optimized "binary-xml" encoder).
I think the DOM bridge is most useful when you distribute a silverlight app to be embedded in arbitrary websites where you can't make assumptions on the backend environment but need to provide ability to interact with the SL app.