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).
Related
I want to perform Remote Procedure Calls between Android and Desktop.
If RMI was there,it would have been mine choice.
But android does not support Java-RMI.
Can anybody suggest similar and simple RPC mechanisms that i can use as easily as RMI,without worrying about lower layer transport layer implementations
Kindly give me the alternative for RMI in android
I think you may be able to use different strategies:
- Web Services calls using SOAP, XML RPC, using Rest invokations types.....many strategies
- alternatives to Web Services available like the one provided in Spring Remoting with Burlap/Hessian protocols (you are not obliged to be tied with Spring to use such strategies)
Main idea is to use as core component a protocol managed by your android device : HTTP...
HTH
Jerome
Another option is Versile Java (full disclosure: I am one of the developers). It is in development but already quite stable, so you may want to have a look. Here is a demo which shows an Android client using Versile Platform to interact with a python based service running on a desktop.
RPC is generally a lousy technique, especially for remote operation. And it's not supported in most UI environments because you're never supposed to "wait". Far better to use some sort of a request/response approach.
I come from a .Net background and recently x-training to java.
I wanted to develop an Android application that required simple functionality to communicate with a server. For example, functionality such as post a username/score to a website (or service), or request information such as top 10 scores.
What type of communications should I focus on? What is the common technology to use? Does Java have the equivalent of WCF? Or does it have some sort of simple web service? Can web services be secured with authentication?
Ive heard other references to xml-rpc. Should this be something I should look into?
Depends on what your server is running. I usually just use URLs to fetch and/or send data and then parse the response with whatever is suited (such as org.json for JSON or org.w3c.dom for XML or HTML).
Java has the equivalent of WCF in the fact that you can develop Web Services with Java and use frameworks to develop such services to benefit from different features. The format which you send messages to these web services I think is what you are asking as such you literally can use any format you want (Dependent on support of such format by the service). You will find libraries for many of the well known formats like SOAP (KSOAP2), REST (JSON,XML) etc... Since the transport of these can be over HTTP, and you get a library in android to develop such services over HTTP you have quite a choice.
For Reference:
http://ksoap2.sourceforge.net/
https://metro.dev.java.net/
http://msdn.microsoft.com/en-us/netframework/cc950529.aspx
Hope this helps,
Andrew
Without knowing all of your requirements but assuming it's gaming-related, you might be better served trying one of the Android gaming APIs rather than trying to roll-your-own networking solution. Scoreloop and OpenFeint, the two I am currently considering for my own Android game, both offer Android APIs that make it fairly straight-forward for posting and retrieving high-scores, in addition to other game-related features such as challenges and social network integration.
The advantage of this option is that you don't have to worry about how the phone talks to the server nor do you have to host the server itself - they have already solved those problems for you - and they're free which makes it great for us indie developers.
Is there a demand out there for a small, lightweight, Java 7 based open source project that is geared toward making Cloud services more elegant? I have written several servers in my lifetime, and was curious if there was a need for this.
My thoughts were to keep it simple, lightweight, and use the Java 7 NIO 2 functionality for network communications. I was also thinking of using either a broadcast address for local cloud based communications between servers in a rack solution (MBONE) or a serialization-based communications protocol.
I don't want to use Spring or Tomcat, as they are overweight, and they are written on older Java technology. Furthermore, I don't want to use another Apache project because it's too dependent on Apache technologies. Keywords here are "small", "lightweight", "portable", and "efficient".
Maybe this will even have the potential of being installed and used in mobile devices as background servers, or even mobile cloud networks.
From my own point of view, no.
If I want a lightweight servlet server, I use Jetty.
If I want a more powerful, versatile Web app server, I use Tomcat.
If I want a full J2EE server, I use Glassfish.
All of these are of course highly proven. Memory is cheap enough these days that I'm not very worried about a little bloat. That comes standard with Java apps :)
Also, I'd consider it crazy to deploy server technology on mobile devices. Maybe other people have bright new ideas, I think mobile devices should communicate with central servers.
I would probably not want to use a Java 7 server not based on J2EE, at least the servlet part, unless someone comes up with a really compelling alternative. On the other hand, I wonder how small you could make a compliant server.
Finally, as far as I know, Tomcat already (optionally) supports nio: http://tomcat.apache.org/tomcat-6.0-doc/aio.html .
Strictly a personal opinion from an old curmudgeon.
I want to create a webservice that allows users to enter the longitude and latitude for a particular building. Buildings will belong to a broader category called a Region. If a specific building does not exist in a region the user could add the longitude and latitude data through the webservice. Similarly if a user finds data to be inaccurate, they could update it.
This webservice would not need to have a web front-end only a RESTful API that would only be accessible to my application(s). I want the webservice to be able to accept new and updated data (as described above) and also print out relevant data (in xml format) based on the appropriate API calls.
I need to ensure that this data would be secure - i.e. nobody would be able to gain access to the data i have accumulated.
What is the best way to do this? I have familiar with client side Java and not much server side technology (not familiar with server-side Java, rails, django, etc...). What language/frameworks should i use that would accomplish my needs with the shallowest learning curve?
You can just use basic authentication (username/pw) with ssl enabled. That way you are encrypting the connection and providing a broadly supported means of authentication. I believe apache Axis will take care of most of it for you.
I've used the Restlet framework to deploy web services that are password protected. It supports basic authentification and several others out of the box. You can also set up your services behind an https "server connector".
Another approach is to run your application in a Java EE application server which supports JSR 196 (eg, Glassfish or JBoss). You would then use the server's facilities to establish the authentication.
Here is the Glassfish security page.
If you have never programmed server-side code you will be facing a pretty steep learning curve, I'm afraid. If you are comfortable with Java then the Restlet framework mentioned by another commenter is a good choice. It is easy to use, includes both client and server tools, and has pretty decent documentation. The video screencasts are very good.
Another option is Ruby on Rails. I am currently implementing something very similar to what you are planning and Rails has worked extremely well. Rails has built-in support for XML output through both the ActiveRecord class and XML Builder templates. I used Atom Authentication (http://www.xml.com/pub/a/2003/12/17/dive.html) between the client and server and it is working beautifully. There is a learning curve for both Ruby and Rails but the power of the framework makes it worth it. I am partial to the Ruby and Rails books at The Pragmatic Programmer but O'Reilly has some good ones, too.
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.