Thanks Julius, but our DLL does all of the following, as well as compiling on our build server to work in our mobile app, in Docker Containers, and in Microsoft Azure -  it's more effective to retain complex business rules in a .NET library so that it can be used on a much wider basis. Also, .NET is easier to maintain in the sense that adding any new barcode format to the DLL updates all of our environments, not just the Cache one. We're into microservices in a big way, Cache is just our facade pattern entrypoint to the whole distributed system. Alot of the business rules tranlation is done simply by exchanging JSON at the microservice REST endpoints (we've also got a QR code Server in a docker container that's standalone and accessible by anything via a REST endpoint), however somtimes it's easier just to slap in a DLL as per the above question. Also, a lot of our team's expertise is tied up in .NET technologies so quite often a .NET solution is quicker and easier than passing the technology transfer information to the Cache developers. Thanks though.

Thanks, Dmitry, you're a hero!

I'm actually the .NET developer on the project, I passed your answer to the Cache developer and he's over the moon with delight!

Thanks Adam!!!

Thanks so much Julius!

Hi Robert, thanks - but you've merely defined the numeric data type we can do already:

{ "MyProperty":1}

What we are looking for is how to create the following non-numeric data type:

{ "MyProperty":"1"}

Oh this is fabulous Nigel, thank you! In particular, the error routines are very helpful!

I've come across from C# and am still getting used to the scripting syntax here, all three of these answers have helped, we're properly posting now!

Kind regards,

Anthony Harrison

Thanks! And for replying so quickly! Marked as accepted answer in addition to the previous comment, both are helpful!

Thanks so much!!! Especially for answering so quickly! Marked as accepted answer!

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!

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.

Thanks!

Hi Evgeny -

Re: "

It's a greeting from the DC manager )

This comment looks like an answer for me and because we have a nice feature on DC to convert comments to answers and vice-versa. So I converted it for you and if you want you can mark it as accepted answer now. 

"

... sorry, but I don't know what you mean, nor what you are referring to.

Eduard, sorry, but you miss-read my comment, I marked 'my' answer as accepted, as my explanation of my fix was in my comment 'to' Stefan.

And just to iterate that answer here, I put the pages concerned through an HTML validator and we discovered some tags that were no longer legal (frameset), even though some browsers still accept this in quirks mode, Android (Xamarin) doesn't.

Yup, I do a similar thing, switching between Mac and Windows as required, after all of this bother I've finally got it working on all of iOS, Android, MacOS, UWP, and WPF - and that makes the pain worthwhile!

Thanks for your encouragement as well, Cache can be a lonely world without the occasional post of support to prod one along!

Hi Stefan, thanks!

I've just resolved the issue, we used http://validator.w3.org/ to validate the HTML and as it turns out the Android webview is really strict and breaks when validation errors occur.

In our case it was a Frameset tag, which although not being legal, are still currently rendered in the other browsers that we use.

So guess what, I'm context-switching from my usual Xamarin duties where I consume the Cache generated content, to figuring out how to style an iframe instead, to work on all browsers. Tricky, because the iframe has to expand to the viewport, and then the content link has to zoom to the bounds of the iframe so that no scroll bars are shown.

Thanks for your suggestion!

Hmmmmn, setting the Chrome browser didn't change the phenomenon!

Thanks, Timothy!

It happens on the first run when the app is installed, so nothing is cached, I should have mentioned that, but thanks!

Robert,

I'm just using the default browser, thanks, I'll try and configure the app to use the Chrome browser!

Of course my immediate worry will be whether or not I can inject Javascript across the C# bridge, as the app is reliant upon that capacity, but I'll cross that bridge when it comes!

Thanks!

Thanks Bernd, allowing the Extra's was what we needed to do, that fixed it!

Thank you also Sean and Eduard for your suggestions!

Kind regards,

Anthony