I am trying to develop an application that can be embedded in the HTML code of a website. I looked into using a Java Applet, but I am turned off of this option from the fact that Applets are decreasing in popularity, and that I am not totally comfortable with Java.
I have experience with Visual Studio C# and VB, and I was wondering if there was some sort of option where I could write an embed-able application using Visual Studio, and if they have some sort of equivalent or similar tool to Applets that I could utilize.
Thank you for your responses.
This depends on whether you want the C# code to run on the client or server side.
Server side you will have to use ASP.NET.
If you want to run on the client side (which it sounds like), this is essentially impossible due to security concerns and technological limitations (a .net clr would need to be invoked and the code passed to it for execution).
You could potentially look into using javascript based activex/com objects to invoke the clr.
Embedding C# code was possible in earlier versions of Internet Explorer, but no longer.
Related
I read that DukeScript, a technology meant to bring Java to every client without the need of a plug-in.
Can this technology used as an applet replacement?
In geneneral I'd say yes.
Is there a particular reason why you would choose to use java applets in the past, meaning: did they need to do things like accessing the hardware and/or file system?
If your applet would do nothing more than what JavaScript would be able to do, then yes, you can definitely look at Java to to JavaScript solutions like GWT or DukeScript. They're quite different: one translates Java source code to JavaScript, the other one uses Java VMs written in JavaScript in order to run bytecode. Regardless, they're subject to the same limitations, when deployed to standard browsers. DukeScript though can be packaged up as a standalone app, running inside the JavaFX browser or as a native app on mobiles, therefore it can do more than standard JavaScript can do.
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 have just been looking at the GWT and i am impressed by what i have seen but i do not really understand how it is used to when creating web applications.
For example, when im programming in PHP or JSP creating a simple app that lets users register, adds the detailes to a database and then allows them to login is pretty simple but i was wondering how GWT does this?
When doing this in GWT, would GWT widgets be used to construct a frontend(client) that accepts user input and then sends it to a server which is written using pure Java, the Java then does all of the data processing and database interfacing?
If my understanding is correct, is GWT just a way to write javascript frontends in an easier way?
Have you looked into the GWT Overview? I think this line explains it the best:
The GWT SDK contains the Java API
libraries, compiler, and development
server. It lets you to write
client-side applications in Java and
deploy them as JavaScript.
Basically, you write your code in Java, all the while using the GWT to create complex UI's, etc. When you "compile" it, it is highly optimized JavaScript that translates well to multiple browsers, including web platforms.
Whatever language you want to use server-side does not matter - ASP.NET, PHP, etc - it will all work with GWT because GWT is, ultimately, JavaScript.
Basically, Google is trying to make it simple to develop web applications in a familiar language, and doing all the underlying work for you. I'm sure there is someone else who can further expand on the capabilities and advantages of GWT, but I hope this helps!
Exactly. "In the end, it's just JavaScript", you can "Use the backend language of your choice"
There are many RIA frameworks popping up (flex, extjs, gwt to name very few).
If my server is written in Java, why not use java web start?
The benefits I see: I get to program in a language that is easy to debug (compared to javascript), I can use the same code in server and client side (validations, model objects). With SWT I get nice looking GUI.
Even if it means requiring a plugin in the browser (or using a cli tool), if my application is an enterprise application, does it matter?
For webstart you need Java installed on the client. For Flex Flash. For Silverlight .Net. For other RIA platforms a JavaScript enabled browser. It is a lot of product politic in that question.
And Java is very intenting, because "all seems to be a nail". Of course one of the great advantages of Java: same language, same knowledge, same code on every platform or environment (server/client/middleware).
For enterprise internal use, no it does'nt matter at all. If your biz is on the internet the decison is much more complicated (or even you have to offer the same functionality in diferent platforms).
The only contra argument is that in a lot of cases it's impossible to force the clients of your rich client app to have Java runtime installed on their machines. Everything else is a matter of taste, already existing knowledge and experience.
I think that until now the perfect client technology simply does not exist. We were excited about ajax and then there is another "hot" technology like Adobe Air. What is the difference between these techs and the "old-fashion" client-server apps? My friends we are back to the early 90s!
The AIR for example needs a runtime installed on the client machine, it has access to local system resources and communicates with the server using a binary protocol. On the other hand we are developing "RIA" applications (and very good ones :) using pure java swing clients communicating with the server through the Spring's binary remoting protocol. And i must say, in such a development life-cycle Java-Webstart is the winner. Especially in large-scale projects (and i mean laaaarge-scale, not just e-shops) in the java field i haven't found something more productive and maintainable (ah! maintainence... another big story) than this.
IMO if your users can live with a nice look-and-feel and you don't have to adopt another technology just because it is young and sexy use webstart. Put more work in your business model. After all enterprise apps is about business, not animations. And money is where the business is ;)
Yes I think it does matter, seeing that some big companies still have IE6 as their standard browser and as a requirement for web based applications. And those won't allow you to install any third party plugins into their dinosaur browser.
And you don't make a difference between RIA technologies that use existing browser technologies like JavaScript, CSS and HTML (including GWT which just generates client side JavaScript and ExtJS which is just a JavaScript Component library) and the ones that require an additional runtime environment (Flash, Flex or client side ).
Of course some things are easier to accomplish with proprietary or third party solutions (or you just have more knowledge in one of these platforms), but I still think that there is a huge potential in technologies that are standardized and already implemented in every modern browser (the differences between the browsers are slowly but steadily getting better, too).
If you ship it as a 3rd party application you can define a JRE as a System requirement, anyway but then instead of JavaWeb Start ship it as a normal Java Application as well.
I'm developing an app for iPhone with a Java desktop companion that it synchs to over the network. I'd like to embed a scripting language into both apps so that end users can write scripts that add new behaviours and interact with the object model, and so that I can more rapidly develop some features.
Any suggestions for this, or anyone done this before and got experiences to share? I'm thinking of something like tcl which I've used in the past, but not tcl itself as I'm not a big fan of the language.
Main criteria are that it should be
lightweight as poss (memory usage)
easy to interface and extend with java and objective-c
(nice to have) readable/approachable for people with limited programming experience
My initial hunch is that I should be using one of python, ruby, or lua. My preference would be ruby, as I already have some experience with it and don't know much about the others. However my main unknown is which of these is easiest to get integrated with iPhone and Java.
edit 2: per Jason Coco in the comments, the SDK terms prohibit embedded scripting languages. Checking into this it does indeed seem to, but I read it to preclude dynamic installation and extension only. I would still be interested in answers here, as the agreement doesn't seem to preclude having prepackaged scripts inside the application bundle itself - Apple would still get to vet that code.
The agreement also seems to allow use of Apples "interpreters"...what are these? Javascript and what else? Any route to use those here?
JavaScript
As I understand the iPhone SDK Licence, there is nothing preventing you from using a scripting language in your app - just that you cannot intall any interpreters or runtimes of your own. You can only use those scripting languages for which Apple provides the interpreter in the SDK.
Given that you want to run the same scripts in your iPhone app and in a Java app, the obvious choice is JavaScript. You can use Apple's APIs in your iPhone app, and something like Rhino (http://www.mozilla.org/rhino/) in your Java App.
You have to be aware that there may be slight differences between the two interpreters in the more obscure regions of syntax or object model.
P.S. I assume that users are going to be writing their own scripts to run on their own device/desktop. These would be part of the application data, and should be fine under Apple's licence
The only thing I've seen that allows a non-objective-c/c/c++ application to run on the iPhone is Unity3d (http://unity3d.com/unity/features/iphone-publishing) - BUT, it uses C# via Mono and does a full static compilation (http://tirania.org/blog/archive/2008/Nov-05.html) down to native code in order to do it. So, by the time the app is on the phone, it's no longer C# so it's allowed by Apple (and several apps have already made it into the App Store - so this does seem to be acceptable).
I don't think you would be able to do the idea you're talking about even if you could do the equivalent for Java/Ruby/Lua/Python/other (so having your desktop app pre-compile and upload just the native code to the device). As far as I know, you can't execute code outside of your application bundle...and if you modify the application bundle, then you invalidate the codesigning Apple does which allows the app to run on your phone in the first place. So even if you could get executable code to the phone, I'm not sure that you would be able to run it if it didn't come along with the app in the first place.
I was researching this too, and it seems that it's possible to pre-compile a Lua script (by converting it to C using Lua and then compiling the C file). Because all of your code could then be part of the application bundle (including the embedded Lua interpreter), it should be acceptable as an iPhone app.
See here for a discussion and sample script:
http://lua-users.org/lists/lua-l/2008-11/msg00453.html
*Note that I haven't tried this (yet)