No problem. I look on the other blogs/groups. AN
On Mar 28, 5:12 pm, hackbod <[EMAIL PROTECTED]> wrote: > Sorry, this is now very far outside of the scope of what I can > answer. I am just an engineer. :) > > On Mar 28, 2:15 pm, android_newbie <[EMAIL PROTECTED]> wrote: > > > Thanks hackbod for your quick reply! I have another quick question. > > > We're trying to make the UI of our app look as aesthetically pleasing > > as possible while balancing the use of limited resources on mobile > > devices. We're considering having several different background images > > for different screens to add aesthetic appeal. If we use a lot of > > different background images for the competition, will we be penalized? > > Are we supposed to demonstrate that we are taking into consideration > > the memory and storage constraints of mobile apps for this > > competition? or should we just try to make the application as visually > > appealing as possible (as long as we use the standard widgets)? > > > Are there any size constraints on the jar/file that we submit? (Since > > I haven't filled out the submission form yet, I'm not sure exactly > > what files we're supposed to submit?) > > > Thank you again, > > > AN > > > On Mar 28, 2:36 pm, hackbod <[EMAIL PROTECTED]> wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
