Sepsis/inspector: Difference between revisions

Jump to navigation Jump to search
(→‎Where we're at: owner's manual)
Line 28: Line 28:
Best practices and other things to consider when writing a viewer:
Best practices and other things to consider when writing a viewer:


* The viewer's |subject| setter should not try to detect whether the subject is the same as the one it's already inspecting.  The Inspector's "refresh" command is implemented by sending to the viewer the same subject as the one it's already inspecting.  This is helpful if there are no APIs for observing changes to the subject in order to automatically update the viewer UI.  (If there *are* APIs for that and you're already using them, whether you detect this or not is moot, so go ahead and do that if you like.)
* The viewer's |subject| setter should not try to detect whether the new subject is the same as the one it's already inspecting.  The Inspector's "refresh" command is implemented by sending to the viewer the same subject as the one it's already inspecting.  This is helpful if there are no APIs for observing changes to the subject in order to automatically update the viewer UI.  (If there *are* APIs for that and you're already using them, whether you detect this or not is moot, so go ahead and do that if you like.)


* Be careful about implementing the viewer filter in such a way that it accepts or rejects an object based on that object's current ''state'', rather than the ''type'' of object it is.  There's no guarantee that your filter will be called again on an object that it initially rejected but that would now pass.
* Be careful about implementing the viewer filter in such a way that it accepts or rejects an object based on that object's current ''state'', rather than the ''type'' of object it is.  There's no guarantee that your filter will be called again on an object that it initially rejected but that would now pass.
Confirmed users
82

edits

Navigation menu