Archive for category Web
Fixing localStorage and WebSQL Databases on iOS5.1
If you’re an iOS developer using an embedded webkit UIWebView in your app, then you’ve probably stuck the problem where your localStorage and WebSQL databases will just disappear when upgrading your app on iOS5.1. Other symptoms for this bug are not being able to call window.openDatabase() (it throws a “SECURITY_ERR: DOM Exception 18” error) or not being able to save to localStorage, after upgrading your app on iOS5.1. This was particularly painful for me when using a framework such as PhoneGap. The reason for this happening is that as of iOS5.1 the database files are stored in the Caches folder, which can potentially be wiped when an app is reinstalled or upgraded, or even if the device runs out of memory. Apparently it’s some kind of new thing to stop databases being automatically installed to iCloud. The other problem is that when upgrading/reinstalling your app, it gets given a new path on the storage, but the WebView preferences aren’t updated automatically to point to the new location.
Read the rest of this entry »
State of Play
So it’s been a fair few months since my last post and I thought I’d try get back into it with an update of what’s going on in the world of IM and Pidgin plugins and stuff.
In case you didn’t know the Christchurch earthquakes have been affecting my life for the past few months. These are pics from a walk around the block around my house. Over 7000 aftershocks and still going!
So what does this mean for the Pidgin plugins?
For the most part, not a great deal. Things have slowed down since I’m spending more time of earthquake cleanup and wedding planning rather than coding, but they’re still plodding along. Unfortunately the power-cuts and brown-outs have caused damage to the server machine that I use to build all my plugins (and which runs this website/blog) and it needs to be rebuilt. Currently it’s running of a live CD of Gentoo since the main partition won’t mount at boot. If you’ve been unable to access the Skype plugin site recently, that’s why.
So what’s the state of the Skype plugin?
As mentioned in previous posts, I had started work on a SkypeKit plugin. Unfortunately, the terms and conditions completely rule out using the SkypeKit SDK in open-source software and so the SkypeKit protocol would need to be clean-room reverse engineered – this has been made harder by the added layers of encryption recently added to the SkypeKit protocol. Instead, I’ve been following closely the skype-open-source efforts, to create a native Skype protocol plugin for Pidgin, however a lot of people have been having difficulty with it as certificates and other protocol things are out of date with the newest Skype versions. For now, I recommend just using an old version of Skype (eg, v3 or v4 on Windows) along with the skype4pidgin plugin, to keep memory usage down.
So what’s the state of the Facebook plugin?
Well at the moment, there’s a lot of people having a lot of trouble with the plugin. Things have changed in the ‘FB HTTP’ protocol and I haven’t had a chance to do anything about it. Unfortunately, Pidgin (well, libpurple mainly) can’t just switch over to using the official FB API’s for login and status messages and stuff since it all relies on having a browser being embedded into the app. It also relies on the browser supporting JavaScript, something which especially can’t be assumed when using Finch from a terminal. There’s some code in source control at the moment that uses the login system from the HTTP chat method to allow the Pidgin app to do the XMPP login and all that jazz without any kind of user interaction, but that probably breaks a lot of FB terms and conditions. 🙂
What about the other plugins?
Yeah, I write one or two other plugins for Pidgin/libpurple 😉 A lot of them are being integrated into the Purple Plugin Pack but I’ll list them out here with a brief status update:
- OkCupid protocol plugin: Still going strong. I’ve been asked to port the plugin to work in InstantBird which I’ve started investigating.
- Windows 7 Extensions plugin: Looking good. If you’re using Windows 7 or later and don’t have the plugin, you’re missing out on some useful eye-candy 🙂
- Automatic translation plugin: Not so hot. The calls to the Bing/Microsoft Translate service are all coming back as null, and the Google Translate API’s are closing up at the end of the year. I’m looking at other (free) online services to use.
- Steam protocol plugin: There’s now a SteamKit library out which talks the native Steam protocol. Unfortunately it’s written in .NET and would either need a complete rewrite to work in Pidgin, or for a Pidgin plugin to be written using embedded mono. Writing OO code in C is crazy
- Keyboard LED notification: Not working on this any more since it works well for most people
- Protocol Icon Override: Has an annoying bug that the icons don’t show up when creating a new account, otherwise fine
- IRC HTML Formatting: Oddly needs to be re-enabled after Pidgin starts, and it’s currently not matching up HTML colour codes to their closest-match IRC colours. Bold and italics and underline work alright though 🙂
- Wordfeud protocol plugin: Most of the protocol is reverse-engineered and chatting works fine, it just needs some kind soul to make a GTK interface for the Wordfeud game board
- Gammu protocol plugin (SMS via your phone): Works fine
- Typing sounds: Why would you even want to use it? 🙂
- Omegle protocol plugin: No idea. Let me know if you use this one
- Ning protocol: Also no idea. Again, let me know if you use it
- NetNexus protocol: Unfortunately noone hangs out in the NetNexus rooms any more
- Pidgin Juice: Needs a massive overhaul to take advantage of some new HTML5 goodness.
So yup, that’s an update. While I’m not in the super active development mode I was a year or two ago, I’m still fairly contactable. So if you have any questions, queries, bug reports or feature requests feel free to either contact me, or leave a post in the comments. 🙂
Taming the GAM beast
One of the things I have to do in my day-job is manage our Google Ad Manager system, which we call GAM. One of the downsides of using GAM (actually a lot of different ad management systems) is their use of the javascript function document.write(), as well as their requirement to load in a big whomping load of javascript in the <head> of the page. One of the keys of website optimisation is to load all javascript at the end of your HTML page, so that the webpage renders as quickly as possible.
The way we can deal with this is overload the document.write() function to bend to our own wicked ways. Normally, you load the GAM code at the top of the page, but we’ll put it at the bottom and use a neat little function I wrote.
function insertAds(AdSlotName, width, height)
{
var slot = document.getElementById('my_ads_'+AdSlotName);
if (!slot)
return;
var oldwrite = document.write;
document.write = function(text){slot.innerHTML+=text};
GA_googleFillSlotWithSize("ca-pub-yournumhere", AdSlotName, width, height);
document.write = oldwrite;
}
Now we just slap in a <div> with our ad slots name, so we’ll replace
<script type="text/javascript">GA_googleFillSlotWithSize("ca-pub-yournumhere", "AdSlotName-760x120", 760, 120);</script>
with
<div id="my_ads_AdSlotName-760x120"> </div>
(which will render faster)
Then load in the ad at the bottom of the page:
<script type='text/javascript'><!--
insertAds("AdSlotName-760x120", 760, 120);
// --></script>
And there you have it. You can take out some more javascript from your <head> and speed things up a bit. My own speed tests showed between one-and-a-half to two seconds decrease in start-rendering time. Would be interested to hear your own findings.
Cross-Browser Gradient Backgrounds
Posted by Eion Robb in Uncategorized, Web on 2009-09-20
Recently, one of the websites I work on was given a makeover and I was asked to implement the design. One of the features it called for was rounded-cornered gradient backgrounds. Rather than turning the design down, I took up the challenge to try to implement it.
Looking around on the internet, there’s a little bit about how to go about that in a cross-browser way, but I thought I’d document it here.
The basic idea I took is to use an SVG as the background. Unfortunately, IE doesn’t support SVG’s and most of the browsers that do support them didn’t support them as backgrounds at time of writing. Fortunately, we can mess with CSS and HTML to display the SVG as an image behind the content, while at the same time providing a fallback for IE.
The basic idea, is to show the SVG after the content, then push it up behind the content with some absolute/relative positioning, so we write code similar to:
<div id="svg_outside">
<div id="svg_content"></div>
<div id="svg_background"></div>
</div>
Give the outside div a “position:relative” and the background div “position:absolute” and you’re all set. Put whatever you want for a background in the background div and your content in the content div (funnily enough).
While this doesn’t look nearly as clean as having just a single div with the background set to the svg, it does allow us a lot of flexibility to deal with IE. Since IE can’t natively handle SVG’s (yet), we can use a gradient filter on the background div. Alternatively, we could use some VML. You could even use a video as a background if you so felt like it 🙂
Check out http://eion.robbmob.com/svgdemo/ for an example.
There can be issues with the Adobe SVG plugin taking over sometimes.
Can’t be bothered writing about this any more, so I’m just gonna post it. Its been sitting in my drafts folder for long enough 🙂
Gzip Encoding
On PHP pages that I get control over, one of the first things I do is add Gzip encoding. This compresses the text on the page for browsers that can handle it, and really reduces network traffic, speeding up page load/download times on dial-up (well, and broadband) connections significantly.
On PHP this is really easy, its just one line of code at the top of the page:
ob_start('ob_gzhandler');
But until now, I had trouble finding out how to do this for .NET sites. All I could find was that you can enable it server-wide on IIS but now I found this handy bit of code that can go at the top of your .NET pages.
string AcceptEncoding = HttpContext.Current.Request.Headers["Accept-Encoding"];
if (!string.IsNullOrEmpty(AcceptEncoding) && AcceptEncoding.Contains("gzip"))
{
HttpContext.Current.Response.AppendHeader("Content-Encoding", "gzip");
HttpContext.Current.Response.AppendHeader("Vary", "Content-Encoding");
HttpContext.Current.Response.Filter = new System.IO.Compression.GZipStream(HttpContext.Current.Response.Filter, System.IO.Compression.CompressionMode.Compress);
}
And that’s it. Tasty Gzip encoding for all. The next step is testing it, which I use the mod_gzip_test site for. You can see an example of the changes we made to gameplayer.co.nz (a .net site) here