Re: [android-developers] Re: Resource Alias not resolving
Hi Mark, I had the very same issues this day and did exactly what you proposed. The problem now was, that it is not possible to decode the alias via BitmapFactory.decodeResource(). The only workaround seems to be: ((BitmapDrawable) getResources().getDrawable(_resId)).getBitmap() But I need to load them in RGB565 format because they are quite large and they don't need to have alpha... Do you know any way out of this dead end? Thanks in advance, Max Herberger - MAGIX AG Am Sonntag, 4. Juli 2010 13:53:34 UTC+2 schrieb Mark Murphy: On Sun, Jul 4, 2010 at 7:31 AM, Tom Gibara m...@tomgibara.com wrote: This is what I'm not clear on: suppose you have a UI design that calls for an ImageButton that fills approximately half the screen. The geometry is easily defined by combining layout_weight and fill_parent etc. The image displayed in the ImageButton will cover approximately the same number of pixels on say both the Dell Streak and the Nexus One. So how do we organize our resources such that both of these phones will choose the same image resource for the button, while at the same providing a smaller image for devices such as the G1 (ie. a device that has far fewer pixels, but the roughly same screen size as the Nexus One)? To get more concrete, and to roll this discussion back to Mr. Lebed's original questions, let's suppose you have one square icon, 250 pixels to a side, that you want to use on WVGA screens, and another square icon, 100 pixels to a side, you would like to use on HVGA screens. And, these logically are the same icon, so you want your layouts and Java code and whatever to refer to them as the same name. If so, by eyeball (i.e., haven't slung the code for this specific scenario), the following should work: Step #1: Put the 250px icon in res/drawable/ as icon_250px.png Step #2: Put the 100px icon in res/drawable/ as icon.png Step #3: Put a resource alias in res/drawable-large-mdpi/ as icon.xml, pointing to icon_250px.png (note to Mr. Lebed: one of your earlier problems was having your -mdpi and -large suffixes reversed -- they need to be in the order seen in Table #2 in the URL shown below) http://developer.android.com/guide/topics/resources/providing-resources.html Step #4: Put a resource alias in res/drawable-normal-hdpi/ as icon.xml, pointing to icon_250px.png From the standpoint of resolving resources, when Android encounters the @drawable/icon reference: -- A Dell Streak (a large, mdpi device) will choose the res/drawable-large-mdpi/ resource, which will reference the 250px image -- A Nexus One (a normal, hdpi device) will choose the res/drawable-normal-hdpi/ resource, which will reference the 250px image -- Devices that are not large/mdpi or normal/hdpi, like the G1, will choose the res/drawable/ resource, which is the 100px image -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Consulting: http://commonsware.com/consulting -- 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: Resource Alias not resolving
I am going to very strongly urge you *not* to do this. And definitely don't do what was recommended by someone on the other thread you started, using the deprecated explicit size qualifier. What you are doing is going against the design of Android that is there to help applications deal with the variety of screens we have. So not only are you fighting the platform, but you are setting yourself up to have a continual series of problems as you encounter different kinds of devices. Let's take this statement: The Dell Streak being a high res device should have used the 480x720 imagery. Well... no, that isn't the way it is. The Dell Streak is a medium density large screen. The Droid and other such phones are high density normal screens. There are VERY different things, and you shouldn't be treating them as the same. That is why the platform support identifies them as being different. For example, the standard text size on the Streak is going to be smaller than on Droid... because the Droid has a higher density screen, so a larger text size is needed to have the same effective physical size. If you don't take this into account, you are either going to end up with a strangely huge UI on the Streak, or an unusably small UI on the Droid. Further, you really should not be creating a fixed size UI. Just start with the number of screens you will encounter today: QVGA low density, HVGA medium density, WVGA (in two different sizes) high density and medium density, and you can be sure that more will be appearing in the future. If you design your UI based on the platform facilities (densities, screen sizes, layout) then your app will nicely scale to all these screens with little work on your part. If you try to treat the screen as a rigid size, you are going to set yourself up for continual pain. On Sat, Jul 3, 2010 at 9:27 PM, Stephen Lebed srle...@gmail.com wrote: Hi Dianne, I wish I could share with you my source so you can see why its necessary. I've already tried various methods before settling on the solution I have now. My app now displays its custom graphics on the G1, Droid, and Dell Streak's specs on the emulator. My app is a utility that uses rendered graphics to make the app look nice. I have imagery that is 320x480 for use on mdpi devices, and imagery at 480x720 for use on hdpi and large devices. My goal was to create graphics that would not require resizing for the majority of high res devices. The Dell Streak being a high res device should have used the 480x720 imagery, but instead used the images in the 'drawable- mdpi'. It was only after I created a 'drawable-large' folder with a duplicate set of 480x720 images that the Dell Streak would finally use them. I could have worked it out so that the Streak would use the graphics in the mdpi folder and just scaled them up to fill the screen, but that would have been a bad solution for people capable of displaying high resolutions. I also tried creating a 'drawable-hdpi-large' folder, but it wouldn't work for some reason. I hope this makes sense and helps explain the issue I was having. I found that the resource aliasing only works from a 'drawable' folder. I've copied all my high res images into that folder and I have references in my 'drawable-hdpi' and 'drawable-large' folder. I believe it is a shortcoming of the way Android is designed where I can't run the alias's from anything other than the 'drawable' folder. I understand the difference between screen sizes and dpi', I'm just trying to find a simple way to make a device utilize graphics that its capable of supporting. Thanks, Stephen On Jul 2, 5:33 pm, Dianne Hackborn hack...@android.com wrote: Why do you want to do this? The Streak's screen is really what it reports -- mdpi density, but more space. If you use hdpi graphics, then your graphics will appear incorrectly large on the screen. You should layout your UI to use the extra space, not blow it up larger. The main time I can think where it would be okay to just use larger graphics is a game, where having everything blow up bigger is not so noticeable. In that case, you should maybe just go down the path of picking the graphics you want to use explicitly based on the raw space you have to work with. Before going down that road, though, you should probably stop and consider what it really means to be manually adjusting for whatever the screen is. On Fri, Jul 2, 2010 at 5:15 PM, Stephen Lebed srle...@gmail.com wrote: I'm hoping there is an answer to my problem. I've created two sets of graphics for my app. A set for medium res phones and a set for high res phones. I've placed them into their drawable-mdpi and drawable- hdpi folders. I've now learned that the Dell Streak identifies itself as a large- mdpi display. I've created a drawable-large folder and placed the high res images into it. Its so far, everything is
Re: [android-developers] Re: Resource Alias not resolving
Dianne, I'm confused about the correct approach. With the release of the Dell Streak, this question is coming-up more frequently. Al Sutton put up a blog post about it too: http://blog.alsutton.com/2010/07/03/android-tablets-and-mdpi-large This is what I'm not clear on: suppose you have a UI design that calls for an ImageButton that fills approximately half the screen. The geometry is easily defined by combining layout_weight and fill_parent etc. The image displayed in the ImageButton will cover approximately the same number of pixels on say both the Dell Streak and the Nexus One. So how do we organize our resources such that both of these phones will choose the same image resource for the button, while at the same providing a smaller image for devices such as the G1 (ie. a device that has far fewer pixels, but the roughly same screen size as the Nexus One)? Tom. -- Tom Gibara email: m...@tomgibara.com web: http://www.tomgibara.com blog: http://blog.tomgibara.com twitter: tomgibara On 4 July 2010 09:32, Dianne Hackborn hack...@android.com wrote: I am going to very strongly urge you *not* to do this. And definitely don't do what was recommended by someone on the other thread you started, using the deprecated explicit size qualifier. What you are doing is going against the design of Android that is there to help applications deal with the variety of screens we have. So not only are you fighting the platform, but you are setting yourself up to have a continual series of problems as you encounter different kinds of devices. Let's take this statement: The Dell Streak being a high res device should have used the 480x720 imagery. Well... no, that isn't the way it is. The Dell Streak is a medium density large screen. The Droid and other such phones are high density normal screens. There are VERY different things, and you shouldn't be treating them as the same. That is why the platform support identifies them as being different. For example, the standard text size on the Streak is going to be smaller than on Droid... because the Droid has a higher density screen, so a larger text size is needed to have the same effective physical size. If you don't take this into account, you are either going to end up with a strangely huge UI on the Streak, or an unusably small UI on the Droid. Further, you really should not be creating a fixed size UI. Just start with the number of screens you will encounter today: QVGA low density, HVGA medium density, WVGA (in two different sizes) high density and medium density, and you can be sure that more will be appearing in the future. If you design your UI based on the platform facilities (densities, screen sizes, layout) then your app will nicely scale to all these screens with little work on your part. If you try to treat the screen as a rigid size, you are going to set yourself up for continual pain. On Sat, Jul 3, 2010 at 9:27 PM, Stephen Lebed srle...@gmail.com wrote: Hi Dianne, I wish I could share with you my source so you can see why its necessary. I've already tried various methods before settling on the solution I have now. My app now displays its custom graphics on the G1, Droid, and Dell Streak's specs on the emulator. My app is a utility that uses rendered graphics to make the app look nice. I have imagery that is 320x480 for use on mdpi devices, and imagery at 480x720 for use on hdpi and large devices. My goal was to create graphics that would not require resizing for the majority of high res devices. The Dell Streak being a high res device should have used the 480x720 imagery, but instead used the images in the 'drawable- mdpi'. It was only after I created a 'drawable-large' folder with a duplicate set of 480x720 images that the Dell Streak would finally use them. I could have worked it out so that the Streak would use the graphics in the mdpi folder and just scaled them up to fill the screen, but that would have been a bad solution for people capable of displaying high resolutions. I also tried creating a 'drawable-hdpi-large' folder, but it wouldn't work for some reason. I hope this makes sense and helps explain the issue I was having. I found that the resource aliasing only works from a 'drawable' folder. I've copied all my high res images into that folder and I have references in my 'drawable-hdpi' and 'drawable-large' folder. I believe it is a shortcoming of the way Android is designed where I can't run the alias's from anything other than the 'drawable' folder. I understand the difference between screen sizes and dpi', I'm just trying to find a simple way to make a device utilize graphics that its capable of supporting. Thanks, Stephen On Jul 2, 5:33 pm, Dianne Hackborn hack...@android.com wrote: Why do you want to do this? The Streak's screen is really what it reports -- mdpi density, but more space. If you use hdpi graphics, then your graphics will
Re: [android-developers] Re: Resource Alias not resolving
On Sun, Jul 4, 2010 at 7:31 AM, Tom Gibara m...@tomgibara.com wrote: This is what I'm not clear on: suppose you have a UI design that calls for an ImageButton that fills approximately half the screen. The geometry is easily defined by combining layout_weight and fill_parent etc. The image displayed in the ImageButton will cover approximately the same number of pixels on say both the Dell Streak and the Nexus One. So how do we organize our resources such that both of these phones will choose the same image resource for the button, while at the same providing a smaller image for devices such as the G1 (ie. a device that has far fewer pixels, but the roughly same screen size as the Nexus One)? To get more concrete, and to roll this discussion back to Mr. Lebed's original questions, let's suppose you have one square icon, 250 pixels to a side, that you want to use on WVGA screens, and another square icon, 100 pixels to a side, you would like to use on HVGA screens. And, these logically are the same icon, so you want your layouts and Java code and whatever to refer to them as the same name. If so, by eyeball (i.e., haven't slung the code for this specific scenario), the following should work: Step #1: Put the 250px icon in res/drawable/ as icon_250px.png Step #2: Put the 100px icon in res/drawable/ as icon.png Step #3: Put a resource alias in res/drawable-large-mdpi/ as icon.xml, pointing to icon_250px.png (note to Mr. Lebed: one of your earlier problems was having your -mdpi and -large suffixes reversed -- they need to be in the order seen in Table #2 in the URL shown below) http://developer.android.com/guide/topics/resources/providing-resources.html Step #4: Put a resource alias in res/drawable-normal-hdpi/ as icon.xml, pointing to icon_250px.png From the standpoint of resolving resources, when Android encounters the @drawable/icon reference: -- A Dell Streak (a large, mdpi device) will choose the res/drawable-large-mdpi/ resource, which will reference the 250px image -- A Nexus One (a normal, hdpi device) will choose the res/drawable-normal-hdpi/ resource, which will reference the 250px image -- Devices that are not large/mdpi or normal/hdpi, like the G1, will choose the res/drawable/ resource, which is the 100px image -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Consulting: http://commonsware.com/consulting -- 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: Resource Alias not resolving
Thanks Mark, That lays it out very clearly. If that is the approach we should be taking, then I don't think I understood Dianne's contraindication in the post I replied to. Also, it concerns me that, as the number of variations in screen densities and screen sizes increase, this approach might be unwieldy - I'm having difficulty visualizing how many variations developers could be required to accommodate so I'm not sure. -- Tom Gibara email: m...@tomgibara.com web: http://www.tomgibara.com blog: http://blog.tomgibara.com twitter: tomgibara On 4 July 2010 12:53, Mark Murphy mmur...@commonsware.com wrote: On Sun, Jul 4, 2010 at 7:31 AM, Tom Gibara m...@tomgibara.com wrote: This is what I'm not clear on: suppose you have a UI design that calls for an ImageButton that fills approximately half the screen. The geometry is easily defined by combining layout_weight and fill_parent etc. The image displayed in the ImageButton will cover approximately the same number of pixels on say both the Dell Streak and the Nexus One. So how do we organize our resources such that both of these phones will choose the same image resource for the button, while at the same providing a smaller image for devices such as the G1 (ie. a device that has far fewer pixels, but the roughly same screen size as the Nexus One)? To get more concrete, and to roll this discussion back to Mr. Lebed's original questions, let's suppose you have one square icon, 250 pixels to a side, that you want to use on WVGA screens, and another square icon, 100 pixels to a side, you would like to use on HVGA screens. And, these logically are the same icon, so you want your layouts and Java code and whatever to refer to them as the same name. If so, by eyeball (i.e., haven't slung the code for this specific scenario), the following should work: Step #1: Put the 250px icon in res/drawable/ as icon_250px.png Step #2: Put the 100px icon in res/drawable/ as icon.png Step #3: Put a resource alias in res/drawable-large-mdpi/ as icon.xml, pointing to icon_250px.png (note to Mr. Lebed: one of your earlier problems was having your -mdpi and -large suffixes reversed -- they need to be in the order seen in Table #2 in the URL shown below) http://developer.android.com/guide/topics/resources/providing-resources.html Step #4: Put a resource alias in res/drawable-normal-hdpi/ as icon.xml, pointing to icon_250px.png From the standpoint of resolving resources, when Android encounters the @drawable/icon reference: -- A Dell Streak (a large, mdpi device) will choose the res/drawable-large-mdpi/ resource, which will reference the 250px image -- A Nexus One (a normal, hdpi device) will choose the res/drawable-normal-hdpi/ resource, which will reference the 250px image -- Devices that are not large/mdpi or normal/hdpi, like the G1, will choose the res/drawable/ resource, which is the 100px image -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Consulting: http://commonsware.com/consulting -- 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.comandroid-developers%2bunsubscr...@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: Resource Alias not resolving
On Sun, Jul 4, 2010 at 8:11 AM, Tom Gibara m...@tomgibara.com wrote: That lays it out very clearly. If that is the approach we should be taking, I'm saying it is *an* approach. then I don't think I understood Dianne's contraindication in the post I replied to. Also, it concerns me that, as the number of variations in screen densities and screen sizes increase, this approach might be unwieldy - I'm having difficulty visualizing how many variations developers could be required to accommodate so I'm not sure. Well, actually, those two points are probably tied. My reply made one assumption: your proposed graphic design was the right one to implement. Let's back up a step and talk about the design: two images, each taking up half of the screen. First, let's think of a Web app, where a designer wanted to use that design. Browser windows can range from 800x600 to 1920x1080 just within the desktop/notebook realm and still be considered reasonably sized. There are over a million possible browser size combinations, courtesy of re-sizable windows. Screen sizes can easily range from 10 netbooks to 30 Cinema Displays. What is half of the screen in this case? At this point, there are three possibilities that I can see: 1. The Web designer elects to use JS/CSS tricks and a metric buttload of images to achieve the desired look. The Android equivalent of this is what my reply covered. 2. The Web designer decides that the original design was nonsensical and comes up with a design that works better on a range of browser window dimensions. The Android equivalent of this is more or less what Ms. Hackborn was hinting at (I think) in her replies on the two threads -- use a different design. 3. The Web designer decides to get all modern on us and use SVG for the images, which works on some browsers but not all, but provides near-infinite scalability. In Android, we'd need an SVG library from which we could generate bitmaps at appropriate sizes, caching as appropriate to avoid the SVG calculations every time. libsvg-android is one candidate, though I have not tried it and it uses the NDK and so may have issues on some chipsets: https://launchpad.net/libsvg-android Or, I've seen some hints that WebView can render SVG, perhaps in newer Android releases, though I have not tried it. Personally, for now, I'd aim for #2. Have different images for different densities, so they can have a common approximate physical size. Have layouts for different physical sizes, where you perhaps display more information on a larger-size screen, less information on a smaller-size screen. My sincere hope is that all of this gets revisited in 6-9 months, as #2 pretty much assumes we're talking phones and tablets. Once you get to 10-foot UIs with Google TV, #2 starts getting problematic, unless televisions are given pseudo densities and physical sizes based upon apparent values from the greater distance. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Consulting: http://commonsware.com/consulting -- 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: Resource Alias not resolving
On Sun, Jul 4, 2010 at 5:42 AM, Mark Murphy mmur...@commonsware.com wrote: 2. The Web designer decides that the original design was nonsensical and comes up with a design that works better on a range of browser window dimensions. The Android equivalent of this is more or less what Ms. Hackborn was hinting at (I think) in her replies on the two threads -- use a different design. Yes, trying to make fixed size bitmaps into a UI that splits the screen in half is simply the wrong approach. So you go through contortions to make a bitmap that works on the screens you know of so far... and conveniently one of the large size screens happens to have the same number of pixels as current high density phones (at least in one dimension; in the long dimension there is more variation), and then along comes something like this: http://www.wired.com/gadgetlab/2010/06/samsung-enters-tablet-race-with-the-galaxy-tape/ And there are going to be all other kinds of screen configurations that appear. (Trust me -- I hear all kinds of things that manufacturers want to do, and we try to manage the things Market ships with to keep things relatively simple for developers, but the platform has the infrastructure to support many different screen sizes, and you will be encountering more of them down the road.) 3. The Web designer decides to get all modern on us and use SVG for the images, which works on some browsers but not all, but provides near-infinite scalability. In Android, we'd need an SVG library from which we could generate bitmaps at appropriate sizes, caching as appropriate to avoid the SVG calculations every time. libsvg-android is one candidate, though I have not tried it and it uses the NDK and so may have issues on some chipsets: https://launchpad.net/libsvg-android The 2d Canvas APIs are functionally pretty equivalent to SVG, and can be used to generate the same kinds of images. Also there is the approach that the platform itself uses extensively: 9-patch PNG images, allowing you to create images that can expand to fill the available space. There are some limitations on what you can do with these (various types of gradients can't be done for example), but this has the benefit of being very easy to use for a lot of the common cases and efficient to render. My sincere hope is that all of this gets revisited in 6-9 months, as #2 pretty much assumes we're talking phones and tablets. Once you get to 10-foot UIs with Google TV, #2 starts getting problematic, unless televisions are given pseudo densities and physical sizes based upon apparent values from the greater distance. No it doesn't. Things are defined as they are to be flexible for this -- that is why density is not tied to a specific screen dpi, but rather is a more general concept of here is the scaling factor to use to have a UI that is the appropriate size for the user. So on a TV display one could certainly report a density class that is significantly different than the real DPI if you were to look at the raw display... density is intended to represent the user's perceived size. Not that I know this is how that is going to end up... we aren't doing third party apps on GoogleTV yet, and there are a lot of things to decide about how they should all play out with third party apps. -- 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
Re: [android-developers] Re: Resource Alias not resolving
On Sun, Jul 4, 2010 at 3:04 PM, Dianne Hackborn hack...@android.com wrote: The 2d Canvas APIs are functionally pretty equivalent to SVG, and can be used to generate the same kinds of images. True, but I have yet to see an Illustrator or Inkscape plugin that exports to Android 2D Canvas Java code. The point behind SVG is one part vector graphics, one part something that a graphic designer won't go ape-bleep over. If the answer is that a programmer has to hand-create each and every graphic via slinging Java code, we're screwed. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Consulting: http://commonsware.com/consulting -- 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: Resource Alias not resolving
On Sun, Jul 4, 2010 at 6:06 PM, Stephen Lebed srle...@gmail.com wrote: I've tried your suggestions, but its still not working. I am testing on the emulator, so there may be an issue with that. I'm targeting v1.6 Do you have your supports-screens element set up properly? -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Consulting: http://commonsware.com/consulting -- 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: Resource Alias not resolving
2. The Web designer decides that the original design was nonsensical and comes up with a design that works better on a range of browser window dimensions. The Android equivalent of this is more or less what Ms. Hackborn was hinting at (I think) in her replies on the two threads -- use a different design. Yes, trying to make fixed size bitmaps into a UI that splits the screen in half is simply the wrong approach. Half-the-screen is a conveniently simplified example just to discuss the technicalities. Al's screenshot of the facebook app provides a concrete real-world example. There are six possible actions, and the UI design maps this on to a grid of 3x2 buttons that fill the screen. Though this design might look quite bold over a large screen, I think that in the context of this discussion, its the kind of UI that a developer might reasonably be called on to implement; calling the design nonsensical is to bypass the issue. I apologize for a lack of clarity in my previous post, but I'm not trying to make trying to make fixed size bitmaps into 'a UI that splits the screen in half'. I'm trying to ensure that the image resource with the most appropriate density is selected by for display by a variably sized view. The 2d Canvas APIs are functionally pretty equivalent to SVG, and can be used to generate the same kinds of images. I do this a lot - it's liberating to have the option of resizing resources precisely to the required dimensions, but it comes with a lot of effort relatively speaking (handling caching and view resizing are two significant areas of additional work). Though I broadly agree with Mark's sentiment; designers want to export graphical assets into UIs that, for their complexity, the developers don't want to touch - let alone render in code. Tom. -- Tom Gibara email: m...@tomgibara.com web: http://www.tomgibara.com blog: http://blog.tomgibara.com twitter: tomgibara -- 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: Resource Alias not resolving
Okay let me put it this way... what you are trying to do is not how things are intended to work, because it results in applications that are very tied to specific screen resolutions and are likely to not behave well when encountering new kinds of screens that they didn't anticipate. So I strongly recommend not going down this route, and instead using another approach. However, if this is REALLY what you want to do... then you need to take control, and decide exactly what you want to have happen yourself. That is, stick all of your possible graphics in drawable-nodpi, and at run time look at the space you have on the screen and other information to determine exactly which graphic you want to use for that environment. Definitely don't do things like try to mix physical screen resources, with density resources, with screen size resources. It IS well defined which resource you will end up with given a particular screen (via the resource matching hierarchy described in the docs), but it is likely it won't do exactly what you want. If one were to ask is a large screen resource better than a high density resource? well... it depends. For our purposes we will always match screen size before density since layouts tends to be more fragile than densities (we can after all always scale graphics), but you are going against how the platform thinks about screen sizes so you can't really count on it doing what you want here. That is, screen size and density are two completely orthogonal things, and have no bearing on each other. You are trying to put them together, and fighting with the platform by doing so. And honestly -- just DO NOT use absolute screen size configurations. Those are deprecated for a reason. They will only cause pain. They just do not work for being able to adjust for the kinds of different screens we have. But let me say one more time: with the approach you are taking, there is a good chance you are going to end up having to tweak your app each time a device with a new kind of screen appears. It is going to cause you some trouble. If that is absolutely what you want, then go ahead and take control and do it... just don't be surprised at the consequences. On Sun, Jul 4, 2010 at 4:16 PM, Stephen Lebed srle...@gmail.com wrote: As another test, I removed the drawable-normal-hdpi and drawable-large- mdpi folders and left drawable-480x320 and drawable-800x480. The G1 is displaying correctly, the Droid is using the layout for the G1, using the normal res graphics and scaled them to fill the screen, the Dell Streak is displaying correctly. Stephen On Jul 4, 3:58 pm, Stephen Lebed srle...@gmail.com wrote: I have tried creating a drawable folder called res/drawable-480x320 and res/drawable-800x480 thinking that this would do the trick, but it doesn't work either. Stephen On Jul 4, 3:44 pm, Tom Gibara m...@tomgibara.com wrote: 2. The Web designer decides that the original design was nonsensical and comes up with a design that works better on a range of browser window dimensions. The Android equivalent of this is more or less what Ms. Hackborn was hinting at (I think) in her replies on the two threads -- use a different design. Yes, trying to make fixed size bitmaps into a UI that splits the screen in half is simply the wrong approach. Half-the-screen is a conveniently simplified example just to discuss the technicalities. Al's screenshot of the facebook app provides a concrete real-world example. There are six possible actions, and the UI design maps this on to a grid of 3x2 buttons that fill the screen. Though this design might look quite bold over a large screen, I think that in the context of this discussion, its the kind of UI that a developer might reasonably be called on to implement; calling the design nonsensical is to bypass the issue. I apologize for a lack of clarity in my previous post, but I'm not trying to make trying to make fixed size bitmaps into 'a UI that splits the screen in half'. I'm trying to ensure that the image resource with the most appropriate density is selected by for display by a variably sized view. The 2d Canvas APIs are functionally pretty equivalent to SVG, and can be used to generate the same kinds of images. I do this a lot - it's liberating to have the option of resizing resources precisely to the required dimensions, but it comes with a lot of effort relatively speaking (handling caching and view resizing are two significant areas of additional work). Though I broadly agree with Mark's sentiment; designers want to export graphical assets into UIs that, for their complexity, the developers don't want to touch - let alone render in code. Tom. -- Tom Gibara email: m...@tomgibara.com web:http://www.tomgibara.com blog:http://blog.tomgibara.com twitter: tomgibara -- You received this
Re: [android-developers] Re: Resource Alias not resolving
On Sun, Jul 4, 2010 at 3:44 PM, Tom Gibara m...@tomgibara.com wrote: Half-the-screen is a conveniently simplified example just to discuss the technicalities. Al's screenshot of the facebook app provides a concrete real-world example. There are six possible actions, and the UI design maps this on to a grid of 3x2 buttons that fill the screen. Though this design might look quite bold over a large screen, I think that in the context of this discussion, its the kind of UI that a developer might reasonably be called on to implement; calling the design nonsensical is to bypass the issue. Let's take for granted that the app should do something good with the space it has for its UI. Is that to just enlarge all of the UI elements to cover the screen? You can maybe get away with this for the Dell Streak screen, but for anything larger than that it gets ridiculous. For example what happens when you encounter this? http://www.wired.com/gadgetlab/2010/06/samsung-enters-tablet-race-with-the-galaxy-tape/ Not saying today this is an Android compatible device (actually I don't know off-hand), but some day it surely will be. I don't think just making things large is going to make much sense for that, and it is still significantly smaller than say an iPad. So there is going to need to be some restructuring of the UI for these larger screens. A phone-centric UI with lots of movement between full-screen pages doesn't make sense on a larger screen. Just blowing up the UI is not the right approach to take. The Streak is an interesting middle-ground between a phone UI and a real tablet like that Samsung, but still just blowing up a phone UI is a waste. The buttons are plenty large enough to see and press without blowing them up. So how about using all of that extra space for something worthwhile? Maybe show recent friend activity along the bottom or something? That is relatively easy to accomplish, by having a different layout for -large which contains the UI for additional content. I do realize that this will increasingly become another level of complexity for developers. I really don't know which of these larger form factors will actually be the most popular -- nobody does -- so adjusting UI for them becomes fairly speculative. The general rule I would recommend is to ensure your UI doesn't break for the different screens (using the platform facilities helps greatly in this), and don't worry so much about tuning until there is more clear demand. Also I am currently working on some platform facilities to provide more help in adjusting for these new screen sizes, so I am definitely aware it is an upcoming issue, and we do plan to have more platform support coming up. Re: I apologize for a lack of clarity in my previous post, but I'm not trying to make trying to make fixed size bitmaps into 'a UI that splits the screen in half'. I'm trying to ensure that the image resource with the most appropriate density is selected by for display by a variably sized view. In the case of the streak, the -mdpi bitmaps are absolutely the most appropriate because those are the correct size for the screen. If you want to ignore density and just pick an image based on raw size, you will need to do that yourself; it shouldn't be hard to say write an ImageView class that does something like this. I'd like at some point to also have some kind of SizeDrawable that does such a thing, but this behavior is only for special situations. -- 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
Re: [android-developers] Re: Resource Alias not resolving
Thanks, that clarifies things a lot. It can sometimes be difficult to understand how to best apply APIs, even if you're familiar with them, and especially when they are tracking a moving target. So my personal high-level take-away from this is that it's simply not the responsibility of the resource selection framework to deal with this case; I can see how SizeDrawable would work, but that's in the future (if ever); doing the work in view layer is the way to go for now. I find the questions around how to use the significantly greater screen-estate of some devices, really interesting. I'm quite excited about what developers will be able to do with progressive enhancement in this area. The web design community has been applying the principles of graceful degradation for a long time, but adaption to varying screen sizes mostly ended with CSS powered fluid layouts. Tom. -- Tom Gibara email: m...@tomgibara.com web: http://www.tomgibara.com blog: http://blog.tomgibara.com twitter: tomgibara -- 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
