I noticed that if in fullscreen mode and then use ALT+TAB to cycle windows. When I return to the project window, then exit fullscreen and then close the applet, the taskbar and all open applications remain hidden.
The only way to overcome this issue is to CTRL ALT DEL to task manager and restart my PC.
This is not something end users should have to experience.
Does anybody know what is causing this issue and how to overcome it?
I have reduced the issue to the AWT being focused while in fullscreen mode. It might be a case of ensuring any listeners are disabled on that window to stop this issue from occuring.
By the way, do you know that java applets are dead? Don’t go this way.
The applet behavior depends on the OS, webbrowser and even the version of browser’s plugin. This is a hell for programmer and if your solution is not made for a customer which will guarantee that every workstation would have the same configuration, you’ll waste a lot of time just to keep your applet working on different configurations.
What @FrozenShade said. Mostly due to browser support issues. Chrome deprecated, and then stopped supporting, the API that the normal Java browser plugin relies on. No word yet about anyone doing an updated plugin that would work - only with chrome, so far.
Microsoft Edge, which is being pushed as the default, next gen, preferred browsing experience on all those free Windows 10 upgrades, does not support browser plugins at all, which even leaves some Microsoft products out in the cold… (Silverlight, for one)
In short, unless something changes drastically, the future of in-browser clients are going to be JS/Html5. Anything that needs closer to the metal/OS will need to be a downloaded stand-alone app.
The reason I went with a browser applet is because initially it was a good way to ensure it could be rolled out on any OS. Basically, the applet within a browser is OS independent and several years ago when I tested my website on numerous browsers and OSs it worked like a treat and I only needed to roll out one version.
I also liked the idea of having my 3d engine program wrapped in a website. This also ensured the initial container was freshly downloaded and practically negated hacking.
Is the preferred way not to install a downloaded stand-alone app? what other options are there? Is it feasible to download the stand-alone app every time to launch it?
The best way to handle this will depend a lot on the details of your application. In general, if your client side does significant work, you’re going to want to use a locally installed application. You would only want to require a new download if you’ve made changes to this client. From tidbits here and in your other thread, I believe this is where you will end up.
You mentioned being concerned about hacking. I’m assuming you mean that someone might modify the client to, e.g. move impossibly fast, etc. This is normally handled by having the server validate actions against what could actually happen based on possible control inputs. Keep the client from doing ‘transparent wall’ hacks by only shipping out geometry data that the player can see from their current location, etc.
If your use is more board-game type, not a lot of complex real time rendering, etc. It might make sense to do you front end as html5/JS, which really is cross-browser, cross-OS. Plus, it’s downloaded new every time the user visits.
HMTL5 using spring and JSF doesnt look like it is the tech that I am looking for. Although HTML5/js sounds interesting - can they launch java compiled apps without the use of an applet?
I would like the java app to be embedded on the page.
My applet footprint is very small. It is basically a library downloader. Libraries are stored on the end user HD. The applet is delivered via SSL and has a security certificate so it is very difficult to interfer with if it has any chance to be accepted for execution from the webpage. If any checksums of the saved libraries are incorrect a new version of the library is downloaded. If the applet cannot validate the necessary libraries it disconnects. So in effect my project is an installed application. The anti-hacking feature is that the initial thread is always started from the downloaded applet so it is very difficult for a hacker to interfer with. I’m not saying it is full proof but it makes it very difficult for someone to change the code to circumvent the library checking and validating.
If there is an alternative way to run java compiled client code delivered via a website other than using an applet then I am very interested to find out about it.
No. You cannot embed a Java app in a page anymore, at least not of you want it to work on all browsers.
Html5/JavaScript is just what it says on the tin. You would need to build a front end that was a web app (this forum page is an example of what that might look like) and then link back to a server that is running the game on JME. Currently, this would be an entirely custom job, and would not be a good choice for anything that requires client-side 3d rendering, because:
JME does not have a back end implementation that supports this anyway, and @nehon stated a couple of months back that its not a priority at this time. If you needed those features, you would need to implement them yourself, which looks like a rather large project in its own right.
If you are doing a project where a lot of things need to be done on the client side, native deployment is your best bet. Creating separate binary bundles for the major OSs is standard practice, and there is plenty of info out on the net about how to mitigate the issues that can happen when someone mods a client to cheat. If the app is stand-alone (ie, no server, runs as single player) you don’t even need to worry about the last.
Thanks for the clarification. JSF was not exactly what I meant, but that’s a side point. Also, your app is different enough that what I was thinking of is irrelevant.
“Library downloader” with checksums and automatic replacement makes me think that what you are looking at is some form of DRM? That is a subject all its own, and I’d be in way over my head trying to discuss it.
The changes in browsers were specifically intended to prevent you from doing this. I don’t doubt that you have good intentions, but others have used their powers to be nasty.
You could have an installer launch an app that deletes itself when done, your users will just have to allow it through their OSs user account control system each time. Might be possible for each download to have some sort of generated authentication for its connection to your servers? Unique code, sort of like a session ID, that means running the app again has no effect?
I’m starting to feel like this particular problem may best be addressed by a different technology stack, but I’m enough of a noob that I can’t give any useful suggestions.
Signed applets protection works as long as your browser respects certificates and plays fair - it protects user from dangerous applets. But the moment user have custom browser he could load anything in place of your applet while telling your server that everything is OK.