I found this question very similar to what I need but I need chrome. Because of many reasons android webView (as I discussed here ) is not compatible with my application's requirements.
So are there any ways to Use Chrome as render engine for Android webview
This is coming as the default in Android 4.4 KitKat. See https://developers.google.com/chrome/mobile/docs/webview/overview
Here is a proof of concept for a view that uses the Chromium code and has a WebView-like API.
https://github.com/pwnall/chromeview
Make sure to read the Issues section in the Readme. This is merely a starting point, it's not ready for production use.
In addition to #Hyangelo's answer, if anyone needs to support Chrome for Android versions 4.0-4.3, you can use crosswalk.
Related
I have a few questions about webRTC on android. I can say I'm new about android and webRTC but I can also say I made tooo much research about webRTC on android. But still have a few questions. (some of them because of I'm new, and some of them because of I'm okey but not fully)
I'm trying to make an android app which is going to communicate between web browser (first choice is chrome) and android device directly (p2p we can say). So I made too much research and I found webRTC is good for me. Do you advise me something other or is it okey you think? (also I am going to code a plugin for chrome).
Nearly every document says 'android is not directly support webRTC'. So I need something to provide me webRTC on android. What it is? Is it native android that I have to code? Is it native (NDK) library that I have to include my project? Or is it a java lib? Or should I go for cordova/crosswalk or sth like that? I researched all but didn't find something can help me. Yeah there are documents about it but not enough..
Some of documents says, I need chromium. But why and how? They show me lots of linux terminal commands and even there is no a line java or C or C++ code. Even some terminal commands and links that they give is not working.
I read/found/tried these things as a result of my research:
Apache cordova
Crosswalk
http://www.webrtc.org/
https://github.com/webrtc
http://webrtc.github.io/samples/
http://simonguest.com/2013/08/06/bui...t-for-android/
http://orcaman.blogspot.com.tr/2014/...tc-source.html
https://github.com/pchab/ProjectRTC
https://github.com/pchab/AndroidRTC
and something more..
in a nutshell I need help. Please give me your hand. Thank you. (because I'm really very helpless and tried to do my best)
Thank you.
As others have suggested, I recommend checking out g.co/webrtc. As I understand it, your goal is to make Android connect to a web browser using WebRTC. There are two (three) ways you can achieve that.
You can just use Chrome, Opera or Firefox for Android. All these browsers support WebRTC, and it allows you to use the same code for your web app, as for your Android app. With the new Add to homescreen support, as well as support for push notifications from web apps on Android, this could be a very good solution for you.
You can use the Android native WebRTC library, available from WebRTC.org. As mentioned in my article, I recommend using the pristine.io compiled library, available from MavenCentral.
If you can limit your application to Lollipop, you can use WebView, which support WebRTC now iirc. I don't know much about it though.
And the best resource for getting help is discuss-webrtc. It's a lot more active than StackOverflow.
(re-post from the PG google group)
I know there's been a lot of conversation on this in the past, but I've been researching it for the past few days and couldn't seem to find a definitive answer (or even what it would entail).
I was wondering how plausible it would be to embed a snapshot build of the Chrome webview (or even the Gecko webview) into a Phonegap app and to use that in place of the native webview that PhoneGap uses. The problem is twofold - 1) Android's native browser/webview is terrible and 2) Each phone seems to have idiosyncratic bugs/differences, which having one set snapshot to build against would fix.
I've seen answers ranging from "Oh, yeah, just build the source and drop it in" to "You'd need a full team of Java devs to hack the PhoneGap API core to get it to work". Does anyone have an answer of what it would entail, how much time it would take, if it's even plausible, etc? I suppose the biggest concern is - given we can get a snapshot build of the Chrome webview, does that break any of the connections to the PhoneGap APIs? Are they tied specifically to the native webview?
Any and all thoughts are appreciated. Thanks!
Chrome has the ability to be embedded by use of the Content Module. In theory (I have never done it) you can build this and embed it into your Application and use that instead of a WebView - it has the advantage of being an up to date Chrome and multi-process. It loses value in that it can't be used pre-Jellybean.
I would like to use -webkit-calc() on Chrome for Android, but it doesn't seem to be available
Is that correct?
How do I get information on webkit feature support?
A little late to answer the question, but Chrome for Android was on M16 and M18 for quite a long time which didn't have any support for -webkit-calc. As of M25 -webkit-calc is now available
We talked about it in our latest video http://www.youtube.com/watch?v=3eHKebsEOns&feature=player_detailpage#t=72s3
I also created a simple demo at http://jsbin.com/esepeq/latest that you can see it in action on any browser that supports it.
Anybody has a feeling how much effort it would be to replace the webkit engine with firefox in Android for webview rendering? I am quite unhappy with the webkit engine on some features.
Mozilla started working on GeckoView, which does exactly what you need. This blog post points to some sample code.
Here is the master bug, in case you want to follow progress: https://bugzilla.mozilla.org/show_bug.cgi?id=geckoview
Non-trivially difficult. Depending on how much consistency you need between your new WebView implementation and the existing implementation you could have a lot of work to do. There is an existing Firefox browser on Android so you could start with that (which would hopefully save you a lot of time) but at the very least you would need to check that the Firefox libraries exist and are accessible, you would probably need to bundle them with your app to get them to work (which would massively increase the size of your app) and then hooking up all the WebView apis would involve a lot of work.
The good part: there is an 'official' geckoview tutorial about how to integrate GeckoView, and a geckoview demo project on github:
The sad part: the official mozilla download site does not host the libraries anymore, and the latest available zips are from 2014:
http://people.mozilla.org/~mfinkle/geckoview/
At some moment there was a geckoview gradle artifact and a AAR, but the URLs are now dead.
Conclusion: apparently, GeckoView development has been halted, since URLs from the wiki page are broken, the library has been removed from the Mozilla continuous integration, and the bugs keep piling up with nobody to handle them. Hopefully I am wrong.
Will Titanium work properly on all android sdk versions (1.5, 1.6, 2.0, 2.1, 2.2).....
Based on the research I've done, yes, I believe so. I'd recommend trying it out.
Yes it is.
But be warned that while Titanium has its strengths, it also has its weaknesses (ie; memory).
If you're working on a project for a client or are just starting your journey into mobile development, I would recommend learning how to code a native application. At least that gives you some options if you run into troubles. I've been burned a couple of times.
Titanium works with all android SDKs .You just have to make some changes to make it work with all SDKs. Titanium works with sdk 2.1 and below without any changes. But in order to make it work with 2.2 and above you have to add a symbolic link of adb file which is in
platform-tools(source) folder to tools(target).
Occasionally the platform-level support for a particular feature is different between the iOS and Android. For instance, the underlying audio support is significantly better on iOS; many features are simply missing on Android (we eventually patched them ourselves).
In addition, the way that the underlying platform's primitives are wrapped differs, so that code that is correct Javascript will result in incorrect Java on Android. An example we came across was related to the treatment of null and undefined when used with the Ti.App.Properties.setXXX functions. This issues are becoming fewer and farther between, as mentioned, but there are still issues not just related to UI.
I suggest you make a point of continuously developing and testing on both platforms; you'll find incompatibilities (mostly related to leaky abstractions) and their workarounds more easily that way.
Well it works great for the cross platform Execution.
The Only problem is that when user want to compare the iphone version & Android Version by developing same code.
iphone is excellent as per its gesture supports & fine UI works.While Android is still improving the terms.
So you should firstly check your terms and requirement then Go a head with Titanium. OtherWise
Appcelerator consistently working around all the native support as well as common features.
you need to find the possibilities in proposal for the Framework.it will be great approach & future perception as well.