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.
Related
I'm sort of new to http://www.parse.com . And I want to develop backend in Java using REST API. It seems parse.com does not provides direct Java library for REST API development. But I found some third party libraries(un-official) like for Java:
JAVA
Almonds — A Java REST API that mimics the Android API.
mobile-parse-api — This library implements the REST API of parse.com in java with open interfaces for libgdx and playN.
Parse4J — Library for the REST API.
ParseFacade — Parse Android SDK alternative.
But I am not understainding how to get start with these libraries in order to create backend API in Java
#Mahendra
I assume by now you have found your answer. In case you haven't then here is a thought process that might be of interest.
From the little reading I have done on Parse.com it is a sort of like an Object database in itself which provides ready REST style api for all data stored there. See this - https://parse.com/docs/rest/guide
In addition they provide libraries for all popular Front Ends (iOS, Android, JS).
I think they are advocating a paradigm shift for programmers who are used to having a lot of processing on the Backend servers and exposing simpler rest API which provides a processed and targeted response to each http request.
Basically they are suggesting that the whole backend infrastructure (db, app server, server side logic etc) can be replaced by parse.com
If you are considering using Parse.com I assume you have read and understood above mentioned thought process and decided that it makes sense for your project.
I would advise you to consider using a using a common client side Java library that works with the Parse rest api and then use appropriate Client SDK (iOS, Java, JS etc) to work with your library and design the UI. Since you are asking about Java library, I assume your language of choice for storing processing logic is Java.
What I suggest next may be bit of a long shot ... but worth a consideration.
Write code non-ui code in Java and work with the Android API from Parse.com. Use a Java to Objective C. https://github.com/google/j2objc
This will also allow you to use Java code for your web browser (using GWT as a UI framework).
Then write UI code in the framework suited for the platform (obj c for ios, Java for Android, GWT + Java for web browsers) and use the java library to connect to Parse.com.
If you have already tried out such an approach would be good to write back opinions in a comment so the community may benefit.
I just started working on a project which will about making a big website.
With big i mean:
Webshop
Forum
Normal Website (Information pages etc..)
At first i just wanted to pick a decent open-source webshop and just built my site around it.
But then i started thinking about how to expand etc.
I started to think how i would like this website to be acces from a mobile phone. Not just with a browser but with an App. (I have decent experience in making apps for Android & Iphone). So the real question is:
Would it be smart to make the "Core" of my whole website in Java and use services to acces it and thus allowing different frontends to use the same "Core". Like:
- PHP for browser frontend
- Java (android) for the android App
- Objective C for the IPhone App.
And let them all just communication to the "Core" through REST (Json).
What will be the advantages / disadvantages with this approach and will there be a significant delay in rendering eg. a webpage (http request to php, then php making calls to java server (different physical server) then accessing the database and then returning it all, so php can format it to HTML).
Hope hearing some answers or suggestions!
I would skip the Java layer and make the "core" PHP. There is a wealth of tools and frameworks (like Zend FW) for building thoses components in PHP. Design your application around a REST interface and allow your mobile apps to use REST.
Better yet, use Rails. It's so easy to design and set up a REST interface.
I think your solution is “smart”. The only changes I suggest are:
Use the same platform to build both the "core" and the "browser frontend." This way you will have more productivity.
Keep the "core" and "browser" frontend on the same server, if possible in the same process. Unless you have a reason do it differently. This will reduce problems with performance, latency and so on.
If you're already familiar with Java I would suggest you look at something like GWT (or GWT + third-party libraries like Ext GWT or Smart GWT) for your front-end. I don't see the point in picking another language for the front-end unless you really want to learn something else (e.g. PHP as you suggest in your question).
I think the rest of your approach is sound (i.e. Java on the backend, providing RESTful services, etc.)
I am having a Java application and a .NET application both residing in two different machines and need to design a communication layer between these two applications. Any inputs or ideas would be really helpful. Below mentioned is the nature of interaction between these two applications.
Java applications sends large amounts of data to the .NET application
Data latency should be kept to a minimum
.NET application should also be able to request for some data (synchronously/asynchronously)
The easyest way .Net and Java can talk is using Web-Services - we have done in my company with much success (using apache's cxf and standard code on the .Net side).
But if latency and size are the main requirements, you should use Sockets - both platforms offer a pretty extensive socketing frameworks and it would give you the best performance possible.
I think this can be done by setting up an xml webservices layer on the java side. You can use RestEasy for restful web services. Just my .2 cents.
Another alternative is some form of MOM (Message Oriented Middleware). There are a lot of implementations, but one to look at first might be ActiveMQ as it has both Java and C# bindings (among others).
I'm not saying this is better than using a web-service, it entirely depends on what your requirements are.
We have had good experiences with providing web services with JAX-WS (part of standard runtime in Java 6). They explicitly list .NET compatibility as a goal and is well supported in IDE's.
The Endpoint.publish() mechanism allow for small, simple deployments.
You can use Web Services. Jax-WS is the API in java that allow you to use it. As the implementation of this API I recommend metro (http://metro.java.net/), this already came with the SDK, and has a great integration with netbeans.
As already someone referred yet, you can use a socket, and create a communication channel on that, but this have some problems, starting with security. Don´t use this in real life applications.
If you need help with this subject you can start reading this:
Getting started with JAX-WS
It really depends on your requirements. The simple way is generally Web services. However, if you want higher performance, or more fine-grained access to the API on the other platform, you might want to consider JNBridgePro (www.jnbridge.com).
Disclosure: I work for JNBridge.
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.
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).