Category Archives: webapps

Mobile web apps I have developed

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!

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.

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!

PubCrawler and Firefox 3.5

I’m using Firefox 3.5 at home and its great. It adds HTML5 support so it should work with PubCrawler. However, whilst the geolocation functionality works well the local storage does not, so crawls cannot be saved. This is due to the local storage support being of a different type to the WebKit browsers like Safari in iPhone OS 3.x. The Google Gears Add-on is not supported by Firefox 3.5 yet so that’s not an option either. PubCrawler is primarily a mobile web app so this is not high on my list to fix.

PubCrawler HTML5 geolocation

I’ve been neglecting the PubCrawler a bit recently because of my current widget fetish. I made one quick change to it last night though. It now has HTML5 geolocation for browsers that support it. I tested it in Firefox 3.5 beta 4 which is a bit flakey when it comes to the geolocation stuff even on other peoples’ sites. Ideally I need someone to test it with a new Palm Pre which it should work for. Please contact me on webmaster at ubikapps.net if you do. Either that or I will have to wait until iPhone OS 3.0 comes out and try it on my iPod Touch.

I have lots of changes I want to make to PubCrawler. One thing that is high on my list is updating it for Google Maps API V3 which has a much improved mobile experience. I may have to create a separate version though because V3 is not fully featured yet.

Update: just installed OS 3.0 on my iPod touch and it works.