Hi Tim, sorry for the delayed answer. On Mon, Dec 27, 2010 at 1:55 PM, Tim H. <timho...@gmail.com> wrote: > Preview 2 is much improved - being able to drag views up and down the > list (and into child layouts) is great, no need for the up/down button > now. Again, can still use some work, but it's getting back to the > point where I am comfortable using drag and drop, but able to do > things manually now. > > Here's some frustrating things I would like to get see fixed, which > may relate to the tools or integration with Ecliipse: > > * Refactoring > If I rename something, all references to it should be updated
This is in the plan, we want full refactoring across Java and XML for resources. > * Other Properties in the right-click menu > > I could take off the stinking property window completely, if all > custom properties (like references or resources) could be picked from > here - this is already done for things like layout_width (Other...) - > resource references/properties could be done the same way, (Select > Resource..) This is in Preview3, and personally I don't like it too much. There's too much in there. I think the better option is to fix the properties view to not suck which we have plans for too. > * Property state > > If you move from one view to the other, you get pushed back to the top > of the property window. Especially if I am editing a property that > every one of the views I click on has, this should not happen... my > property window should stay focused on the same property for the new > view. It does this *some* times, but the times it doesn't is > frustrating I think the issue is when moving to a view of a different class. We should do something to try to keep (some) of the same properties on screen but it's never going to work perfectly for all cases. > * Resource Chooser (for String Properties) > > Very frustrating when you have any more than about 100+ strings, say > using them for tags, and you need to select one from this - it loads > the list of resources and resets back to the top of the list - every > time. You can either try to scroll down the list and quickly click > your item, or wait for the whole list to load, reset to the top, then > scroll down to your item - this is a lot of wasted time. I could just > manually type the string (@string/whatever), but I'd prefer to pick > from a (quicker) list. That's a good feedback. We should definitively improve things there. We have plan to fully rewrite this dialog anyway, so we'll see when we get there. Since we didn't have a bug open for this I'll create one: http://code.google.com/p/android/issues/detail?id=13875 > * Simultaneous Viewing of MultiRes Layouts > I'd really like to see a way to view multiple layouts simultaneously > (i.e. compare my HVGA and WVGA side by side) Do you mean when editing? We would like to have a way to preview all variations of a layout so that you can compare them. Doing it during editing is mostly going to be challenging with regards to screen real estate, but should be doable. http://code.google.com/p/android/issues/detail?id=13876 > * Merging Layout Changes > > Even more, I'd like to see a way to make it much easier to work with > multi-res layouts. Currently, if I add a view to one layout, I have to > add it to all layouts that it will apply to. For example: > > I have customized version of: > > res/layout/main.xml > res/layout-land/main.xml > res/layout-large/main.xml > res/layout-ldpi/main.xml > > If I want to add a view, assuming it would be added to all layouts, I > have to either add it once for each version of my view, and set all > the properties each time - or (try to) copy and paste it to each > layout, although copy and paste needs a lot of improvements still. This is extremely challenging because either we're too cautious and it'll never happen or we do it too often and it won't do what you want either. I think a better solution is to use the <include> tag. You'll see in ADT 9.0 preview 3 we have a way to extract part of a layout into a new layout to be extracted. It doesn't (yet) support also updating alternate version of the layout, but we'll add that. In ADT 9.0 you'll also have improved support for <include> tag which will make them a lot easier to work with. > * Deprecated/Newer Feature Warnings > As developers, we want to make things compatible for as long as > possible, so it would be helpful if the tools pointed out if we are > using things that may not work prior to "x.x" - such as new properties > that are added/removed/etc. We do get warnings for deprecated > properties (in the property window), but that is about it. That's a good point. I think devs often compile against a newer versions to have access to new resource items (or manifest elements), but want to target previous versions. Something that tell them that some used attributes will be ignored on previous versions would be useful. http://code.google.com/p/android/issues/detail?id=13874 Xav -- Xavier Ducrohet Android SDK Tech Lead Google Inc. http://developer.android.com | http://tools.android.com Please do not send me questions directly. Thanks! -- 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
