Re: [android-developers] Re: Mismatch in runtime layout selection based upon size/density
I'm not sure I am totally following you, but if you have two different layouts, one for smaller screens, and one for larger screens, then yes you probably want to have two resources, one with no qualifiers (for the smaller screens), and one with the appropriate screen size qualifier for the larger screens it is intended for. As a general rule, if you see a density qualifier being used with a layout, there is probably something wrong. Layouts are density independent -- that us why there are dp units and such for any sizes you use in the layout. As the most general case, there is really a continuous range of densities and screen sizes. We created the bins for each early on, to ease things for developers, but this is an arbitrary restriction. In fact in 3.2 we realized that the bins for screen sizes wasn't working, which is why we have dropped them in favor -swNNNdp and related configurations. This is actually easy for developers, because they had to deal with a pretty much continuous range of screen sizes anyway, we already have good tools for handling this (through layout managers), and now they can be much more explicit about the break-points where they want to switch between different layouts. The same situation nearly exists for density as well. You can run a device at any reasonable density you want, and applications will still work. There is not as clear a case for allowing this though -- it definitely causes more pain for developers who have a much harder time deciding how to create graphics, and there is not as much benefit for device manufacturers to have such freedom. However, even so, tvdpi was introduced in I think 3.2. It is an interesting density between mdpi and hdpi. It is certainly conceivable for other new densities to pop up in the future. So, that leaves us, with both screen size and screen density needing to be treated really as continuous ranges. For this to work, something must help applications turn a small discrete set of design points into supporting a range of values. For screen size, this is layout managers. For density, this is the automatic scaling of bitmap drawables and dp units. If you are using density configurations with layout resources, you have a fundamental issue because layouts can *not* be scaled to match the actual density. So what happens if you have a layout-hdpi and are now running on an xhdpi screen? We'll use the layout-hdpi resource because that is the best match, but there is no mechanism to know how to transform that into something appropriate for an xhdpi density. So the layout-hdpi is a break point where your layout changes in some fundamental way across different densities... but does that even make sense? If I have one device with a normal size mdpi screen, and another with a normal size hdpi screen (so they are the same size in my hand, just higher density screens), why would the layout be different between them? I should just see UI elements with finer details, not a different layout of those elements. On Thu, Feb 23, 2012 at 7:39 PM, William Ferguson william.ferguson...@gmail.com wrote: So Dianne, you're saying that if I only have a single configuration for a screen size that I might as well drop the density qualifier as it will have no impact, as the screen size will totally override the decision as to which resource is used, This means that if I want to implement the layouts I thought I have been supporting I will need 4 definitions of 2 layouts - default- layout_A_less_capabable_screens - large-mdpi - layout_A_less_capabable_screens (this config does not currently exist). - large-hdpi - layout_B_more_capabable_screens - xlarge- layout_B_more_capabable_screens Or if I want to implement the layouts I have actually been supporting, I can collapse this to - default - layout_A_less_capabable_screens - large- layout_B_more_capabable_screens William On Feb 24, 11:09 am, Dianne Hackborn hack...@android.com wrote: Keep in mind that all densities are a potential match, and screen size is considered a more significant match than density. So if there is the choice between resources with two different densities, but one has a better match for the screen size, the screen size will win. And I will say what I usually do -- I very strongly recommend mixing screen size and screen density qualifiers in the same configuration. These are two * orthogonal* axis. You will need to think very hard and long about the set of different screens that are going to match the qualifiers you have, and I think it most cases this is *not* what people are thinking. Usually people do this because they think they are more finely-tuning to try to design for a specific screen resolution, but that is not what this does. On Thu, Feb 23, 2012 at 1:48 PM, William Ferguson william.ferguson...@gmail.com wrote: Thanks for the review Mark. I didn't think I was
[android-developers] Re: Mismatch in runtime layout selection based upon size/density
Thanks Dianne, that's clarified quite a few things for me. I guess my disconnect was started by fact that the layout qualifiers allow for a density specifier. William On Feb 25, 6:49 am, Dianne Hackborn hack...@android.com wrote: I'm not sure I am totally following you, but if you have two different layouts, one for smaller screens, and one for larger screens, then yes you probably want to have two resources, one with no qualifiers (for the smaller screens), and one with the appropriate screen size qualifier for the larger screens it is intended for. As a general rule, if you see a density qualifier being used with a layout, there is probably something wrong. Layouts are density independent -- that us why there are dp units and such for any sizes you use in the layout. As the most general case, there is really a continuous range of densities and screen sizes. We created the bins for each early on, to ease things for developers, but this is an arbitrary restriction. In fact in 3.2 we realized that the bins for screen sizes wasn't working, which is why we have dropped them in favor -swNNNdp and related configurations. This is actually easy for developers, because they had to deal with a pretty much continuous range of screen sizes anyway, we already have good tools for handling this (through layout managers), and now they can be much more explicit about the break-points where they want to switch between different layouts. The same situation nearly exists for density as well. You can run a device at any reasonable density you want, and applications will still work. There is not as clear a case for allowing this though -- it definitely causes more pain for developers who have a much harder time deciding how to create graphics, and there is not as much benefit for device manufacturers to have such freedom. However, even so, tvdpi was introduced in I think 3.2. It is an interesting density between mdpi and hdpi. It is certainly conceivable for other new densities to pop up in the future. So, that leaves us, with both screen size and screen density needing to be treated really as continuous ranges. For this to work, something must help applications turn a small discrete set of design points into supporting a range of values. For screen size, this is layout managers. For density, this is the automatic scaling of bitmap drawables and dp units. If you are using density configurations with layout resources, you have a fundamental issue because layouts can *not* be scaled to match the actual density. So what happens if you have a layout-hdpi and are now running on an xhdpi screen? We'll use the layout-hdpi resource because that is the best match, but there is no mechanism to know how to transform that into something appropriate for an xhdpi density. So the layout-hdpi is a break point where your layout changes in some fundamental way across different densities... but does that even make sense? If I have one device with a normal size mdpi screen, and another with a normal size hdpi screen (so they are the same size in my hand, just higher density screens), why would the layout be different between them? I should just see UI elements with finer details, not a different layout of those elements. On Thu, Feb 23, 2012 at 7:39 PM, William Ferguson william.ferguson...@gmail.com wrote: So Dianne, you're saying that if I only have a single configuration for a screen size that I might as well drop the density qualifier as it will have no impact, as the screen size will totally override the decision as to which resource is used, This means that if I want to implement the layouts I thought I have been supporting I will need 4 definitions of 2 layouts - default - layout_A_less_capabable_screens - large-mdpi - layout_A_less_capabable_screens (this config does not currently exist). - large-hdpi - layout_B_more_capabable_screens - xlarge - layout_B_more_capabable_screens Or if I want to implement the layouts I have actually been supporting, I can collapse this to - default - layout_A_less_capabable_screens - large - layout_B_more_capabable_screens William On Feb 24, 11:09 am, Dianne Hackborn hack...@android.com wrote: Keep in mind that all densities are a potential match, and screen size is considered a more significant match than density. So if there is the choice between resources with two different densities, but one has a better match for the screen size, the screen size will win. And I will say what I usually do -- I very strongly recommend mixing screen size and screen density qualifiers in the same configuration. These are two * orthogonal* axis. You will need to think very hard and long about the set of different screens that are going to match the qualifiers you have, and I think it most cases this is *not* what people are thinking. Usually people
[android-developers] Re: Mismatch in runtime layout selection based upon size/density
Replying to the list: On Thu, Feb 23, 2012 at 2:54 AM, William Ferguson william.ferguson...@gmail.com wrote: you can download a very small project showing this behaviour from [REDACTED] Deploy it to a 2.2 (I haven't tested other Android Version but I expect the same) AVD with a resolution of WVGA800 (800*400) and default Abstracted LCD density of 160dpi (ie mdpi). The buttons will show the text for large hdpi. Well, I can reproduce the problem, on multiple Android emulator versions (including 4.0) and the original Galaxy Tab 7. In the sample you sent me, it pulls from res/layout-large-port-hdpi/ If I add a res/layout-large-port-mdpi/ directory, that gets used on a 4.0 emulator and the 2.2 emulator, but not the Tab 7. That's indicative of a bug in the Tab 7: http://stackoverflow.com/questions/7049659/understanding-samsung-galaxy-tab-screen-density In terms of why it pulls from res/layout-large-port-hdpi/ instead of res/layout-xlarge-port/ or res/layout-port/, I cannot say. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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
[android-developers] Re: Mismatch in runtime layout selection based upon size/density
Thanks for the review Mark. I didn't think I was going insane, just tearing my hair out. William On Feb 23, 11:15 pm, Mark Murphy mmur...@commonsware.com wrote: Replying to the list: On Thu, Feb 23, 2012 at 2:54 AM, William Ferguson william.ferguson...@gmail.com wrote: you can download a very small project showing this behaviour from [REDACTED] Deploy it to a 2.2 (I haven't tested other Android Version but I expect the same) AVD with a resolution of WVGA800 (800*400) and default Abstracted LCD density of 160dpi (ie mdpi). The buttons will show the text for large hdpi. Well, I can reproduce the problem, on multiple Android emulator versions (including 4.0) and the original Galaxy Tab 7. In the sample you sent me, it pulls from res/layout-large-port-hdpi/ If I add a res/layout-large-port-mdpi/ directory, that gets used on a 4.0 emulator and the 2.2 emulator, but not the Tab 7. That's indicative of a bug in the Tab 7: http://stackoverflow.com/questions/7049659/understanding-samsung-gala... In terms of why it pulls from res/layout-large-port-hdpi/ instead of res/layout-xlarge-port/ or res/layout-port/, I cannot say. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android Training...At Your Office:http://commonsware.com/training -- 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: Mismatch in runtime layout selection based upon size/density
On Thu, Feb 23, 2012 at 4:48 PM, William Ferguson william.ferguson...@gmail.com wrote: I didn't think I was going insane, just tearing my hair out. Speaking as a follically-challenged individual, I don't recommend tearing your hair out. :-) -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in DC: http://marakana.com/training/android/ -- 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: Mismatch in runtime layout selection based upon size/density
Keep in mind that all densities are a potential match, and screen size is considered a more significant match than density. So if there is the choice between resources with two different densities, but one has a better match for the screen size, the screen size will win. And I will say what I usually do -- I very strongly recommend mixing screen size and screen density qualifiers in the same configuration. These are two * orthogonal* axis. You will need to think very hard and long about the set of different screens that are going to match the qualifiers you have, and I think it most cases this is *not* what people are thinking. Usually people do this because they think they are more finely-tuning to try to design for a specific screen resolution, but that is not what this does. On Thu, Feb 23, 2012 at 1:48 PM, William Ferguson william.ferguson...@gmail.com wrote: Thanks for the review Mark. I didn't think I was going insane, just tearing my hair out. William On Feb 23, 11:15 pm, Mark Murphy mmur...@commonsware.com wrote: Replying to the list: On Thu, Feb 23, 2012 at 2:54 AM, William Ferguson william.ferguson...@gmail.com wrote: you can download a very small project showing this behaviour from [REDACTED] Deploy it to a 2.2 (I haven't tested other Android Version but I expect the same) AVD with a resolution of WVGA800 (800*400) and default Abstracted LCD density of 160dpi (ie mdpi). The buttons will show the text for large hdpi. Well, I can reproduce the problem, on multiple Android emulator versions (including 4.0) and the original Galaxy Tab 7. In the sample you sent me, it pulls from res/layout-large-port-hdpi/ If I add a res/layout-large-port-mdpi/ directory, that gets used on a 4.0 emulator and the 2.2 emulator, but not the Tab 7. That's indicative of a bug in the Tab 7: http://stackoverflow.com/questions/7049659/understanding-samsung-gala... In terms of why it pulls from res/layout-large-port-hdpi/ instead of res/layout-xlarge-port/ or res/layout-port/, I cannot say. -- Mark Murphy (a Commons Guy)http://commonsware.com| http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android Training...At Your Office:http://commonsware.com/training -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Mismatch in runtime layout selection based upon size/density
So Dianne, you're saying that if I only have a single configuration for a screen size that I might as well drop the density qualifier as it will have no impact, as the screen size will totally override the decision as to which resource is used, This means that if I want to implement the layouts I thought I have been supporting I will need 4 definitions of 2 layouts - default- layout_A_less_capabable_screens - large-mdpi - layout_A_less_capabable_screens (this config does not currently exist). - large-hdpi - layout_B_more_capabable_screens - xlarge- layout_B_more_capabable_screens Or if I want to implement the layouts I have actually been supporting, I can collapse this to - default - layout_A_less_capabable_screens - large- layout_B_more_capabable_screens William On Feb 24, 11:09 am, Dianne Hackborn hack...@android.com wrote: Keep in mind that all densities are a potential match, and screen size is considered a more significant match than density. So if there is the choice between resources with two different densities, but one has a better match for the screen size, the screen size will win. And I will say what I usually do -- I very strongly recommend mixing screen size and screen density qualifiers in the same configuration. These are two * orthogonal* axis. You will need to think very hard and long about the set of different screens that are going to match the qualifiers you have, and I think it most cases this is *not* what people are thinking. Usually people do this because they think they are more finely-tuning to try to design for a specific screen resolution, but that is not what this does. On Thu, Feb 23, 2012 at 1:48 PM, William Ferguson william.ferguson...@gmail.com wrote: Thanks for the review Mark. I didn't think I was going insane, just tearing my hair out. William On Feb 23, 11:15 pm, Mark Murphy mmur...@commonsware.com wrote: Replying to the list: On Thu, Feb 23, 2012 at 2:54 AM, William Ferguson william.ferguson...@gmail.com wrote: you can download a very small project showing this behaviour from [REDACTED] Deploy it to a 2.2 (I haven't tested other Android Version but I expect the same) AVD with a resolution of WVGA800 (800*400) and default Abstracted LCD density of 160dpi (ie mdpi). The buttons will show the text for large hdpi. Well, I can reproduce the problem, on multiple Android emulator versions (including 4.0) and the original Galaxy Tab 7. In the sample you sent me, it pulls from res/layout-large-port-hdpi/ If I add a res/layout-large-port-mdpi/ directory, that gets used on a 4.0 emulator and the 2.2 emulator, but not the Tab 7. That's indicative of a bug in the Tab 7: http://stackoverflow.com/questions/7049659/understanding-samsung-gala... In terms of why it pulls from res/layout-large-port-hdpi/ instead of res/layout-xlarge-port/ or res/layout-port/, I cannot say. -- Mark Murphy (a Commons Guy)http://commonsware.com| http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android Training...At Your Office:http://commonsware.com/training -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Mismatch in runtime layout selection based upon size/density
Hi William, I will suggest you to use layout weight/ weight sum ( basically instead if giving dip value, give in percentage) Moktarul Anam On Feb 22, 7:08 am, William Ferguson william.ferguson...@gmail.com wrote: I am trying to work out why a device (in this case an AVD) that is 800*400 and mdpi is selecting a layout that is large-hdpi. There are only 2 layout options for the app, the default and large- hdpi. I can conceivably see how the device could be considered large - large screens are at least 640dp x 480dp (fromhttp://developer.android.com/guide/practices/screens_support.html#range) even though it's not quite there is one dimension. But it's only 160dpi, so certainly not hdpi (ie approx 240dpi). I had always thought that in order to match a resource qualifier (including layout) you need to at least match all items. So I expected this to fail to match based on density. Is my understanding incorrect? Is it actually trying to do a nearest match or best fit and is determining that large-hdpi is the closest fit for large-mdpi? It's almost like it has ignored density altogether when choosing the layout. Is there a way to programatically determine which resource selectors have been used to choose layout? William -- 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
[android-developers] Re: Mismatch in runtime layout selection based upon size/density
Hi Moktarul, thanks for the input but this isn't about attempting to scale particular images or views. This is about attempting to choose an appropriate layout for the device. Ie on devices that have enough room to fit more fields (eg tablets) I display extra fields. What I'm struggling with is how the decision on which resource qualified layout is chosen. In particular why an 800*400 160dpi device is considered large-hdpi William On Feb 22, 9:35 pm, moktarul anam mokta...@gmail.com wrote: Hi William, I will suggest you to use layout weight/ weight sum ( basically instead if giving dip value, give in percentage) Moktarul Anam On Feb 22, 7:08 am, William Ferguson william.ferguson...@gmail.com wrote: I am trying to work out why a device (in this case an AVD) that is 800*400 and mdpi is selecting a layout that is large-hdpi. There are only 2 layout options for the app, the default and large- hdpi. I can conceivably see how the device could be considered large - large screens are at least 640dp x 480dp (fromhttp://developer.android.com/guide/practices/screens_support.html#range) even though it's not quite there is one dimension. But it's only 160dpi, so certainly not hdpi (ie approx 240dpi). I had always thought that in order to match a resource qualifier (including layout) you need to at least match all items. So I expected this to fail to match based on density. Is my understanding incorrect? Is it actually trying to do a nearest match or best fit and is determining that large-hdpi is the closest fit for large-mdpi? It's almost like it has ignored density altogether when choosing the layout. Is there a way to programatically determine which resource selectors have been used to choose layout? William -- 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: Mismatch in runtime layout selection based upon size/density
If you create a sample project that can demonstrate the problem, I'd like to take a peek at it. On Wed, Feb 22, 2012 at 6:44 PM, William Ferguson william.ferguson...@gmail.com wrote: Hi Moktarul, thanks for the input but this isn't about attempting to scale particular images or views. This is about attempting to choose an appropriate layout for the device. Ie on devices that have enough room to fit more fields (eg tablets) I display extra fields. What I'm struggling with is how the decision on which resource qualified layout is chosen. In particular why an 800*400 160dpi device is considered large-hdpi William On Feb 22, 9:35 pm, moktarul anam mokta...@gmail.com wrote: Hi William, I will suggest you to use layout weight/ weight sum ( basically instead if giving dip value, give in percentage) Moktarul Anam On Feb 22, 7:08 am, William Ferguson william.ferguson...@gmail.com wrote: I am trying to work out why a device (in this case an AVD) that is 800*400 and mdpi is selecting a layout that is large-hdpi. There are only 2 layout options for the app, the default and large- hdpi. I can conceivably see how the device could be considered large - large screens are at least 640dp x 480dp (fromhttp://developer.android.com/guide/practices/screens_support.html#range) even though it's not quite there is one dimension. But it's only 160dpi, so certainly not hdpi (ie approx 240dpi). I had always thought that in order to match a resource qualifier (including layout) you need to at least match all items. So I expected this to fail to match based on density. Is my understanding incorrect? Is it actually trying to do a nearest match or best fit and is determining that large-hdpi is the closest fit for large-mdpi? It's almost like it has ignored density altogether when choosing the layout. Is there a way to programatically determine which resource selectors have been used to choose layout? William -- 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 -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- 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
[android-developers] Re: Mismatch in runtime layout selection based upon size/density
Thanks Mark, I'll put something together tonight. On Feb 23, 10:07 am, Mark Murphy mmur...@commonsware.com wrote: If you create a sample project that can demonstrate the problem, I'd like to take a peek at it. On Wed, Feb 22, 2012 at 6:44 PM, William Ferguson william.ferguson...@gmail.com wrote: Hi Moktarul, thanks for the input but this isn't about attempting to scale particular images or views. This is about attempting to choose an appropriate layout for the device. Ie on devices that have enough room to fit more fields (eg tablets) I display extra fields. What I'm struggling with is how the decision on which resource qualified layout is chosen. In particular why an 800*400 160dpi device is considered large-hdpi William On Feb 22, 9:35 pm, moktarul anam mokta...@gmail.com wrote: Hi William, I will suggest you to use layout weight/ weight sum ( basically instead if giving dip value, give in percentage) Moktarul Anam On Feb 22, 7:08 am, William Ferguson william.ferguson...@gmail.com wrote: I am trying to work out why a device (in this case an AVD) that is 800*400 and mdpi is selecting a layout that is large-hdpi. There are only 2 layout options for the app, the default and large- hdpi. I can conceivably see how the device could be considered large - large screens are at least 640dp x 480dp (fromhttp://developer.android.com/guide/practices/screens_support.html#range) even though it's not quite there is one dimension. But it's only 160dpi, so certainly not hdpi (ie approx 240dpi). I had always thought that in order to match a resource qualifier (including layout) you need to at least match all items. So I expected this to fail to match based on density. Is my understanding incorrect? Is it actually trying to do a nearest match or best fit and is determining that large-hdpi is the closest fit for large-mdpi? It's almost like it has ignored density altogether when choosing the layout. Is there a way to programatically determine which resource selectors have been used to choose layout? William -- 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 -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android Training in NYC:http://marakana.com/training/android/ -- 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
