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 <[email protected]>wrote: > On Sun, Oct 30, 2011 at 12:56 PM, Chris Stewart <[email protected]> > 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
