ISoP ISoP on Twitter | ACoP ACoP on Twitter | PAGE | WCoP | PAGANZ | PAGJa

Introduction to the Shiny Framework for Pharmacometrics


Title: Introduction to the Shiny Framework for Pharmacometrics
Presenter(s): Jessica Wojciechowski
Date(s): May 20, 2016
Time: 12:00 pm EST
Shiny Tutorial paper as published in CPT:PSP
Background Resources for the Audience:
Files: (2.0 KB)
Video link -

Related Topics:
Building Pharmacometric Applications using R: An online R Shiny Tutorial:

ISOP Shiny Server Information:

About the ISOP Pharmacometrics Study Group

  • Do you have lab-meetings and learning tutorials in-house in your academic group, company or your neighborhood?
  • Do you know that not all institutes have the same critical mass of pharmacometric experts as yours?
  • Pharmacometrics Study Groups is a platform to share your learning experiences with peers all around the world. Turn those in-house lab meetings to global knowledge and skill sharing opportunities! .

How it Works: All events will be broadcast live via “Google Hangouts” and detailed notes will be uploaded to the ISOP github site.

Discussion and Questions During the Meeting: You can ask questions by using the Reply Button below here in the Discuss Forum. The presenter will check back to the page during and at the end of the presentation to address questions.

Duration: Generally the study groups are of about 20-40 minute duration. if you need longer, consider having two study group sessions!

Where to Sign up or Suggest an Event Topic:


Please post your questions for today’s discussion here!


ISOP maintains a shiny server for ISOP members who would like ISOP to host non-proprietary apps. Jinzhong Liu has agreed to administer the ISOP Shiny site. Send your material as a zip file (maintaining any file structure that is required) to who can upload the materials to the server and help to ensure that your application is working correctly.

More information at


In your experience, how well does Shiny work with apps that take along time to run? Is their a way to indicate if an app is running, for example, during a long simulation or during fitting?



I will have a poster about this at ACoP to demonstrate in more depth some of the techniques, however to answer your question, simulating with shiny for long running processes is a bit of a double edged sword. On one hand, shiny achieves its reactivity by simulating an event loop of sorts - that is to say it checkpoints across all the things it is watching to see if anything has changed and then appropriately responds. This gives you the power to do some things that aren’t available in native R, such as dynamically responding to user interrupts (base R really only allows you to cancel/exit). The downside is, the concepts can be nontrivial to wrap your head around to make it work properly.

For example, in order to checkpoint for user exiting prematurely, it means you have to stop iteration. One thing that makes R fast is it vectorizes its calculations to C, however if you are stopping, you can’t use a single vector. In the simplest things you can just use good old R iteration

for(i in …) {


but if you are going through a lot of reps or rows in a dataframe etc, it can be on the order of 10-10000x slower than the vectorized counterpart. So now you have different options at hand, for example, you can ‘chunk’ vectors where you say every 10 or every 100 reps check for input. These are more design + programming decisions that to evaluate can take more time and thought to implement “optimally”.

So, is there a one-off function that you can just plug in and it “just works”, not really, though if someone on the team understands some of the more ‘under-the-hood’ aspects of R and the tradeoffs, you can do some really fun stuff.

Lastly, the other thing that I will call a side-effect negative of shiny, that isn’t really a fault of shiny itself, is if the developer of the app does not appropriately bound how the inputs are managed for simulations, then a user can accidentally grind to a halt or completely crash shiny apps very easily. For example, if you hook up a slider to a process that is long running, and they drag the slider all over the place, it might fire off a whole bunch of calculation requests. This must be migitated by things like debouncing inputs (for example, keeping the slider value from broadcasting a change until a certain amount of time has passed where it isn’t moving anymore) or managing the submission buttons, so say after submitting a run, it deactivates the button until the run is complete so someone can’t just click the button over and over, queuing up runs that they can’t cancel.

If anyone has more questions feel free to ask away.