Skip to content

FirebaseArray in FirebaseListAdapter is not accessible from subclasses #206

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

Closed
davideno opened this issue Jun 30, 2016 · 11 comments
Closed

Comments

@davideno
Copy link

davideno commented Jun 30, 2016

Situation

You have a mobile app with Firebase as backend
you would like to view all the items in firebase location as cards in UI
you would like to remove some items just from the UI
(imagine a UI like Tinder app where a user can remove a card from UI and see the other cards in the list, where cards are items in Firebase db but they are not deleted when removed from UI)

Problem with FirebaseListAdapter

I use the FirebaseListAdapter as explained in the tutorial and I can easily retrieve the items from firebase and display them in the UI.
I don't know how to remove items from UI without removing it from Firebase too. The code below remove items from the Adapter but also from firebase.

Firebase itemRef = adapter.getRef(position);
itemRef.removeValue();

I think the only way to remove items from the adpater without removing the firebase reference is to have access to the FirebaseArray used in the FirebaseListAdapter.

Proposed solution ?
Have the FirebaseArray protected so that when implementing our CustomAdapter we can have access to the FirebaseArray and remove items from it.

@puf
Copy link
Contributor

puf commented Jul 6, 2016

In general we kept filtering data out of FirebaseUI until we're ready to implement that feature properly (see #15). The potential for problems is quite big if you start manipulating the FirebaseArray. For example: how would you deal with move operations or other operation that require looking up an item by its key? While these questions may not apply to your use-case, the library is made to work equally for all of them.

How would you use the array in your custom adapter subclass?

@davideno
Copy link
Author

davideno commented Jul 20, 2016

Hi Frank
sorry for the late answer. I understand your point and I then changed the UI of my app so that now I have a list of elements (with LinearLayoutManager) and they are always visible with the user scrolling down, so I don't need anymore to "hide" elements of the list.

Knowing better Firebase than before I think one possible solution of my original problem would be to keep a reference on Firebase through index (ex: "card already seen") and update the original list checking always against the boolean "card already seen".

Thanks!

@pantos27
Copy link

pantos27 commented Jul 28, 2016

@puf
I would also love to see FirebaseArray exposed

I'm using a RecyclerView with a long list of items
I would use it to retrieve the row number of a certain item using a search query on one of it's fields
+It's exposed in iOS, why not equal rights? ;)

@samtstern
Copy link
Contributor

@pantos27 you should be able to track the row index of items by creating a Map<Integer,Object> and populating it whenever you get a call to populateViewHolder. Then you're only tracking items the user has actually seen, which in most cases are the relevant parts anyway.

Also the iOS comparison isn't exactly fair since Objective C doesn't really have access modification like Java has 😄

@pantos27
Copy link

@samtstern interesting idea.
Though I'm not sure it would help in my case since I need to search the entire list synchronously, even for items not yet displayed to the user
I can pull the entire list to a map but that would be a bit cumbersome
Is there a way to use FB cache to access the snapshot?
Maybe just expose certain funcs like get item at a certain index or key?

@samtstern
Copy link
Contributor

@pantos27 FirebaseRecyclerAdapter already exposes the methods you likely want:

    @Override
    public int getItemCount() {
        return mSnapshots.getCount();
    }

    public T getItem(int position) {
        return parseSnapshot(mSnapshots.getItem(position));
    }

@pantos27
Copy link

@samtstern right you are!

It's not not exactly what I need but it gave me an idea
Retrieving by key would be a great addition still

Thanks

@samtstern
Copy link
Contributor

samtstern commented Jul 28, 2016

@pantos27 I like when someone asks a question I have a good answer for. You can get the key using this method from FirebaseRecyclerAdapter:

public DatabaseReference getRef(int position) { 
    return mSnapshots.getItem(position).getRef(); 
}

So it looks like String keyAtPosition = getRef(i).getKey(). Boom!

@pantos27
Copy link

@samtstern Nice, but it's not retrieving by key.
You still have to iterate through it all until you find the right one

@puf
Copy link
Contributor

puf commented Jul 28, 2016

If you're trying to find the position of an item in the recycler view that
matches certain condition, it has little to do with Firebase/FirebaseUI.
Just loop over the rows until you find the item that matches your
condition. Since the data is already client-side, it won't occur network
traffic.

If that is not what you're trying to do, it'll probably be easier to help
if you show the code you struggle with.

On Thu, Jul 28, 2016 at 11:16 AM Amir A [email protected] wrote:

@samtstern https://github.com/samtstern Nice, but it's not retrieving
by key.
You still have to iterate through it all until you find the right one


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#206 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3w3x8calfTiaXTnHE6WMnp-_2yo3O_ks5qaPH7gaJpZM4JCCV_
.

@pantos27
Copy link

pantos27 commented Aug 3, 2016

@puf you're right.
@samtstern 's solution should do the work very

Thank you both!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants