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
