I'm not sure we're not talking past each other. Let me make my case against
using device identity a bit more clear, and see if you don't agree.
Let's say we have a device, the iDroidMax, which has the nasty habit of the
screen cracking, if you perchance display a certain icon, an apple.
You're writing your code, you have heard about the bug. So you detect the
device. Let's consider three example detections:
* iDroidMax
* iDroidMax Rev0
* iDroidMax Rev0 Android 2.3
Take your pick -- or come up with your own detection. Decide now, and write
your code -- display a peach if it's this device.
Now, let's move into the future, and consider some events.
* The iDroidSuperMax comes out. It has the same bug.
* The iDroidMax Rev 1 comes out. It fixes the bug.
* The iDroidMax Rev 0 is updated to Android 2.3.1, which doesn't have the
bug, but Android 3.x builds don't have the fix until Android 3.0.1
Did you make the right choice? Of course not -- there is no right choice
with direct device detection. Not even if you have a crystal ball.
The problem is, keying things directly to device identity locks you in.
Now, consider a different world. In this one, you don't tie your workaround
(displaying a peach icon) to the device identity. Instead, you tie it to a
little database of characteristics. Let's call it iDroidMaxDamage. It
doesn't matter what we call it of course -- we could even call it iDroidMax,
since it's the defining characteristic of the device. But even with the name
being the same, the outcome is different.
The user starts your app, after one of the above events. If he's not run it
before, or the identity has changed in any detail, we figure it would be a
good time to check for an update to the database -- something we'd get
around to anyway.
Now, once the data makes it into the database, all your iDroidSuperMax users
are protected. And all your iDroidMax Rev 1 and iDroidMax Rev 0 Android
2.3.1 and 3.0.1 users get their nice apple icons like the documentation
says.
And everyone is happy.
So that's what I'm talking about not using device identity. Now, as for
bug/feature detection code -- that's a different story, a different benefit,
and a different cost. This is an area that has been well-explored by
various Javascript packages that work around various browser bugs and
incompatibilities. The big advantage of direct feature detection is that
it's automatic. Nobody needs to do the work to update every device on every
software or hardware upgrade, and if someone plops a custom build on there
that fixes the bug -- the bug is detected as fixed. Instantly.
So this is a real nice-to-have, because it makes it cheaper to maintain and
more accurate.
But it costs more to develop -- sometimes just a tiny cost -- like detecting
whether a method is present.
Other times, it's prohibitively expensive in one way or another. For
example, some tests could be security holes, or take too much time, or be
hard to develop.
And sometimes, it's impossible.
That may be what you meant by "you can make the whole thing much lighter".
If so -- you misread my intent. I was describing the overall flow, and where
this sort of thing should fit in. If we detect a camera, and assert the
device has a camera, then we assume it has a camera -- but we can override
that for a device that claims to have a camera, and has a camera -- but to
get to it, you have to take out the battery. Then, your model-based feature
derivation would override this detection, and assert the device does not
have a camera (perhaps with additional localizable explanatory text, if you
want to get fancy).
And then in the final step, you go on to assert that if it doesn't have a
camera, we set the LiveWebCamCapable attribute to false.
If "has a camera" is detected, you save on having every model's feature set
supply that information. Likewise, the basic characteristics of the camera.
You get all the benefits of using the native API to determine this
information, but you also get the benefit of additional information --
including corrections, missing information, etc.
Actually -- this also brings up a model issue. It's not just devices and
attributes -- but also resources. For example, a description of internal and
external SD-card memory capabilities would be helpful -- asking about SD
cards might give a list of SD descriptions: [{name=internal0,
removable=false, location=/sdcard}, {name=external1, removable=true,
location=/sdcard/1}, {name=external2, removable=true, location=/sdcard/2}].
Asking about cameras might give you front-and-rear, and point out the nice
flash is attached to the front-facing camera to blind yourself with, and not
helpful for taking that family photo.
But we can start with device attributes, and the core is the ones based on
model identity.
On Tue, Apr 26, 2011 at 9:00 PM, Brill Pappin <bpap...@sixgreen.com> wrote:
> I think with all the comments we have a good start to what it *should* be.
> I agree with you bob, that we don't want the API to work based on what the
> device is, but rather an "abstraction of fixes" so to speak.
>
> However, using the device identity could still work ok for this... we've
> been throwing around a locale-like method of finding the dataset for a
> specific problem.
> Although i understand the desire to test for a capability, I think that you
> can get enough detail on a specific implementation (including os build and
> carrier) that you can make the whole thing much lighter than if you were to
> run a bunch of test code.
>
> That not to say that you never want to... IMO we want to use whatever the
> best method is of determining a capability.
>
> Anyway, I certainly think there is room for discussion, and I think it
> should be assumed that prior to first release, we'll refactor the code over
> and over again :)
>
> - Brill Pappin
>
> --
> 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
