Re: [android-developers] Re: Fragmentation-resistant product design
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 android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Fragmentation-resistant product design
(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
> system APIs. Neither would be want to put in model-specific if-else
> clauses at different places in the application. How can we stand on
> middle-ground here?
>
> Bob, can you please elaborate on your method? How can a system of
> rules be designed so as to capture differences in EXIF timestamps that
> I mentioned?
Well, abstracting APIs is sort of a different-but-related issue. The big
advantage of abstracting the API is that it lets you handle all of the
conditionalization in a single place, rather than throughout your code. If
the system API in question is defined as an interface, this can be done as a
fairly simple proxy object that delegates to the standard system object,
with whatever workarounds on specific methods. I have a methodology for
doing that:
You make your proxy object's InvocationHandler take two values:
1) the base system object, that implements the interface.
2) an override object, that also contains the base system object, and
defines any methods you want to override.
The InvocationHandler uses reflection to determine whether the override
object defines the method -- if so, it invokes that one, which may delegate
to the base object as well. Otherwise, it invokes the base object.
You only have to define this InvocationHandler class once, and use it for
every object you want to abstract, and you can implement caching of the
lookup, so it can be as efficient as any reflection-based operation.
This is very similar to how I do mock objects -- a topic for another day.
Now, as for the rules, the easiest way would be a simple (but fictional)
example:
UTC
America/Los_Angeles
LOCAL
UTC
LOCAL
When you build your app, you download and include the current version of
this database.
When you start the app the first time, and periodically thereafter, you try
to update it. You can cache the results and discard any that aren't relevant
to this device -- you can also include the relevant information in the query
and reduce how much has to be sent to the device. (Of course, this requires
internet permission, but it's an optional feature. There could also be a
service app that publishes this information to other applications).
You process each rule in reverse order; if the attributes match the values
in android.os.Build and Build.VERSION, set those attributes in a
Map.
Then look it up via Platform.getAttribute("exif-timezone", TimeZone.class)
-- the TimeZone.class indicates that you want a TimeZone value; there'd be a
set of available conversions. Or perhaps converter objects, e.g.
public class Platform {
...
public static Converter TYPE_STRING = new StringConverter();
public static Converter TYPE_INTEGER = new IntegerConverter();
public static Converter TYPE_TIMEZONE = new
TimeZoneConverter();
...
/**
* Obtain a platform attribute in the desired form.
*/
public static T getAttribute(String name, Converter converter) {
... }
/**
* The abstraction interface I mentioned earlier.
*/
public static T customize(Class iface, IMPL
baseObject, Object override) {
if (override instanceof OverrideHandler) {
((OverrideHandler)override).setBaseObject(baseObject);
}
return Proxy.newProxyInstance(iface.getClassLoader(), new Class[] {
iface }, new OverrideInvocationHandler(baseObject, override));
}
}
(This makes it extensible -- you can store things like base64-encoded
images, young children, or small planetoids).
Unfortunately, ExifInterface *IS* *NOT* *AN* *INTERFACE* -- boo hiss! -- so
you can't use my Platform.customize method. (I have built systems that would
automatically construct a suitable class using byte-code generation, but
that won't work on Android). However, since ExifInterface is not declared
final, and is directly constructed by the programmer, we can subclass it
instead:
public class ExifReader extends ExifInterface {
public ExifReader(String filename) { super(filename); }
public static final String ATTR_EXIF_TIMEZONE = "exif-timezone";
@Override
public String getAttribute(String tag) {
if (TAG_DATETIME.equals(tag)) {
TimeZone tz = Platform.getAttribute(ATTR_EXIF_TIMEZONE,
TYPE_TIMEZONE);
return parseAndFixTime(super.getAttribute(tag), tz);
}
return super.getAttribute(tag);
}
}
Unfortunately -- this still isn't quite right for this application --
because this assumes it's the current platform that took the pictures. Image
files can be moved from device to device. So skipping a few more details in
our Platform class, what we really want to do is:
public
Re: [android-developers] Re: Fragmentation-resistant product design
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 to proceed, and fully expect it to change. -- 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
Re: [android-developers] Re: Fragmentation-resistant product design
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 to limit it to > defect detection, and I think it somewhat biases the model. > > -- 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
Re: [android-developers] Re: Fragmentation-resistant product design
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 limit it to defect detection, and I think it somewhat biases the model. I think it's better to think of it as device attributes, which can include defects, but can also include corrected screen dimensions, camera color model information, actual measured optical resolution, accelerometer sensitivity and noise floors, icons that match the icons on the buttons on the device to plug into your help text... Defects are the place to start, though -- the most bang for the buck. On Wed, Apr 27, 2011 at 8:07 PM, Brill Pappin wrote: > 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 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
Re: [android-developers] Re: Fragmentation-resistant product design
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 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 ba
Re: [android-developers] Re: Fragmentation-resistant product design
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 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
Re: [android-developers] Re: Fragmentation-resistant product design
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
Re: [android-developers] Re: Fragmentation-resistant product design
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 wrote: > On Mon, Apr 25, 2011 at 12:12 PM, Brill Pappin > 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
Re: [android-developers] Re: Fragmentation-resistant product design
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 stuff, but its actually got the wrong values for the basic dimensions that those values are based on. Anyway, when we get this stuff up, i'll post to the list and see if anyone wants to participate. - 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
Re: [android-developers] Re: Fragmentation-resistant product design
On Mon, Apr 25, 2011 at 2:29 PM, Brill Pappin 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 of > capability. Quoting you from earlier in this thread: > In our case were noticed that some phones do not properly report their > resolutions etc. Your goal should be "find out the right resolution" (a capability). You don't need a library to find out what the device is -- that's handled by the Build class. Perhaps you're just using terminology in ways that I'm not expecting, or vice versa. This exchange has the hallmarks of "talking past each other"... :-) -- 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
Re: [android-developers] Re: Fragmentation-resistant product design
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 use reflection, device type, etc. It seems to me that knowing the device gives you a pretty good indication of capability. Maybe "capability" becomes a 3rd component. However, we can work that out as we go. -- 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
Re: [android-developers] Re: Fragmentation-resistant product design
On Mon, Apr 25, 2011 at 1:12 PM, Brill Pappin 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 suggest "detect a capability", not "detect a device". -- 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
Re: [android-developers] Re: Fragmentation-resistant product design
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 can still be used to detect that specific device. So far we think we want to separate it out into two main components; detection and action. 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. Anyway, we've agreed among ourselves to get it set up so the community can participate... it'll take us a few days though to extract what we have and clean it up for a public codebase. >From there we can invite people and start refactoring to make it more robust (we'll put it up on Google Code). - 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
Re: [android-developers] Re: Fragmentation-resistant product design
On Mon, Apr 25, 2011 at 12:12 PM, Brill Pappin 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
