 |
|
 |
Could you tell me please how can I get the whole list of user agent in the combobox? I use the RedCircleWebForm.
Thanks a lot!
|
|
|
|
 |
|
 |
Hi,
I have not touched this technology for some time now, but from memory, it has a simple object model and WURFL has good documentation. I'm sure you will be able to work through it.
Regards,
Nic
EDIT: The browser user-agents are kept in an XML file. If the API does not give you what you want, you can query and build your lisrt from the XML file directly...
|
|
|
|
 |
|
 |
Great article! Thanks a lot!
Unfortunately RedCircle is closed down..
|
|
|
|
 |
|
 |
Thanks for the info on RedCircle...
|
|
|
|
 |
|
 |
My organisation, 51degrees.co.uk, has released an open source .NET Mobile API at www.51degrees.co.uk. The API takes WURFL data and integrates it into the .NET framework. We've focused on performance in the design and a performance test page is included in the demonstration project. It may be useful to readers of this article.
|
|
|
|
 |
|
|
 |
|
 |
Hi Amimpat,
Thanks for the headsup.
Nic
|
|
|
|
 |
|
 |
Hi, Nic.
New Official WURFL .NET API is under development. If you want more info, check WURFLDotNetAPI group[^]. It is a direct port of Java NG API.
The SVN repository seems to be closed, but I can send you a snapshot if you want.
Other API, but outdated, is my personal implementation: Somms.NWURFL[^]. It was a try of abstracting search logic from data access. I'm working on a new version, with heuristic and browserCaps mapping.
Julio.
|
|
|
|
 |
|
 |
Hi Julio,
> check WURFLDotNetAPI group
I joined the group.
I checked out another implementation (not Somms.NWURFL) which was a direct port of the JavaApi and it was "flakey as". I hope this one has more momentum...
> I'm working on a new version
I think it will be important to factor in a decent caching model where the WURFL tree (or a whitelisted subset of it) can the loaded into application scope, and quicker calls made for user-agent specific methods.
Nice to touch base, keep up the good work.
Regards,
Nic
|
|
|
|
 |
|
 |
Hey Nic,
The .net wurfl API is not a direct port of the latest java api.
For an .NET version of the latest java api (including the LD string comparison), check out:
http://www.5thfinger.com.au/corporate2/wurflApi.asp
Also, there's a web application the company i work for has recently released that provides an http web service to return the device data. It's available at http://www.mobileelements.com and its built on our custom useragent matching technology.
If you'd like to contact me privately, i'd be happy to set you up an account so that you can add it to your list of api's to test.
I also built out a test harness that was intended to test accuracy instead of speed, that i'd like to share with you for feedback, and maybe inclusion in the article.
Regards,
Gene
|
|
|
|
 |
|
 |
Hi Gene,
> For an .NET version of the latest java api
I'll check it out...
> the company i work for has recently released
I had been looking at MobileElements prior to your post; it has been mentioned at the wmlprogramming group.
> so that you can add it to your list of api's to test
It uses a different method than the other implementations (it's a webservice, right) and is not conducive to the same test regime. However, I must say the capabilities look compelling.
> maybe inclusion in the article
Appreciate the support; I am now looking at developing an article on Caching and Sharing WURFL.
Thanks,
Nic
|
|
|
|
 |
|
 |
Have you had a look at Device Atlas? If so, how does it compare to the other Wurfl implementations?
|
|
|
|
 |
|
 |
I have not done a formal comparison (no metrics); were not aware of it until your message.
Reflections after a cursory look:
- JSON is used instead of XML - may parse faster; lacks a schema.
- The property set has quite a lot of differences - Java concentrates on JSR support (DA); J2ME list is more granular (WURFL).
- DA is commercial - even their free cut down version is only for a year; WURFL is open-source.
DA givers its own comparison here http://deviceatlas.com/node/1096285[^].
A lot depends on your needs and biases...
modified on Thursday, January 22, 2009 12:03 AM
|
|
|
|
 |
|
 |
Hi Nic,
First off, I work for dotMobi and am the lead developer of the DeviceAtlas API, that's the disclaimer out of the way.
I wanted to fill you in on the facts re DeviceAtlas. I don't want to go into a hard sell but rather to encourage you to do some impartial testing of our API vs WURFL, we had one user on the mobiForge.com forums who did one last year that generated some healthy debate around the two systems however his tests were with the Java API, and the old one at that
We have recently released v2.3 of our API as a Beta and hope to have it thouroughly tested and released officially in the next month or so. I'd encourage you to download it and try it out, http://deviceatlas.com/downloads/beta.
(Yes, you do need to register to download Your membership is shared with all our sites by the way, I'm sure you'd be a valued contributor at mobiForge)
The download comes with a sample data file that you can use for your tests. The data in the sample file was generated in late January so should be relatively up to date. It is a new format that will become official when the API does as it includes data about UA Profile headers and allows you to add these to your API queries. We have found this greatly improves the accuracy of your queries, especially when the device uses a generic UA like many Windows Mobile devices and Blackberrys.
A few general points to note:
1. The developer licence available on our site is FREE and valid for only one year but is NOT limited in any way. The data you get and the API you download are exactly what you get with a paid licence. We just trust you to be honest and buy a licence if you use DeviceAtlas commercially.
2. The number of properties we have is smaller than WURFL, however we have chosen the set of properties we offer carefully based on user feedback to:
a) Not bloat the data with properties that you don't need and mostly have no data for
b) Offer the properties that developers tell us are important.
We regularly add new properties that are requested by our users. If we don't have a good data source for them we create tests on our test suite at deviceatlas.mobi (Also ta-da.mobi). Every person that visits deviceatlas.mobi with a mobile phone completes a set of tests that help us gather data about their device.
3. Our data is distributed as a JSON file for a few reasons:
a) Speed, it parses very quickly.
b) Size, the data file is much smaller than it would be if we used XML and as a result improves the speed.
c) Layout, our data is structured in a special tree structure allowing it to be searched very efficiently without the need for regular expressions. There is no need for developers to look into or even understand the data structure, that's what the API is for
4. We have numerous data sources. The most powerful of which is our test suite, deviceatlas.mobi, which I have already mentioned. Users are also able to manually submit data via our web interface. Other sources include WURFL itself, data from numerous operators and manufacturers and other valueable partners such as Volantis. What we try to do with DA is pull all of these sources together and distill the data such that we get the best and most accurate dataset. Each source has gradings based on our confidence in their data and as such conflicts are resolved based on this. These weightings constantly change as we reassess our sources and compare their data to the data we receive elsewhere.
So there you go, DeviceAtlas in a very big nutshell
One of the new features we're particularly happy about with the new .NET API, and one I'd REALLY appreciate your feedback on, is the IIS module that is now part of the new API. It plugs into any ASP.NET app and suppliments the existing Request.Browser object with the up-to-date data from DeviceAtlas.
Feel free to contact me if you have any questions
|
|
|
|
 |
