Tag Archives: pubcrawler

Fun with CSS3 animations

I have been playing around with CSS3 animations for my day job and so I thought I would apply one to PubCrawler. The location marker now pulses:

marker

The CSS for this is incredibly simple:


.pulse_map_marker{
-webkit-animation: scale_map_marker 2s ease-out;
-webkit-animation-iteration-count: infinite;
}

@-webkit-keyframes scale_map_marker {
0%{-webkit-transform: scale(0.5);}
50%{-webkit-transform: scale(1);}
100%{-webkit-transform: scale(0.5);}
}

It basically scales the image down by half, then back to full size and back to half again over a 2 second period. The “ease-out” part smooths out all of the transitions. I originally tried a slightly different method:


.pulse_map_marker{
-webkit-animation: scale_map_marker 1s ease-out -1s alternate forwards;
-webkit-animation-iteration-count: infinite;
}

@-webkit-keyframes scale_map_marker {
from{-webkit-transform: scale(0.5);}
to{-webkit-transform: scale(1);}
}

Unfortunately, Android does not seem to like the use of the “from” and “to” clauses. Other Webkit browsers such as iOS and Chrome are fine with it. This is just one example of several inconsistencies in CSS3 compatibility between Webkit implementations.

Mobile phone networks can break your website

Sometimes my day job throws up some weird problems. Recently during development of a web app iPhones suddenly stopped loading the JavaScript file. No matter how far we rolled back the code it would not load. Other phones were fine and it had worked on the iPhone in the past. Eventually we found that the problem, of all things, was the mobile network! We only found this out because the JavaScript worked on Wi-fi but not on 3G and all the iPhones we tried were on the same carrier (I won’t say which but it begins with an ‘O’ and ends with a ’2′). Certain carriers “optimise” web pages before sending them to phones as I found in this blog post. This is supposed to speed up sites on phones but can actually slow them down by introducing latency. We worked around this by putting the JavaScript in line. Luckily the mobile network I personally use doesn’t seem to do this (hint: it’s name is a single digit more than 2 and less than 4, 5 is right out). Next time your contract is up be careful which network you choose!
Fortunately, PubCrawler doesn’t seem to suffer from the issue.
A good way to test and validate a web app post carrier fiddling is to tether a handset to a computer. Then using Firefox with the User Agent Switcher add-on mimic the desired mobile phone. Viewing source will display just how much the mark-up, CSS and JavaScript has been altered. Images are usually transcoded (unless the Cache-Control response header is set to “no-transform”) and linked CSS can sometimes be brought in-line for example.
I think this issue highlights the complexity that mobile developers face when trying to troubleshoot a problem. Dealing with differences between handsets and software is the norm but add carriers to the mix and it makes things even harder.

PubCrawler updates: HTML5 offline cache and more

I have updated my PubCrawler web app to use HTML5 offline caching. This means that saved crawls can be accessed even when there is no network connection. However, the Google Maps imagery will not load unless it is in the browser’s cache. Also creating a new crawl does not work offline as it’s a bit difficult to use geolocation with no cell towers or Wifi connect to! I have also added a favicon specific to the app.

When I updated PubCrawler to use Google Maps API V3 I forgot to mention that I changed the routing travel mode to walking. This should provide better directions as I should hope most pub crawls are done on foot!

A Big Thank You

Yesterday I received a free Nexus One from Google as part of their Android Developer Seeding Program. Reader Widget Free qualified for this so I just wanted to say a big thank you to everyone who downloaded, rated and provided feedback on it. It has been downloaded over 22000 times. Also thanks to those who bought the Pro version too and my other app, SMS Bot Widget. Of course a massive thank you must go out to Google for supporting Android developers like myself.
I first registered this domain on 9th April 2009 so this blog is just over a year old. I have enjoyed running it and developing it’s associated applications immensely. They are some things I have lined up which should make ubikapps.net’s second year even better than the first!

PubCrawler updated to Google Maps API V3

Good old PubCrawler. I have somewhat neglected my duties in maintaining this web app. However, I recently completed the migration to Google Maps API V3 for it. Advantages of this include:

  • Automatic display of controls based on device. For example zoom buttons are displayed on Android devices but not on the iPhone (because it has multitouch built in). This means that I have done away with the buttons below the map.
  • Built in map type buttons (Map, Hybrid, Satellite, Terrain) so I got rid of the button to do this at the top
  • Speed: it uses less data and therefore loads maps faster. They built it with mobile devices in mind.

There’s more but Google themselves can explain it better than I can. PubCrawler running on Maps API V2 (or PubCrawler Classic as it might become known) is still available here. I actually started this process of migration to V3 not long after it was announced. However, at first the full feature set wasn’t there so I parked it for a while. I’m not sure when the API became complete enough for PubCrawler’s needs but everything is there now.

Revisiting PubCrawler after such a long break means that the iPhone-esque look and feel is starting to look a little dated to me. At some point its going to need revising to something more unique and suited to the application’s purpose.

Back from Android Developer Lab

I had a good day at the Android Developer Lab. It was pretty freeform with a short presentation, lunch and then diving right into device testing. We got our hands on:

  • Motorola Droid
  • HTC Tattoo
  • LG Eve
  • Samsung Behold II

I concentrated on the Tattoo and Droid because of their non-standard screen resolutions. The Reader Widgets worked with only minor alignment issues on the large widget on the Tattoo. A fix is on its way. PubCrawler’s geolocation didn’t work on the Droid. Instead of Google Gears it uses HTML5 (more thoughts on that later). However, I managed to upload a fix there and then. It seems that the Droid is fussier than the iPhone when it comes to HTML5. More impressions of the phones and the day are coming soon.

Reader Widgets and Android 1.6

I have installed the official Android 1.6 (aka Donut) ADP build on my G1. I’ve done some initial testing and found that both Reader Widget Small and Reader Widget Pro work on it. I have also uploaded screen shots for both to the market (only visible in the 1.6 version of the market). PubCrawler still works too. Now where is my Android 1.6 build for my Hero, HTC? :)

Touch screen implementations and browser size

I have noticed something not mentioned much elsewhere when testing the PubCrawler on various devices. It is how much screen space is devoted to a web page. This is not a simply dependent on screen size as these screenshots show:

iPod Touch/iPhone 3.0 HTC Dream/T-mobile G1 Android 1.5 HTC Hero
iPhone Dream Hero

All the devices have the same resolution at 320×480 but the iPhone has the larger screen at 3.5 inches. The other two have 3.2 inch screens. It is obvious that the iPhone is showing less of the page, chopping off the bottom of the map. This is an important thing to remember for a single page web app like PubCrawler. The map should resize dynamically for each device which is something I might look into. Luckily the iPhone does not need the controls at the bottom thanks to multitouch pinch and zoom. The reason for the lack of browser room is the absence of physical buttons on the iPhone. This means it has to show more buttons on the screen which take up valuable space. Some people have wandered why there are so many physical buttons on Android devices but they are there for a reason: freeing up screen space and providing more options.
As mentioned before the Hero turns the entire screen over to the browser window forsaking even the notification bar. This leaves a big gap between the map and the controls at the bottom. Space for an ad perhaps? Maybe but you wouldn’t see that ad on the other devices!