Re: [android-developers] Where do you aim for design specs?
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.comwrote: 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
[android-developers] Where do you aim for design specs?
I'm starting the design for an app that spans phones and tablets (2.1 - 4.0, custom action bar pre-3.0, native action bar 3.0+) and working with a designer used to the iPhone. 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. So I'm wondering, which screen size, resolution, density, do we aim for to start with? 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? Any thoughts on this topic are welcome. -- Chris Stewart -- 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] Where do you aim for design specs?
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
Re: [android-developers] Where do you aim for design specs?
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.comwrote: 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
