Is there one or several java based technology that can help me write an application code base once (including Logic-Views-Controllers) and then compile and run it for
all platforms including main desktop and mobile operating systems as well as
in the browser. It must work and save in offline mode too so that it could sync with remote server as soon as it is connected to the internet. To me, it seems there must be a way if I use some sort of html/css/js technology to handle my views for such an application since I don't need fancy operating system dependent view technologies, and java for Logic and controllers. So far I have found Oracle ADF Mobile which seems to be commercial, eclipse RAP, eclipse scout .... But I look for something that covers Desktop as well. In addition if I can make the application run only in web browser, in case it would run and save in offline mode, it would be fine enough for me.
You could use Eclipse Scout for this with the following setup/limitations:
Since June 2016 Scout only supports web UIs (until 2015 Scout also had support for Swing/SWT, but this is gone now)
You would need to run the Scout frontend model part in a local Tomcat
or similar
You would need to add the sync code for connecting the Scout frontend
model with the Scout backend (that would sync data once a client installation gets online)
Asking for a mobile solution in combination with Java will most likely put you in a messy situation, especially with the discontinuation of RoboVM
Hint: The Scout team has started working on JS offline capability of the Scout UI. However, this is effort is still many months away from production quality (many parts/concepts still missing, not all parts open source, no documentation, etc.)
Addition: You will have the same limitations with Eclipse RAP (needs a frontend server, only web based, hint: styling rap apps is hard).
Looking for the silver bullet... Beware that "not caring about something" (the OS) will make you care a lot about a framework that does the "dirty work".
Leaving opinions aside, in 2016 you will reach your goal quicker with JavaScript, it has become the only thing supported everywhere.
It may be a good deal if you're OK with JS, and living on the bleeding edge with heterogeneous / less mature tooling (see NPM gate).
Java in the browser (applets) is dying soon due to its well documented security issues. One could argue it's been dead for a long time.
If you do want to code in Java only, GWT is still alive. It compiles your Java code into highly efficient JavaScript.
However, ever since Google reduced its involvement by giving away the project to a steering committee, the developments have slowed down drastically, and I'm not even sure they are up to date with JDK 8 yet.
Google still uses GWT in projects like inbox, for what it's worth.
I would go with GWT.
Google also uses this for projects like the inbox webapp, and the inbox android app. Using GWT a lot of code between the two apps can be shared.
It is also possible to compile as a windows desktop application.
Related
I'm making a database for my project (wirtual clinic) which will be a web application, but here is a thing.. I want in order that my app will based on a JavaFX (MVC pattern, where in View segment I could use .fxml files edited in SceneBuilder) is this solution possible?
If you need a web application running in a browser with a backend in a container, then you cannot use JavaFX. But you might try Vaadin. There you can use either Java code or HTML to build your application. They also sell a designer application.
The http://javafx-samples.com/ mentioned in the other answer shows a JavaFX application running as a server process and mirrored thru the network using JavaScript. This is technically admirable and might work reasonably well for your use case but you should keep that in mind when comparing it to client side JavaScript solutions.
It will not work well for flaky internet connections and extending it will have limits since it would require both Java server side code and JavaScript side code.
Such architectures have been used extensively in the past (e.g. Echo2, AjaxSwing etc.) and they all never gained serious traction even when compared to similar architectures such as GWT.
There are now several client side JavaScript based VM's including TeaVM which are pretty amazing and can produce pretty good results entirely on the client e.g. we used this VM in a recent demo.
Of course it is possible, but with the plugin and updates problems.
Some solutions are in progress. You can check this site:
http://javafx-samples.com/
It is promising I think because you don't need plugin.
My society was hit in the face with the NPAPI deprecation in the google browser.
We were using Silverlight for a long time and we are curently looking for any replacement solution.
What was good about applets and silverlight was the easiness for the applications to access the file system and get the rights to automatically save anything into the computer.
Beside it was compatible with the major OS and almost all Browsers, which was a great thing for our customers.
But chrome decided that NPAPI causes too much security problem, and they will remove it by september.
I'm looking for a simple way to provide access, at least to the file system of the customer.
asp.NET gives us anything we need, on the server side, but it can't do a thing on the client side. With silverlight we were able to use the clipboard,save multiples files on specific directory, send mails from the client etc.
I thought about making our own plugin on several OS, but that would be a lot of work. So i was wondering if there were a simple compatible solution that already exists.
You could build a FireBreath2 plugin to provide this functionality -- FireBreath2 will work on chrome w/ native messaging, and the functionality you describe shouldn't be too hard to do cross-platform. Keep in mind that you've got some serious security risks to protect against, though.
FireBreath2 as of this writing isn't quite production ready, but it's pretty close. ActiveX support isn't complete yet, but it shouldn't take that much work to finish it. It would require a good understanding of C++ and a willingness to help with the project since it's not 100% ready for prime time yet.
I would like to replace Java Applet which currently needs to use client's resources, i.e. external readers, and to communicate with a server via socket.
Reason:
1. I have thousands of client machines using this Java Applet program, and most of them are running out-dated JRE. When the Java Applet program is updated / added new features, all client machines will need updating the latest JRE.
Expected Solution:
The Java Applet program would be expected to be replaced by a web-based application, which allows to compile and run source code at client's side such that the new web-based application could still use client's resources and communicate with server via socket.
Can I use JavaScript to achieve it?
I would very appreciate your help/suggestion for this problem. Thank you!
JavaScript is a scripting language that gets evaluated in the browser.
I would not describe it as compiling and running but yes, it does mean you can run code in the client and is commonly used to create applications that run in the browser.
There's a staggering amount of frameworks that you can use to write your application. Take a look at the TodoMVC site to see the same TODO app created using several different frameworks.
If you come from Java applets, GWT may be interesting to look at.
If you wish to let the JavaScript client listen for messages from the server, take a look at websockets.
The smart card reader is going to be a problem, though!
See Architectures to access Smart Card from a generic browser? Or: How to bridge the gap from browser to PC/SC stack?
By the way:
The real issue with outdated JREs is not that your code will not run on old JREs, you can create perfectly fine applets using java 1.4 or java 5. Any libraries you may need you can deploy alongside your applet. The pain is a security problem. Anything but the latest version Java plugin is getting actively exploited and puts the user at risk. Occasionally, even the latest version is not safe.
try socket.io
I think this is the latest technology you can use to communicate with client browsers. it support the latest browsers and mobile browsers too.
hope this will help you.
Javascript has become very powerful with HTML 5.0. Here is a list of new elements that you can use to access all kinds of resources, including local files, audio, video, GPU rendering (canvas + WebGL) and GPU compute (WebCL). Here are even more things you can do, including database connections and networking. You can even create offline Javascript applications.
jQuery and jQuery layout make robust GUI development a lot easier. Rich tool suites, such as Google Closure offer optimization and a compiler for improving performance and detecting obvious mistakes early in the development process.
W3 offers useful stats for making an informed decision on how many users on average have access to which features. Note that the most annoying guy in that list arguably is IE8 due to it's lack of proper HTML 5.0 support.
In case you want to stick with Java, then one alternative would be to use my http://bck2brwsr.apidesign.org project. It's goal is to create small Java that can run in 100% of modern browsers without any plugin installed.
There are Java bindings to HTML (via knockout - one of the four most popular frameworks for HTML5) and that is why one can code whole business logic in Java and just render it via HTML. Should be enough to replace most of the applet UI.
In addition to that there is an experimental API to render on HTML canvas. People use it to write Java games that run in a pure browser.
There is a simple way to communicate with server via JSON REST API or via WebSockets. A live example is here.
I´m soon to start a new mobile app project and I dont have that much experience with either iOS or Android development but I have used Vaadin for presentation tier on different occasions.
The app will most likely be lightweight for the mobile client but more heavy for backend servers(jboss). I feel kinda lost so i´m asking you.
Question: What are the drawbacks of using Vaadin touchkit compared to other frameworks/ build from scratch? Where might a problem occur? Any input and recommendations are welcome!
I am currently developing a small application using Vaadin TouchKit that once it enters production will have some hundreds of users. I haven't been able to locate any publicly available apps in production that have been implemented using Vaadin Touchkit, so what I'm going to list here is based solely on my personal experience with the technology.
Drawbacks compared to native applications:
I'm assuming this is what you refer by "building from scratch".
As this is web techonology, your application performance will always correlate heavily with the quality of the users Internet connection. If you have to render large UI's with a lot of components and details, it will be slower than doing so in a native application. A lot slower if the users connection is poor. Or if a connection is unavailable, then your application pretty much becomes unavailable. There is a way to use HTML5-cache for providing an offline-mode in a Vaadin Touchkit app, but it is not very useful for storing large datasets as the cache has a lot more limitations than for example an Android SQLite database. For simple UI-stuff it might be viable, but storing data for offline-access is in my opinion pretty much out of the question.
Other than the above mentioned points, I have not run into any missing capability, as you can use any Java library at any time on the server-side, and your application will be running safely in a servlet container.
Upsides compared to native applications:
You didn't spesifically ask for the upsides, but I guess this is any input and recommendations.
Your Vaadin Touchkit app can run on basically any mid-high tier mobile device launched after 2010, basically excluding only the ones with Windows Phone OS, since Internet Explorer does not use WebKit for rendering and other browsers are not available as far as I know. And since this is a web application, it does not exclude any other desktop browsers than Internet Explorer. By creating one application, you support roughly 80-95% of your users.
As mentioned, any Java library, any internal API, any authentication method supported by your hosting environment is available to your app, which is not as easy to implement for native mobile applications. This can be overcome with great software engineering, but demands a significantly higher amount of developer resources, not to mention that you are still stuck doing it for each platform separately.
And of course maintenance of a servlet app compared to the maintenance of a native application is considerably more simple: deploy once, all users get the changes without doing anything. No app store, no versioning, no hassle.
Vaadin TouchKit compared to other web development:
I am not familiar, at all, with web application development without using Vaadin, so I am not going to tell you whether or not it is the way to go compared to other modern web application technologies and frameworks. All I'll say is that in my experience Vaadin makes creating UI's and backend functionality relevantly easy and more graspable if you are familiar with Java development and desktop application development in general.
To conclude, don't rush in to create your mission critical application using Vaadin TouchKit before at least prototyping with it, and getting to know the performance and limitations it presents. For certain type of applications, it might be one of the best solutions. For a certain, larger group than the other, it is probably one of the worst. It is not a very mature or generally adopted framework, but it is useful. I'll be happy to hear more about the type of app you're planning and help you figure out if there are any showstoppers for using Vaadin TouchKit.
P.S. You've probably already run into this, but this document opens up the guts of one of the TouchKit demo apps:
http://demo.vaadin.com/vornitologist/VAADIN/tutorial/touchkit-tutorial.html
I just tried out vaadin touchkit examples on my android phones, well now I got affirmation why I prefer native software over html in some cases. Try it out - dont be confused by nice-looking styles, just try to USE it, this is what apps are made for. In my case I cannot withstand non responsive GUI or not smoothly scrolling lists. Again, for a simple gallery - a JavaScript/HTML solution is just perfect :) So the right way is the hybrid way! (imho)
Vaadin Touchkit offers very good user experience and provides wide range of UI components to apps.
Its default iOS theme provide almost iOS like UI and it also offers many other themes too.
But this will not run as smooth as platform specific mobile apps. as ultimately it will not completely leverage the real power of mobile platform features as finally it is going to run in a mobile web browser. as compared to native mobile apps
Find more detail on vaadin touchkit and comparison with similar technogies like ZK Mobile and native platform specific apps. : http://jtechnoprojects.blogspot.in/2012/12/vaadin-touchkit-vs-zk-mobile-vs.html
I am wondering if there are specific cases where GWT is not suitable? For example would it be approriate to re-develop Stack Overflow using GWT?
I am developing an app which has a Java Restlet API and I was planning on using GWT (previously I would just have used bog-standard HTML/CSS with back-end PHP code calling an API). I am wondering if there are reasons why I shouldnt choose to do this?
My answer is not full but I believe the following bullets may be useful.
GWT should not be used for applications that mostly present textual information and some pictures, i.e. not very interactive. For these applications GWT does not bring you a lot of benefits.
GWT should not be used by teams that have strong web skill and relatively weak java skills.
Do not use GWT if you are required to support browsers that GWT does not support officially. For example MSIE 6.
have a look at this topic GWT for big projects?
GWT is best choice to manipulate complex actions in a single page. like Google wave, Google mail ... you can easily update (ajax) any part of the page.
Because of the GWT is java-to-javascript compiler, user should wait the loading of .js files and it causes many and many problems if your web app is big. The bigger your project, the bigger javascript files, the more user should wait the loading of .js files
IMHO If you have a static looking website like a blog, news portals, etc which each page has its own identity and represents an entity and is requested separately don't use GWT alone (you can still mix it with server-side generated pages like FB).
For most of other web apps especially if users sign in to use your app or your app is interactive and there is no technical problem use GWT (like Gmail design).
I would propose to avoid GWT at any cost. I have experience developing huge project with GWT and it is nightmare, because of long development circle. If you have application in angularjs/react/jquery, you update source code, click F5 and reload it. You can quickly debug clicking F12.
If you use GWT on huge project, you have to wait ~1 min for app to compile. And then there is no good way to debug it. Google provided special browser plugins, but they worked unstable and didn't support last versions of browsers, so I had to downgrade FF. Also huge GWT app debuggin takes tons of java memory, so you have to provide more memory to tomcat. And finally in practice you can't avoid learning js, you will have to learn it if you do modern web development.
UPDATE 15.05.2017: My answer was downvoted by GWT fans, but I'd like to note, that my info is up to date: 1-page hello world app rebuild cyrcle takes about 30seconds with last IDEA and 10Gb mem SSD notebook. I also asked friends having GWT in production for serious project: they claim 2min is average redeploy time.