IMatch 2018 Sneak Peak 3

[Mario]

Background Apps (Service Apps)

This is a new type of app that is automatically started when IMatch starts. IMatch uses an invisible window to host these apps.
Everything else works as for regular apps. You just specify the type of the app in the app.json as "background".

Background apps can just hang around, monitoring IMatch events and then do something at specific events. Or they just do something and then terminate themselves when their job is done.
This is great for doing stuff when certain things happen, or doing stuff whenever IMatch starts. Using the standard JavaScript functions such a background app can also run code at specific intervals.
Lots of cool things one can do with that.

For security reasons, the app manager manages background apps in a special way. When a background app is loaded for the first time, or one of its files has changed since the last run, the App Manager asks the user for permission to run the app:



The new Developer Mode IMatch setting suppresses this warning so developers who work on background apps don't get bothered.

[Jingo]

Love this idea... but will there be a way to monitor which background apps are running and what they are currently doing..?  And... can they be halted/restarted if something were to go awry?  Thx!

[Mario]

Monitoring? No. IMatch has no monitoring facilities for apps.

Don't write background apps where something can go wrong.
There are plenty of ways to handle IMWS errors or JavaScript errors in sensible ways, without crashing or anything.
If you are not aware of these features, check them out. This way your background app can run "forever".

Since background apps have an associated app window, there is an endpoint to show / hide this usually hidden window. You can use that to show output or tell the user that your app made a mess.
You can of course also use console.log() or /addlogentry to display information on the console or in the log file.

If you plan to write an app which can run into trouble, write a regular or modal app instead. Allow the user to deal with the errors caused by your app. Don't cause problems in IMatch.

Restarting an app is nonsense. This would be the same as reloading the document, and you can do that from your app yourself.
A background app can terminate itself if it gets bored, though.

Since background apps are normal apps, you can run them in your web browser for testing / debugging.

[ubacher]

If I understand this correctly: I can write and run such an app as usual. I can run it with the window visible until I am sure it runs OK and then
I can hide the window and let it work in the background.

[Carlo Didier]

GREAT! Finally something to replace my old event scripts!

[Mario]

If I understand this correctly: I can write and run such an app as usual. I can run it with the window visible until I am sure it runs OK and then
I can hide the window and let it work in the background.

IMatch starts service apps (I changed the name, because service apps better explains what these apps do) automatically and runs them invisible in the background. For that, IMatch creates a window to host Chromium, with a default size of 320 x 200 pixels. The size of this window can be controlled via the app.json. There is an endpoint which allows a service app to make the window visible, for debugging and testing purposes, or maybe to display some sort of configuration - if really required.

This is not recommended, though. By default, service apps are designed to run in the background, without any user interaction. Like a Windows service or Linux daemon.

You can test and debug your background app like any other app in a browser, even attach to it while it's running in the background.

[sinus]

Sounds cool.
But at the moment I lack of phantasie, what could be done by such apps.

[Mario]

Sounds cool.
But at the moment I lack of phantasie, what could be done by such apps.

Many things....

Complex metadata updates when files are changed.
Backing up files to cloud services.
Writing back files automatically at a certain time or in intervals. (like one of your recent feature requests).
Running code when IMatch starts, loads or closes a database, ...
...

Basically everything you can do in an app. This is also a replacement for IMatch 5 application and database scripts. Just with more features and much better support for debugging.

[sinus]

Hah, sounds really cool.

Hm, yes, seems to have a lot of potencial is such a thing! 

[Jingo]

Monitoring? No. IMatch has no monitoring facilities for apps.

Don't write background apps where something can go wrong.
There are plenty of ways to handle IMWS errors or JavaScript errors in sensible ways, without crashing or anything.
If you are not aware of these features, check them out. This way your background app can run "forever".

Since background apps have an associated app window, there is an endpoint to show / hide this usually hidden window. You can use that to show output or tell the user that your app made a mess.
You can of course also use console.log() or /addlogentry to display information on the console or in the log file.

If you plan to write an app which can run into trouble, write a regular or modal app instead. Allow the user to deal with the errors caused by your app. Don't cause problems in IMatch.

Restarting an app is nonsense. This would be the same as reloading the document, and you can do that from your app yourself.
A background app can terminate itself if it gets bored, though.

Since background apps are normal apps, you can run them in your web browser for testing / debugging.

Ha!  That's all well and good.. until something goes completely wrong and IM becomes totally unresponsive.. and, since these apps then run by default - not having a way to turn them off is not a great concept.  My company uses background processing extensively across hundreds of modules to communicate data from one application to another... these jobs sometimes go awry - being able to spy on the process can help determine what happened.  What works in the foreground today... can go horribly wrong in the future (not because of a badly written script - but because of a bad image or file)... we see these type of issues all the time in IM.  Guess one might be able to write a log file to overcome some of this...

[Mario]

Just rename the index.html in the app folder. Problem solved. App cannot run.

[sinus]

Writing back files automatically at a certain time or in intervals. (like one of your recent feature requests).
...

Basically everything you can do in an app. This is also a replacement for IMatch 5 application and database scripts. Just with more features and much better support for debugging.

You mean, this is possible, e.g.

- (put off write back and off DD-categories update) at 13 pm. and 18 pm. the app would automatically update DD and write back files?

- if I enter a value in a attribute-field, the app would detect this and update immediately the DD-driven cats?

Wow, if this would be correct, then I could see really a lot of possibilities. 

[Mario]

This should be doable.

[Jingo]

Writing back files automatically at a certain time or in intervals. (like one of your recent feature requests).
...

Basically everything you can do in an app. This is also a replacement for IMatch 5 application and database scripts. Just with more features and much better support for debugging.

You mean, this is possible, e.g.

- (put off write back and off DD-categories update) at 13 pm. and 18 pm. the app would automatically update DD and write back files?

- if I enter a value in a attribute-field, the app would detect this and update immediately the DD-driven cats?

Wow, if this would be correct, then I could see really a lot of possibilities. 

That is what I was thinking.... though this would mean keeping IM running 24/7 unless we could leverage these scripts to run via a service that acts on the DB even without IM itself running?

[Mario]

If you want a service app running 24/7, IMatch has to run too. No apps can run when IMatch does not run.
Or you write your app to use IMatch Anywhere - but then IMatch Anywhere would have to run.

Or you just start IMatch via the Task Scheduler.

[Jingo]

Yeah.. I get it..  never mind... not enough coffee yet!