As a Front-end developer, it’s my main gig to make sure our web application shines brilliantly across all the popular browsers. This way, I can share the happiness and provide a fantastic and consistent experience to everyone, regardless of their browser choice. Squashing any compatibility bugs is usually a walk in the park in standalone browsers – you have your faithful developer tools at hand, either locally or through remote connections, like on mobile devices. However, the game becomes a touch more thrilling when your web pages are loaded in an embedded browser control, like UIWebView. But, that’s just another fun challenge to embrace, right? So, let’s dive into how we can conquer this challenge together.
In the context of an embedded browser control, you may find yourself facing a bit of a challenge when it comes to the debugging process. This is largely due to the fact that you will not have direct access to the same set of tools that you might be accustomed to using in a more traditional browser setting. It can be a bit of a letdown, particularly when you begin to notice that a significant portion of your traffic is coming from the Facebook app. This issue might not be immediately noticeable, but as the numbers begin to roll in and you start to analyze your traffic sources, the impact of this limitation can become all too clear.
Remember those cozy old days when remote debugging of web pages was nothing more than a fantasy? In those days, when having remote debuggers for mobile devices was just a dream, developers had a trusty tool named Weinre. Weinre was nothing short of a lifebuoy in an ocean of code, acting as a debugger for web pages, akin to FireBug (for FireFox) and Web Inspector (for WebKit-based browsers), but with the cherry on top – it worked remotely. However, as mobile device platforms started to integrate remote debugger features for their browsers into their toolkits, our dear Weinre became obsolete and, sadly, faded into obscurity.
we’re going to be using this super useful tool to iron out any minor issues when our website appears within an embedded browser control. Weinre going to be our star player, helping us spot and fix any problems, ensuring a smooth and top-notch experience for all our amazing users. So, let’s not wait any longer, let’s start putting this reliable tool to work – let’s take it to its glory days.
The Webpage Side
So, we want to debug our webpages. No worries, All we have to do is to load a JavaScript file from our super handy Weinre server. But wait, we care about our users and we don’t want to slow things down. So, here’s the cool part – we’ve found a smart way to include this JavaScript file only when we, the developers, needs it.
We’re about to bring a little magic to our pages! When you click on any H1 header, a cute little input box will pop right up on the screen. Here, you can type in the host from which you’d like to load the script. Once you’ve done that, your JavaScript file will be ready and loaded, just like that! And remember, you can change the selector to whatever you want to kick off the script loading process. This is just one fun example!
This approach ensures the JavaScript file only pops up when summoned, avoiding any unnecessary load for those who don’t need this feature. It’s a win-win situation – you enjoy a seamless experience, and our webpage remains fast and efficient.
<script>
(function () {
const self = this;
self.selector = 'h1';
self.loading = self.loaded = false;
self.loadScript = function() {
if ( !self.loaded && !self.loading ) {
let host = prompt("Please enter your host", "");
if (host != null) {
let script = document.createElement('script')
script.src = 'http://' + host + '/target/target-script-min.js'
script.onload = function() {
console.log("loading script [OK] : " + script.src);
self.loading = false;
self.loaded = true;
};
script.onerror = function() {
console.log("loading script [XX] : " + script.src);
self.loading = false;
};
document.body.appendChild(script);
self.loaded=true;
}
}};
document.addEventListener('DOMContentLoaded', function() {
document.querySelectorAll(self.selector).forEach( function(elem){
elem.addEventListener("click", self.loadScript );
});
});
})();
</script>
Running the Weinre Server
We’ve reached a fun part! It’s time to run the Weinre server. We need to make sure it’s tucked away in a host that’s a breeze to access online. This step is crucial because it makes connecting from your mobile device as easy as pie!
You should see output like this:
$ npm -g install weinre
...
$ weinre --boundHost -all-
2024-05-26T12:38:44.826Z weinre: starting server at http://localhost:8080
Fantastic news! You’re all set and ready to connect to the server using your machine’s public IP at port 8080. when fetching http://ip:8080/client/#anonymous You’ll be greeted with a screen like this:
Now, we when we click on one of h1 headers, and provide the <public server ip>:8080, we will see a new connection in clients:
When you successfully connect, you’re greeted with a bunch of cool options to ramp up your interaction with the system. This includes the super-power to tweak certain elements on the server side directly, giving you a level of control that totally revolutionizes your user experience. You can play around with the look and feel of these elements, tweaking their style to match your specific needs and tastes. This goes for everything from their color and size to where they sit and how they look, creating a user interface that feels uniquely yours.
Plus, you have the console logs at your fingertips, a nifty tool that keeps a detailed record of everything happening within the system. These logs can be your best friend when you’re troubleshooting, keeping track of user interactions, or just wanting to see how the system’s performing.
You also get access to the network logs. They’re like a backstage pass, showing you all the behind-the-scenes data exchange and communication happening within the system. They give you a sneak peek into how the system operates, from data transfers to the interplay between different components.
And the cool features don’t end there. You not only get to view, but also run JavaScript snippets. These snippets, which run within the context of the webpage hosted in the embedded web browser control of the application, let you interact with the web content in a more dynamic way. You can create, test, and run these snippets, turning what was static web content into a lively, interactive platform. This feature takes your interaction with the web content up a notch, providing a more sophisticated and dynamic user experience.
Your Thoughts
Yay! We’ve successfully navigated the tricky world of debugging our pages within the Facebook application. Thanks to our trusty old friend, the Wienre tool, we’ve made this task seem like a walk in the park! But hey, it wouldn’t have been possible without hard work Wienre tool, right? Now that we’ve crossed this off our list, I’m really eager to hear your thoughts. What do you think about this method? Do you have any other methods in mind?