Implement a resetState() function for objects which describe a specific state in the views in order to guarantee disassociation from old file data when loading a new file.

USE CASE: WHAT DO YOU WANT TO DO?

When loading a new file, it is critical that the major file specific objects (describing a state in the views) are first completely reset and then potentially adjusted for saved preferences when a new file is loaded. This has always been implemented and used with TVModel and works well.

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

N/A

CURRENT BEHAVIOR

Final objects (MapContainers) are not properly reset, non-final objects may keep lingering in memory limbo after new objects are initialized (TreeSelection) for a new file until Java garbage collector decides to deal with them.

Objects may thus carry over remnant states in their member variables from old files which can result in severe problems.

Also, final objects like the MapContainers can never be newly initialized, so resetting them via a method is the way to go since using one initialized object is easier to handle and test in the case of DendroView (mostly because setting up the layout often requires objects to already exist). Most importantly, this way we can guarantee that no old settings interfere when a new file is loaded and that crucial objects are never null!

EXPECTED BEHAVIOR

Simply the same behavior that TVModel always had. There is one TVModel object per matrix and if a new file is loaded, it will be reset before the new data is loaded back in. This should be implemented in MapContainer + TreeSelection and potentially some view classes that rely on a file specific state (labels).

This helps immensely to guarantee a clean move from old file to new file without accidentally dragging old data baggage along.

File specific objects should be reset to a default state in RAM after closing an old file. When the new file is loaded into RAM, those objects can then be used in any case without issues because they always have a guaranteed default state that should always work (unless severe bugs occur - should be avoided by exception handling + unit testing).

Then, if applicable, the objects' state can additionally be adjusted according to previously saved preferences by querying the relevant node. Once all objects are set properly the new file can be shown to the user. s

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

For all files listed below, Implement a resetState() function which sets default/ universally applicable values for all of its class' member variables.

FILES AFFECTED (where the changes will be implemented) - developers only

(List might not be complete) - if applicable, call method on all objects of the individual classes (each axis)!

1) MapContainer.java

2) TreeSelection.java (currently new objects are created for new files but this should be changed to use final selection objects to guarantee only one copy for each axis in memory).

3) Possibly LabelView.java and other view classes since they describe a file specific state (label size, orientation etc.)

LEVEL OF EFFORT - developers only

medium

COMMENTS

TreeView 3 and showing multiple matrix files?

Final declared objects that exist only once in memory would need to be handled correctly if we still want to be able to open multiple matrices. Only their references in DendroView and related classes could be declared final and then be reused by resetting their state if a new file is opened and the old file is closed.

If we want multiple parallel matrices as TreeView 2 allows (open new file and keep old) then we'd need the relevant objects declaration to be non-final before being passed to their specific instance of DendroView (each matrix has its own view). Loading a new file here would not require a reset of state because brand new objects from a pre-DendroView level are used (e.g. exactly 2 new selection objects, 4 new MapContainers -> 2 interactive, 2 global, 1 new LabelView etc.).

Comments (9)