For the past two weeks, I've been playing around and implementing a
mobile web site using the ASP.NET 2 Mobile UI Controls (in
System.Web.UI.WebControls namespace).
When trying to read browser capabilities by casting Request.Browser to
MobileCapabilities, common attributes like IsColor, ScreenPixelWidth,
ScreenPixelHeight are often wrong. I've tried on a variety of color
mobile devices and IsColor always returns false...
Something is strange here, and I'm not sure what MS is doing to
determine the MobileCaps.
Has this been a problem for anyone else?
I've built WAP pages before in JSP that read the UA-Profile from the
HTTP Request header, fetch the XML URI therein and parse it for the
true and accurate MobileCapabilities.
Have MS completely forgotten about UA-Prof on mobiles?
-Vijay
Here are some good links that discuss the issue:
http://www.hanselman.com/blog/MakingDasBlogWorkOnMobileDevices.aspx
http://www.codeproject.com/aspnet/browsercaps.asp
http://www.slingfive.com/pages/code/browserCaps/ (IE ONLY)
For the schema of the BrowserCaps section, see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfbrowsercapssection.asp
There's a browsers folder inside CONFIG that contains .browser files
that try to cover the entire gamut of browsers. However, the config
files are missing most unique device models (but seem to include most
manufacturers), defaulting to some primitive capabilities. For example,
my K750i returns false IsColor, and under-valued screen res.
I couldn't find the schema of the .browser files, nor find an obvious
link between machine.config/web.config and the browser files.
These browser config files need updating for new devices.
Does anyone know where I could buy ASP.NET browser config files for our
projects? Or, must we generate them ourselves from device trial/error.
The only real solution I can think of is to parse the RDF in the
X_WAP_PROFILE request header field and generate per USER_AGENT browser
configurations. There still needs to manual tweaking and merging for
capabilities that aren't explicitly specified in the profile RDF.
This should be part of ASP.NET...or a documented missing feature..
IMHO, this limitation constraints the usefulness of ASP.NET Mobile.
Next time, I may even try and avoid ASP.NET mobile entirely for mass
market sites.
PS: I hope someone from MS reads this, because this is pretty important
to get ASP.NET working ubiquitously on mobile browsers.
-Vijay
--Aaron
I was thinking on making a uaprof file parser myself. Did you start
working on this already? I would be interested to share some thoughts
on it.
Peter
check http://mobilelabs.redcircle.com/
Paulo Gomes has written a tool to inject wurfl data directly into the
asp.net browser capabilities infrastructure, bypassing the browser
definition files!
I did some testing already, and it all seems to work like a charm.
Definitely, let's keep this conversation going, and come to a solution
together.
On Jan 28, 10:21 am, "Peter van Rees" <petervanr...@gmail.com> wrote:
> Guys, someone has been faster than we are
>
> checkhttp://mobilelabs.redcircle.com/
the short coming might lie in the fact it uses a huge xml file which I
think is cached memory? I can really notice the slower response of the
first page being viewed after restarting the application.
Further more: as far as I can tell wurlf does not work with regular
expressions in the useragent recognition, so literally every firmware
version of a phone has to have it's own entry.
I would be very satisfied if I could have the wurfl level of detection
integrated with the .Net controls. It would be head and shoulders
above what it is now. The .browser files are SOOOO far behind.... I
had to write my own generic blackberry file just to get it recognized
at all...
> > version of a phone has to have it's own entry.- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -
What I have found are notes to the effect that it doesn't actually
override the default behavior of .Net controls. In other words the
existing Command Link will still decide based on the .Net
implementation on whether to emit a link with javascript or a regular
command button based on it's own detection of javascript capabilities.
I distinctly remember posting a question about this on a forum they
used to have, however I can no longer find that forum. I also
distinctly remember after checking back for an answer after a week,
posting a not so happy remark about they need to engage the developer
community if they want this to go anywhere. From what I recall none
of the posts were actually answered on that forum, which is probably
why they removed it.
This coupled with the fact that it only shows that it has been
downloaded a total of ~60 times doesn't give me a warm fuzzy feeling.
The application that I'm looking to solve this for is a fortune 50
client. I don't have a whole lot of confidence in this organization
at this point.
I'm willing to write my own over-ride based on the wurfl file (because
it is that good), but I'm not aware of any way to do this...
How has your experience been with it? Have you tested it out
significantly? If all your looking for is detection for your own
custom decision points I highly recommend it. If you find that it
does integrate seamlessly please let me know. I'll be playing with it
again this afternoon to re-familiarize myself with it.
If it does integrate the way I need, I'm sure we can speed up the slow
down you said you noticed.
I'm reading the source now, it seems it does override the default
capabilities. Maybe I was doing something wrong back when I was
checking it out?
If nothing else this gives me the jump-start I need to writing my
own. I wonder what Microsoft's plan is for this? Have they just
abandoned it? If so are they just abandoning the entire mobile
development framework?
About asp.net mobile: I recall having read stuff about merging mobile
and 'normal' web controls into one set of controls back when .net 2
wasn't out yet. Mobile web forms/controls would have been rendered
obsolete in that case. Obviously this did not make it into the final
release. I have no idea whether it is still on their wish list.
btw: thanks for sharing your notes. I guess you had a version earlier
than this one, or forgot to put in the <browsercaps> section in the
config file?
About the slow start of the app: it does not bother me, it is only
when the application starts, so this will not happen too often (I
hope...).
And no, I did not do a lot of testing yet, I have it running on an
internal test server in a very alpha stage application I am
developping, so I cannot comment on the robustness of it all. The good
thing is it comes with the source though, so problems can be addressed
without waiting for someone else to respond. It will certainly make a
good start for your own system!
For now I am sticking with it, there are very few alternatives. Even
browserhawk doesn;t do a decent job with mobile devices.
I will do my best to keep you informed
> development framework?- Tekst uit oorspronkelijk bericht niet weergeven -