|
 |
Hi Adrian,
Thanks for the feedback.
> encourage you to do some impartial testing of our API vs WURFL
When I undertook the article, I just wanted to share some of the findings that I encountered when doing my own research. The article is about WURFL implimentations; so it would be out of context to discuss APIs other than WURFL. It certainly is a good enough topic for another article but I cannot commit to that at this point in time.
Some brief feedback on what you have mentioned:
1. > developer licence available on our site is FREE and valid for only one year but is NOT limited in any way - I prefer open-source, or at least free without limits.
2. > The number of properties we have is smaller than WURFL - that is fine for web development if you have the crucial ones.
3. > data is distributed as a JSON file - I like JSON.
4. > We have numerous data sources - the source, relevance, and continual maintenace of the data are decisions the customer will have to make a decision on.
> It plugs into any ASP.NET app and suppliments the existing Request.Browser object
This mechanism is used in WURFL.Marg as well.
Thanks again.
Regards,
Nic
|
|
|
|
 |
|
 |
Hi Nic,
No problem. As you say a comparison of the 2 is out of context for this article. If you are interested in comparing the 2 as the subject of a new article at any time please feel free to contact me for any help or information. (Also we may ask your permission to re-publish the article.)
Obviously you prefer Open Source Who doesn't prefer something free over something you have to pay for, count me amongst that number too. That said DeviceAtlas tries to cater to the whole web developer market from individual developers doing small websites right up to large systems integrators working on massive enterprise level websites.
The support contracts we offer our enterprise customers are an important differentiating factor between ourselves and WURFL, as I believe is the case with most OS software. The need for a strong SLA, as you say, is down to the developer and the project requirements, but it's always interesting to know how we compare "down on the track".
Looking forward to hearing more on the subject.
- Adrian
|
|
|
|
 |
|
 |
Thanks a lot for this project, it really helped me to understand how WURFL was implemented in .Net and helped me to decide wich implementation to go for (RedCircle)
-------------------
---- DFX ----
-------------------
-------------------
|
|
|
|
 |
|
 |
You're welcome DFX.
The person who wrote the RedCircle implementation (Paulo Gomes) has his own software company in Brazil (brauksoftware.com) now; but he answers email sent to the address at the RedCircle article.
Nic
|
|
|
|
 |
|
 |
Hi, thanks for the info!. In your article you mention a fairly simple way to reload objects when wurfl.xml or any of the other data files gets updated using System.Web.Caching, can you share how you do that? I've been unable to find a simple way
-------------------
---- DFX ----
-------------------
-------------------
|
|
|
|
 |
|
 |
> can you share how you do that?
I was thinking of doing another article on it but outlining won't detract anything from it.
Look into Cache.Insert or Cache.Add; specifically the CacheItemRemovedCallback parameter.
There are practicle examples out there (google it) that outline the whole process.
Regards,
Nic
|
|
|
|
 |
|
 |
Hi,
I finally published the article on caching WURFL (www.codeproject.com/KB/aspnet/WURFL_AbstractCacheShare.aspx). It wraps WURFL.Marg but with a little retooling can wrap the other implementations as well.
UPDATE (2009-02-08): I have temporarily pulled the project while I check out a few new contenders...
UPDATE (2009-02-09): The article is up again. Stuck with marg as other solution was in beta.
Regards,
Nic
modified on Sunday, February 8, 2009 7:43 PM
|
|
|
|
 |