It started when I favorited a tweet
in February in which a request was being made for some help updating a
JavaScript book. I had recently spent some time contributing to a jQuery
Mobile book and wanted to continue writing. Shortly after I contacted
Louise (my editor) and it turns out that they had already found someone
to update the book.....
It turns out that Louise had some plans for a Node.js Recipes book,
which I thought would be spectacular so I set to work writing an outline
and proposal for the book.
After a few weeks I had the proposal in hand, sent it to the
publisher and it was approved. This is where things get crazy, because I
now had to write the twelve chapters I'd outlined and I had less than
two weeks to write each one if I was to make my deadline.
This crazy schedule, while good at keeping me on task, was not great
at keeping me rested and stress free. There were many late nights and
long weekends where I was not able to spend quality time with my family
or friends. I am grateful that they allowed me time to research and
write, because I was able to create a book which I feel will be a useful
tool for any developer who wants to learn more about Node.js. It will
give readers a glimpse of what goes on in Node.js not only in the Core,
but also in the third-party modules that have helped to create the
robust Node.js ecosystem.
A few weeks ago Mozilla announced another initiative to get some more applications into the FirefoxOS Marketplace.
I had submitted a simple compass application early on in the
Marketplace's life, but thought that this opportunity would be perfect
to get an PhoneGap wrapped HTML application that I created for Android
onto the marketplace, so I applied for a phone for app port deal. Within
a couple days I recieved confirmation that I would be getting a
developer preview phone from Mozilla, in exchange for my app port.
Now, I could have waited around until I received the phone to get
started working, but with the FirefoxOS simulator available as a Firefox
Add-On I set to work right away. I had previously submitted an
application so I knew the general Firefox manifest format which is
probably helpful. Once I had a Firefox app manifest being served (with
the proper MIME type) from AppEngine I was ready to submit. I did
however wait until I had a physical device to test and ensure it
appeared and functioned as I expected.
I have had a busy time over that last few months. Firstly, I have been engaged in a very ambitious and exciting project for my day job.
Aside from this keeping me busy, I also had a talk accepted for the jQuery Conference in Portland in June. Conferences like the jQuery Conference are always welcoming to new speakers and the community as a whole is open to everyone's input. Experiencing a conference such as this is always a thrill. This was my first talk at a big conference but I think it went well and I hope to do it again.
If you listened to at least the beginning of that talk, you may have heard me mention that I’ve been writing a book. This book has been a great deal of fun, but has also been challenging. Between research, writing code, writing text, editing, and following up with the technical reviewer it has kept me busy. It should be published this fall so stay tuned…
A little less than a year ago, I wrote a post about remote debugging tools. Since that time the landscape has changed, so this post will try update where we are in the world of remote debugging. (Note: by ‘we’, I mean me, and by ‘world’ I really mean, what I’ve used since last year)
First, lets review where we were a year ago. Chrome for Android was brand new, and had remote debugging support baked in. Opera Dragonfly had great remote debugging support. Adobe Shadow (now Edge Inspect) was new, and WEINRE was still a .jar.
Fast forward to now. Chrome for Android still has great remote debugging support, when connected you can see all your inspectable tabs from your remote device, and debug away. In Opera land, things have shifted a bit. Since they have started their switch to Webkit, who knows where their remote debugger will be in another year. Adobe Edge Inspect is a very popular debugging toolset for iOS and Android. Weinre is now (debatably) more accessible as a Node.js server, making it super easy to install and run a local/or remote hosted server. Weinre powers the phonegap debug service . It is also the service behind the experimental mobile debugging option at jsfiddle.net.
The newest version of jsbin.com has a pretty incredible remote rendering capability, but you can see for yourself on youtube:
Over the course of the last year, Firefox has built a homegrown set of Developer tools, so developers need not rely soley on Firebug on Firefox. These tools have been built with remote debugging as a high priority - with the proliferation of Firefox on Android, and the fancy new Firefox OS - remote debugging is important. Remote debugging for Firefox has been around for a few versions, but I really like to live on the nightly branch (currently 22.0a1), so thats what you’ll see here. Its quite simple to enable on your computer: just swing over to ‘about:config’ and toggle ‘devtools.debugger.remote-enabled’ to ‘true’ restart, and you are set.
\
Next (assuming you’ve got your android platform-tools installed) you simply connect your device to your computer and
adb forward tcp:6000 tcp:6000
Then, assuming you have enabled remote debugging on your Android device, you again go to ‘about:config’ and toggle the ‘devtools.debugger.force-local’ to ‘false’ and ‘devtools.debugger.remote-enabled’ to ‘true’.
Restart. Debug. To Debug you open the remote console by selecting ‘Connect…’ from the Tools > Web Developer menu. Thats it.
Remote debugging is important. And as the web development industry moves more toward mobile, these tools need to and will get better and more accessible for everyone. I expect I’ll be revisiting this topic again soon as tools improve or emerge.
I've built a couple of HTML5 (jQuery Mobile) applications that have also targeted native app stores using PhoneGap. When building these applications, it becomes clear that to get desired navigation in iOS, one must carefully consider the PhoneGap settings for url handling "OpenAllWhitelistURLsInWebView" and "ExternalHosts". In many configurations this results in setting the "OpenAllWhitelistURLsInWebView" to "YES" and Subsequently setting a single "ExternalHost" as "*" in order to keep your application functioning within the WebView exclusively. This is great for everything except where you wish to open an external link that would break your HTML5 applications navigation (due to a lack of back button). What follows are a few tricks I have picked up to help with whitelisting.
In many cases you know when you're building your application where you'd like to have the external links open, in which case you can set these external links within your Objective-C source code letting the applicaiton know which links to open. This would look something like the following Gist (which looks to the prefix of the URL in order to open a link outside of the WebView):
In other cases, your application may allow for some dynamic client created content to come from the server. This can mean either a maintenance nightmare for setting up this prefixed whitelist, where you get to update the whitelist and resubmit the app to Apple everytime the list changes (icky).... Or we can come up with a solution that works better.
One way in which this can be accomplished is by looking to the suffix of the URL to find a querystring parameter that would indicate that we need to open external.
A perhaps more robust solution, allow for the conversion of any link with target="_blank" to open in Safari. This solution is inspired by this where you tell your iOS app to find a specified document fragment, and also tell your web application to ensure that target="_blank" links always have such a fragment.
The Obj-C code looks like this:
and telling the webapp to set this fragment (using jQuery) looks as follows:
