We Keep Coding

What is the advantage of using JavaFX for an android project instead of android UI itself other than portability of the code

The reason why most people would ever make their android project in javafx would be to have the same codebase across different platforms (such as ios, desktop, android, maybe even web using Bck2Brwsr/teavm/doppio)
But my question is, is there any advantage in javafx ui framework itself when compared to android ui framework?
I have never ever written even a hello world application for android, but I intend to do it now. So I am wondering if having the code in javafx is worth the effort when I can develop directly on android apart from the benifit of portability.

This type of question might result in a subjective/opinionated answer but I think it is a good question so I will provide my assessment.
Having the same codebase across all those platforms is huge. Do not dismiss this. I'm using Gluon Mobile to port aspects of the Deep Space Trajectory Explorer (DSTE) to Android and iOS. As you can see from the video its extremely complex application. There's no way I would rewrite that in native Android... it would be a no-go from a cost perspective.
Starting development from JavaFX makes it easier to make complex visuals. I don't just mean traditional 2D GUI forms. Again looking at the DSTE you will see we use Canvas to do dense renderings and JavaFX 3D along with the FXyz library to do 3D renders. These things are easy in JavaFX and again using Gluon simply "just work" on Android/iOS. In fact it only took about a day to get those aspects of the DSTE code base to work on a Pixel C tablet, most of which was getting the Gradle build setup properly. Now imagine having to port 3D code from JavaFX to a Native framework? I'm a 3D guy and I still wouldn't try it.
Testing is so much easier on the desktop than a mobile device. This doesn't mean the testing is 100% on desktop. Sometimes something that works on desktop "doesn't work" on the mobile platform and you have to tweak accordingly. However you can save a LOT of time standing up the application using JavaFX knowing that 90% of it will work the same on your mobile device.
Word of advice though... remember that a desktop application is NOT a mobile application. You will be tempted to just "port" your desktop app to your device. I was my first time. You can get into other issues where the interfaces and layouts you design for a desktop "work" on the mobile device but are not appropriate and so the usability goes down. Start slow when you port. Think of what aspects of your desktop workflow should be mobilized. Only port the things you absolutely belong in a mobile workflow. Save yourself some headaches.

3d effects in android and Iphone

We have a lot of days of research but can't find a solution for the following project. We need to convert a flux project to IOS and android native app. But as flux supports flash scripting it has easily implementing some 3d effects like shadow, emboss gradient etc. Please check the link here for seeing the swf file we have. We need to convert all this features into a native IOS and android app. We have research some area and found that most of the item we can implement except one icon here. The fourth icon have some 3d effects, shadow effects, border, emboss, contour and gradient etc. Can anybody check on this and guide us whether this can be implemented in IOS and android. I am pasting the entire url here again http://projects.zoondia.org/signfabcreator/signCreator.swf. Please check and let me know if this is possible. Let me if this is possible or not. If yes it will be helpful for me if anybody can give me a clue about implementing those in both android and ios

Very interesting! But I'm afraid you have to reimplement all this functionality by yourself. Don't be upset. There are good news for you - OpenGL ES and GLSL are extremely portable. So you can reuse 100% of your shaders. What is even better now you can share the other code too and stay native. Not long ago Intel announced the Multi-OS Engine. It enables you to develop native mobile applications for iOS and Android with Java. There are a bunch of tutorials inside installation package. One of them is especially dedicated to cross-platform OpenGL capabilities. Please check out my OpenGLBox sample.

java games with maximum portability

i want to program a simple java game, what should i consider to make it maximal portable? i'm pretty new to java, which grafik and rendering libraries should i use to make it easyly portable to mobile java (for mobile phones)?
i can't develop it directly for mobile java, because i also need a pc version.
or should i jast develop strait forward for pc and do a completele new mobile version later?

