The main issues or concerns with device repositories are 1) the time and resources required for maintaining the repository accurate and useful over time, and 2) fragmentation (a favorite topic in mobility).
When developing a product, you either marry to a specific solution, or try to abstract it (using your own abstraction) which kind of defeats the purpose. The right answer is to have *one* standard abstraction, all all device repositories implement such abstraction. All device repository players should get together and solve this *very, very common* problem related to device characteristics that all mobile web developers must deal with every time; I am looking forward to that day. Once the abstraction is defined, let the best implementation win; i.e. this is the implementation that solves the issue of keeping their content accurate and useful long-term….
What matters is that the DB is accurate over time. It doesn’t matter if it is automatically updated by having the handset propagate its characteristics (like MobileZoo does by instrumenting code), or by *manually* entering the information. Of course, automating the process is a good thing. But the most accurate DB will be the one that humans themselves tweak; the developer community and handset manufacturers, and everyone how deals with handsets.
There are levels of device information to track: minimum such as display size, image formats, other formats (useful for mobile web applications), then there is additional information such as supported APIs, RAM, storage, etc. (useful for local applications). Both must be addressed.
Related to this see:
ceo