Record Class SaveOutputs
- Record Components:
files- the app's output files, in display order.truncated- whetherMAX_VISITED_ENTRIESstopped the walk — the dialog says so rather than silently showing a short list.
What a SAVE produced: the files an emulated Swing app wrote into the temp
directory it was handed, in the order the download dialog lists them
([D_save_binds_download]). Pure — no Vaadin, no session, no I/O beyond the walk — so the
question "which files does this save offer, and which one goes on top" is
decided and tested on its own, apart from
BrowserFileTransfer's dialog and transfer mechanics.
The invariant everything here rests on: SessionTempFiles.newTransferDir()
hands out a fresh, empty directory per show, so every file found is
the app's output by construction — no heuristics, nothing to disambiguate,
and no way for one user's save to see another's.
-
Field Summary
FieldsModifier and TypeFieldDescriptionstatic final intCap on directory entries one walk visits. -
Constructor Summary
ConstructorsConstructorDescriptionSaveOutputs(List<File> files, boolean truncated) Creates an instance of aSaveOutputsrecord class. -
Method Summary
Modifier and TypeMethodDescriptionstatic SaveOutputsWalksdirunder the defaultMAX_VISITED_ENTRIESbudget.static SaveOutputsBreadth-first walk of a SAVE transfer directory.final booleanIndicates whether some other object is "equal to" this one.files()Returns the value of thefilesrecord component.final inthashCode()Returns a hash code value for this object.final StringtoString()Returns a string representation of this record class.booleanReturns the value of thetruncatedrecord component.
-
Field Details
-
MAX_VISITED_ENTRIES
public static final int MAX_VISITED_ENTRIESCap on directory entries one walk visits. Counts every entry touched, directories included — a tree of empty directories holds no files and would never trip a file-based cap, yet would be re-walked every 500 ms by the download watcher. Counting visits also makes a depth cap redundant: the walk cannot descend past what this budget allows.- See Also:
-
-
Constructor Details
-
SaveOutputs
-
-
Method Details
-
discover
Walksdirunder the defaultMAX_VISITED_ENTRIESbudget. -
discover
Breadth-first walk of a SAVE transfer directory.Breadth-first is what makes
visitCapmeaningful: you get the shallowest entries, which are the likely outputs, where a depth-first walk could spend the whole budget inside the first subdirectory. The shape that motivates it: an app that builds a large tree and then zips it writes the one file that matters at the root.Ordering is deterministic and stable under a growing file, because the download dialog reconciles rows rather than rebuilding them and a shifting order would move rows under the user's cursor — which is why modification time and size are not sort keys. Files come out ordered by depth (root before nested), then by parent directory, then within a directory by
inFolderOrder(String).Symbolic links are neither followed nor offered: a link loop would spin the walk, and there is no case where following one is what the migrated app meant. Directories are traversal only — they never become download rows.
- Parameters:
dir- the transfer directory; null or unreadable yields an empty result rather than an error.promptedName- the name typed at the save prompt, used only for the match-first ordering rank; blank means "no signal".visitCap- maximum directory entries to visit, counting directories.
-
toString
-
hashCode
-
equals
Indicates whether some other object is "equal to" this one. The objects are equal if the other object is of the same class and if all the record components are equal. Reference components are compared withObjects::equals(Object,Object); primitive components are compared with thecomparemethod from their corresponding wrapper classes. -
files
-
truncated
-