v0.2.6-alpha.3

Kotlin: Remove an attachment

attachmentRemove(reference) deletes one attachment's local queue row outright and answers the sandbox path whose bytes the app still has to delete. Unlike Cancel an attachment, the reference is gone afterward: nothing is left for a later drive or retry to pick up.

Examples#

Basic#

// app/src/main/kotlin/com/example/todo/TodoScreen.kt (excerpt)
import java.io.File

val path = kizunasync.attachmentRemove(reference)
path?.let { File(it).delete() }

Remove before deleting the row it belongs to#

// app/src/main/kotlin/com/example/todo/TodoScreen.kt (excerpt)
kizunasync.attachmentRemove(reference)
kizunasync.from("todos").delete().eq("id", todoId).execute()

Parameters#

Name	Type	Required	Description
`reference`	`String`	Yes	The value stored in the row's attachment column.

Returns#

String?. The sandbox path whose bytes the app still has to delete, or null when the row carried no local path or did not exist.

Errors#

Code	Condition
`STORE`	The row could not be written.
`ENGINE_UNAVAILABLE`	The bridge answered with an envelope carrying no code, which is not a gradeable failure.
`ENGINE_UNAVAILABLE`	The client has no engine because Initializing has not run.

Notes#

The engine only deletes the queue row; it never touches the filesystem itself, so a present return value is a path the app owns and must clean up. A second call against the same reference answers null, because the row is already gone.

This is a stronger operation than Vacuum attachments, which only sweeps bytes no row references any more: attachmentRemove acts on one reference the app names, at the moment it names it, whether or not the transfer ever finished.

This method reaches the kernel through the same JSON-RPC call every typed method uses underneath; it behaves like any other client method and raises the same KizunaSyncError.Engine.

← Cancel an attachment Vacuum attachments →

Found a problem? Edit this page on GitHub