trigger.io claim it is possible for their apps on Android 4.4 [1] that uses Chromium as basis for the webview, but I didn't have the chance yet as I am still on 4.3.
So WebViews in KitKat are not screencast-able as they are currently pegged at Chromium 30. Nevertheless, a debuggable WebView is an enormous leap forward in Android Web development.
Your apps inside a WebView are just as important
and deserve a runtime that keeps users up to date.
There are large engineering and logistical
challenges. We're not quite there yet, but we're
working on it.
I presume that the engineering feat is getting WebViews packaged in an updatable form. Right now WebViews are linked through the Android system, exposed as Java classes to apps... code that is not contained in APKs.
I can think of two ways to solve this:
1) Android learns how to receive partial system updates outside of device and carrier certification processes (maintenance releases). Through the Play Store, for instance.
2) WebView architecture is changed to run WebViews as a service hosted in a dedicated WebView app, upgradable as an APK. This would require either an enhancement to RemoteViews or a new solution altogether.
>1) Android learns how to receive partial system updates outside of device and carrier certification processes (maintenance releases). Through the Play Store, for instance.
That's what google is doing with the Google Play Services 'super app' - it's meant to untie Android API updates from carriers. With the bonus of the app being closed source and thus not part of stock AOSP.
I'm really in need of accurate iOS Safari emulation in the browser so I hope this brings it. I have a javascript "push-menu" effect that works properly on every device except the iPhone's Safari and debugging it is proving tedious because the effect works in the current dev tols "simulation" of the iPhone as well. On every device the push-menu pushes the other content aside, leaving the button that activated the originally hidden menu still visible. On mobile Safari, the menu covers up the existing content, including the button I would use the close the menu.
Note that Chrome for Android (and the desktop emulator) are very different than Safari on iOS. Even when they were both built on top of Webkit, they had different renderers and platform bindings (and the iOS binding was not open source, which caused some of the friction that caused the split). Now that Blink has forked from Webkit, they are diverging even further.
So while this means you can do basic mobile web development this way, testing that your UI generally works on mobile devices, it's not substitute for testing and developing on actual iOS Safari.
I'm on Linux and installing a virtual box with a Safari browser just for that seems like too much trouble. I have access to my brother's iPhone but it's annoying for me and for him to have to push my changes to a staging site then go "hey can I use your iPhone for a second" every 5 minutes.
Honestly, you're never going to be able to replicate the iPhone without using the browser engine it uses. These Chrome Dev Tools will have nothing to do with iPhone Safari.
No I've just been using the iPhone user agent "simulation" in Chrome's dev tools. All this does I think it set a reasonably correct resolution and scaling factor, but all the other rendering specifics get overlooked.
I have had success debugging iOS Safari layout issues with https://github.com/google/ios-webkit-debug-proxy. It claims to support Linux, but I have only used it on a Mac. Could be worth a shot.
This seems pretty cool (actually very similar to at least the port-forwarding part of OP's article - except for iOS), but I imagine on Linux you'd still need a device. On a Mac you could just use the Xcode's iOS simulator.
You don't need to push your changes to a staging server. Just have your computer and iPhone on the same wifi network. Then direct the iPhone's browser to your computer's IP address:port
This seems like the holy grail and I will definitely do the free trial to test it out but at this point I am not getting paid for my website development efforts so I'm not ready yet to pay a monthly fee for this (just hacking on something for myself).
What I did (before I got someone to pay for it for me :D) was buy an iPod touch on craigslist. Got it for like $80. It was a big stretch, financially, at the time, but the hours upon hours it saved was well worth it. You can also sometimes pick up iPhones with bad esns/cracked screens for a lower than normal cost.
'Course all of that assumes you would need more than 2 months worth of debugging on browserstack.
It's a great product, unfortunately (for us) the price has been steadily rising. When I first signed up it was $20/month for everything now I think it's $40/month.
I used both and while I can't give a precise comparsion I think that the chromeDevtools are generally more advanced but Mozilla is working really hard to improve with actually good results.
One thing that got me stuck for an entire coffee was that I needed to run Chrome Mobile Beta on the device to get the Screencast toolbar button to appear, otherwise you just get regular remote debugging with no button.
Devil's Advocate (from an uninformed newbie): What's the benefit of this when no one uses chrome for mobile? All android devices come with "Internet" and all iOS devices come with Mobile Safari. This doesn't help me resolve issues on the browsers that people actually use on mobile devices.
I suppose you are referring to devices like the new Nexus 7 that come with Chrome pre-installed. It doesn't have android's native browser and as far as I know it's the only device that ships with Chrome.
Nope, it's basically any device with the Play Store on running Android 4.2 or later.
Chrome being the only browser on Nexus devices has become another reason to avoid Nexus devices, along with the Hangouts as only messaging app and the general lack of storage. It's merely that the alternatives are arguably worse.
also with 4.4 they sort of broke/fixed the aosp browser, so things like text wrap is gone and zoom behavior acts similar to chrome.. almost forcing people to use chrome
