Android studio, using firebase realtime database and storage, how to re-arange list

I am saving an array list at the realtime database, and I want to add an option for the user to select and delete an object, for examples I have 5 objects (indexes 0 to 4) and I want to delete index 2. The question is how I can re-arrange the list at the database because if I will not do so there will be a gap, I will have the indexes 0,1 and then 3,4. Every object have url of images that I uploading to the storage and I save them at indexes of the same indexes as the object.
At bottom line I want to re-arrange the list at the storage and the real-time database, it is possible? if so, how?

I tried to override the list reference with the updated array list from the model it self, and it works obviously but the problem is with the storage mostly.

For example:

I have 5 claims at the database:

And the same 5 indexes at the storage with the images

So if I would like to delete index 2 and then make it to be 0 to 3 with no gaps.

In your current setup, removing a key from the sequence means that you have to renumber all the keys after it. There is no way around this without changing your data structure, so the common approach would be to read the claims node, change it in your application code, and write the entire claims node back to the database.

My recommendation is to not use sequential numeric values for the keys in your Firebase Realtime Database, precisely for the reasons you mention. In fact, using sequential numeric keys is documented anti-pattern, for example in this blog post from 2014: Best Practices: Arrays in Firebase.

The better way to model this ordering is to store a value in each child nodes that indicates its relative position. Initially that value could be the value that you now use as a key, but then as a floating point value. So:

"claims": {
  "-Nasdak...": { // 👈 push key
    "index": "1.0",
    ...
  },
  "-Nbisai..": { // 👈 push key
    "index": "2.0",
    ...
  },
  "-Ncsadu...": { // 👈 push key
    "index": "3.0",
    ...
  },
}

So this uses push IDs for the keys, and stores the relative index in a property under each key. With this structure you can:

• Use orderByChild('index') to get the ordered result.
• Remove any index, and the result will still work.
• Move an item to a different position, by making its index value the middle between the two (new) neighboring nodes.

An example for that last operation: say that we move the first node in the above example to between the other two nodes, the result would be:

"claims": {
  "-Nasdak...": {
    "index": "1.5", // 👈 changed value
    ...
  },
  "-Nbisai..": {
    "index": "2.0",
    ...
  },
  "-Ncsadu...": {
    "index": "3.0",
    ...
  },
}

Nothing but that one index value changed here.

The only think to keep in mind with this approach is that this only works for a certain number of swaps (depending on your platform) until you run into floating point precision limits. I usually don't reach such limits yet, and in the cases where I worried - an occasional re-indexing (time-based or swap-count based) - solved it.

For the folders in your Cloud Storage bucket, I would actually just add the name/path of the folder into the relevant node(s) in the database:

"-Nasdak...": {
  "index": "1.5",
  "storageFolder": "path/to/folder" // 👈
  ...
},

Using a name/path not related to the key means that you will have to look up that path, but that's a constant cost - while having to move/rename folders in Storage will be much worse as most of these systems don't really have native move operations. For example, on platforms where Cloud Storage SDKs implement a move API, it is implemented as a copy/paste/delete-original-data sequence.