Hi Community,
I’m currently developing an app (template) with assembly instructions and I have another app to print a label during the assembly process. So I want to change the app during the process.
The problem is I can cancel or complete the app, but I want to pause the app an resume to it.
Do you have any idea how I can change the app during the process without losing all the variables and times from the base app?
Hi @Gunnar -
This is a great question. A couple things to consider here:
Would it be possible to have the print app as a step inside the assembly instructions app rather than as a separate app? It is important to consider overall approach to building apps here. Tulip usually recommends building smaller, composable apps (so one app for each specific process) rather than parameterized apps where you have to pass information between them and they may be harder to scale.
I know there are some cases where you might want to keep you app design as is (parameterized) due to process complexity (high mix, etc), and in this case, there is a way to connect apps in the manner you are asking about. In fact, @danielpomeranz just posted a nifty tutorial example of how to do this here: [Video Tutorial] - Don't Repeat Yourself: Abstracting Repetitive Tulip Steps into Separate Apps - #4 by sebme
Let me know if this makes sense or you have any additional questions!
At present you can achieve something similar by marking all variables in the apps to “not clear” after completion.
You will still have to build quite a bit of additional overhead as explained in the topic @Beth referenced. And if you follow this route, be prepared for quite a bit of margin for error should operators break out of a stable process for any reason.
I would go as far as saying Tulip - at present - is just not designed to work in that way. I think that’s a real pity because it forces you to potentially have to repeat yourself over and over if multiple apps require the same supporting action.
I may be over simplifying things here but is not as simple as to just Pause the App? Here is an example:
Hm… so, how do you switch now to a different app? You can’t. With pausing you are only stopping the internal step timer. That’s not what we are looking for here…
Fundamentally, Tulip needs to change it’s App Lifecyle to allow this kind of behavior. I think this would be very powerful because it would make re-using app logic much easier (think about a defect app that can be triggered from any app and once done, continue where left off). The good thing is, this is a solved problem because pretty much any app platform (iOS, Android, Windows) implement it.
Thanks for your help.
If I have the step in every app, changes to the print layout in the future will hit us very hard because we have to update like 50 apps.
With a seperate app it would be really easy.
This is a helpful tutorial. Actually I allready created a station table to exchange information over different apps. But it will still clear the variables. If I deactivate the clear on completition I will have to clear all the variables later with the complete button. I think the following function will just reset the app variables like app timer, app user etc… But not the custom variables:
So I need to find a way to create a loop or something that clears all variables.
And then there are the loaded placeholders which I probably need to reload again.
Thank you.
This would help me when I get back to the app. But then I need to clear them later on. At the moment I don’t have an idea how I can clear them all with one trigger.
Hi, you can clear all custom variables with the first action in the trigger shown below. This is what the app also does whenever you launch it afresh - it populates every defined variable with the specified default value - if defined - otherwise it will blank them out.
The second will clear all placeholders.
So you will need two actions in the trigger to achieve what the completion transition will do - if and only if - the “clear on completion” flag is set for the respective variable/placeholder record, which is the default behavior for every placeholder/variable that gets added to an app.
That part is reasonably easy. The bigger problem is that it creates the potential to arrive at a process that is full of holes like a Swiss cheese if something goes not as planned and an operator breaks out early in the process. In this case you might have partially populated apps with an old state flying around. Depending on what you want to do that might or might not be a problem. But keep it in mind.
Again, I really hope we will see some changes to this in the future to make modular development possible.
Thank you, so it would be possible to clear everything. But the swiss cheese could cause problems.
Modular development would be great. Also I would love to see functions and native loops instead of workarounds.
100% with you on this as well! Only Tulip team knows the answer 
