However, having found a requirement which could have been satisfied with either native components, or the use of the embeddable web browser, I opted straight for the web browser route. The reason for this, mainly, is that this solution has been used across iPhone, Android and BlackBerry with little or no tweaks needed on the server side when integrating the new platforms. Take all the content needing shown, use HTML to handle the layout (optimised for the requesting device, of course), wrap it all up and send to the device which can store it locally for offline viewing. Elegant, efficient, flexible... perfect. And best of all, changes to this layout requires no code changes, so can be edited even after the apps have went live. Beautiful, I must say, even though I can't take the credit for the original idea. Cue WP7 deciding to be a bit special.
Things were going well with this flexible, reusable solution. Now there seems to be very little information about what the WebBrowser is supposed to support, but there is a vague quote floating around that it is essentially IE7 with a little bit of IE8 thrown in. Imagine my shock then, when attempting to use a data URI to encode my content, and store it locally, only to have IE laugh at me, spit on my face, then roll over and die. Well not that shocked really. I am disappointed but not surprised that in this day and age, people still have to spend time working around IE. Seriously, what decade is this again? It is times like these that I am grateful to be mostly an 'app man' and don't have to spend much time at all as a web dev. I do empathise entirely however. It is simply painful. Not that there aren't plenty of complexities ensuring optimisation and compatibility across devices when writing native apps, but they pale in comparison. Very grateful.
So that was Data URIs out the window, plan B in the making for that one. Second major hurdle working with the WebBrowser was the inability to allow me to have scrollable content on a fixed background image. Yes, despite my best efforts, I couldn't (and still can't) find any way to achieve this. Lack of support for background-attachment:fixed in mobile browsers (yes, all mobile browsers) seems to be the cause of this. For Safari, I found you could use something like:
#fixed
{
position: fixed;
bottom: 20px;
height: 100px;
width: 100px;
}
but not got it going on WP7 yet. Pretty confident I'm going to have to abandon the use of the WebBrowser altogether, which is doubly devastating as it means the solution requires more work than I'd hoped, and that the solution becomes fragmented between platforms.
A further kick in the teeth is that with the next big update after copy/paste (likely named 7.5, or Mango) we are likely to get a much better browser in the phone based on IE9. Yes, still isn't Webkit (sticking with Trident), and probably is never going to be, but hopefully IE9 can breathe a little down Webkit's neck which can't be a bad thing for typical end-users. By then however, I'll already have been forced to produce an alternative solution, and worse still, support this fragmentation for some time to come for legacy WP7 users.
Damn you IE. You are like a family pet, long passed the cute stage, that no one really wants to seem that heartless as to suggest putting it down, given the many years it has been part of the family. Well sometimes people just get tired of cleaning up shit after you.
With recent versions of iPhone, Android and BlackBerry all running on Webkit-driven browsers, it becomes harder to stand behind the notion of competition is good. Or at least, I'd be happier to have that attitude if I wasn't the one paying the price for it. IE9 better be worth the wait when it hits the mobile; now more than ever these devices need a damn fine browser.
Could be worse, could be supporting WM6.x. Always a silver lining.
Could be worse, could be supporting WM6.x. Always a silver lining.
No comments:
Post a Comment