Related
We're designing an app that will run on Windows, OSX, iOS, and Androids. It would be really nice to at least have most of the code in a single language rather than having to use Objective C for the Apple versions, C# or C++ for Windows, and Java for Android.
We were looking at Flex (with all of its problems) as a way to avoid having to use a different language for each version, but Adobe has thrown in the towel and in the long run that's not going to do the job. Java used to promise to be universal, but it looks like Apple no longer supports it as a part of the distributed OS, and as far as I can tell Microsoft never supported it. We don't want our users to have to download and install something just so they can use our app.
Is there a solution? Or are we stuck with building the app in multiple languages?
HTML + css + JavaScript!
Run your app on a standard web server. All of the above have standards compliant web browsers, all of the above support JavaScript and AJAX. The only thing that really varies is screen size and this can easily be dealt with by using a custom .css file for each target browser.
You could host a web application on a server and use the app browsers to interact with the application.
Although not a native application, all devices would be able to use it.
The downside is that server connectivity would be required, however this may not be an issue.
"global" languages are most likely to use virtual machines, so you can't escape the "users have to have to download and install something just so they can use the app"... I think Java is your best bet if you don't want to deal with problems of languages that compiles into native machine code.
You could use C# on all those platforms:
"Normal" .NET on Windows
Mono on OSX
MonoDroid on Android
MonoTouch for iOS
(If you ever wanted to write an app for Windows Phone 7, you'd be fine there too.)
Of course the UI part will have to change significantly between different platforms, and I doubt that it'll be particularly seamless, but it's worth considering at least.
i am not very sure, but i have heard python is a universal language. I have tried this with both mac and windows, not sure about the other plactforms
I believe C++ code can be run on all those platforms: Windows has full support for it; Android has NDK; and you can use Objective-C++ on iOS (and I assume OSX as well!).
I wouldn't go so far as to claim it's the best option, but I figured it was worth mentioning.
Ultimately a lot will depend on the nature of the app you are developing. If it's a large app I'd strongly suggest doing some detailed consultation with someone with experience in the area: because of the vagaries of the different platforms, this is one area where experience counts for an awful lot.
There are multiple options, depending on your app requirements:
First, Web app, as many said before. It is the same as the greatest common divisor - very small
Second Build the core of your app in c/c++, and for the interface use a framework that fits your needs. These suggestions are really, really great. You can even develop the interface separately for each platform, in Java for Android, Objective C for iOS, etc
Do not forget that never, ever you will be able to make the same code run on all platforms. There will always be some part with #define MAC or #define ANDROID. It's just impossible to run identical code, even for the simplest app.
Unless is a
void main(void){}
Even a web app will have a code like
if(browser()==Safari) {}
else {}
I think the answer depends on what kind of app you are going to build.
If it's like twitter, a good web interface is the answer. Each client just need to handle the GUI work, with the platform's own language and lib.
If it's a game, no communication with server. I prefer C and a script such as Lua to build the core of your app.
"Is there a solution? Or are we stuck with building the app in multiple languages?"
No, no solution for this. We use different languages because they run in different platforms. Universal languages, such as HTML, have lots of constrains because to be universal you must cut all the differences. It is the intersection set of all platforms, which is very very small .
Using HTML and Javascript is likely to be the best approach. Another option which runs on these platforms is Java FX 2.0.
I have written some basic applications using J2Me and felt that getting things done in terms of UI/UX were a night mare especially with blackberry OS 5. I then started playing around with Webworks and found it to be better and faster however i keep getting told that it is better to stick with J2ME. Which one is a better choice? Is one limited in features than the other? What will RIM support for the long term future?
This is a decision to be made for each application.
How well do you know HTML, Javascript, and CSS? How much device integration do you need? How graphics intensive will the application be?
HTML et al have a much lower learning curve than J2ME and the RIM APIs. You are missing some of the more functionality that integrates deep into the phones abilities. But you have a distinct advantage in that anything that you find missing in the Webworks libraries, you can write as Javascript extension in Java.
Webworks itself is limited to the blackberry platform, but HTML, Javascript, and CSS are practically universal. It's simple to turn the application into something that will work in a web browser. Just take out Javascript calls to any blackberry.* apis (or wrap their use in blocks like if (blackberry) {), and redirect anything in an XMLHTTPRequest to be proxied through something on the local server. I'm doing it this way for a Playbook app I'm working on. It's nice that I can show others that don't use a BB the functionality of my app.
It's probably pretty easy to take your Webworks app and alter it for another framework like Adobe AIR or PhoneGap (I haven't tried, but intend to at some point).
From experience, Webworks seems to be easier to develop in terms of UI. But in terms in functionality, there isn't much. I don't know if they've changed this, but before, if there wasn't specific functionality in Webworks, you could create your own by porting the Java code over and creating your own extension.
I would say that using J2ME, would be the better choice if you need more integration with device functionality, rather than UI.
I've read a bit on client-side browser languages and tried a few out but I'm not convinced I know of all the options. To make it clear, I'm looking for something that can be processed either through the browser or otherwise on the clients computer with minimal need for additional installations/configurations.
At the moment I know of JavaScript, Java, and Flash ( I'm aware this isn't actually a language, but seems pertinent to mention it still as an option). If at all possible it seems like avoiding Flash would be best, but it's still a consideration. I know there are various flavors of JS and Java but I don't really know of any that make the end-product that different than just the raw language. Java and JavaScript both seem relatively slow when it comes down to more complex and weighty apps, though performance is always improving as our browsers and libraries get better.
All this said, is there anything available or about to be available that will do things better?
JavaScript is the only native browser language that’s widely supported. Flash isn’t native, but it’s the most widely-supported plug-in.
Nothing else yet seems to be installed widely enough to be worth considering in general, although obviously you should always try to figure out what the actual/intended audience of your specific project has installed.
JavaScript performance has come on leaps and bounds in the latest versions of all browsers as it’s become more widely used.
As far as interface programming goes, the only thing JavaScript has built in is the DOM interface, which lets you programmatically control the HTML page that the JavaScript is running on. The DOM interface is pretty raw and basic, so there are lots of frameworks that try to make it more palatable (like jQuery), and frameworks that seek to provide libraries of desktop-like UI controls (e.g. jQuery UI, Cappucino).
JavaScript is the main language for client-side browser development that interacts with the elements on the page, does ajax requests (update screen without a full page refresh), etc. Depending on your specific requirements, I would recommend JavaScript, as its most likely the tool that will accomplish your needs.
Java is NOT a client-side browser language, Java is a programming language, you can write apps in Java and embed them in a website, that is called a Java Applet. This will require that all users have a JRE installed on their machine for your applet to work.
Java has nothing to do with Javascript -- they share some similar syntax, and thats about it.
Flash is a browser plugin, if you want to write a flash application, ActionScript is the language it uses. It still requires that anyone going to view your application have the Flash plugin installed.
HTML5 is the future.
Currently many features are achieved with JavaScript, but these are being wrapped in libraries (e.g. the "polyfill" library Modernizer and even in other languages, e.g. Java with GWT. This is an area in a greater state of flux than most.
You forgot unity.
Unity is an up-coming client-side application development platform. It does require installing just like flash but it's a lot more powerful then flash and seems to be picking up popularity.
Unity has a lot more inbuild framework rather then doing it in HTML5+JavaScript. I would say these are your two main options. For an example of javascript & html5 in action look at cloud9ide
One of the big advantages of unity is the 3D engines.
Java applets are so 1998 and are not an option.
Thinking outside of the box here...
What possible basic approaches could be taken in an effort to create a Flex component that could run Java?
I know I can easily use flex to browse to or launch a Java app, but there are things I can only do if I can run the Java from WITHIN an MXML Component.
I the strictest sense, I know it's not impossible (ie: if you had all the source code for flex and for the jvm), but what's the least impractical means to this end?
Edit:
Lots of people are interested in the reason WHY someone might want to do this. I see it as irrelevant to HOW to do it, but here goes: I have over 100 proprietary pixel-reading windows programs that I could port to Mac in this way, much easier than any other way. But instead of arguing the premises, the winning answer will ignore the reasons why, and focus on the HOW.
Showcase your creativity.
This sounds crazy insane to me. My answer is to not go down this route. It may be a fun technical challenge for fun; but has little practical value that I can see.
Answer the question, Why would you want to run a JVM inside a Flex app?
Also, How would you use a Flex App to browse or launch a Java App? As best I understood, the security sandbox of the browser prevents you from launching other local applications.
I don't believe you are correct about not being able to accomplish certain things you "can only do if I can run the Java from WITHIN an MXML Component". With proper communication set up, you can have the Applet and the SWF simply communicating with each other through an external set of processes.
The easiest way to accomplish this is to "fake it". Load a Java Applet (This should be possible by use of the SWF's ExternalInterface API -- generate the Object tag and add it to the HTML around the swf. To make this even more convincing, use CSS to have to Applet appear "on top" of the swf. ) and have it communicate with the original swf through JavaScript calls. If that is not possible, then it may be possible to have the Java Applet generate some form of pseudo-server which the swf could then communicate with.
If neither of those work, then there is always the SWF bytearray syntax. It would need to load a ByteArray, manipulate the internal data, and then send it... somehow.
A while back I prototyped something like this. I exposed a window / native app via a VNC server and then used an open source VNC client library to connect to the VNC server. It was totally hacky but it worked. Performance was not great but was usable. Here is the Flash VNC client library I used:
http://www.wizhelp.com/flashlight-vnc/index.html
I'm with Flextras, you need to explain why before a reasonable solution can be proposed.
Unreasonable solution:
Implement the jvm in AS3. Read jars in as bytearrays. Pass the bytearrays to you new jvm.
Reasons for unreasonableness:
Implementing even a partial jvm would be at least thousands of man hours of work.
Running a virtual machine inside of Flash's already (relatively) slow vm would be like riding a golf cart that's being towed by a tortoise: either one by itself would be faster.
You can interface between Air & a Java app using merapi (although that's just communication, not actually running the api inside air)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
When java was young, people were excited about writing applets. They were cool and popular, for a little while. Now, I never see them anymore. Instead we have flash, javascript, and a plethora of other web app-building technologies.
Why don't sites use java applets anymore?
I'm also curious: historically, why do you think this occurred? What could have been done differently to keep Java applets alive?
I think Java applets were overshadowed by Flash and ActionScript (pun unintended), being much easier to use for what Java Applets were being used at the time (animations + stateful applications).
Flash's success in this respect in turn owes to its much smaller file sizes, as well as benefiting from the Sun vs. Microsoft suit that resulted in Microsoft removing the MSJVM from Internet Explorer, at a time of Netscape's demise and IE's heavy dominance.
1) AWT made for horrid UIs. Swing improved on that but it was too late, because...
2) Microsoft dropped support for Java in the browser (its propietary MSJVM), and before it did, it would only support the last version it released, which was roughly JDK 1.1 compatible.
3) So today you cannot be sure that an applet will run on the majority of non-developer machines, unlike flash.
Same can be said of ActiveX by the way.
For what it's worth, Sun is pouring money and resources into applets again. They've made some really significant improvements in JDK 1.6.10 to mitigate a lot of the 'clunkiness' applets used to exhibit. For instance, with this update, you can display your own custom loading image/animation while your applet loads, and the plugin has been put on a major diet to improve performance.
They've also embarked upon an initiative to directly compete with Flash and Silverlight - JavaFX.
Whether or not the market will respond to any of this remains to be seen, but it's certainly a fascinating move on Sun's part given Flash's dominance in the market place.
By the time Java's GUI API stopped totally sucking, everyone was using Flash. And even today, Java is no where near as good as Flash at doing fancy graphics.
I assume it's because java is a "real", ie. general purpose language. To make an applet, you have to write code, and there aren't any shortcuts.
Now that flash etc have come along, you can pretty much just drap and drop your way through making a cool animation for your website. This is a much lower barrier for entry - you don't have to know how to program in order to get a flash animation working. So flash proliferates, and java applets are hardly used anymore.
I think applets are collateral damage in the battle between Microsoft and Sun.
At first, the JVM was very slow to load and demanded too much memory.
Then, when increase in computing power made the JVM possible, Sun played hard as it attempted to control all things Java:
As part of another private antitrust lawsuit filed against Microsoft by Sun in March, Sun sought a preliminary injunction requiring Microsoft to include a current Java virtual machine (JVM) in the Windows XP operating system. Microsoft said the decision to include the JVM this week is a direct result of the latest legal entanglement with Sun, but Microsoft plans to disband support for Java in Windows following Jan. 1, 2004. Microsoft Reverses Course, Will Include Java VM In Windows XP--For Now
They took forever to load up and get going in the browser, and then for a lot of people they didn't work. When they finally did load, the interfaces were ugly and clunky. I think the poor user experience was a big step towards making applets obsolete.
So to answer the original question I have a question of my own - you ask "Why don't sites use java applets anymore", and my response is "why would anyone want to?"
I see them a lot in acedemic settings (hosted on department or faculty sites), but you're right in that they are not very popular.
However, remember that Java's big promise has been achieved. We have Flash, Java Applets, Silverlight, and ever-improving JavaScript frameworks.
Now if I made add a personal opinion - I think that Java applets are inelegant. They tend to look ugly, the Java runtime makes its presence in the OS far too known (in terms of runtime visuals, updates, and the ugly installer). Flash is much better with its rich media environment and its transparent (and ubiquitous) deployment.
People still use applets. But you are right, there are tons of different solutions out there. For example, take a look at javafx
I think compatibility issues were a big problem. Most notably with IE and Microsoft's Java VM which wasn't as standards compliant as it might have been.
Even with the Sun JVM you could have problems. I've had fun where I've had two 3rd-party Applets requiring different versions of Java which causes all sorts of problems. Sun have tried to solve this problem by replacing Applets with Java Web Start which gives you a link in the browser that launches the application in it's own window instead of inside the browser. (In theory with JWS you can have different applications using different VMs but it never seems to work for me as well as it should.)
Advancements with JavaScript have also made it possible to developer much richer web pages so a lot of things in the past that you could only do in Applets can now be done simply with AJAX.
First, they not gone. You can still find lot of applets on the Web, lot of people use them particularly to demonstrate algorithms and such.
Advantages: can leverage existing libraries (math, physics, sorting, graph, etc.) and it is faster than Flash.
Inconvenience: it might be risky to target a recent JVM (although Sun did a good job on automatic updates, looks like lot of people are using Java 1.6 already), load time is a bit slow (even though great progress have been made there).
You can still find lot of game applets too, like Bookworm, with the added advantage, perhaps, to have part of work already done to run them on mobile phones...
Second, I can predict a regain of interest with JavaFX. Applets on steroids, able to break legend of "applets are ugly"... :-)
Last, a library like Processing makes super easy to create graphical intensive applets, and you can find lot of them on the Net, eg. on OpenProcessing where the worst (beginners in programming) is near the best!
I wonder how widespread the JVM actually is? In the case of Flash, IE5 preinstalled it, giving it a large automatic user base. But unless the JVM was included with the OS install, users wouldn't have it. I suppose as a developer you target the largest install base, meaning choosing Flash over Java.
There are Java applets here and there; definitely not widespread though.
i believe it's their ugliness that kept them away from the modern web. flash brought the design, javascript brought a convenient way to make some cool things on a client. being a box inside a browser (just like a flash, though, but much uglier) applet technology was put away.
actually, the only thing that might be missed is the possibility to have a 'client-server' type of communication inside the web, because java applet could have a stateful connection. on the other hand, you would have to put some server on the other side and open a port for it, which just was too much house-work for shared hosting environments.
applets still live in some different areas, like control centers for roads, tunnels, power plants and stuff like that.
People are still using applets, at least for the company that I am working with. The applets are used mainly by internal users.
I feel that applets have their benefits, as companies which employ Java at the server side, most probably will have a large pool of talents who are better skilled at Java.
Although perhaps other technologies like Javascript, HTML/CSS or flash are more popular or more fanciful, but the talent pool could be better employed to create web apps with Java applets as it is a language that they are already familiar with through their work with the server end stuff.
It could be faster for the Java talent pool to deliver a change request with Java applet solutions at a higher accuracy than any other technologies.
Sometimes, the most important thing in a technology solution is its functionality and how fast people who need to provide support for them can react to changes.
The JVM is very widespread, especially in the coorporate world, at least where I've worked, there was always a JVM installed.
I'm currently working on a Java Applet, but in general, I would never an applet unless I had to. But then again, I wouldn't use Flash or Silverlight, either. Applets have a slow load time, and look out of place in webpages. Also, Macromedia/Adobe have outmarketed the good ol' applets.