I want some way of creating a dedicated browser window for a browser (chrom-e/ium or firefox). Its content needs to be controlled by a java application (a http call to localhost or better a more direct way of communicating). These two should be bundled together in some way.
A little Background
I want to write a java desktop app but don't want to use Swing or javaFX for the UI. The UI should be written like a one page app and may be ported (at least partially) to the web. I have taken a look at the javafx WebView but would rather have a full fledged browser on my hands. It would also be nice to have a little more control over said browser to send files and read files in a more desktopish way. The only real requirement is that there has to be some java backend behind it and that is has to work offline.
Is something like this possible at all or is it just a pipe dream?
I am very almost a year late for the party, but:
There are a few (that I know) technologies that can help you:
Electron. It is basically what you want, you can use web
technologies to "forge" a desktop app, it's quite well known, I never used it but for what I have read that you can stick almost anything to it's "backend".
JavaFxWebView. There are some really nice ways to use it, you can
even use bootstrap and AngularJs, here is a example (not by me)
Yes it's possible and not all that unusual. Your app can open a default browser as described here -
https://stackoverflow.com/a/10967469/5087125
And then proceed to respond to http requests to your app.
Related
Today I'm using an applet to modify client-side information, considering the new browsers i have to found out a new workaround to continue modifying file and execute windows command at client-side because some browser are suspending the applet execution.
Any ideia for solution that has allow windows command execution and access file at client side like Activex ?
Applets have always been sitting between webapps and desktop apps. In that sense, what you want to achieve is exactly what every hacker in the world wants to achieve, that is gain access to your computer from a browser. And I think it would fair to say that for that reason, applets are dying and are not coming back from the dead anytime soon.
But unfortunatly some functionalities need applets to run, and what you can do really depends on those functionalities.
Statu-quo
They are still working in IE (not Edge), Firefox and Safari. If you control your clients environment you can maybe still use them as is. But for how long ?
Move to Server
You move your functionalities on the server. In your case, it would probably mean upload files on the server, execute your commands there and send the file back on the client. Javascript and HTML 5 can certainly help here improve the overall user experience.
Move to Desktop
If you are doing some pretty intensive stuff on the client (processing multiple files, accessing resources that cannot be used from a browser, etc), you should consider regrouping this into a desktop app. You can even launch your app from a browser and sends some parameters to it by registering a Custom Protocol Handler, a la iTunes. Again, this is certainly not an easy replacement, as functionalities will often be spread out between the desktop app and the web app, which makes for some interesting scratch head moments trying to link the 2.
My supervisor has tasked me with programmatically reducing a website's content by looking at the HTML tags to reveal only the core content. Importantly, this particular piece of the project must be written in Java.
Now having learnt about the differences betweenPlugins, Extensions, Applets, and Widgets, I think I want to use an Extension that calls a client-side Applet. My approach was going to be this:
Using the Google-Chrome API, I was going to display a button that
the user can click.
If clicked, the action is to launch a new browser tab that has the
Applet embedded within it.
The applet automatically sources the called tab's HTML code and
filters it.
Once filtered, the reduced copy of the original site appears.
So I have a few questions. To start, is it even possible to use an Extension with an Applet? Moreover, is it possible for an applet to look # another tabs HTML code? If not, is it possible to just reload the original tab with the Applet now embedded within it and complete the function. Thanks.
Javascript is already on most mobile web platforms. Java is not, and there is no reasonable way mobile customers will be able to install Java. Android, which runs many, but not all, mobile devices has a Java run time environment, and is basically a loader for Java apps. But an Apple iPhone is not an Android device... nor is a Windows Phone.
If you want to summarize content on the client, and in Javascript, as I see it you have two choices:
Succeed with some inner burst of genius where dozens of the best expert PhDs in Natural Language Computing have just begun exploring how to extract "true meaning" from text; OR
look at document.title and be done with it.
The 2nd approach assumes that the authors of web pages set titles and set a title appropriate for summarizing their website. This isn't a perfect assumption, but it is OK
most of the time. It is also a lot less expensive than #1
With the 1st approach you can get a head start with a "natural language toolkit" that can do things like scan text for unusual words and phrases. To get a rough idea of the kinds of software that have been built in this area, review wikipedia: Outline of natural language processing:: toolkits. A popular tookit for python is called NLTK. Whether you use a toolkit from java, or python, it means working on the server because the client will not have the storage, network speed, or CPU. For python there are server side app frameworks like django or web2py that can make building out a server app faster, and on Java there are servlets frameworks. Ultimately you'll need a lot of help, training, or luck and as I have hinted above it can easily be beyond the capabilities of a small team of fresh hires, and certainly way beyond what a single new developer eager to prove his/her capabilities can do in a few weeks on their own with limited help.
Most web pages have titles set like this near the beginning of the downloaded HTML:
<head><title>My Furry Kittens!</title></head>
You don't need to write a parser. If you are running in the browser, the title has been parsed into the DOM or Document Object Model already. The string "My Furry Kittens!" in this example would be available in the global variable document.title.
If you like, you could put a button into a plugin and let people push it to summarize the website. Or, they could just look up at the title. It is already on the page. Of course, if the goal is to scrape titles one can avoid writing a parser and use a "fake" headless scriptable browser like phantomJS or similar.
You can read more about document.title on the Mozilla Developer Network. MDN is a great reference for learning how web browsers work. They are the maintainers of the Mozilla Firefox browser. Most of what you can learn there will also work on Chrome, Internet Explorer, and various mobile platforms.
Good Luck!
How about implementing a local proxy server on the mobile device. The browser would just need to be configured to use the proxy, while the custom proxy implementation can transform the requested html however it likes.
I have a program allowing script files to "compete" with each other in a games such as Tic Tac Toe .
The visualization is made in the console and looks something like this:
| XO |
| OX O|
| X |
- X is the winner! Meh..
Not very exciting.
I was thinking of making a Swing visualisation, but after seeing a presentation on the Raphaël JavaScript vector graphics library I decided that I'd be cool to make the visualization browser based, even though every thing will be running on the same computer.
Do I need a full fledged web server to accommodate for this? How does the JavaScript communicate with the Java program?
Building a Swing interface would be the most straightforward solution, but this would probably be the messiest one as well.
The web browser solution is probably the most satisfying if you already have a web server going, but has a lot of overhead to set up and properly understand. Then again, you have layers of different technology to play with and get confused in (java, JSP, HTML, javascript, css, etc).
These days, with HTML5 and available javascript libraries, the web interface is in my opinion the best choice for most interfaces, so you might as well set up your machine and have it available for the next project.
Any communication between the server (Java) and the browser will take place with a HTTP request from the browser.
This may happen in two ways:
a) By pressing a submit button on a browser HTML page and rendering a HTML page on the server as a response (usually through server side scripting like JSP, although you could generate the entire page through java code)
b) By using Ajax in javascript to make an asynchronous call to the server, which will respond with data that you can then interpret and render with javascript (probably the best solution for what you are trying to do). There are many ready javascript libraries to help you with this, including jQuery.
In method b, you would essentially be waiting on the server side for a post from the browser and then you would be responding with a page written in XML, json or even pure text. Your javascript code would then interpret the data and render it on the browser HTML page (which you will have loaded at the starting point for the application).
Do I need a full fledged web server to accommodate for this? How does the JavaScript communicate with the Java program?
If you're going to host the JavaScript and display in a browser, then yes, the browser would need to be able to request the data from the Java via an HTTP request. Although browsers can load data via file:/// URIs, it's (quite) awkward to handle those requests dynamically.
It's trivial to install a web server, though. Tomcat is easy to install, and there are several other options if you prefer, such as TJWS (no relation), Winstone, LiteWebServer, Jetty...
If you're forced to run Java for the game engine I would suggest using Jetty to give you the ability to service HTTP request from a browser. It's all embeddd in your application and there's no faffing with having to package your app as a WAR and deploy it everytime you make a change.
[edit]
Just read about Tiny Java Web Sever which could also be an alternative to Jetty if you need a smaller footprint.
Javascript can communicate with a Java applet on the page (at least in theory). A Java applet is going to throw up a warning when it loads, and requires that Java be installed on the machine.
Yes a webserver will be necessary. Javascript will probably run as part of an html form. If any Java side processing is required, then web server is necessary. Since it is not possible for the html/javascript to communicate with a standalone java program. But Why need a java server side program at all? Can the logic not be written in java script totally?
I've been trying to understand how flash animations or a Java Applet work within a browser.
I can think of a couple of ways -
The Flash Player/Java Applet are machine code that's dynamically linked it, and given
some parameters about the area of the screen that belongs to them; after that, they
run within the same process space.
The browser exposes an API that the player/applet use to talk to it and they live
in a separate process. (Presumably they talk via sockets?) The API could correspond to
openGL/X11/some custom calls.
These possibilities still don't explain things like how a button click can make the
player full-screen, how it can play music, how it can inspect the DOM, etc. For that matter,
is the video displayed by decoding to a sequence of images, and rendering them
one at a time, or is there a more efficient way, e.g., of pushing the deltas in the image?
The Wikipedia page on Java Applets (1)
talks about how the applet is run in a sandbox (presumably a separate process), but
it doesn't say how the browser and the applet communicate.
Perhaps the answer depends on the underlying platform?
Any pointers to systematic discussion of this topic would be appreciated (as would
a reference to the APIs).
(My interest in this stems from an insatiable curiosity.)
I'm pretty sure plugins like Java applets and Flash run via NPAPI in most browsers. I looked into this matter myself some time ago and NPAPI was the answer I found.
In the case of browser and Java applets, the applets are typically run within the Java plugin, which runs as a separate process (you can see it e.g. in the task administrator in Windows).
The plugin creates an object for each applet in the DOM, and you can thus interact with the applet from Javascript. Anyway, calls to the applet that take a while to return do have the effect to freeze the browser, therefore I'd say the communication with the plugin runs in the same thread as the main refresh loop. This seems at least to be the case with Firefox.
I am working on an application in Linux which will interfaces with hardware. One of the requirements is to create the GUI in Web-browser . the application will be c++ based. I m not familiar with web realted stuff so i want to know Is it possible to do such a thing (currently it's a console application take input from txt file/cmd line). gui will be simple using button and showing output messages on browser from the application. i want to know which technologies/languages are involved and how can it be done. some of the idea i read but havn't found anything concrete yet. if u have any idea about these or a better suggestion please share
run the app in background and communicate with browser ?
call library functions directly from browser ?
any other idea ?
I would start by setting up a regular HTTP server, like lighttp or Apache httpd.
You say you already have a command line program that does the actual work - As a first step, I would reuse that, and configure the web server to call your program using CGI - see forexample http://httpd.apache.org/docs/2.2/howto/cgi.html for apache
Finally, I'd pick some javascript framework like jQuery or YUI with Ajax capabilities to do requests to the server to call the CGI script from within a webpage. You could also create a form-based web application without ajax or any framework, but that would require you to stuff all kinds of logic in your program to generate HTML pages. By using Ajax, you can leave the command line application as is, and parse any responses it gives with javascript, and then use that to dynamically change the webpage in a way that would make sense to the user.
If this all works, then I would try to figure out how to package all these components. Perhaps you just want to create a simple archive with all the programs inside, or maybe you want to go as far as actually embedding the webserver in your program. Alternatively, you may want to do it the other way around and rewrite your program as an ISAPI module that you can plug into your webserver. Or if that's not integrated enough still you could write your own (partial) HTTP server. That's really up to you (I'd probably spend time and energy on searching for the leanest, meanest existing open source http serverr and use that instead)
At any rate, the prior steps won't be lost work. Most likely, developing the web page is going form a substantial part of the work, so I would probably create a quick and dirty working solution first using the age-old CGI trick, and then develop the webpage to my satisfaction. At that point you can already have an acceptable distributable solution by simply putting all programs in a single archive (of course you would have to tweak the webserver's configuration too, like changing the default port so it won't interfere with existing webservers.) Only after that I would spend time on creating a more integrated fancy solution.
I ended up using Wt though I'd update for future reference.
These are how I thought of doing this, in order of complexity for me:
Create a simple server-side-language (PHP/Python) website that can communicate with (ie launch and process the return of) your application
Modify your application to have a built-in webserver that just punched out HTML (command line parameters taken through the URL)
Modify the app to publish JSON and use javascript on a simple HTML page to pull it in.
You could write a Java applet (as you've tagged this thread) but I think you'd be wasting time. This can be quite simple if you're willing to spend 10 minutes looking up a few simple commands.
After 12 years, web browser-based GUI started to appear, WebUI is one of them.