I am developing a shiny application (shiny-server) which in last instance should be able to allow downloading files (which are hosted in a directory in the server) to the local directory of a user.
I have been looking for this but I have not been able to find a solution so I have started wondering if it is actually possible.
Thank you very much, any help will be very valuable!
You can do this with a normal download button as suggested by #Sumedh
ui.R
downloadButton("demo", "Download")
server.R
output$demo <- downloadHandler(
filename = function(){
paste("demo","txt",sep=".")
},
content = function(con){
file.copy("some-file.txt", con)
})
Related
I have a shiny app that I deployed as a library. Inside my shiny app, I write a json file in real time, I want to write this file in the working directory of each user. Nevertheless, the file is written in the directory of the library.(Please refer the code below)
app.R
library(Tree)
ui <- htmlTemplate("www/Tree.html",
text_output = tableOutput("table2")
)
server <- function(input, output, session){
# This block fires each time we receive a message from JavaScript
output$table2 <- renderTable({
#Write json file
json_value = input$jsonData
write(json_value, paste0(getwd(),"/",fileName, ".json"))
})
}
# Run the application
shinyApp(ui , server)
I though that with the function getwd()I will be able to see my json file in my working directory but taht is not happening. My json file is written in the directory of the library
This directory
/Library/Frameworks/R.framework/Versions/4.0/Resources/library/Tree/
How can I change my code to be able to see my jsonfile in the RProject which the user wants to work?
A shiny app is running in your browser and, as a concequence, subject to strict safety regulations imposed by the browser. There are plenty of restrictions regarding the file system to make sure that web pages cannot freely roam your hard drive. That is why there might not be a solution with a good user experience to achieve what you want.
The safest solution would be the download button (as suggested by #HubertL).
If you want to work with the users' home directory you can get the path with file.path(Sys.getenv("HOME")) (at least on Windows it works). Now you can work with that path. Use OutputPath <- file.path(Sys.getenv("HOME"), fileName) to create the path %HOME%/fileName.
The third alternative (I can think of) is a simple textInput. Users can paste a string there that represents the path to the directory where they want the file to be stored. Check the string with dir.exists and use it if it is valid.
I made a relatively elaborate Shiny app for my job that runs great locally. However, I am trying to host the app so that users who don't have R Studio downloaded can access it. I cannot get the app to run through shinyapps.io. It seems this is mostly related to the fact that it cannot find the files that are located on Dropbox. The app is based almost entirely on loading and writing files on Dropbox. I tried to change the file paths and use rdrop2 to load the files, but it changes the formatting of some things and would be pretty complicated to reconcile as far as I can tell. I'm very much a novice programmer and the thought of having to restructure the entire app is giving me a bit of anxiety and will certainly require a fair amount of effort. Does anyone know of a more "simple" way to modify files located on Dropbox through a shiny app hosted on shinyapps.io, preferably while still able to use the "openxlsx" package? Thank you very much in advance.
One workaround I thought might work but didn't was to make the file path to the Dropbox file specific to the user because anyone using the app should have access to Dropbox:
this.data <- as.data.frame(read.xlsx(paste("C:\Users\", Sys.info()[["user"]], "\Dropbox\rest of the file path", sep = "")))
Disclaimer : I would not recommend relying on google-unsubmmitted URLs to guarantee privacy.
Modify the share link copied from DropBox replacing dl=0 by dl=1 to make the download start rather than display in DropBox UI.
You can then download.file() into a tempfile() before read.xlsx() it:
library(shiny)
library(openxlsx)
library(DT)
ui <- fluidPage(
titlePanel("XL Read from dropbox"),
mainPanel( DTOutput("dt"))
)
server <- function(input, output) {
tmpfile <- tempfile(fileext='.xlsx')
download.file(url = "https://www.dropbox.com/s/1v0l...5u803a9hg/my_file.xlsx?dl=1", destfile = tmpfile , mode="wb")
output$dt <- renderDT(read.xlsx(outfile))
}
shinyApp(ui = ui, server = server)
I'm building a shiny app that create multiple files depending on the uploade file by the user. The created files has the same names and this can make that when a user download the files end with a none relative information to his data.
How can be created an independent directory for each user in Shiny app?
I have found the next solution so far to create the directory to store the files:
directory <- paste0(format(Sys.time(),"%Y%m%d%H%M%S"),rnorm(1),
rnorm(1))
dir.create(directory)
setwd(directory)
But I have read that this may not work if I upload the app to a server. How should I do it?
This is the answer that I get in RStudio community and worked for me:
By #pieterjanvc from RStudio community:
Setting the working directory is likely not going to work like that in Shiny. I suggest you generate a folder based off the user's session token, which is generated when a user connects to a Shiny app and located in the session variable.
library(shiny)
ui <- fluidPage(
)
server <- function(input, output, session) {
dir.create(session$token)
file.create(paste0(session$token, "/userFile.txt"))
}
shinyApp(ui, server)
Once you created the directory, you can save any file in that one using again the token which is the name of the base folder for that user. You should remember to erase the folder after the task finished, or you will have a lot of folders soon.
I would like to include a local image file in my shiny app, following these instructions:
Embedding Image in Shiny App
However, my IT networks security, for some reason, prevents R from reading that image.
I can confirm it is an IT security blockage, because the same exact code and file/directory structure works when I move to another computer.
It is also strange, because I am able to read other files from that folder, because other commands like read.csv() are not blocked. I dont know what subroutines go on inside img(src()) but my network does not like it.
Any alternative ways to embed an image in a shiny app ui?
Maybe with base64 encoding:
b64 <- base64enc::dataURI(file="myfile.png", mime="image/png")
ui <- fluidPage(
img(src=b64)
)
server <- function(input, output) {
}
shinyApp(ui = ui, server = server)
Where myfile.png is in the same folder as the app.
Can files be uploaded to server using the shinyFiles package? I'm looking for similar functionality to the standard fileInput from the shiny package. The closest thing I could find in shinyFiles:
app.r
library(shiny)
library(shinyFiles)
server <- function(input, output, session) {
shinyFileSave(input, 'save', session=session, roots=c(wd='.')) }
ui <- bootstrapPage(shinySaveButton('save', 'Save', 'Save as...'))
shinyApp(ui=ui,server=server)
But this only allows me to browse the server files (not local) and even when I save I don't see the file created.
The short answer is no (sorry about that)... shinyFiles is simply a browser for the server file system, mainly intended for use when a shiny app is meant for local use (to avoid the overhead of file copying required in native web implementations).
The functionality of shinyFileSave is simply to let the user specify a non-existing filename at a certain location and pass that information back to the server - It's up to the server logic to handle that information in a meaningful way, by creating a file at the specified location.
You could somehow couple shinyFileSave and fileInput to upload a file and put it in a specific location, but the UI for this would probably be quite messy as it would inevitably mix shinyFiles/Bootstrap ui with native ui elements. As the local filesystem is guarded from Javascript code for security reasons this would be the only approach though as long as the server and client resides at different locations...