Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InfiniteContainer change fetchMore() to protected #2721

Closed
Nightbringer42 opened this issue Feb 25, 2019 · 6 comments

Comments

@Nightbringer42
Copy link

commented Feb 25, 2019

Would it be possible to change the modifier of the fetchMore() method of the InfiniteContainer component to protected ?
The idea behind this is to be able to control if the component must wipe all components it contains or not to avoid data collision in successive Rest calls.
The method used here is to throw a custom RuntimeException in the fetchComponent(int index, int amount) if the data is outdated and catch that Exception in refresh() (already done and working) and in fetchMore(). The throw force the component to abort the process of wiping components and works pretty fine with refresh(), however we ran into some (rare) cases when the fetchMore() was receiving this Exception but of course was not able to catch it, so the exception was showing to the user.
The change could permit us to override the method without copy-pasting the whole component to a new class and so without the need of checking if any part of the code has change between updates, just for a small protected modifier.

If you have a prettier solution, I'm of course open to suggestions 😃
Thanks in advance.

@codenameone

This comment has been minimized.

Copy link
Owner

commented Feb 27, 2019

I don't understand the description of the use case?
I understand you have a rest call in progress and something happens?
fetchMore is pretty problematic as it's very much an implementation detail that accesses internal state.

@Nightbringer42

This comment has been minimized.

Copy link
Author

commented Mar 1, 2019

Our use case is an InfiniteContainer linked to a searchCommand from Toolbar.
The container contains the logic to fetch data from our server at the beginning of the fetchComponent() method.
The searchCommand call a refresh() of the container each time something is typed in the search bar.
We store the value of the current search before calling the rest service and compare the stored value with the value actually searched.
If they differ, we throw a custom RuntimeException. This RTE is catched within the overrided refresh(), which is just a call to super.refresh() surrounded by a try-catch block.
In a perfect world, the RTE should be throwed only on a refresh() call, but we ran once into a case were this RTE was thrown by the fetchComponent() called by the fetchMore().
And if it happened once, it could happened twice, so we would like to override the fetchMore() to encapsulate it within a try-catch block in order to catch our RTE.

The use of the throw-catch here is used to ignore the

if (components == null) {
    components = new Component[0];
}

which is called after fetchComponent(). And in the refreshImpl() method, it allow to ignore the removeAll().
Maybe creating a fetchMoreImpl() method like it's done with refreshImpl() would do the trick.

This is somewhat linked to this SO post.

@codenameone

This comment has been minimized.

Copy link
Owner

commented Mar 10, 2019

I don't understand why you need to throw a RuntimeException instead of just returning the cached results?

@slibert

This comment has been minimized.

Copy link

commented Mar 11, 2019

IMHO in a real world app, we have to be prepared to :

  • slow server connection
  • smooth mobile-app UI refresh

As said in previous comment it's quite easy to stop the code before it refresh the UI for nothing.
Imagine five concurrents calls to a slow webservice, user's UI would refresh 5 times. And what if the user had time to scroll down the list so the refresh make the list goes up. Not really user friendly.

I see three advantages using a custom exception :

  • No waste of memory storing a component's cache
  • No UI refresh / redraw if it is not useful
  • Easier to code and read

Below a sample code


		InfiniteContainer container = new InfiniteContainer(amount) {
        	@Override
        	public Component[] fetchComponents(int index, int amount) {

        		ArrayList<Binder> list = null;

        		String currentWord = word;
        		if(word == null){
        			list = RestManager.getListBinders(index,amount);
       			}
        		else {
                    		list = RestManager.getSearchedBinder(index,amount,word);
       			}

        		if(currentWord != null) {

    	    		if(currentWord.compareTo(word)!=0) {
    	    			throw new OldRequestException();
    	    		}
                    
        		}

        		Component[] more = new Component[list.size()];
        		int i=0;
        		List<Component> compos = new ArrayList<>();

        		for(Binder p:list){
        			MultiButton mb = new MultiButton(p.getLastname()+" "+p.getFirstname());
        			compos.add(mb);

        			mb.addActionListener(new ActionListener() {
        			    public void actionPerformed(ActionEvent ev) {
                            <snip>
        			    }
        			});
                    
        			mb.setTextLine2("Detail ...");
        			i+=1;
        		}	
                
        		scrollComponentToVisible(this);

        		more = compos.toArray(more);
        		return more;
        		
        	}

        	//FIXME: Override also FetchMore()
        	@Override
        	public void refresh()
        	{
        		
    	    	try
    	    	{
    	    		super.refresh();
    	    	}
    	    	catch(OldRequestException e)
    	    	{
    	    		Log.p("Old request, just ignore it.");
    	    	}
        	
        	}
        };    

Instead of changing fetchMore to protected, or make a fetchMoreImpl function, you could also take care of the exception directly in the InfiniteContainer, some CN1IgnoreRequestException, that we could just use without overriding any function. Quite easy to implement as only two functions are involved.

Best regards
Sebastien

@codenameone

This comment has been minimized.

Copy link
Owner

commented Mar 13, 2019

I see, that use case makes sense. I agree that an exception might not be the right thing for this...
We need a cancel refresh method/callback or a decent strategy for an impatient/bad connection user.

@codenameone codenameone self-assigned this Mar 13, 2019

@codenameone codenameone added this to the Version 7.0 milestone Mar 13, 2019

@codenameone

This comment has been minimized.

Copy link
Owner

commented Jul 12, 2019

I've given this some thought. I think a better approach would be to add a button like "Error: Retry".

Then we would need. a way to "continue" from the same spot if that button is clicked. So essentially the code should be something like this:

// on error
SpanButton errorButton = new SpanButton("Networking Error, Press to retry");
errorButton.addActionListener(e -> {
     errorButton.remove();
     continueFetching();
});
add(errorButton);
return null;
DurankGts added a commit to DurankGts/CodenameOne that referenced this issue Jul 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.