#13 Nested PlaceHolderView: rapid scroll up and down cause crash

[Anonymous]

Originally created by: jjhesk

There is an dimension issue when scrolling up and down on the placeholderview.

com.mindorks.placeholderview.PlaceHolderView#onMeasure() did not set the measured dimension by calling setMeasuredDimension()

It seems to be too heavy when calling refresh on the parent placeholderview when the child has an update on the dimensions and items.

I think the problem would be better to ask how to make the parent placeviewholder to refresh at the marked child placviewholder.

[Anonymous]

Originally posted by: janishar

@jjhesk You have two methods for that in 0.2.7

1. <t>void refreshView(T resolver): This will refresh the child placeholderview. Pass the instance of the class containing child placeholderview. Call mainPlaceholderview.refreshView(obj)</t>
2. public void refreshView(int position): This will refresh the child placeholderview after new data is added based on the position of child placeholderview in the mainPlaceholderview.
3. 1. <t>int getViewResolverPosition(T resolver): This will give the position of the class object which is added as the child placeholderview in the mainPlaceholderview, even before the item view is binded to the window.</t>

[Anonymous]

Originally posted by: jjhesk

I think this is a possible leak from recyclerview. Still not sure why it will crash after several scroll up and down.

[Anonymous]

Originally posted by: janishar

@jjhesk Please use this only

mProfileList.getBuilder()
                .setHasFixedSize(false)
                .setItemViewCacheSize(5)
                .setLayoutManager(new GridLayoutManager(mContext, 4, LinearLayoutManager.VERTICAL, false));

In stead of

mProfileList.getBuilder()
                .setHasFixedSize(false)
                .setItemViewCacheSize(5)
                .setLayoutManager(gridLayoutManager);

I checked that, providing the global gridLayoutManager onResolved was the reason from
com.mindorks.placeholderview.PlaceHolderView#onMeasure() error.

[Anonymous]

Originally posted by: jjhesk

@janishar As you have suggested the optimization in [#11] will have to revert because having any kind of layout manager initialized at the constructor will lead to placeholderview on measure error crash.

[Anonymous]

Originally posted by: janishar

@jjhesk I have created a demo project:
This project has 4 child placeholderview in the main placeholderview
the repository for the project: NestedPlaceHolderView

This project fetch google news and show in the the child placeholderview's

[Anonymous]

Originally posted by: jjhesk

@janishar thank you for the example supports. I have noticed that you have commented out the animation on the class.@Animate(Animation.CARD_LEFT_IN_DESC) are there any significance or caveat?

[Anonymous]

Originally posted by: jjhesk

@janishar looks like this code shown as below is a kind of self automation.

    private final int DO_NOTHING = 0;
    private final int ADD_VIEW = 1;
    private final int UPDATE_VIEW = 2;

    private HashMap<GridItemView, Integer> listItemGoogleNewsMap;

...

 for(GridItemView gridItemView : listItemGoogleNewsMap.keySet()){
            switch (listItemGoogleNewsMap.get(gridItemView)){
                case DO_NOTHING:
                    break;
                case ADD_VIEW:
                    mainListView.addView(gridItemView);
                    listItemGoogleNewsMap.put(gridItemView, DO_NOTHING);
                    break;
                case UPDATE_VIEW:
                    mainListView.refreshView(gridItemView);
                    listItemGoogleNewsMap.put(gridItemView, DO_NOTHING);
                    break;
            }
        }
...


                    new Handler(Looper.getMainLooper()).post(new Runnable() {
                        @Override
                        public void run() {
                            for(GoogleNews.entry entry : googleNews.getResponse().getFeedData().getEntryList()){
                                listItemGoogleNewsMap.put(new GridItemView(entry), ADD_VIEW);
                            }
                            newsListView.refreshView(RowListView.this);
                        }
                    });

Is that a good idea to wrap them into annotation so the implementation of late update event has less lines?

[Anonymous]

Originally posted by: janishar

@jjhesk No there is no particular reason to comment those lines. It was just that the news example required no animation as such. Do try the example by commenting them out too. Thanks

[Anonymous]

Originally posted by: janishar

@jjhesk I think the framework should be generic and the control should be in the hands of the programmer.
Above example is just one of the solutions for not repeating addition of views when the parent view is re bound to the window.

The recyclerview uses the same view type to repopulate the views, so it requires the view to re make whenever it come in the bound state. Hence this method will be called every time the binding takes place and any addView written will add that view every time it is called.

How will such an annotation be designed I am not able to visualise. Annotations are metadatas and will not be changed dynamically. So how that will work if you want to add or refresh with updated data of the view depending on conditions and based on annotation?

If you have any suggestion do share.

Thanks