I have an RMI application that has service implementation and it has a lot of code in it and I do not want to redo the business logic just to support an iPhone app.
Could someone assist me on a best way to access these RMI services using Objective C? Or is there any other way for making this possible, please let me know if this is a terrible question, being a software programmer, I would expect that there would be a way for heterogeneous programs to communicate with each other, so this question comes to me with that assumption.
There's no Java runtime in iOS, nor any support for Java in the SDK, and an Objective-C app can't start up another process on the device (unless it's jailbroken), so there'd be no way for your app to run a JVM. So the only other option I know of (short of rewriting the Java code) would be to make your Java functionality available via web services.
Also, there's no direct way for applications to communicate with each other (or for that matter to even be running in the foreground simultaneously) in iOS.
Related
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.
I am new to java and want to develop a java application which will run continuously like a server.
Is it possible in Java to develop a UI less application which will work continuously? This application should also have JNI support, so functions exported using JNI should get called from a C++ application.
Can anybody tell me the pointers to start?
Help is appreciated, thanks.
Vishal N
It is certainly possible to run without a UI. By the sounds of it you would like to create your Java APP as a console app and then run it as a Windows Service/Linux Daemon (You did not mention the OS). There are java service wrappers out there that lets you run your java code as a service (e.g. this one) or you could write your own.
I recommend this book to learn the JNI. Although it sounds like what you need it not really JNI but rather an interface exposed over TCP or something similar that another C++ app can use to talk to your app. JNI won't allow another process to talk to your app, it is there to extend your Java code with functionality that cannot be implemented in Java itself e.g. calling some Windows API function.
Edit:
By the way, a plain Java Hello World App like this one IS a console app:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World");
}
}
Yes you can develop UI less applications in Java.
I'll expect an application server to handle multiple requests, transactions, security, life-cycle, persistence, etc.
If answer is Yes then I will choose the Java EE route to implement your requirements. I'll implement my business model using EJB3.0 and deploy in one of the application servers i.e. Glassfish, JBoss etc. which will support all features described above without reinventing the wheel.
Note: The solution will also give flexibility to expose your remote methods using WebService, CORBA or JMS.
If answer is No then I might create my own standalone server type application which will listen on some port and communicate through some bespoke protocol.
In order to support JNI -I would expect that you'd have to write a plain JavaBean wrapper or proxy. This proxy would then be used by the JNI.
Yes.
Is it possible in Java to develop a UI less application which will work continuously?
Create a thread or code main thread that will run foreever.
This application should also have JNI support, so functions exported using JNI should get called from a C++ application.
yes , have a look at here
You can certainly develop a Java application without a user interface; I think most folks would agree that it's easier than developing one with a user interface.
Regarding JNI, if I understand the question, you've got it backwards; using C++ as an example, JNI lets you call C++ code from Java, not Java code from C++.
Yes, you can run Java as service (daemon). You can simply run your code a "daemonize" it. This way, it will be detached from terminal sessions and will run in background.
Take a look here:
https://github.com/mkowsiak/jnicookbook/tree/master/recipes/recipeNo022
to see how you can run service inside C.
And here, to check out how to run service part in Java:
https://github.com/mkowsiak/jnicookbook/tree/master/recipes/recipeNo029
Have fun with JNI!
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 currently in the research phase of my dissertation project.
My project is a ticket booking system for a mobile device and I have chosen to target Android.
I anticipate the need for a client/server architecture with a central server, and so am currently looking at how Android could communicate with such a server. The server would grant the client access to ticketing information, and the client would send information about ticket bookings to the server. I'm looking at Java EE for the server as Java is the language I'm most experienced with.
I'm aware that Android comes with java.nio and java.net, as well as some org.apache packages, but am also looking for libraries/technologies that would be possible to use with Android.
So far I've not found anything massively helpful on the internet, so I'm seeing what SO can suggest.
Specifically I am interested in knowing:
What support is there for various middleware technologies in Android? e.g.
RPC based middleware
CORBA
Message based middleware
Web services such as XML-RPC, SOAP, REST
How well (or not) do existing Java libraries work when used on the Android platform? (e.g. If I wanted to use a library/API designed for Java SE rather than Android what problems might I encounter?)
Ideally, as the focus of my project isn't meant to be the communication between the server and client, I could use an existing middleware to handle the communication, but I am prepared for the worst case, which is having to write my own.
What support is there for various
middleware technologies in Android?
My personal opinion -- though I do not feel I am alone in thinking this way -- is that only protocols specifically designed to run over the Internet are remotely suitable for use with a mobile client. So, of your list, the only one that I would even entertain would be:
Web services such as XML-RPC, SOAP, REST
Some people have been maintaining an Android port of kSOAP2. However, I get the distinct impression that most Android developers working in this area have tended towards REST and REST-ish protocols. If nothing else, that's what all the fun Web sites and services are using for an API, particularly compared with XML-RPC (old) and SOAP (old and icky).
I have successfully used both the java.net.URLConnection and Apache HTTPClient libraries in Android for communicating with REST-style endpoints -- both directly and through third-party JARs -- with no real Android-specific issues.
How well (or not) do existing Java
libraries work when used on the
Android platform?
It is difficult to answer that in the abstract. Android implements a substantial subset of JavaSE, but not all of JavaSE, so there's a chance that any given JAR will expect something Android does not offer. Similarly, Android does not use environment variables, command-line switches, or a variety of other things that developers focused on the desktop might have introduced as semi-requirements. So, some things have worked for me with nothing more than a recompile (Beanshell), and some things have worked for me after removing redundant classs (JTwitter), and some things looked like they were going to be ghastly to get working (JavaMail).
I was wondering what are the benefits of using anything else but Java for Mobile Application Development.
I do think that yes, Java is the most common language for devices, with two exceptions:
Windows mobile applications, that are frequently built in C++ but that will be built more on the .NET framework in the future.
iPhone applications, that use Cocoa and Objective-C.
Java is the most ubiquitous and for that alone it is your best choice.
You have to use whatever the phone vendor(s) that you intend to support will provide. As most provide Java, but only some provide other things, if you want to support a range of handsets, you probably need to use Java for at least some of them.
Your client (be they internal or external) will need to decide what handsets to support, and you then need to base your decision on supported handsets.
It's not entirely impossible that you'll have to ship versions in different programming languages, which may make code reuse more "challenging". It all depends on your requirements. Nobody on this site can tell you what they are :)
It really depends on what you're trying to do.
Java, whilst ubiqutious does have speed disadvantages. Also it's not "write once, run anywhere" as it is on the desktop space, as different manufactureres, even different devices have different sub-sets of java installed each with differening inclusions of APIs.
Using native code is going to be more efficient, whilst more difficult to port. It provides a more direct representation of the devices capabilities without the sandboxing of a VMs Apis.
Alternatively, you could use a language like C which whilst isn't strictly portable, will have implemenations on many devices with minor tweaks to make, whilst retaining a lot of the speed beenifts of such a language. (OpenC on S60/Symbian), C on Palm etc.
It depends on what you see as the future of the the mobile space. If the iPhone turns out to be as popular as the iPod, then no, Java probably wouldn't be the best choice.
One thing to consider is that at some point there may no longer be such thing as an iPod Nano, perhaps the Touch will be the only iPod available. In that case, every single iPod out would support Apple's iPhone OS and the number of iPhone OS mobile devices would far exceed those of Java.
Five years from now perhaps "Cocoa vs. Android" will be the new Mac vs. PC. In that case, Java could be just as good as Cocoa.
The only reason I can think of is that you wouldn't need a Java runtime on the target device.
Palm, for instance, allows you to code in C and talk directly to the OS routines in ROM. The C code compiles directly to the machine language without needing a runtime.
before one can provide a speculative answer to such a trivial question there are other variables that need be answered. What kind of phone application does one want to develop.
e.g. you can use xhtml for something that does not need to connect to the phones' core features.
and when you need to connect to the phone software or hardware you have can use java,python,c++,windows mobile or the new kid on the block android.
Java is the best if you want to support multiple phones, however J2ME is a limited environment. If you are doing homebrew development then develop for whatever your own phone uses, for commercial development then Java is the most widespread (and there are companies that can port Java to other platforms).
One of the advantages of using native code is your are closer to the hardware, on a mobile phone this means you might be able to take advantage of features which are not exposed to the virtual machine upon which your Java application is running, the promise of Android is that everything is a lot more exposed that it is with a typical Java Mobile implementation
Best is to go to nokia, apple microsoft or google web sites or whaterver and see what developer tools and resources are available and choose the one you want to develop for all of them are very good as good mobile app developers can help increase their market share.
Depends on what Application you are trying to write.
If its a simple service / data provider I would use HTML and CSS via a framework like
jqTouch, jQuery Mobile, or http://www.sencha.com/ as these will run on mostsmart phones and you can package them into a binary app using something like http://www.phonegap.com/ this will allow for sliding, GPS, local file storage using HTML5
If you need to a database, motion sensing, bluetooth, game type application then you could look at
http://monotouch.net/
http://monodroid.net/
That lets you write c# .net code and deploy onto any platform do you should be covered for windows mobile, android and iPhone.
There is also http://rhomobile.com/ that lets you write applications for all mobile platforms using Ruby.