Ah, but that has always been the excuse; it may even become your project's "Swan Song";)
" I'm trying to design an app that not only functions well, but looks better than everything else out there" was the excuse for ignoring the distinction between physical and logical tags in HTML, too. And ever since. Yet I have never seen an app where it was worth the costs Dianne has already warned of. You already alluded to how iPhone apps get away with this: they don't HAVE to run on a wide variety of hardware. On Jul 4, 8:16 pm, Stephen Lebed <srle...@gmail.com> wrote: > Thanks Dianne, > > I really do take what you say to heart. I would love to abandon fixed > graphics sizes and work with scalable graphics. The problem is that > I'm trying to design an app that not only functions well, but looks > better than everything else out there. It seems like it would be > easier to create stunning looking graphics for the iPhone because you > know exactly the spec to design your graphics for. I want to create > apps that have a polished, high end look to them for Android. For me, > that means rendering my interface in a 3d graphics environment (even > if the end result is just a 2d display). I would attach a screen > shot, but I don't know how in this forum. > > I realize I am fighting the way the platform is intended to be used. > My scenario is that I'm writing a utility that has graphics that cover > a 320x480 display and a 480x720 display using a surfaceview. I have a > layout under the surfaceview that positions buttons based on the size > and density of the display. My graphic has drawn buttons and needs to > overlay the actual buttons from the layout. That is the reason why > I'm struggling with resolutions and densities. > > I've taken your advice and wrote a new routine to manually load the > images I need based on the screen size of the device. I've actually > made it a generalized routine, so adding support for future unknown > displays will be trivial. > > Thanks again for all your hard work and taking time out on this > holiday to help me out. Hopefully I have a chance to meet with you at > a future I/O conference. > > Best, > Stephen Lebed > > On Jul 4, 6:19 pm, Dianne Hackborn <hack...@android.com> wrote: > > > 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 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<android-developers%2Bunsubs > > > cr...@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
