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

Nightbringer42 opened this issue Feb 25, 2019 · 6 comments


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.


This comment has been minimized.

Copy link

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.


This comment has been minimized.

Copy link

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.


This comment has been minimized.

Copy link

commented Mar 10, 2019

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


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) {
        	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());

        			mb.addActionListener(new ActionListener() {
        			    public void actionPerformed(ActionEvent ev) {
        			mb.setTextLine2("Detail ...");

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

        	//FIXME: Override also FetchMore()
        	public void 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


This comment has been minimized.

Copy link

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


This comment has been minimized.

Copy link

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 -> {
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
None yet
3 participants
You can’t perform that action at this time.