After five and a half years full-time work on a product ranking engine project, which revolves around a 64,839 line applet, the browser companies have seen fit to dump applets.
At this point I am in no position to convert the applet to another language (unless I get a huge injection of funds to hire a team of programmers). My partner is not going to support me for another two years.
I know the questions are rather vague and I should be keeping up with the latest tech, however I've had chronic earaches for 14 years that affect memory and concentration, so programming is difficult enough without trying to keep up with the latest developments in software as well. The reason I am asking for advice is that I don't want to make another monumental screw up.
Question 1: My understanding is that Java Web Start launches the application, but it then cannot communicate back to the JSF web page any more (JSF2.0). Is there any way of getting around this?
Question 2: Can anyone suggest any other options other than re-coding the whole thing?
Question 3: Is it likely that applets will be altered to use the latest plugin format or are they gone for good? Does anyone have any inside information on this?
Overview of the applet's requirements:
The applet allows a user to customise some or all of the product ranking criteria, which has been preset by a panel of knowledgeable experts, to their own particular needs. The criteria is stored and edited via graphs (custom painted jPanels).
The ranking criteria can be altered entirely using the mouse (to change the graph shapes), though some values can be entered using the keyboard if the user wishes. Once customised, the applet is then used to submit the changes to the ranking engine server.
It is also used to allow third party experts to alter the ranking criteria to create their own product usage category ranking criteria. The third party expert can then place links on their own web site that will allow users to rank products using the third party expert's own ranking criteria. This allows anyone to create their own ranking criteria for use by others.
The applet uses a plugin bean that is also used in a standalone Java editor application, which is used to create a product usage ranking criteria file from scratch (the editor is 77,710 lines of code, though 61,257 lines of that is the plugin which is also used in the applet). This means most likely having to convert the editor as well, as the two are inextricably linked. The plugin basically is the applet and also the editor.
The plugin can capture, edit and store ranking criteria for virtually anything the human brain can rank. Thanks to the graphs, it can use any attribute that the brain uses, and for which we have no formal system of measurement; hence why the applet is so damn big.
Your question is probably too broad for Stack Overflow, but I'll give a brief response.
Java Web Start
Java Web Start is probably the best route for you. This technology is basically a convenient way for a user to obtain, install, and run a Java desktop app. The web browser is only used to initially download a small XML file describing your app and where to get the app. The Java Network Launching Protocol (JNLP) defines these pieces of information stored in that XML file. Your app will be downloaded from a server, and saved to the local machine. A Java Runtime Environment (JRE) can be downloaded and installed if need be as part of the process.
By default the app runs within a security sandbox similar to Java Applets. But you can sign your app and define security protocols to break out of some of those restrictions including making network connections.
The bulk of your programming would remain intact. The app is still pure Java, running in a JVM. You would need to do a bit of reprogramming to be a desktop app rather than packaged as an Applet. And you would have to learn about easing those sandbox restrictions. And your app will have a menu bar of its own as a full-fledged app, so you may want to take advantage of that. But the guts of your app would remain the same.
Over the years, Sun & Oracle have put efforts into improving Java Web Start. Unfortunately it came too late after Java-on-the-desktop had lost too much mind-share. And Swing never got the overhaul it so desperately needed. So Java Web Start never went big-time. But Java Web Start does work as advertised, so give it a try.
While there were some security issues years ago, I believe they have been resolved long ago. The many infamous security problems with Java were largely involving the web browser plugins bridging between browsers and the Java JRE; those problems do not affect Java Web Start (though you should do your own research to confirm).
For the general public, Java Web Start may be too much to ask of new, anonymous, and less-motivated users. For a commercial product with a user-base of eager customers, it may the perfect solution for you. I suggest you do some more study, read the Wikipedia page, study the Oracle technology page, look at the Tutorial, read this overview by John Zukowski that includes an example of network (making socket connection to time.nist.gov), and so on.
Vaadin
The Vaadin framework is an open-source free-of-cost professional user-interface development framework that uses pure Java to run your app on a server in a Java Servlet web container while automatically generating a user-interface using standard web technologies (HTTP, HTML, CSS, JavaScript, GWT, WebSocket, etc.) for presentation within a regular web browser (Firefox, Chrome, Safari, IE, Edge, etc.). As a graybeard, I think of Vaadin as an X Window System for the new millennium: The user interacts with screen widgets on their local computer but the business logic of the app is executing on the server, and the server is updating the remote UI as a result of that business logic executing.
Vaadin is not yet-another-web-templating system. Instead, your app is written in pure Java. No need for you to learn the alphabet-soup of web technologies listed above. Vaadin takes care of that for you, auto-magically. You say in Java “I want a label, then a field, and a button” and Vaadin makes those appear in the web browser.
Using Vaadin would allow you to retain your Java code for the business logic part. But you would need to re-write the user-interface parts to use Vaadin widgets instead of Swing widgets. This would not be so terribly difficult as Vaadin was inspired by the general style of Swing, defining layouts governed by layout managers in which you place your various widgets (fields, labels, buttons, etc.).
Vaadin can make very professional business-oriented apps that feel almost like desktop business apps. Tip: I prefer the Reindeer theme for business apps over the newer Valo theme.
But you mentioned some kind of free-form drawing canvas in your Swing applet. That may be a sticking point. I do not know of such a widget for use within a Vaadin app. I am not saying there is no such thing, I just do not know of any. There are slider widgets that may useful, but I don't clearly understand your needs in that regard.
Related
So here's the situation:
I recently took over responsibility for a Vaadin8 WebApplication from a former colleague who left the company, meaning I will now be responsible for maintenance and also for developing any enhancements the customer may want to have.
The application basically displays a form in which the user can enter his / her personal data which, upon clicking "Submit", will be sent back to the application server which then stores the data in a backend database.
Since the customer is planning on using this application in environments were WiFi connectivity may be very bad / unreliable (e.g. large fairs with thousands of people accessing the WiFi simultaneously) they have requested me to come up with a way the application could be used offline. This means that the appliaction should be available with or without internet connection, and the data should be stored locally until a connection is reestablished.
Now, as far as I understand Vaadin (I am by no means a Vaadin expert, last time I briefly touched Vaadin was 2 years ago), offline operation is not really what Vaadin is meant to do, not leastly because of its server-side architecture.
My question, therefore, would be if there is any good way to achieve the mentioned requirements.
While googling around a bit, I came across Vaadin Touchkit, which more or less seems to do what I want. However, to me (haven't worked with it before) it looks like it's a technology that is pretty deeply integrated into the application, making it difficult for me to get an estimation on the effort it would take to "convert" the existing app to a "touchkit-app".
Any help and / or suggestions on what technologies to look at would be greatly appreciated.
Now, as far as I understand Vaadin (I am by no means a Vaadin expert, last time I briefly touched Vaadin was 2 years ago), offline operation is not really what Vaadin is meant to do, not leastly because of its server-side architecture.
Yes, vanilla Vaadin with Java is stateful architecture, hence offline operation is not supported out of the box.
While googling around a bit, I came across Vaadin Touchkit, which more or less seems to do what I want.
Yes, Touchkit 5 with Vaadin 8 is meant for creating mobile applications. Note, if you have target to create one application that scales between desktop and mobile, including offline support, Touchkit is not very well suited to that purpose. Touchkit it works ok when you want to create two Vaadin UI applications, one for desktop and one for mobile. Those can share some common business logic and backend logic.
Any help and / or suggestions on what technologies to look at would be greatly appreciated.
Our newest version of framework Vaadin 14 is based on different client side tech stack. It does not yet have support for complex offline mode logic. It however have support for simple offline page, which can be customized.
Documentation is here: https://vaadin.com/docs/v13/flow/pwa/tutorial-pwa-offline.html
There is another discussion see how you can try to customize it:
PWA offline mode not loading from cache on mobile browsers
Vaadin 15+ onwards there has been possibility to create views also using TypeScript. One of the primary use cases for this is to be able to create views that are stateless by nature and are easier to support offline as well. There is a chapter about creating offline views in Vaadin's documentation.
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
[Note: I have modified my original post to provide some clarifications - m.e.]
Does anyone know of a way to embed a web browser within a web page, e.g. through a Java applet or similar mechanism? I have reviewed the discussion on various solutions for embedding a browser in a Java application. However, this will not work for our web-based tool, which is built on an asp.net framework. Using a Java applet is our current idea, but if you have other suggestions to address this issue, please post those as well!
This is to be used in a web-based tool that guides middle school, high school, and college students to read websites critically. The tool provides a set of guiding questions and other information along with a data-entry box surrounding the actual 3rd party web-page being viewed. The purpose of our tool is to allow teachers to choose websites for students to view and analyze - or allow students to choose the sites themselves. We (/the tool) do not control what sites or types of media are chosen.
We are currently loading the web-page in an IFrame, but that technique is limited in several ways. It does not provide full control for browser-like features we would like to provide, and is very sensitive to changes in both third party web-sites and to browser versions used by students. The most difficult issue we have pertains to anti-hijacking mechanisms used on the third-party sites. For good reasons, they use mechanisms that make them impossible to load into an iFrame -- that is, when you try to load the page into the iFrame, it will take over the entire browser window. Not only will the page not load WITHIN our frame, it will actually make our application "disappear", thereby making it impossible for students to use these sites within our tool, and potentially also causing students to lose their work.
The tool, which has take several years to develop, is currently web-based for a variety of reasons based on the needs of our users. I would appreciate any advice or insights the community may have!
Thanks.
If you have web application (ASP.NET page as you described), use web-based solutions, i.e. IFrame, etc.
Web browser controls anyway is a desktop solution.
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.
Is there a way i can use an access database from my Blackberry Curve?
All i want is to be able to open the DB, open table and run queries.
How?
Thanks,
I'm not sure that's going to be possible due to the size of the engine needed to interface with Microsoft Access. Perhaps something like SQLite would be better? If you already have data in Access, then transforming it into something like SQLite first?
As a general rule you have to either adopt some web based technology, or at least get your hands on some developer tools that work on the particular product in question.
Obviously access does and run on Linux or a Mac Computer. Obviously word or excel does not run on your smartphone either.
However most smartphones do support web based technologies or have some type of web browser.
Access 2010 allows you to build web based applications. I'm currently testing and playing with some of my access applications on an apple iPad right now, and they work great.
For couple small little forms, it's probably likely cheaper and better to adopt some web based development tools like asp.net, but this is all going to come down to what type of infrastructure and web servers and other resources you have at your disposal within your organization to bring into play here.
You can take a look of the following video of mine, and you'll notice at approximately the halfway point, I switch to running the access application 100% inside of a standard based web browser.
http://www.youtube.com/watch?v=AU4mH0jPntI
So Access 2010 + sharepoint allows you to build 100% browser neutral based applications. This means no ActiveX or even Silverlight is required. Thus the resulting access application will run inside most modern browser, and this includes most smartphones.