Just bought a cheap defunct hp touchpad. I notice that when I browse to my asp.net web app the url returns session id. The touchpad has cookies enabled and my web.config contains no mention of 'cookieless' which I would have thought would default to "false". IOW This should not be happening. And I have not seen this behavior with any other Browsers I have used on this particular web app.
Is there some other reason that would result in the session id being embedded in the url for this browser?
Edit
Ok i just noticed that, although cookies are enabled for the browser (and visits to 'Browser capability' online sites back this up), ASP.NET's HttpBrowserCapabilities.Cookies is set to false.
Sounds like the default ASP.NET browser capabilities detection doesn't handle WebOS browser.
Microsoft has given up updating the browser capabilities actually, but you can have similar functionality from Wireless Universal Resource File (WURFL) project:
http://wurfl.sourceforge.net/dotNet/ (powered with sample code)
The current officially recommended way to make use of this data is through a library called 51Degrees.mobi http://51degrees.codeplex.com/
I say officially recommended as per:
http://www.asp.net/learn/whitepapers/add-mobile-pages-to-your-aspnet-web-forms-mvc-application
which is one of the most complete references for dealing with mobile devices in general, and is part of:
http://www.asp.net/mobile
Check it for more documentation.
There are other alternatives as well like:
http://blog.mobileesp.com/?page_id=53
which gives you general classes of devices. You'd be checking for WebOSTablet instead of cookies support, so, it's helpful more in device specific optimizations than for general capabilities detection.
But you probably want to try the WURFL project API or the 51Degree.mobi API for the detection.
Related
Is there a way with bubblewrap when building a TWA to force the #custom-tabs engine that is used? Ie at the moment if a user has their default browser set as Firefox the TWA installed will use the Firefox/gecko implementation...
I'd rather force TWA to use chromium #custom-tabs due to additional APIs available and CSS handling..
Additionally testing is far easier with one engine than two.
Thanks
Bubblewrap doesn't provide an option to always use a specific provider. That is by design, for two reasons:
it's not possible to guarantee that a given browser will be installed for all users.
favour the user's browser choice.
It is possible to modify the app directly to get this behaviour, but due to the reasons above, not recommended.
I'm investigating the possibility of building a chrome app for a specific enterprise customer. This app would only be used by that customer (ie, it is not a general purpose app).
Among the use cases described on the Technical Overview are the ability to replace "Legacy desktop applications" and "enterprise applications that require heavy computation" - the solution I'm considering fits into both these gaps, as we have some mathematical libraries that we'd like to incorporate into a client-side web app.
Later on in the same document, however, it indicates that you can only deploy native client apps that are deployed on chrome webstore, as clarified by the https://developers.google.com/native-client/devguide/distributing document (and various developer scenarios).
Question: Is it possible to have build a web-app that uses Native Client, and distribute that to users worldwide, but without using Chrome Webstore (ie, using an internal server)?
Note: I've seen this document about creating a private chrome app collection on webstore, but this seems to be specific to ChromeOS. I'm interested in deploying to users that have the latest stable build of Chrome.
It is absolutely possible to run a Native Client app without hosting it on the Chrome Webstore -- otherwise, it would be very difficult to develop an NaCl app in the first place. It is possible for end users to use an NaCl app hosted on any random site. The catch is that the user needs to specifically enable the feature in their Chrome browser. It looks like the current way to enable this is to visit the "chrome://plugins/" page (or "about:plugins" page, same thing), and check the "Enabled" box under "Native Client".
Perhaps enterprise-level administration makes this easier to roll out, or perhaps allow finer-grained control so that only NaCl apps within the corporate intranet are trusted while not allowing stuff from the broader internet (NaCl is supposed to be safe and sandboxed, but Google is still playing it safe and paranoid, just in case).
For a public example of a self-hosted NaCl app, check out NaClBox, a Native Client port of the venerable Dosbox emulator. While it is also hosted in the Chrome Webstore, their support page describes how to run it directly from their site.
I have .NET website that is mainly built for desktop browsers but I'm currently making a mobile version of it. What I'm trying to do is load the website according to the device on which it is accessed by the user. Is there a way that I can get information about the user's device when they request the site?
Regards,
Sumit.
As suggested by others you can use the System.Web.HttpBrowserCapabilities class accessible through Request.Browser however without updated browser definition files the information is completely worthless.
For example, if you use Request.Browser.IsMobileDevice this should give you what you want, but is based on a set of very dated regular expressions in your .NET framework folders in Windows.
You can see the kind of problems that can be encountered on a (currently unanswered and unloved) post here on Stack Overflow.
If you do not plan on keeping the browser definition files up to date (which is no small task) then quite simply do not go down this route.
If you simply want to know whether the user is viewing on a mobile device then here are a few options:
Detect Mobile Browsers
51Degrees.mobi
WURFL
User Agent Info
Some of those are free, some aren't and if you are really only interested in whether it is a mobile device, my recommendation would be to use Detect Mobile Browsers.
Take a look at the HttpBrowserCapabilities class.
Enables the server to gather information on the capabilities of the browser that is running on the client.
This is actually exposed on the Request property of the Page object - in an ASP.NET page you can do the following:
var browserCap = this.Request.Browser;
You can examine the HttpRequest.Browser property - MSDN link.
If you are looking for something more low level: http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.useragent(v=vs.90).aspx
A commercial alernative is BrowserHawk
As web browsing continues to change due to apps with "web view" widgets, tablets, etc., I want to track hits to my website based on browser-type so I can proactively tailor content and presentation.
When I examine a small handful of web browsers from iPad, Android, Macbook, iPad and others, it appears that the userAgent is simply the appCodeName concatenated with appVersion.
Is that always true? Can I rely on it for presentation (i.e., CSS) decisions?
Any other issues to consider?
I think it's better to use a browser detection mechanism like WURFL(Wireless Universal Resource File).
This is an XML file (and now a DB file) and various DBI libraries that not only contain up-to-date wireless user-agent data, but also what features and capabilities those user-agents support.
And Detect Mobile Browser that do this in Apache, ASP, ColdFusion, JavaScript and PHP.
I've included a mobile web form in my asp.net project, I thought that it could/should be seen just for my mobile users but I realize that it can also be seen from any browser, I don't see problem there cause I could diff the access using HttpBrowserCapabilities.IsMobileDevice=true and transferring to the appropiate aspx page, but it results that when I access to the web form from my mobile device it is identified as IsMobileDevice = false and sends me to another page.
How could it be possible that?
The mobile device runs Pocket PC 2003.
IMHO: The value of HttpContext.Current.Request.Headers("User-Agent") is a much safer bet as it actually indicates the browser that is making the request, and not the type of device per-se.
I've learnt from experience that if a smart phone makes a request through a third-party browser to your service, more-often-than-not any sort of "what type of device are you" test (HttpCapabilitiesBase.IsMobileDevice and/or HttpContext.Current.Request.Browser.IsMobileDevice) will fail.
Unfortunately though, short of a big list of allowed user-agents (or disallowed user-agents for that matter), you'll just have to make sure it doesn't start with Mozilla, iPhone or Opera before you render the page...
It's a hard arena to play in.
Good luck.
Some are not recognized, because the UserAgent has been messed with or a new browser is being used. Such as Opera Mobile 9.5. To fix this you need to create a Browser (*.browser) file specifically for defining this. I had to do it for the new Mozilla based UserAgent that is being sent from Google.
I think you should use other DDR better than Microsoft Browser Capabilities. I´m using http://wurfl.sourceforge.net>WURFL, it is open source and maybe it is more extended and updated. There is other commercial DDRs like DeviceAtlas.
There is many some .net libraries but i´m using Marg.Wurfl. It allows to rendering web mobile page using wurfl capabilities.