I think we need to think of it as having several phases:
- Feature detection. That is, directly determining specific capabilities,
anti-capabilities, bugs, and other data that you may need to consider in a
program.
- Model detection -- determining one or more matching devices (i.e. HTC,
HTC Nexus 1, HTC Nexus One running 2.3.3, etc.). These form an ordered set.
- Model feature derivation -- determining from a database a set of
features that cannot be directly detected (or for which the usual feature
detection may not yield the correct result).
- This might include model-specific feature detection as well.
- Feature derivation -- defaulting, facts derived from other facts
The end result would be a set of facts about the device. The program would
not care just how these facts were determined -- from the model, or from
code that detects specific bugs, etc.
I would say that the specific model information should not be exposed in the
end API -- that if you have a model-specific bug or capability, you add that
into the database. We've seen all too many cases of bugs (or features) which
start out in one model, and then turn up in a later model by that same
manufacturer. And we'd also need to manage the possibility that after a
certain point, that bug may be fixed. You can't do that if you key things
off the specific model in your code, so we shouldn't enable that coding
behavior.
On Mon, Apr 25, 2011 at 9:25 AM, Mark Murphy <mmur...@commonsware.com>wrote:
> On Mon, Apr 25, 2011 at 12:12 PM, Brill Pappin <bpap...@sixgreen.com>
> wrote:
> > We have had the same issue with several devices. In our case were noticed
> > that some phones do not properly report their resolutions etc.
> > Until now we have stridently avoided doing specific device detection in
> our
> > apps, but it has now become necessary to do so.
> > We have been thinking of publishing an open source library to handle
> these
> > cases so we can keep the code separate from the application code and can
> do
> > detection/reporting if and when a manufacturer fixes their system.
> > We're thinking that we'll get a better library and cover more devices is
> we
> > share the library with all of you, which serves all our interests.
> > Is anyone else interested in participating in a library like this?
>
> I have long assumed that eventually we'd need to set up the Android
> equivalent of "browser caps"-style databases, to detect varying
> capabilities of devices that are beyond the SDK.
>
> If you're going to collect data, I recommend that you aim to be a bit
> open-ended about what's getting collected -- IOW, don't just limit it
> to screen size/density/resolution stuff. It may be that we can
> leverage this project for other device discrepancies, such as "Is it
> really a phone?" (e.g., Samsung Galaxy Tab not supporting telephony
> stuff despite passing android.hardware.telephony).
>
> If you create a project to collect the data (FluidInfo database?), I
> promise to contribute data from my fleet of devices. Or, at least the
> devices that still work. :-)
>
> --
> Mark Murphy (a Commons Guy)
> http://commonsware.com | http://github.com/commonsguy
> http://commonsware.com/blog | http://twitter.com/commonsguy
>
> Android Training in London: http://bit.ly/smand1, http://bit.ly/smand2
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
