Thanks a lot for the responses. I didn't realize such a large number of devices are categorized into just two buckets. I suspect normal/xhdpi will gain share sooner rather than later, as I believe the Galaxy Nexus fits in that group. I would imagine the influx of high res/high density displays will begin soon as well.
-- Chris Stewart http://chriswstewart.com On Sun, Oct 30, 2011 at 4:21 PM, B Lyon <bradfl...@gmail.com> wrote: > ugh. Dealing with this exact same issue myself at the moment (iPhone --> > android). The "screens" link Mark pointed out is great to see what things > are out there as of Oct 3 - 90% are apparently Normal/hdpi or Normal/mdpi, > so you can set up the avd's to take a look at how things look (or buy all > the devices). Not depicted on the list, of course, is the potential > increase of Kindle Fires that are to be shipped Nov 15. Amazon has some > info on how to configure the emulator for this ( > https://developer.amazon.com/help/faq.html#KindleFire .... which I found > via one of Mark's answers on stackoverflow). > > > On Sun, Oct 30, 2011 at 1:20 PM, Mark Murphy <mmur...@commonsware.com>wrote: > >> On Sun, Oct 30, 2011 at 12:56 PM, Chris Stewart <cstewart...@gmail.com> >> wrote: >> > Going from a world where he worried about 3.5" >> > only, to a world where every size is potentially available, is a >> concern of >> > mine. >> >> >> http://www.amazon.com/Red-Bull-Energy-Drink-8-4-Ounce/dp/B000MTST70/httpcommonsco-20 >> >> :-) >> >> > So I'm wondering, which screen size, resolution, density, do we aim for >> to >> > start with? >> >> That's like saying "do I focus on 800x600, 804x567, or 923x725 >> resolution browser windows first?". The answer is "all of them, >> because you focus on creating a design that incorporates rules for >> handling resizeable browser windows". >> >> > Certainly we'll need to work on each of the layout/resource >> > variations (small, medium, large, xlarge, ldpi, mdpi, hpdi, etc, etc) >> but >> > I'm looking for a reference point to get started. Should we be >> focusing on >> > the largest for phones, and largest for tablets, with the expectation >> that >> > we can mostly scale down from each of those to the smaller phone and >> tablet >> > sizes/resolutions/densities? >> >> I wouldn't. On a tactical level, it's almost always easier to scale up >> than down. >> >> Strategically, your first job is to determine what you care about. >> -small screens, for example, are not terribly popular, so you might >> elect to skip those in the interests of reducing development effort. >> See: >> >> http://developer.android.com/resources/dashboard/screens.html >> >> Your second job is to come up with the big-ticket designs for your UX >> on the remaining screen sizes. For example, where will you use one >> fragment per activity in -normal devices and use multiple fragments >> per activity in -large and/or -xlarge? See: >> >> http://developer.android.com/guide/practices/tablets-and-handsets.html >> >> Your third job is, within a fragment, to design layouts that can >> handle the variations in screen size the fragment will be expected to >> cope with. For some fragments, they will have minor variations in size >> (e.g., a phone-sized screen on a phone or a phone-sized portion of a >> tablet screen). For some fragments, they will have much more dramatic >> variations in size (e.g., a case where you will only ever have the >> fragment by itself in an activity, or you have an activity sans >> fragments). Here, your need to teach your GUI designer the basic rules >> for The Big Three Android layouts: >> >> -- use android:layout_weight with LinearLayout >> -- use android:stretchColumns and android:shrinkColumns with TableLayout >> -- use all the android:layout_* rules with RelativeLayout, to >> stipulate what is attached to what (with whitespace therefore implied) >> >> Your GUI designer should be able to give you GUI designs that depict >> these rules. >> >> Densities tend to fall out after the basic design is complete. Either >> stick with a single density for each image (and let Android resample >> it, with varying degrees of quality and performance) or package in one >> copy of the image per density (at the cost of a somewhat larger APK). >> If you have the same image that should appear in different sizes in >> different screen sizes or layouts, again you will need to decide if >> you want Android resizing the image (saves development effort at cost >> of speed/quality) or if you want to package in multiple renditions of >> the image at different sizes (e.g., icon-standard vs. icon-embiggened) >> for each relevant density. >> >> This would be an approach for a regular app. Games probably come at >> this from a totally different approach vector, for example. >> >> -- >> 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 >> > > -- > 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
