Apps ExpandableListView in ExpandableListViw

[kizanlik]

Hello to everybody!
I hope you all have nice day or night depending on where you are right now!

As you understand from the subject, I want to put an ExpandableListView into a parent view which is an ExpandableListView. Actually I achieved this but I have a "little problem".

The little problem:

- Parent ELV's adapter populates values for its groups.
- When a group is expanded in parent ELV, child ELV's adapter starts to populate values for its groups.
- Child ELV's groups are shown properly and there is not any problem

but

When child ELV's group is expanded, it shows child ELV's child view in a "single line" but I want to show a "custom view".

While a "custom view" is shown properly (orientation, width, height... etc.) in parent ELV, why another "custom view" is shown in a single line in child ELV?

 

[kizanlik]

The little problem is narrowed: Parent ELV's child's height is not set to the height of child ELV's height. Could it be a bug or something?

By the way, Android version is Gingerbread, API 10.

 

[alostpacket]

You would know more about this than I, but from what I've heard ELV isnt very flexible in terms of customization like that. I could be wrong but I thought I read that somewhere.

Basically I feel like I have heard of this problem before when researching if I wanted to use an ELV.

Personally though, I would ask myself the question "Is multiple embeded/expandable views really the experience my users will want and understand?"

For me I think the answer would be to find a different type of user interface to convey the concept. (Maybe separate activities with a breadcrumb style menu at the top).

To answer your question though, you might have better luck using regular ListViews inside each other, if you find the constraints for ELV too restrictive. However I'd imagine handling the touch events could get tricky.

 

[alostpacket]

Also, you could just use the top LV as a container and create views dynamically yourself using addView(). Some people prefer this method, but I forgot to mention it because it's not one I use myself.

 

[kizanlik]

Firstly, I want to thank you thank you alostpacket for your response.

Actually I figured out why the little problem occures and I'm working on it.

The little problem is here that parent ELV's child's height is not bound to the height of child view's container height.

It seems that parent ELV's child's height is set by "number of children * child's view height" formula rather than binding to the children's container height.

In my case, I have only one child which is an ELV. So, I think I have only one option: Getting child ELV's groupCount as parent ELV's group's childrenCount but as I said, I'm not sure, I'm still working on it.

Proof:
When child ELV has only one group, there is not any problem. It is shown properly (except expanding the group). But. If I add another group to the child ELV, I can see a slice of the the second group. The little problem starts here.

----

If I say something about out of the subject, I don't understand why views are managed in adapters. If adapters are focused on data, what is the logic mixing data and views in adapters? Documentation is also another problem. Very very simple examples, unclear and short definitions... etc.

I think this is a completely Android's design issue and I'm angry with Android because of such things.

Personally, I do believe that Android focused on only smartphones in the begining and didn't consider tablets enough. But now, It is used on tablets widely. Tablets have larger screen. Larger screen increases people needs. Complex people needs require more sophisticated interface/data structure. Android really offers "weird" environment to developers.

I've been working on a "professional todo" project for a month. I've spent more time to figure out Android's logic with pulling my hair rather than writing code.

Sorry for that.

Anyway... If I achieve this, I'll post here.

Have a nice day...

 

[alostpacket]

I used to wonder about Adapters myself. But basically they function a lot like controllers in MVC.

They also technically are adapters in many cases where they are there to manage a cursor. So in essence, the Adapter concept is there because that class acts like an adapter plug or proxy to your Model (data/database).

Basically it is a helper class to define a set of functions that complex views might need to handle the data without knowing what the data is.

Anyways thanks for posting back, and good to hear you are making progress