· Jan 22, 2019

How do people handle licence management in a Mobile App scenario

I'm finding that in a mobile app setting, that Cache is causing the worst User Experience that I have ever seen in a mobile app - I'm just saying this hoping that someone will be able to help me out, my intent is not to criticise Intersystems.

We have a Xamarin Forms mobile app that consumes web pages that are created by Cache. The app compiles into iPhone, iPad, Android Phone, Android Tablet, UWP (Windows 10, all of phone, tablet, and desktop), as well as MacOS.

The cache-generated html that we are wrapping in the app naturally uses a licence slot when a user opens the app. What this means is that when the user navigates away from a cache page, to, for example, an FAQ page where the FAQ is generated on the app (not remotely by cache), we log them out of the cache session in the Xamarin app's page "OnDisappearing" method. Works well.  So when we navigate back to the cache page, we just take another licence slot, and the user is happy. Navigate away to an on-app page and the licence dies, as we want.

Where the problem is, is in the area where the app is closed.

On iOS, there is no guarantee that "WillTerminate is called - hence we have no way of guaranteeing that we can log out of Cache using that method.

So what really sucks is that we are left with one Xamarin Forms methods that we can intercept to log out of the licences:


This method is called when the app goes into the background.

So what we are doing is terminating the cache session when sleep is called (by calling a Javascript function in the page from C# (and the javascript kills the session).

That works well as Sleep is always called when the app closes.

But the problem is that if the app has just gone into the background because - for example - an incoming telephone call sends it into the background, then after the call the user would bring the app to the front and want to continue - but guess what, we have already logged them out. So we have to log them back in.

And as a user doesn't know when an incoming call will come in, he might be halfway through doing something and then because he is logged out, has to start again.

How do people cater for things like this?

It is all very well saying 'hey, design the cache stuff like this from the outset', but the problem is that the outset of this app was 20 years ago and there would be over 4000 modules to rewrite.

So what we are presently doing is logging the user out every time that the app goes into the background, and then forcing them to start again when the app comes back into the foreground.

Has anyone heard of such a shoddy user journey, which is caused for no other reason that the owner has to manage the licences in this new mobile app setting.

Any ideas?

This licence-driven-cache-architecture app design is the worst I have ever seen, of any technology.

And why am I surprised that there are no leading mobile tags, such as Mobile, iOS, Android, UWP, WPF, MacOS. Way behind the times.

Which is why I am asking for a solution.

Kind regards,


Discussion (5)2
Log in or sign up to continue

How Caché works with licenses, actually very interesting and sometimes quite difficult to understand, but it is possible to find a balance for everybody. Fortunately, at the same time, it has actually some tricks on how to turn it on your side.

The first important thing is every time when user login, you should log in the user not only in security but license as well. In this case, if the user uses the same IP address will be used the license unit.

In your case, I'm not even sure about forcing log out, do you really need it? You mentioned that your application still web, and does not matter is at wrapped as an application or opened right from the browser. You should have the same behaviour. So, you can reduce timeout for the session, add some timer which will ping the server from time to time when app is active to extend session time. Sessions on the server side also have a grace period after a timeout which is 5 minutes long, in most cases enough to return back from the call.

Thanks! With 1/4 million people coming through our client's gates for their festival over a mere week, forcing logout is important. We have done tests and without logout, actual user licences being used are artificially high, and it means that we'd be paying higher licence fees than are actually being used.

However you spiked an interesting case, I haven't tested how the server times out the sessions that haven't been logged out and doing so should reduce the number of faux-licence stats.


I agree with the idea of migrating the back-end code to some other technology - I've broadly costed this and it would likely cost more than a quarter of a million pounds, there is so much there.

My ideal situation (other than not using Cache for the data store and using something open-source) would be to merely use Cache as a REST based data store that would essentially be an interaction of JSON requests and responses, and, as you say, do the front end otherwise. In fact I'd go so far as to make it facade pattern so that any client technology (mobile, ASP.NET, node.js, etc) could interact with it as required.

You're right about it being blazing fast - but I can't even find a use case for that, from the Mobile user's point of view there is little noticable difference between getting a response from Cache on a rack somewhere, and, for example, various SQL databases from an Azure or AWS cloud.

I'm sure our National Health Service and such departments as the Police Force have great use cases for this technology but I'm still scratching my head to figure out how it is useful to a small web app where the only real user is the REST endpoint that actually queries Cache.

Thanks for your comments!

In case your back-end logic is not too complex, I would suggest to migrate your back-end code to some other technology (we have great experience with node.js), and use Caché just as a datastore, not as a rendering engine. You have a variety of options on how to connect to Caché (REST, RabbitMQ etc ...)

Then your license units will limit just the number of concurrent datastore connections, not total number of connected clients.

In case you choose some popular language (node.js), this has an added benefit that you can draw from the wealth of libraries the node.js ecosystem provides. No more re-inventing the wheel in Caché.

You mention rendering html on the backend -- there is about a gazillion javascript templating libraries out there. Also, you get to work in some more modern language than COS, and, possibly, with more mature development tools.

That is just how I would do things after working with Caché for four years. Sorry InterSystems. On the other hand, I still think the database is blazing fast :)

You might want to take a look at QEWD?  See my recent posting in the article on the IRIS Community Edition for AWS

See also

For an example where it's being used in the NHS (in a pilot) with both desktop and mobile devices: