TabWidgets appear to default to 65 pixels in height. That's with or without icons. And that's just a bit too huge for my tastes. And like so many Android widgets, there's no convenient way to change simple style properties. Do I really have to create an entire Theme just to change the default height of a tab? Any way to do this dynamically with, like, one line of Java code?

To think that people complain about Swing being demanding. At least with JTabbedPane you can call setMaximumSize(), setMinimumSize(), setPreferredSize(), etc. And let's not forget it's one object--so much easier than Android's TabHost-TabSpec-TabWidget paradigm...

I think the designers put a lot of thought in designing these ui widgets to be this big... That is what I first thought when I was using spinners and check boxes, I was like these are too HUGE... however later on in another post, I saw the rationale... imagine that people will be using the touch screen to navigate your app. And there are some of us (like me) with very HUGE fingers.. I don't think that you want your application to only be workable if someone is using a pointing device like a stylus..... Its easy to get carried away while developing on the computer and using a mouse to click on stuff, so try to picture yourself using your fingers to navigate your UI...

ps. Maybe that's why they changed the date picker to that awful date picker that we are stuck with....

rmanromga wrote:I think the designers put a lot of thought in designing these ui widgets to be this big

Did they? I don't assume that every Android device is going to be a small cellphone, or that one's thumbs will be the main method of navigation. It just seems petty to finalize or omit methods that would allow some design [s]sensibility[/s] flexibility.

Android is a strange mix of freedom and annoying roadblocks. For example, I had no choice but to create my own ListAdapter since the ones that were included force you to supply Views via the XML layout inflator. Maybe some folks think the XML layout paradigm is wonderful but I don't and many agree with me.

Don't get me wrong--I love Android--but it's a tough sort of love.

And there in lies the beauty of Android, personally I love UI designing via xml its is way easier than coding it in Java. However, there are other people like you who may prefer doing the UI the java (swing/swt) way and you are more than welcome to do that and not use the xml method. Also, for the UI elements, if you do not like how Android presents them, then you are free to modify them the way you see fit. For example if you feel that the list view rows are too wide, you are free to write your own views that you can then inflate. If the check box is too big for example, go ahead and write a view that suits your needs.... this is what flexibility means to me so I'm not getting your argument that android is not flexible....

rmanromga wrote:this is what flexibility means to me so I'm not getting your argument that android is not flexible....

I didn't say Android is inflexible. Overall, Android is very flexible. But some aspects are surprisingly inflexible. For example, here's a view...

TextView textView = new TextView(<someContext>);

Now instantiate any of the concrete ListAdapters with this view. You can't, because the provided ListAdapters require an XML layout reference. This is what I mean by surprisingly inflexible. The fact that I can roll my own doesn't make this scenario any less inflexible. The ListAdapters should provide constructors that accept an actual view object reference--as mine does. Or they should have provided factory methods.

In this regard, the ListAdapters are unusual and inconsistent, since all the widgets I have encountered so far allow you to reference dynamic non-XML-layout views.

I'm neither an Android basher nor an Android fanboy. But I sure am an Android enthusiast.

I now see your perspective...all the adapters require a resource id in order to be bound to a list... I guess android should provide a mechanism of creating and identifying resources programmatically to use with the adapters, or provide other constructors that take views created on the fly..... This is definitely a limitation... hopefully more people like you will bring this up and something like this could make it into a future release of the sdk.... In the mean time, keep keeping on!!

cheers,
--D