No, no application will be penalized for using the standard buttons. In fact you're more likely to get penalized for putting in custom buttons that don't work on a touch screen. :}
On Mar 28, 6:13 am, android_newbie <[EMAIL PROTECTED]> wrote: > Thank you for clarifying. We were going to create custom button images > for all of the buttons but it seems like you're recommending that we > don't do that? We just want to make sure that an application won't be > penalized for using the standard button widgets with the orange > background? > > Thank you, > AN > > On Feb 21, 12:01 pm, hackbod <[EMAIL PROTECTED]> wrote: > > > On Feb 21, 8:57 am, aetmos <[EMAIL PROTECTED]> wrote: > > > > Yeah, that's what I was trying to say above. It would be nice if there > > > were a global way to set highlight colors, though. Like, if the > > > default buttons had a number of different colors to choose from. At > > > the very least, the documentation should really make it more clear how > > > to swap out the images. It took me forever to figure out. > > > The main mechanism we have for an application to select standard > > appearances is themes, basically letting you pick between a dark > > background and a light background. (Though note that the current > > light backgroundthemeis not yet ready for use.) > > > There is an interesting balancing act we need to play with the > > standard appearance, because we expect that manufacturers of > > individual devices will want tomodifythe look of the UI to some > > degree to match their hardware (either just the appearance, or things > > like you saw with M5 where the size of widgets is modified to account > > for whether or not there is a touch screen), and we also in the future > > want to support user-installed skins. > > > Our general approach is: > > > - Applications can decide whether they want a dark or light background > > (thetheme), and we guarantee that whatever appearance is in effect > > will match that basic design so you can pick colors and graphics that > > will work on that background. > > - The device decides the exact appearance of the standard UI elements, > > both how they look and their overall size, to match the design of the > > hardware and how the user interacts with it. This is done by > > modifying the standard system resources. During the design of these > > resources, careful restrictions will need to be applied to ensure that > > existing applications work well with them. > > - (Eventually) third party skins can be installed tomodifythe > > standard resources to provide different appearances on a device. > > Skins have a lot more freedom to do wild things with the appearance, > > because they are user-installed and if they cause poor interactions > > with applications they can be removed. > > > We realize that this kind of variation in the UI causes a lot of > > complication for applications. In general, it is best to be > > conservative with your application design: rely on the standard > > resources for the widgets and other UI elements, so you will match the > > device. As the platform evolves and devices appear, we will be > > putting effort into ensuring that applications that use the standard > > UI elements continue to look and run well. > > > I would certainly think twice before replacing a button's graphics > > with my own custom one. If the thing you are doing is not really a > > button nor intended to look anything like a button, then this is > > fine. If it is still supposed to be a button, however, then do keep > > in mind that the way buttons look is going to change (don't expect > > what we have right now to be the look that ships in a device), and > > vary across devices, so it is very unlikely your own graphics are > > going to match other buttons the user sees. > > > Also, if you are doing your own widget graphics, then you are > > eventually going to need to deal with multiple device configurations. > > At this point I would suggest focusing on the current M5 configuration > > -- a device with a touch screen -- and thus design the graphics > > accordingly to be large and touchable like the M5 design. At some > > point in the future, however, you will probably need to make > > additional graphics for other configurations like the old "QVGA non- > > touchable" UI we had in M3. > > > Again, we will be helping application developers as the platform moves > > to different hardware configurations. I realize that right now > > without any hardware it is difficult to visualize what you are > > actually designing for. It is a safe assumption, however, that the M5 > > UI is designed to work on the kind of hardware that will initially be > > shipping, so you would be best off to take it has a guide (and don't > > worry about the particular look), rather than working against what is > > there and doing your own thing. --~--~---------~--~----~------------~-------~--~----~ 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] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
