Re: UA strings

> On Mon, Jun 21, 2004 at 02:29:17PM +0200, Johannes Koch wrote:
> > Kai Hendry wrote:
> > >The UA string for my Nokia 3100 is :
> > >Nokia3100/1.0 (04.01) Profile/MIDP-1.0 Configuration/CLDC-1.0
> > >What does MIDP and CLDC mean for example?
> > Google for MIDP or CLDC. -> first search result
> 
> Oh, right. =)
> 
> This is interesting because I assumed the browser was dependent on the
> Symbian OS. So it's a Java browser?!

No. The Java addition to the string advertises the device's configuration, not 
the browser's.

> Anyway, in my thesis I am proposing that it isn't the hardware
> characteristics that matter. It's the (software) User Agent
> characteristics that do[1]. Has anyone seem revisions of the browser 
on
> the same device?  
> 
> For example: Nokia3100/1.1 (06.01) Profile/MIDP-1.0 Configuration/CLDC-1.0

Yes. Where I work  we see multiple versions of a browser throughout a product's 
lifecycle. Usually these are just bugfixes (or bug includes), but sometimes 
major changes in functionality can occur, such as the addition of XHTML 
to some Nokias mid-lifecycle. Browsers vary between countries and operators 
too.

> <rdf:Description ID="BrowserUA">
>      <rdf:type resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20020710#BrowserUA"/>
> <prf:BrowserName>Nokia</prf:BrowserName>
> </rdf:Description>
> 
> What an uninspiring name for a browser.
> 
> Is there somewhere in a User Agent profile where a user agent's details
> such as version are supposed to be noted?  Otherwise can one assume that
> Nokia's XHTML browser will fixed on each model? 

Doesn't appear so. Nokia gets around the problem by issuing a fresh UAProf for 
each device with an Rnnn at the end of the UAProf name referring to each 
version. This doesn't seem to map exactly, however. Your device advertises 
itself in its headers as version 1.1 of the 3100, but there's only an R100 
UAProf.


> [1] http://natalian.org/archives/2004/06/18/nokia-inline-image-test/

You seem confused by what "file too large" means on a Nokia. It refers to 
the byte-size of the file (eg, it's bust the deck limit or the device has 
simply run out of memory): the geometrical size of the image doesn't cause 
this error.

However, you raise a good point. UAProf captures the actual size of the LCD: 
however content developers need to know the addressable size of the screen. 
A Java games developer may be able to write to every pixel, but a WAP developer 
can't.

The worst example of this is the 3650: the UAProf advertises itself as being 
176x208 pix - OS chrome takes up some the vertical height, which is anticipated, 
but try and stick  a 176px wide image in and it appears offset by 5px or 
so from the left margin. Just as you set about resizing everything to 171px, 
you discover that you can indeed make content fit flush to the left by setting 
the left margin of your content box  to equal -5px in CSS. Why is visible 
screen in a negative position? I'd understand it if Nokia had mandated a 
5px margin unless over-ridden (as IE and Mozilla do). But to make the leftmost 
pixel negative is bizarre.

It would be useful if UAProf was able to catch these quirks and provide them 
as rendering hints. As it is we can only use it as rough guidelines for 
rendering and we remain committed to spending a lot of money on device testing.

Received on Monday, 21 June 2004 11:41:39 UTC