Right now you are only allowed to execute a single app at a time per workstation.
It would be great to be able to run multiple apps in parallel - each in their independent session. This way it would be possible to e.g. create smaller service apps which address smaller but common tasks which can occur at multiple workstations.
Example:
Main app: Core production process
Along the way the operator may launch support apps for e.g. requesting input material, triggering transports, filing an process improvement idea, etc…
The current ability to handover information between apps via user variables is very limiting plus you always have to design your app in such a way that you are able to reload the original state if you want to switch from one app to another and back adding a significant layer of complexity.
There’s no timeline for a specific update for the feature you’re describing, but we expect to continue expanding ways that “support apps” or “helper apps” work with each other and with core functions of another app. Thanks for the detailed write up and we will post updates or related items here as we have them.
Revisiting this topic… Are there any concrete plans to enhance support for app concurrency within the platform, eliminating the need for users to create their own makeshift (and often unreliable) state and session management through tables? I’m confident that Tulip can offer a much better solution!
Is really nobody else that is currently using this platform seeing a major benefit in such capability compared to the current state of things? Is the concept too difficult for the average user? …
…just adding onto this idea for context if someone might eventually come revisit: imagine you could define special apps as kind of a function, with inputs and expected outputs. The app could only be called via transitioning from another parent app. The transition trigger would wait until the child-app is successfully executed and the child-app “returns”.
@sebme I get where you’re coming from with this suggestion. We use our Tulip apps in a similar way. We’ve have a main app that acts as our “home base,” and depending on what the operators select, we move them to different applications. We handle the state and sessions with tables and through ERP API calls.
