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.
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.
I need to develop a portable application mainly for Windows 8.1 and iPad, but could be expanded for Android, WP and iOS later.
The application consists of calling web services to display data in grids and it contains CRUD operation, and it may save some local data for offline mode then synchronizes later when connectivity is up.
I'm torn between too many solutions, I need your advise for better solution.
1- Solution 1: Go Native for each OS (VS for Windows 8.1 [RT and pro] and xCode for iPad): this solution requires code duplication, logic and UI.
2- HTML5 with WebView app: I think this is a weak solution especially that we have local storage, checking for connectivity and calling ws ...
3- Using Xamarin: I think Xamarin does not support WinRT or Windows 8.1 to share logic code between iPad and Windows 8.1
4- Using Xamarin.Forms: Building the UI is tough and also it does not support Windows 8.1.
From your perspective, what is the best solution? please advices if you have any other proof of concept.
Many Thanks.
Most of the html/hibrid frameworks like Cordova (cordova.apache.org), Ionic (http://ionicframework.com/), etc, uses a native WebView on Android. Until Kitkat the performance of WebView is not production-ready and if you've a list with a lot of elements, the scroll experience is really bad.
If you want to do a simple proof of concept, prototype or whatever, I think that html frameworks are a good alternative. But if you are going to put your bussiness on top of one of this framworks, I would not recommend.
There is an alternative to embed a Chrome using Cordova & crosswalk (https://crosswalk-project.org/documentation/cordova.html) but you will end with an APK ~40Mb for a simple hello world.
Just my 2 cents. I don't see a point in using libraries that are unsupported across the platforms you plan to release and support on. Personally, I'd code natively for each platform. While this takes a lot of work, if you have to ask for direction on which path you want to take your application, then this type of project sounds more like a "you reap what you sow" application. Also, you'll be able to directly support each problem without having to wait for patches, but there are 2 sides to that coin as well. Your opportunity cost is missing future features the library will provide, if it's worth it to you.
If you aim at quality, going native is the only way... You can reduce the amount of work like Google is doing: writing the business logic and unit tests in Java, then converting it to ObjC with J2ObjC and to Javascript with GWT.
In your case, being that Java is a dumbed-down version of C#, you can easily find tools to convert to the latter, finding yourself with native business logic for every platform! That should account for 50%-70% of the codebase...
I think going with HTML5 with webapp view is better option.
Using Cordova (Phonegap) most of the native features are easily achievable in HTML webapp.
PhoneGap Platform Guide
Alot of other plugins are available for the advances features like BLE, NFC.
Calling webservice is really not an issue in HTML5.
Simple ajax is enough, however now a days many advanced frameworks are available which makes your work easy. One of the best among them is Angular JS(maintained by Google ).
Angular JS
For database you can access native database of the target OS or SQLite db of the mobile device.
You can check this link
Storage options
So developing a webapp can be a more efficient solution in your case. It can be best way for you as per my view point. However, you can do some R & D and can find the appropriate for you.
(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 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.
Hi there Im new to mobile application development. I had developed Android apps using Java and is just starting to get the hang of Cocoa Touch and Objective C. Now I am curious on mobile web application development to create cross platform/device applications which would at least run on Android and iOS(Apple devices: iphone, ipad). I tried Titanium and developing applications with this framework seems very promising. Although it is very powerful, popular, mature, documented and very easy to learn I had doubts investing time and to commit on using this framework for my projects after reading this blog which many Titanium users seems to agree with Why you should stay away from appcelerators titanium.
It seems that release v1.6 sdk and v1.7 sdk have the issue which they describe, the negative comments stopped right after the v1.8 sdk release was out.
My question is, is Titanium v1.8 sdk free from the memory starvation issue and other issues which were discussed on the blog post?
Would you personally recommend this for production use? And by the way I am using the 1.0.7.201112152014 Titanium build does this use the 1.8 sdk? Thanks in advance.
Take a close look at the progress of comments. It starts from people agreeing with him, and in the end everyone disagrees.
You can select the SDK you wish in the tiapp.xml editor, which is embedded in Titanium Studio. You should indeed use 1.8.x
The platform isn't, and probably never will be, memory issue free. But it also depends on how you build your app.
Stay away as much as you can from includes. And also stay away from creating a window/view/etc. with a file as url in it, this causes most memory issues because it's in a different space.
If you code well, you can use it perfectly without any issues.
Blog post author here. I don't fully agree with Topener - go ahead and read the comments yourself, it's just not true that "in the end everyone disagrees".
For what's worth: my experience is related to version 1.6.2. I've talked to people working with trunk and they told me that the memory issues are far from being resolved.
The only approach that seems to work is, as mentioned in the comments, the Tweetanium approach. But beware, that's not "if you code well". It's "if you code the way Titanium likes". If you take a look at Tweetanium (I suggest you to do it no matter what you decide to do in the end) you'll see that it has a very specific way to deal with architecture. If you follow that path, you should be good. If you think that the way Tweetanium is structured is good for you application, go for it. Be wary though, because (at least in what I consider to be complex) Tweetanium is not very complex, and with growing complexity I found that their approach is difficult to maintain. Again, evaluate for yourself.
Then there's the Android issue. Android support is far from optimal - Wunderlist decided to rewrite their Android version in native, I myself have had huge problems in making anything even remotely complex in iOS working decently on Android. If you need to support only iOS it's alright but, if that's the case, I don't see why you shouldn't write the app directly in Objective-C... considering also the (unavoidable) delay/mismatch between the Titanium and the iOS SDK.
Just my 2c. I suggest you not to take the decision lightly - it costed us a lot.