I'd say do the PC version first (portable across Mac, Linux, Windows if that is a priority for you), and develop a (or even several) completely new version for mobile handsets.
There may be some code (and art work) that you can re-use, but not too much, as a (good) game will have to be very different for a mobile phone than for a PC, not just screen sizes and input methods, but the major changes in game play that those differences probably result in to make it still fun to play.
The code that you can reuse will likely need to be adapted for J2ME or Android, but better to worry about that later than trying to be overly cross-platform from the beginning (which would place limitations on functionality on the PC version, and eat up a lot of time, without being sure if it ever pays off).
Again, if anything, worry about portability within the several desktop environments, and within several handsets, but not too much about portability between the two.
Of course, if your game has a server-side component, it would be ideal to have only one version of the server code that can talk to clients on all platforms.

I think it's feasible to create a game that is portable across a wide range of platforms. While a desktop version of a J2ME game may look primitive, it does enable your users to preview the game before installing it. Check out my project JGame, which enables writing a game that works without changes on J2ME, Android, and PC. I believe the Slick project also has a working Android version.

Best of both worlds: browser and desktop game?

When considering a platform for a game, I've decided on multi-platform (Win/Lin/Mac) but can't make up my mind as far as browser vs. desktop. As I'm not all too far in development, and now having second thoughts, I'd like your opinion!
Browser-based games using Java applets:
market penetration is reasonably high (for version 6, it's somewhere around 60% I believe?)
using JOGL, 3D performance/quality is decent; certainly good enough to render the crappy 3D graphics that I make
there's the (small?) possibility of porting something to Android
great for an audience of gamers who switch computers often; can sit down at any computer, load a webpage and play it
also great for casual gamers or less knowledgeable gamers who are quite happy with playing games in a browser but don't want to install more things to their computer
written in a high-level language which I am more familiar with than C++ - but at the same time, I would like to improve my skills with C++ as it is probably where I am headed in the game industry once I get out of school...
easier update process: reload the page.
Desktop games using good ol' C++ and OpenGL
100% market penetration, assuming complete cross-platform; however, that number reduces when you consider how many people will go through downloading and installing an executable compared to just browsing to a webpage and hitting "yes" to a security warning.
more trouble to maintain the cross-platform; but again, for learning purposes I would embrace the challenge and the knowledge I would gain
better performance all around
true full screen, whereas browser games often struggle with smooth full screen graphics (especially on Linux, in my experience)
can take advantage of distribution platforms such as Steam
more likely to be considered a "real" game, whereas browser and Java games are often dismissed as not being real games and therefore not played by "hardcore gamers"
installer can be large; don't have to worry so much about download times
Is there a way to have the best of both worlds? I love Java applets, but I also really like the reasons to write a desktop game. I don't want to constantly port everything between a Java applet project and a C++ project; that would be twice the work!
Unity chose to write their own web player plugin. I don't like this, because I am one of the people that will not install their web player for anything, and I don't see myself being able to convince my audience to install a browser plugin.
What are my options? Are there other examples out there besides Unity, of games that have browser and desktop versions? Did I leave out anything in the pro/con lists above?

I'd suggest writing a game first.
It's easy to get caught up in how to make the best game ever,which can run on anything from an abacus to SkyNet, but the reality is that you're going to have plenty of challenges ahead of you just finishing a game that runs on your own PC.
Write a game first, for one platform (whether that platform is "Windows native with DirectX", or "Java applet" or even "pure AJAX in a browser"). If you can do that, then you can start thinking about how to port it to other platforms. But trying to do everything is a sure way to end up achieving nothing.
Or to put it another way:
I've decided on multi-platform (Win/Lin/Mac)
so you've actually decided nothing. Decide on a platform to develop on. Then make the game. Then make it work on other platforms.
Don't worry so much about what your "audience" will find acceptable. If your game is fun, then yes, people will happily install Unity. Just like they'll install your game if it's not browser-based. But the important point is not "what do I have to install to play it", but rather "is it worth it". Your focus should be on making a game that is worth the installation.
And unless you're planning to sell 20 million copies of the game and live off it, your "audience" doesn't really matter that much, does it? What matters is putting the game out there so those who are interested can try it.
But a single-platform game is a lot better than an unfinished cross-platform nothing.
A game that requires me to install Unity is a lot better than something that takes you an additional 3 years to develop because you insisted on reinventing the wheel.

Yes you can have the best of both worlds.
It's perfectly possible to write a Java application that will run in both an applet (for your online users) while also running as a standalone application in downloaded form.
The key technologies are:
JNLP
JOGL for the graphics, which also has some good demos
I'm not so familiar with it but I think jMonkeyEngine looks very promising if you want more of a full-featured game engine
If it's any use, an old game I wrote called Tyrant supported running both as an applet and as a standalone downloaded .jar file, all the source is open if you want to look at it. This used simple AWT rather than 3D graphics.
And finally here's another example of converting an applet into an application with a pretty minimal amount of code.

If you really want that kind of penetration then I suggest HTML 5 + javascript depending on the performance you need.

First of all you start with the wrong question. Your decision for a technology should be driven by the concept behind the game. It seems that you are sure about the idea to write a game - so ask your self what the requirements for the game are. This will lead you to your technologie. If it doesn't get an idea of "what" you want to do.
To your Pro's and Con's:
Don't focus on things you will never need or be able to use. Thinking about the steam platform isn't interesting for a hobby developer. Also android isn't interesting if you are not really want to ship your application for android. This Pro's will actually never be a pro in reality.
To sum it up: Let this decision be driven by your idea, not the technology itself. If you have a clear idea of what you want to do you will get your answer.
(And btw.:
Think about what browsergames imply. Behind a Browsergame there is a huge service-area, only for keeping the game running. Companys working in such areas are basically service-providers.)

You might want to look into Google's Native Client, which allows you to write your application in C or C++ (or anything else that compiles to native code, really). A new feature coming to the SDK is LLVM support, which will (hopefully) allow NaCl software to target any platform that Google's Chrome browser runs on (or any browser that the NaCl plugin works with - currently x86 and ARM are supported, IIRC).

You mentioned Android in your question - have you thought about developing the game purely for Android?
In effect you get the best of both worlds, easy to maintain, easy to release new versions, easy to monetize and get some small income and you don't have write your own installer or update mechanisms either.

Yes. You can make something that will work in both. Basically, make your program work inside a JPanel. The applet can display the JPanel, and the desktop version is just a window with your JPanel in it.
You could also have a full Swing (or whatever) GUI, which the applet launches in a new window when they click the little "start" button you'd have on your applet.
There are a few other differences you'll have to take into account, like possibly loading resources, but I've done it before for simple games I've made.

I don't think you can really compare the two:
In my opinion:
Applet, flash and other browser based games are typically small "toy" games either written for free or supplemented with advertising. For examples, check out the Addicting Games website.
C++ games are more likely to be heavyweight studio-written games relying on dedicated physics engines, graphics engines, etc (particularly true of games distributed on Steam I would have thought). The learning curve is likely to be much steeper, as C++ is inherently a more difficult language than Java / Flash.
If you're unfamiliar with C++ my advice would be to steer towards Java with JOGL. That way you can scale the Open GL learning curve before having to tackle C++.
EDIT
To address the other section of your question regarding implementing a game in both browser and desktop form, you could consider implementing the game in Java and deploying an applet and standalone version, whereby the standalone version can take advantage of Java's full-screen exclusive mode API. You could base both applications on the same codebase. You could also consider shrinking the applet's footprint size by retaining data files (e.g. game levels) on the server-side and retrieving them dynamically when required.

While WebSense won't let me browse directly to the site, for obvious reasons, the first thing that came to mind when reading this question is a game like Wurm Online. It's written in Java with JOGL, implements content streaming and local caches, and seems to have touched on a lot of the points you're interested in. It's a desktop Java application rather than being truly "in-browser" but I think you could still learn quite a bit from its implementation.
The in-browser game is always in peril of having its window closed or refreshed, causing it to abruptly lose state unless everything is being kept server-side. This means you either have very simple games that can maintain synchronization using a call/answer model (such as the myriad of Facebook "Mob Wars" text-based games) or risk an inadvertent bump of F5 catapulting someone back to their last "saved game."

I'm not sure that refusing to use a plugin because you personally don't like it is a sensible choice. This option lets you write you app installable as a desktop app, or a browser plugin (with not much extra work) and you still get to write it in C++/GL. You said you don't think your users will install plugins... why not? If they will install an application then why not a plugin which basically boils down to the same thing?
You could look at Flash too, which is gathering some 3D functionality and can run in-browser or as an AIR dektop app. But then users would need a Flash plugin, which you presumably don't have either.

Video training program

I am looking to create a video training program which records videos - via webcam, user screen capture and captures sound. Now the main problem is that I need a cross-platform (mac and windows) solutions.
I know its possible to use flash to record webcam + audio. But its not possible to record the user's screen via flash.
So am wonder if I should use Java (which i believe will work on mac & windows). I do not want to develop to separate versions because of the cost involved in developing two versions.
Please guide me as I am new to this.
Thank you.
UPDATE
Hello again,
I had a look at the following site: www.screencast-o-matic.com or www.screentoaster.com. I see that they have developed a java applet which helps interact with Windows/Mac to record the screen.
I am wondering how to go about developing something like that and integrating it with Flash (for webcam and audio recording).
Is this a better idea?

This is not an answer to your question, but I strongly recommend against using video for educational programmes. Our company delivers university courses on-line, and we long ago learned that video feeds are only effective under particular scenarios. In general, a talking head is a waste of bandwidth. You're much better off to put together a well designed powerpoint presentation, record a voice-over (and edit it!) and then assemble the whole thing as a flash presentation. This is a non-trivial amount of work, but it provides a much more interesting product for the student.
When to use video:
1) When you are demonstrating something dynamic - Mechanics or Chemistry for example.
2) When you are acting out a scenario or case as an illustration -- For example, threat de-escalation techniques for high school teachers.
When you solve the screen recording problem, seriously consider whether you need full motion or if you can get away with stills. Often the motion is distracting, and a still with good voice over can be more effective. (Hint: Replace mouse pointers with something HUGE before recording -- Like Fox did with hockey pucks)

