Thanks a lot Bob for your time :)
--
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
This doesn't help the present issue, but may be of interest to some:
I posted about this on the IPTC Yahoo group, and got this helpful response:
http://tech.groups.yahoo.com/group/iptc-photometadata/message/145
Basically, it has been addressed in XMP by extending the DateTime
attribute's
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
Thanks; I was seriously considering starting something, but won't have time
for a few days, so I'm glad you dove in. I'd be pleased if you added me to
the project.
I do have one little quibble -- 'defect'. While detecting defects is perhaps
the most important use case, I don't think we want to
So coming back to my question, any advice on design for now?
The android developers blog suggests abstracting APIs like the
Contacts API. But it is not practical to go around abstracting all
system APIs. Neither would be want to put in model-specific if-else
clauses at different places in the
Not sure I can change the project name at the point short of setting up a
new one :)
- Brill Pappin
On Thursday, April 28, 2011 3:55:22 AM UTC-4, Bob Kerns wrote:
I do have one little quibble -- 'defect'. While detecting defects is
perhaps the most important use case, I don't think we want
I've copied your post to to a Wiki page in the project re design patterns so
we don't drop it (we should maybe talk other discussion out of the group).
I'm going to upload some simply code that we use in one of our keyboards. We
know it is not correct, but it will give us the kernel from which
(See below)
On Tue, Apr 26, 2011 at 11:40 PM, Vikram Bodicherla
vikram.bodiche...@mchron.com wrote:
So coming back to my question, any advice on design for now?
The android developers blog suggests abstracting APIs like the
Contacts API. But it is not practical to go around abstracting all
project created.
http://code.google.com/p/aosddl/
i haven't sent any code up yet (not that there is much to send up) but will
do so shortly.
Those that wish to participate, please make yourself know to the project :)
- Brill
--
You received this message because you are subscribed to the
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.
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
This makes me want to scream. EXIF has got to be one of the worst standards
out there in common use; this is just one of the many major problems.
You'll find that virtually nothing handles EXIF well, so you'll be in good
company.
I checked the original Japanese standard, in hopes that there
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
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,
Oh i'd agree. The more info we have the better.
i've been discussing this with my partner and we are a bit worried about
including too much complexity.
For instance we're thinking that if a device requires a device specific
complex action, then its outside the scope of the lib, however the lib
On Mon, Apr 25, 2011 at 1:12 PM, Brill Pappin bpap...@sixgreen.com wrote:
For instance, detection would allow you to accurately detect a device, where
as the action component would allow you to properly adjust font sizes (as an
example) which is what we've been interested in initially.
I would
We can certainly discuss how that might be done.
What I'm interested in most is detecting and handling devices that are
broken, but I can see why you might want to detect capability.
However the distinction is mainly based on how you do that detection. i.e.
to simply detect capability, you can
On Mon, Apr 25, 2011 at 2:29 PM, Brill Pappin bpap...@sixgreen.com wrote:
However the distinction is mainly based on how you do that detection. i.e.
to simply detect capability, you can use reflection, device type, etc. It
seems to me that knowing the device gives you a pretty good indication
Yes, I think I'd agree :)
and your right, what we're really interested in is the actual values.
We noticed that the Motorola Atrix reports the wrong stuff, but not only
that, my partner did some manual calculations on screen size/density and
discovered that not only is it reporting the wrong
This is exactly the kind of stuff why people scream about
fragmentation. It's OK that devices are different, but they should be
determinably different.
I think this is where Google needs to step in and revoke the license
of the non-open source stuff until device firmwares are fixed and
updated
I hear that they are going to crack down on that a little... and frankly i
can't wait to be able to depend on the values I'm given :)
I haven't actually done those checks myself, I'm relaying on what my partner
was saying.
As I understand, it looks like they made the resolution of the Atrix
The Atrix definetely fits into the XHDPI bucket...
On Apr 26, 11:15 am, Brill Pappin bpap...@sixgreen.com wrote:
I hear that they are going to crack down on that a little... and frankly i
can't wait to be able to depend on the values I'm given :)
I haven't actually done those checks myself,
22 matches
Mail list logo
