Interface StorageView<T>

Type Parameters:
T - The type of the stored resource. Experimental feature, we reserve the right to remove or change it without further notice. The transfer API is a complex addition, and we want to be able to correct possible design mistakes.
All Known Subinterfaces:
SingleSlotStorage<T>
All Known Implementing Classes:
BlankVariantView, FullItemFluidStorage, SingleStackStorage, SingleVariantItemStorage, SingleVariantStorage

@Experimental public interface StorageView<T>
A view of a single stored resource in a Storage, for use with Storage.iterator() or Storage.exactView(net.fabricmc.fabric.api.transfer.v1.transaction.TransactionContext, T).

A view is always tied to a specific transaction, and should not be accessed outside of it.

  • Method Details

    • extract

      long extract(T resource, long maxAmount, TransactionContext transaction)
      Try to extract a resource from this view.
      Returns:
      The amount that was extracted.
    • isResourceBlank

      boolean isResourceBlank()
      Return true if the getResource() contained in this storage view is blank, or false otherwise.

      This function is mostly useful when dealing with storages of arbitrary types. For transfer variant storages, this should always be equivalent to getResource().isBlank().

    • getResource

      T getResource()
      Returns:
      The resource stored in this view. May not be blank if isResourceBlank() is false.
    • getAmount

      long getAmount()
      Returns:
      The amount of getResource() stored in this view.
    • getCapacity

      long getCapacity()
      Returns:
      The total amount of getResource() that could be stored in this view, or an estimate of the number of resources that could be stored if this view has a blank resource.
    • getUnderlyingView

      default StorageView<T> getUnderlyingView()
      If this is view is a delegate around another storage view, return the underlying view. This can be used to check if two views refer to the same inventory "slot". Do not try to extract from the underlying view, or you risk bypassing some checks.

      It is expected that two storage views with the same underlying view (a.getUnderlyingView() == b.getUnderlyingView()) share the same content, and mutating one should mutate the other. However, one of them may allow extraction, and the other may not.