Say the user wants to save the configuration of the application so that the next time they want to run the calculations they don't need to import everything again. This would be beneficial for two reasons:
It eliminates repetition and thus errors.
It allows us to add more advanced and extensive options to the program without fear of overwhelming users with settings.
Right now, shiny v0.14 supports bookmarking. Bookmarking makes it very easy for us to save user input (it's really just calling two functions). However, the mechanism that shiny implements for saving is not conventional for desktop applications. Basically, bookmarking works like this:
The user does some work and configures the program to their liking.
The user hits the Bookmark button and the shiny server saves the application state to disk. Then it provides the user with a link.
The user must save the link somewhere to regain access to the configuration they left behin.
Right now, bookmarking has a few shortcomings:
It's not as straightforward to save input files as it is to save simple inputs like checkboxes.
This could be solved by implementing custom bookmark/restore rules and/or serialisation protocols. See [1].
The application is not fully reactive, meaning that the output at a given time cannot be derived from the input at that moment. In our case, this is due to the exclusion power being calculated after the user hits the Calculate exclusion power button instead of calculating it on the fly when input changes.
This could also be solved through [1].
Saving multiple times will result in multiple R datastores being saved to disk. This could end up consuming a lot of space.
See note at the end.
Because R datastores are saved to the inst folder, saving will fail if the user has installed the package in a folder that requires admin access for writing. This might be the case when forrel is used in corporate or lab environments.
For the same reason, updating forrel will likely result in total loss of saved workspaces as the inst folder will be replaced.
This can be probably solved in a shady way by providing an option to download a .zip file of all saved workspaces and then having users restore it when they upgrade to a new version.
Restoring a workspace requires pasting a URL in the browser. This in turn presents two problems:
RStudio users will not typically open their apps in the browser but rather in a window inside RStudio that does not allow them to input a URL manually.
Maybe there is an API that allows restoring an arbitrary datastore from its hash. This needs to be researched.
The shiny server port might change without notice rendering all URLs unusable and thus saved data inaccessible.
See note at the end.
Because shiny runs on a browser and files are uploaded rather than accessed through the filesystem, if users make changes to database, pedigree or reference files, these will not be reflected in the GUI project or workspace if the user does not re-upload them manually.
There is no straightforward way to fix this. Browser sandboxing prevents random access to the filesystem. Maybe the latests set of web standards has defined an API for this but in any case it would require major work to work with shiny. Anyway, maybe this is not so bad as it seems to me -- users may not be as confused as I think they'll be if their data is not updated when changing the source files.
Other forms of saving application state are not straightforward either. Some of the prior problems still apply, namely those that require interaction with the filesystem. Also, because of the reactive programming paradigm of shiny apps, saving/restoring state is not trivial for some input objects.
Note at the end: one way to solve these two problems at once can be to not show the user the URL after saving (can be done by overriding onBookmarked). Instead, when users want to restore a workspace, they would be presented with a modal containing a list of all saved workspaces. This list can be obtained by listing the contents of the directory in which datastores are saved (inst/exclusionPowerUI/shiny_store). Furthermore, we could allow for only one workspace to be saved at a time, thereby also eliminating the problem with too many saved workspaces filling up space.
Say the user wants to save the configuration of the application so that the next time they want to run the calculations they don't need to import everything again. This would be beneficial for two reasons:
Right now,
shiny v0.14supports bookmarking. Bookmarking makes it very easy for us to save user input (it's really just calling two functions). However, the mechanism that shiny implements for saving is not conventional for desktop applications. Basically, bookmarking works like this:Bookmarkbutton and the shiny server saves the application state to disk. Then it provides the user with a link.Right now, bookmarking has a few shortcomings:
Calculate exclusion powerbutton instead of calculating it on the fly when input changes.instfolder, saving will fail if the user has installed the package in a folder that requires admin access for writing. This might be the case when forrel is used in corporate or lab environments.instfolder will be replaced..zipfile of all saved workspaces and then having users restore it when they upgrade to a new version.Other forms of saving application state are not straightforward either. Some of the prior problems still apply, namely those that require interaction with the filesystem. Also, because of the reactive programming paradigm of shiny apps, saving/restoring state is not trivial for some input objects.
Note at the end: one way to solve these two problems at once can be to not show the user the URL after saving (can be done by overriding
onBookmarked). Instead, when users want to restore a workspace, they would be presented with a modal containing a list of all saved workspaces. This list can be obtained by listing the contents of the directory in which datastores are saved (inst/exclusionPowerUI/shiny_store). Furthermore, we could allow for only one workspace to be saved at a time, thereby also eliminating the problem with too many saved workspaces filling up space.References
[1] http://shiny.rstudio.com/articles/advanced-bookmarking.html