Try CamStudio. I don't know, if it works on Mac, but on windows, it's the best solution I know. It's open source, so you can use it's source code, if you want to :)

If you're looking to build an application that does all of the recording and screen capture itself, then you might consider using Adobe AIR (essentially, Flash running on the desktop) in combination with Merapi. Merapi is essentially a bridge between Adobe AIR and Java. So for example, for your project, you might use Java to handle the lower-level (but still cross-platform) stuff you can't do natively in AIR, and use Merapi to wire the Java application to your AIR UI.

This is by no means a simple project. Lets get that said and out the way. There are open source (and cross-platform) options for each element, but nothing (I know of) that will do everything for you.
I think the "cleanest" option would be to use Flash for webcam and audio, as you said, and run a VNC server to send the screen video... The only closed-platform code will be the VNC launching code. That should be pretty simple to maintain!
That raises a problem because most people are behind NAT firewalls these days. Setting up port forwarding is a pain in the behind. I've used an app called Gitso before which allows people to connect to me and send their desktop to my screen (for tech support). Its VNC-based and all it really does is add another layer on top of the VNC connection so rather than me connecting to them, they connect to me. That makes the whole business of port forwarding a non-issue.
And once you've recorded everything, there's the final issue of syncing it all back together... Might not be so hard.

Well, Camtasia provides the solution to get your problem done. It can record the onscreen activity and also the webcam video and put them in the same player template. Another screen recorder DemoCreator can publish the screen recording as Flash movie, but can not record the webcam.