π±Apps
Plugins, but cooler π
Last updated
Plugins, but cooler π
Last updated
Apps are basically plugins, but with many systems and features in the background, making the Apps a great foundation for your ideas and production code!
The apps are also powering the Components, Services, Interchanges, and Coroutine-based architecture, surrounding everything.
The apps can be viewed and managed via the /app interchange.
With /app list
you can see a list full of apps. All the running and currently not running apps are listed here, with each having multiple indicators, showing their current status and compatibility.
Apps are separated into three different segments: The app, the AppCompanion, and the AppCache.
AppCache
A cleaning service is regularly cleaning the caches of every app, so if you put a cleaning instruction inside your AppCache, the cleaning processing can clean your app caches automatically.
You can also choose to override every cleaning function with empty()!
AppCompanion
The app companion automatically creates a public instance property, a coroutineScope, and an identityKey
.
You only have to provide a predictedIdentity
, which has to be the same as the identity of the app itself!
To create an app, you have to define some stuff, firstly give your app an identity!
Additionally, you have to define a display name for your app:
After that, add your companion, which has to be an AppCompanion, out of your own app:
And your app cache too:
After all of that, you can now write your app, there are different overrideable functions available:
hello() which is the onEnable equivalent,
preHello(), which is onLoad
and bye(), which is onDisable!
Only hello() is forced, to be overridden, because in hello() you can add interchanges, components, services, and more!
To add things like Components and Interchanges, you have to use the hello() function body, to add them as you would do in normal plugins.
Look at the code of the SparkleApp.kt, to see the Sparkle app in action and learn a bit from the code, and how it works in a real use case!
An automatic plugin.yml system is planned for a far future release!
Yes, you (currently) still need a plugin.yml provided by your plugin (if you do not use a system, to generate it automatically).
But, because Interchanges are registering themselves on the runtime level, you do not have to define the commands inside the plugin.yml, if they are interchanges and added via an app or component!