To get all the info possible about my location, my demo app utilised both the geolocation and compass APIs and worked like a charm. Looking at the specs, in particular the coordinates interface, something started to bug me. It didn’t make sense! According to the w3c spec ( which PhoneGap’s API is based on ):

interface Coordinates {
    readonly attribute double latitude;
    readonly attribute double longitude;
    readonly attribute double? altitude;
    readonly attribute double accuracy;
    readonly attribute double? altitudeAccuracy;
    readonly attribute double? heading;
    readonly attribute double? speed;
  };

I would like to point out that heading here denotes the direction of travel and must return NaN when speed is zero. The compass on the other hand simply “Obtains the direction that the device is pointing”, returning a single value for heading. Now there is w3c spec for compass, but I think these APIs need to be sorted out nonetheless.

First of all, I think the position and movement describing APIs should either be seperated or united in a much more logical manner. Lo·ca·tion by definition, refers to a particular place or position, so should contain attributes needed to describe just that, namely latitude, longitude, altitude and heading ( will skip the accuracy attributes ). Almost the same, right? Well, 75% true. The first 3 attributes are the same as in today’s spec, but the heading attribute in geolocation should refer to what is returned from the compass API, the direction the device is pointing. After all I can easily stand in one place, turn in any direction and my location should reflect this.

Ve·loc·i·ty, by definition, is the speed of something in a given direction. This is what the speed and heading attributes of the current geolocation API return, but these should NOT be inside geolocation, since they are not describing a particular place or position. These attributes should be in a seperate, let’s say, geovelocity API or simply velocity API.

If you are all confused now, here’s an example to imagine: You are sitting in a car travelling west while staring out the window facing north, taking pictures with your device. The location of any photo taken should describe its geographic coordinates, plus that your lense was looking towards the north. On the other hand a navigation app should continue to update the map showing the direction the car is moving in, so in this case, west. Did that help?

So to sum it all up, I suggest 2 APIs:

geolocation {
    latitude;
    longitude;
    altitude;
    heading;
}

velocity {
    speed;
    heading;
}

I could imagine another solution, for the sake of backwards compatibility, where all attributes remain inside the geolocation, but this would require a straight forward, clear word as attribute name for the compass’ direction. One that doesn’t refer to both the way something is pointing and moving. I prefer the previous.

What do you think?

Share

Problem 1: Crash! Yep, it seems that after a while, probably meaning that a great number of images have been viewed, the browser crashes. Basically a too-many-images-on-the-page issue, but ‘luckily’ someone has met it before and has come up with a solution. Although untested, I have my hopes up based his test page…

Problem 2: I saved all images to be 1.5 times the screen size, so extra details can be seen when zoomed in. All was well until the client added landscape images that were larger and yet didn’t result in more details. At first we suspected some bug in the script, an error in a sizing calculation, but no, that just took the dimensions of the image from the browser. So I started playing with images inside the project, and I soon realized that this had nothing to do with the project. This was something safari did! I quickly wrote a simple page to generate ever larger images in different formats, and answer soon became obvious. Safari resizes jpegs larger than 2MP ( 2,000,000 pixels ). A 2000×1000 pixel image is exactly that big according to the browser too, but 2000×1001 suddenly became 1000×501. Now I did mention that this was the case for jpegs, but as it turns out, it isn’t so for gifs or pngs. With those blessed formats I haven’t run into any issues on scales that matter here. I totally understand that you might be sceptical of my testing methods ( so was I for a while ), so feel free to take a google image search result page on your iDevice, check out a few big pngs and jpegs…

Now, of course these problems can be overcome if you know about them well in advance, during the planning stage of your project. Unfortunatelly, I am now well past the middle, so major changes have to be made to remedy them. I just hope that me writing about it will save you some trouble and time!

Update (2010-11-05): The app kept crashing the browser even after the canvas trick has been implemented, so I kept on searching. The solution came from the maker of the famous jquery cycle plugin. It involves replacing all out of view images  ( and canvas content ) with a 1px gif. This seems to free up the memory and save the app. Hurray, the gallery with several large images and zoom feature is now running smooth!

Share

Well, redoing my own site, I let myself get a little carried away too, and so I ended up building my business card in html. Of course, I wanted to keep the number of <div>s to no more than the number of pieces in the real world. One business card and one holder it is attached to.

<div class="business-card-holder">
	<div class="business-card" href="#balazs"></div>
</div>

And the result:

Before you say anything, of course the logo is an image. No reason that shouldn’t be. But everything else is just css3. To build the card and its holder I would have needed 5 elements, but luckily with pseudo-element selectors like ::before and ::after I could create those from the css without polluting the clean markup.

Firstly the holder got 2 extra blocks to create the little slots the card slides into. These are just 2 rotated rectagles with shadows, cut off by the holder’s overflow: hidden. The tricky part was trying to get the shadow of the card to be larger in the other 2 corners, where it isn’t held down by the slots. After quite some fiddling I arrived at the business-card div becoming a skewed and rotated shadow with -prefix-tranform. Its ::after pseudo element ( reversing the skew and rotation ) became the white paper of the card containing the text. Now because of all this twisting and turning the child elements of the card needed to be adjusted too so they aligned straight and square. As a finishing touch, following the advice of a gifted colleague of mine, a barely visible gradient was added to the ‘paper’ of the card, adding to the sense that it is ever so slightly curved.

As with most css3 adventures, compatibility is limited to modern broswers, but I am curious what it will look like in the version final ie9. Is there hope?

Anyways, I think it turned out quite nice. If you like it, feel free to download it, and do as you wish with it. But if you don’t like it… tell me why not?

Share

Share

Since this page is cms generated, I resorted to saving the page from firefox to my harddrive. After I pointed all resources to the live site, the issue still existsed, so it was time to start hacking away all the pieces that were not needed to reproduce the error. I have to add here that I only had partial knowledge over the solutions used on the page…

It soon turned out, the padding was added with javascript after the image was done loading and it’s width could be determined. There doesn’t seem to be anything wrong with that, right? Right! But there seems to be something wrong with changing the padding of an element with javascript.

In the end my page was little more that this:

<div id="scripted_padding">
    <p>
        Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed a purus eget velit pulvinar faucibus porta ac arcu. Cras vehicula urna odio, eu placerat sapien. Aenean commodo ipsum vitae lorem accumsan non posuere dui iaculis. Sed facilisis velit sit amet libero tristique eu porttitor ante blandit. Sed condimentum urna eget lacus molestie luctus. Curabitur ac iaculis urna. Etiam leo felis, sodales molestie sagittis eu, tincidunt ac nisl. Suspendisse et euismod dolor. Fusce mollis risus quis purus fringilla vel posuere dui aliquet. Sed et felis id est mollis ultrices in quis nunc. Nullam vel sapien sed nulla posuere condimentum.
    </p>
</div>

I had 1 line of javascript adding padding-right to #scripted_padding and sure enough the text inside the p tag would still fill the whole width of the #scripted_padding element. I could see in both browser’s inspector, that the element did have padding, but the p tag seemed to ignore it.

I’ve thrown together a simple page where you can test this yourself.

As a workaround I’ve added a .hide().show(1) after setting the padding in webkit, but I realize that this is, well, ugly and terrible, so I would love to hear a better solution to this problems!

Update [27/5/2010]: Just checked on my iPhone ( 3.1.3 ) and the issue exists there too!

Share