I never worked with applets and have the following questions:
can an existing Java Desktop App be ported to an Applet by just providing a different interface? Can I reuse everything that's behind the GUI (services, injections, databases)?
is the same possible for Java EE applications? Just provide a different UI and reuse the rest of the code?
Basicly you just have to embed the JFrame, or whatever you used before, in an Class,which is extending an Applet. No you can´t use everything, there are some security restrictions for Applets(acces to the filesystem for example) until they are getting signed.
The UI, etc. for the most part is 'reusable', but the applet is also subject to stricter Sandboxing; the applet is limited to only the permissions that the user allows and/or additions to the JVM settings on the user machine. (There are also restrictions on port access for applets for things like database connections - and possible firewall considerations.
So, the answer is a "yes, but there is still a lot of work. Get to know what kind of work that would be based on your user base.
Basically when you are making applets you can't use frames or a menu. You should use panels and work on them. Most of things after that are simple and same.
Related
I want to make a desktop apps and an android apps (mobile)
For desktop apps, i want to use java and netbeans, for android applications I also use java for language and android studio
So my question is, is it possible to create a desktop application and an adroid apps (mobile) with one database: MySQL? Does the data exchange require use web service?
Yes, this is possible, but you might want to do a lot of research before jumping into it. When setting up a server to connect to from standalone devices there are a lot of things to consider. Here is a source to start researching:
The important keyword would be model-view-controller. (other source).
It basically means that in general System you have 3 different Parts/Components (Or how you want to call it). The short explanation:
Model: The first is the Model. The Model is anything that is data related. In your case that would be your MySql Database System.
View:The you have the View which is anything that the user sees and interacts with.
Controller: The Task of the Controller is to make sure that the UI is provided with the model and that the model is updated by the UI.
This is a pattern, meaning it does not care what language you use. In your case I would say, that your MySql Database is the Model and the UIs are the Android and Desktop app.
In simpler constellations the e.g. android app has an internal "Database" if any, Controls the UI with java and the UI would be the xml Stuff.
In this case you would have a 1:1 relation between Model and UI so you need one Controller.
In your case however you want to connect a desktop UI and an android UI to your database which is a 1:n relation. This connection mostly possible through the internet so you need the MySql Database accessible from the internet, meaning running on a server.
Though probably not the best but simplest (for me) setup would be xampp.
Then it highly depends on your use-case and will to scale, but a proper highly scalable solution I would go for (but is by no means the only or always the best solution) is a the Backend-for-Frontend-Pattern.
This means you have a dedicated server for your particular Frontend (UI).
In general I would do a lot more research about architecture, because if you mess up the architectural design, you lose a lot of time fixing it afterwards. Make sure you have identified all important features and use-cases and the general vision of your project before you start implementing.
Maybe you can use systems from different people for less money than paying a developer to implement the same thing again.
So make sure that each component has good reason why its being implemented other than the language that is known to you and your team.
Hope that helps.
This might be a silly question. I am in the process of writing a website. I have already weighed the benifits of using C/C++ in this java program, though every thing i am going to do using C can be implemented in java(Not easily). This code would be written as an applet to be run on the website. I would like to know if anyone could tell me if jni works across different os'es in an applet, and what complications could using jni in an applet pose?
IMO, this is a bad idea. (And this applies to using all forms of native code library in applets, not just JNI libraries.)
First complication is that this can only possibly work in a trusted applet. And (frankly) if a user says "OK" to dialog that asks if your applet should be trusted / run, they are probably making a big mistake. (Potentially nasty applets + potentially nasty native libraries == BIG RISK!)
Second complication is that you need to write, build, test, etcetera a different version of the native library for each and every combination of hardware AND OS platform you want your website to support. If you don't, your website won't work for some of your users.
If you have a corporate user base with a mandated COE and established trust relationships (e.g. preinstalled corporate certificates) these problems are more manageable, but there is still an issue in both cases.
Related:
Dynamically loading a native library inside Java applet
I've just started programming with Java, so might appear as silly question, but I was not able to find simple answer on the internet. This is "big" question which I have to answer before getting too deep into development, so you can help me to save a lot of time on trying different approaches.
I am currently creating a website using Java. Important feature of this website would be realized through separate Java thread (like daemon) which must be run in background for as long as the user is on the website. At the sametime, website applets must have means of communication with this thread.
I see three potential solutions to this:
Create traditional multipage website with stand-alone java applets in each separate page. I am not sure if it is possible, the following questions arise:
is it possible for java thread created by java applet to continue execution after user navigated to another webpage (on the same website)? I assume that yes.
is it possible for newly launched java applet to communicate with java thread already running in background? (I've seen part of documentation covering communication between java applets through JavaScript, not sure that this can be used in my case. Any other options?)
Create single-page website, with one single java applet, responsible for all navigation and rendering all pages. This solves the problem with background daemon, which becomes easy to implement and communicate with, as part of single applet, but raises one more questions:
I know that applet can modify current webpage. Is it feasible to use this feature to simulate navigation between different pages?
Create Java Webstart application, basically by taking the single java applet from p.2 and converting it into stand alone application.
I want the whole thing to have a look and feel of website, so I would prefer option 3 over option 2 and option 1 over option 2.
Thank you for any thoughts you share.
UPDATE:
Does anybody know answers specifically to the two questions under p1? If it is possible to work with java threads the way described?
Now I would most probably opt for making a Java Webstart Application. This should be the least painful way.
UPDATE 2:
I finally decided to work on single java applet, which can be easily converted to JWS application if needed. Nature of my project is that I need to make impression of working with website, that's why I am putting additional efforts to make it appear as a website. For knowledgeable people it will be obvious, that it is more like a local application.
Solution I chose has following benefits in my situation:
- easily convertable from JWS application to Java applet and back.
- no problems with running background thread and communicating with it.
- more reliable security (meaning that I don't need to use any mechanisms to pass over session ids from one applet to the other)
Contras:
- if size gets large, start up will be slow - I hope to avoid this.
- Security issues - I tried signing the applet and it helped a lot.
- Work of navigation buttons in browser (back and forth) - I hope to be able to replicated it in applet. Think applet should be able to catch this event.
Java thread [...] which must be run in background for as long as the user is on the website
If the thread being forked is to preserve state while the client is logged in then I would use a database, memory cache, or some other persistance layer to hold the client session state. This is a much more typical model. You can also have multiple frontends that share session information across the network.
If you are not talking to a browser then creating a stand-alone web application may be the best choice. You can still use HTTP as your transfer protocol in which case I'd recommend using a Java web implementation like Jetty. This would involve significantly less technology and complexity.
If you need to implement web pages, I would certainly use proper frontend models and technology. You should separate your pages into multiple applets -- or multiple controllers/views in the MVC model. Using the applets should be fine. They (or the controllers) should call a centralized service which starts, communicates with, and stops the background threads depending on the information flow.
I would also certainly have another background thread running to time out your client threads in case a client never returns. Your worker threads could just exit after a certain amount of waiting.
Hope this helps.
is it possible for java thread created by java applet to continue execution after user navigated to another webpage (on the same website)? I assume that yes.
Yes. Threads that are forked will continue to run until they terminate or (if daemon) the process terminates.
is it possible for newly launched java applet to communicate with java thread already running in background?
Sure. What they need is some mechanism to be able to share data. For example, your background thread service could keep a Map of the thread objects with the key being some sort of client-id. Whenever a thread wanted to talk to it's background thread then it could call the service to lookup the thread by id. Something like:
BackgroundStream thread = threadService.getThread(clientId);
thread.callMethod(...);
If there was some sort of synchronous question/response then you'd need to have a condition variable or something. Read up on Java threads for more information.
There's an architecture used in Website applications in Java, it's called a Model-View-Controller. Frameworks such as Java Server Faces (Standard on Java EE 5 and higher), Struts (1.x or 2.x), Spring, Apache Wicket, etc. were designed to create web applications using MVC model. The question is, would you prefer the component-based architecture of the framework (such as JSF) or not (which you shouldn't be worried about at this moment)
Applets is defnitely a bad choice as applets are downloaded to client side. Some browsers don't support Applets especially in mobile web browsers and its difficult to apply security settings to untrusted applets, plus you may not know if the client has blocked the applet or not.
Applets are a bad choice because of 2 reasons:
1) First, they are executed on client's browser and not on server. Therefore you cannot perform any backend processing(Business logic or fetching data from server database) using applets.
2) Applets are very buggy and have security issues. That's why applets are out of fashion these days.
Now coming to how you can create website using java technology, for that you need to start understand Java Server Side programming. Start learning about Java Servlets and Java Server Pages. To put it in simple terms, they are java programs which are executed on a web-server or application server.
then start reading about Java Enterprise Edition.
refer this tutorial for Java Enterprise Edition
We have two applications. One application in .asp and second application in java.
we want to build interface for universal authentication, so that one can access the other application once signed into one application.
Both applications are using SQL database, but one is written in .ASP
hosted on Windows server while the other is in JAVA hosted on a Linux
server. The applications are currently resided on two different
servers.
requirements:
1)The end user are most likely to access the applications through
.ASP first, then reach the 2nd application more like "back office"
management system.
2)he JAVA application currently works well with IE web browser, but
not very smooth with other browsers such as Firefox. Would like to
make the application to be more compatible with other browsers.
Please help me, its very important to me. Thanks in advance!
You haven't really asked a very clear question, but a few ideas:
If you had a web service which both platforms could talk to, then the two user interfaces could be reasonably shallow shims over the single code-base
I assume the Java application is actually still a web application, e.g. with servlets? Cross-browser portability has relatively little to do with the technology powering it... it's all in the HTML and JavaScript delivered to the browser. If you have a specific question about how to make some aspect of a web application work well in multiple browsers, you should give details of that.
Finally - do you really need two applications? Even with something like a common web service, you're likely to end up having to write several of the presentation aspects twice, doing very similar things. Is there any reason for not just settling on one platform and making a single application which covers all the requirements currently satisfied by the two applications?
You'll probably want to have a look at Single Sign-On solutions, of which there are quite a few out there in the market. A lot depends on what flexibility & control you have over the applications in order to make changes to integrate such a solution. It also matters as to whether these systems are on a public internet or just have internal clients.
A popular Federated SSO is Shibboleth though I doubt you'd want to put in such a solution for only two servers. It's features might help you clarify what you need from such a product though.
In a place I used to work, for purely internal clients, we just used Windows Domain authentication to allow transparent access to both Windows/ASP and J2EE/Servlet applications. It used JCIFS/NTLM filters for the Java authentication piece so there was never a need to sign onto an application explicitly, the users' login credentials were exchanged between their PCs and the web application "under the hood" and their AD group was membership retrieved to inform their J2EE roles (with the application then controlling access to the database) in much the same way an NTLM authenticated ASP page was handled.
I always seem to have this internal struggle when it comes to user interface. I build up an application "engine" and tend to defer user interface to after I get my algorithms working. Then I go back and forth trying to decide how to let a user interact with my program. Personally, I'm a fan of the command line, but I can't expect that of my users generally.
I really like what's possible in the browser in the age of web 2.0 and ajax. On the other hand it's not so hard to make a Swing front-end either, and you can generally count on a more consistent presentation to the user (though using a good javascript framework like YUI or jQuery goes a long way toward normalizing browsers).
Clearly both approaches have their merits and drawbacks. So, what criteria / parameters / situations should lead me to use a lightweight (e.g. web-based) GUI? What criteria / parameters / situations should lead me to use a heavier (e.g. Swing-based) GUI?
It is not my intent to start a flame war, merely interested in the community's constructive/objective opinions.
Edit #1
In light of the first few responses, I would like to clarify that I would like to deploy my application regardless, not host it on some internet server necessarily. So I would have to deploy with a light-weight web-server infrastructure a la Jetty/Tomcat or similar.
It depends on the application and this is essentially a usability driven question (though there are considerations like data storage and platform requirements). Think of the pros and cons.
Pros of a lightweight Web UI:
Ease of distribution
Platform independent
Ease of maintenance
Cons of a lightweight Web UI:
Less environmental control
Markup standards vary between browsers
Requires a web server and everything that goes with it
Pros of an executable UI
More environmental control (i.e.: full screen applications, etc)
Not necessarily subject to latency and outages
Cons of an executable UI
Pushing updates may be more difficult
Requires installation
Potential platform requirements (frameworks, packages, etc)
Potentially requires knowledge of advanced networking topics (web services, etc)
One small factor you may want to consider is that the user will have go through some type of installation (albeit minimal) if you distribute a swing application.
Also a web application will allow you to accurately track the usage of your application (via google analytics or something similar). Not sure if that's a concern but it may be useful to you in the future.
If it is a client-server application I would normally go for a web frontend for the application.
You will save yourself of countless problems with things like installed JRE versions, distributing upgrades, application permissions, disappeared shortcuts...
You need to break the requirements of the application down to decide this...
Do the users have Java of sufficient version installed? It will need to be, to run a Swing GUI.
Do you have a web server?
Do you need the flexibility of a Swing GUI or the accessibility of the web interface?
Is Java Webstart and option, if so, you can distribute a Swing GUI via the web.
Does your application perform extensive calculations or processing? If so, a client app may be the answer.
There are a million questions such as these. I would suggest a brain storming session and keeping track of all the pros and cons of each, adding a point score, than throwing it all away and going with your gut feeling :)
If you anticipate there being frequent updates to the app then web based may be better since the user would not have to update the client or install a new client containing the updates.
If you think that the user may need the ability to use the app while not conencted to the internet then swing would be better.
Just two things off the top of my head.
Think about the users and use cases of your project.
Do users expect to have access to it when they're disconnected from the Internet (for example, on an airplane or in a coffee shop with no Internet access)? Use Swing.
Do you want users to be able to access the same tool from different computers (for example, both at work and at home)? Use a web UI.
Also consider whether the user needs to save and load data, and whether the tool produces data files that some might consider sensitive (if so, storage on the web might be an issue).
Do make a quick guess I often try to ask myself/customers if the application has a high "write" demand.
For a mostly read-only application a thin-client solution is perfectly well suited.
But if a lot write actions are needed then a swing desktop application has more flexibility.
Personally I always prever a swing desktop application. It can easily deployed using Java Webstart.
Not knowing anything about your application I can not give the best recommendation possible. However I can state from personal/professional experience that installing an application on clients machines is a LOT more of a pain in the ass than it seems.
With AJAX/web you really only have to worry about supporting like three browsers. Installation messes/updates are only felt once when you deploy the product to the web server.
With like a stand-along Swing app, you get to deal with the really really big mess that is installing the application onto unknown systems. This mess was so bad that things like AJAX were really pushed along to make web apps behave/feel like a real native app.