Develop Reference

How can I connect an android with a local server?

sorry if my english isn't perfect.
I'm trying to make an app and I need to exchange information between more devices.
I thought that could be a solution connect the devices on a server but I really don't have the idea where start.
What language I need to study to make this? There is a better solution?

This highly depends on what you are trying to achieve in the first place. It would be helpful if you could tell what you are trying to do, but I will still outline some general aspects:
You need to decide, what information is going to be exchanged and how this should happen
What information: Figure out, what exactly needs to be sent and received. Generic text messages? Images? Byte Streams?
How should this be done: Generally spoken, there are two approaches of getting information as a client: Polling and subscribing.
Polling: This approach means to periodically check an endpoint for new data. For example, HTTP uses this way: A web browser or any other client (REST-Client for example) periodically requests information from a HTTP-Server, using a connection just for this single request.
Subscribing / Sync / Notification: In some way or another, the client tells the server that it is interested in the information and wants to get notified when there is something new. The connection is initiated at the beginning and held open for further usage. The benefit of this approach is that changes are received immediately, but on the other hand a permanent connection needs to be maintained.
Things to study
At the beginning, get a good understanding of the TCP/IP Protocol, how Sockets work, how common Protocols do their job (e.g. HTTP, WebSockets)
Take a look at specific Protocols working on top of the basic ones
Tip: REST: Most common WebServices Protocol, providing a common way to exchange stateless data. Uses Polling.
WebSockets: Socket connection using Web Browsers. Commonly used to update information without needing to poll.
There is no specific language to learn for connections. It's more about understanding what the difficulties are and what ways have been invented to address this. Once you get to this point and know what you want to do, it's possible in every language.
Recommendation: As you seem to use Java/Android, I would try to use REST. A really great client-side library for REST on Android is Retrofit. For the server side use what fits for you .. common Java way would be to use Jersey, but you are free to choose from a lot of choices. If using Jersey is too hard for the beginning, maybe take a look at the JS/NodeJS world, those guys invented Express, which allows you to create a REST service out of just a database, wihtout having to code a lot.

First you need to decide if you want to go for an Android or an iOS application. There are other various mobile operating systems as well, but these are widely used . If you want to go for android which is most widely used in my opinion, then you need to learn Java. If you want to go for iOS application, then you need to learn swift or objectiveC. These languages provide the API to connect with various types of services such as Facebook, Firebase and Amazon etc. If you want to connect to some other local server who’s IP is known to you, then you can use socket programming to send messages.

There could be many ways you can implement this. One way will be using Web services. Of course REST might be a better option, if you follow this approach. You can implement Your service(server side code) with any language. I will recommend you use java since you are already using android.
Aside from this You might need to go through the basics of REST, its specifications and
some reference implementations for language of your preference.

Trigger functions from another java program

We've got a server app and two stand alone client apps (both with different functionality - one for front office and the other for back office). Everything is written in Java.
What we need right now:
If both apps are running - click on a button in one app -> checks to see if the other app is open and triggers some functionality (display a message, open a frame) on that app
if the other app isn't open -> it should display a message saying so.
Can anyone point me in the right direction to achieve this. The best real life example I can give is: how clicking on the an itunes link in the web browser opens the iTunes application if installed and to the relevant appstore page.
EDIT: Our applications don't deal with websites at all. Everything uses Swing.

There is no "best" way to achieve inter-app communications but there are many ways; the best one will be the one that fits best your environment: network conditions, firewalls, number of calls, synchronous vs asynchronous, etc...
Usually communication is achieved using either:
Remote Procedure Calls: an app basically calls a function/method on the other app and passes arguments. RPC are usually synchronous: the response is sent within the same communication/transaction
Messaging: an app sends messages to the other app which, maybe, replies with other messages. Messaging is usually asynchronous.
The frontier between the two can be pretty blur with some protocols like REST.
In the Java world,
RPC is usually achieved using either
RMI: Java only solution; easy to implement; does not like firwalls much.
SOAP Web services: not Java centric; hard to implement; full of traps; network friendly.
Messaging can be achieved using
JMS: Java only; rather easy to implement but asynchronous; extremely powerful on high loads
JSON/XML HTTP/s Messaging: there are many protocols here from the most secure like AS2 to RNIF, plain XML/Json POST etc... These are network and language agnostic but always require some work to implement.
An hybrid approach is REST which has become very popular due to the benefits of an easy implementation and network friendliness but has the drawbacks of not being very formalized. it is a technology rather than a specification. I would look at documentation around JAX-RS and frameworks like Restlet and Jersey to get you started.
(Edit)
I purposely did not mention developing your own with Java sockets. IO is by definition impure and often multithreaded: IO is very hard to get right. If you really insist going down that route, at least, use the help of a proper framework like Apache Mina or Netty.

How can I implement a good Client-Server approach?

I'm developing a distributed application, and I need to connect a client Java based to a server C++ based. Both of them will need to send information to each other, but I need them to be able to do things while waiting for the information, and they don't know when they are gonna get new information, or send information.
How can I achieve this? Now I'm trying to implement a basic communication with Sockets, but I don't really get to communicate them. I have read that using sockets + threads is usually a good approach for client-server apps.
Could you please recommend me some web or book to read about this, or send me some example code to learn?
Do you think that i should use other approach, better than sockets? maybe a higher level library (i would need it for c++ and java) or a totally different way?
EDIT:
I will add some extra information.
What I would love to achieve is the following:
My C++ program has a main loop, where I would like to have a call like GetUpdatedDataFromRemoteDevice() where I read the new values of some numerical variables that previously got updated from the net (the socket, for example).
Eventually, the C++ program will need to send a message to the remote device, to tell him to send other kind of data, and after that, keep getting the updated values.
From the Java program (remote device) the application running is an interactive touchable screen, that cant get blocked by the network transmissions, because it must keep working for the user, so all the networking should be done in a separated thread.
That thread, should connect to the server, and when a button is pushed, start to send the data (4 changing numerical values) in a loop until another event happens.
It would be nice also to be easily re-connectable to the server.

ICE is a modern and good library for distributed applications:
many languages as C++ and Java
many platforms
GNU GPL
good performance
easy to use
First, you define the messages you want to exchange between server and client.
Then, you implement the C++ and Java source code to handle these messages.
More info at http://zeroc.com/ice.html
Have fun ;-)
EDIT: I have to use ACE in some projects. I can tell ACE is very old, maybe mature, but uses outdated C++ coding rules :-(
Therefore ACE is not as easy to use as STL or BOOST. Moreover, ACE is not really efficient... I prefer ICE ;-)

I don't know what your application is but robust client server socket programming is pretty hairy task to do properly. Hardware byte order, String encoding, Network errors, retries, duplicate messages, acks etc.. require lots of good design and careful programming. You need to get it work well as single-threaded before even thinking using multiple threads.
Unless you need instant notifications from server to client I suggest that you use HTTP as protocol between client and server. Client can poll server occasionally for new messages.
Anyway the problem has been solved multiple times already.
http://activemq.apache.org/
http://www.rabbitmq.com/devtools.html
http://www.cs.wustl.edu/~schmidt/ACE-overview.html

I did something of this sort once. In my case it was easier to connect my C++ app to a local Java app using JNI and then have the two Java apps talk to each other.

Client-server game in Java with applets

I have to implement a simple tour client-server game in Java. Unfortunately, I'm just beginning with network programming and have some problems with choosing an apropriate solution.
Let's assume I'm creating a chess game where two clients can connect to the server, authenticate with their username and passwords and play. The clients must be programmed as applets (thin clients), but I don't know what I should use as a server.
I mean, I've read about several different possibilities like RMI, sockets, servlets, but still don't know which one fits bets my needs. I'm a bit confused because I don't fully understand how the communication would be carried out.
Should I create an executable server which would run all the time on the server and wait for the players? This seems to me like an odd way. Or is there any easier way to do so, e.g. can I make a servlet and put it on Tomcat server so that the server would be run only if there are any players? Could that servlet communicate with applets (clients) and vice versa?*
I'd be really grateful for some tips.

can I make a servlet and put it on Tomcat server so that the server would be run only if there are any players
The Tomcat instance would run anyways, otherwise players couldn't connect to it.
What you could do is to provide a server that starts a new game instance when players connect. The server itself would have to always run.
In terms of technology, I'd suggest you use whatever you feel comfortable with. Don't care about performance yet but try and get started.
So if you already have some knowledge with a communication technology, try and use that. Just be aware of the limitations and take those into account (e.g. message formats, push/pull communication etc.).

It depends what kind of game you are after. Applets are usually good choice for presenting animation (completely in Java) and accessible from a browser. Real world examples would divert towards Flash for client presentation.
If your game is a turn type game (chess, cards etc.), then you can implement your logic in form of servlets or web services or ajax, with appropriate use of hashtables or databases to store live sessions on server side. If your game is more involved in terms of user experience (take an example of Need For Speed type, for instance), then creating a custom server make more sense.

If you are looking for a netwrok application framework in Java then you may consider reading about Apache MINA. Documentation claims that it " helps users develop high performance and high scalability network applications easily." and it has support for various transports such as TCP/IP and UDP/IP via Java NIO. Summary of features can be seen here.
My personal experience with MINA is so far good and used in various projects. One implementation resembles your case, Its not a mulitplayer game but do involves multiple applets connecting a server. I found MINA very good in handling multiple sessions. It do it very neatly. Moreover its very easy to scale and maintain code. Easy to add filters and define protocols.
There are no. of good tutorial available to jump start and initial setup is very easy to do.
However, like any emerging opensource project, it has its problems too. That are: Online community is small and documentation, though improving rapidly, is very limited.
Official user guide covers most of the basics and is a good starting point if you want to know more.

Building Java multiplayer server game - difference between sockets and webservice

I'm building a multiplayer card game using Flex on the client side and Java on the server side and I wanted to know if I must sockets and the accept method in order to connect users to the server for in order for them to join a game room or create one or to chat.
In the past I've learned how to build a game server which both sides are JAVA and connection was in sockets but now days the client side will be in FLEX which has few ways to connect to a Java server (XML,SOAP,BLAZEDS(AMF)) and I find it hard to understand how to write the Java server in order to do all the features of a game server , especially managing the rooms and sending data back to the users.
In the sockets way, when a user was connecting to the server and he had opened a room, this room was opened on a thread and who ever was joined that room then he was connected to the same thread and sending the messages to the right place was easy, so the problem is understanding how to do the same using SOAP or BLAZEDS.
Any help would be appreciated.
Thanks.

Please make your questions concise, it is difficult to know what is being asked for.
If you ask the difference between socket and webservice, sockets are used to manage the basic networking communications. Over them, you can receive/send bytes in whatever format / protocol you chose to.
SOAP / Webservices is just one of such formats, its advantage is that it is a standard way of encoding messages so you can easily write code that connects to your service in most platforms, and those messages are human-readable. The main disavantage is performance, both in bandwith and processing power (specially to parse it at the receiving end).
If you are starting, I would advise designing a format related to the application you are using to simplify things.

Take a look at RED5 and remoteSharedObjects. Using this tech, you can essentially put you "game" object in a remote shared object, and all the clients will have the same object with real time updates. Then on top of that you can use AMF (the protocol behind BlazeDS) for your less dynamic data.

Using raw sockets gives you the benefit of control. Control of your protocol format ( how your message data is structured). And because of this you can tweak your messaging to be more secure, or faster, or more robust, depending on your application requirements. All that control comes at the cost of complexity and maintenance. Because you get to say exactly what you want to send and how you want to send it you need to write and debug alot more code. Another issue with raw socket communication is that it has a significantly greater chance of being blocked by firewalls.
Using web services removes some of the complexity of deciding on a message format (with that being it's main benefit). You don't have to worry about things like byte endian-ness, string encodings, or data conversions (as much). As such web services really excel at data communications amongst heterogeneous clients and servers where inter-operability is key. The cost being that it's relatively complicated to serialize/deseserialize, and as such, slower than binary messaging formats. Web services are good to use when you have to communicate with client applications that you have little control of (not really your case). Web services are traditionally tunneled through HTTP, so there is an additional advantage in being able to worry less about a firewall blocking access to your game.
BlazeDS attempts to bridge both worlds - it gives you some of the robust features of web services (fallback communication options, firewall interoperability etc), but uses it's own binary format for serialization/ deserialization. This gives it some of the speed of using raw sockets without a lot of the downsides. I think it's a great candidate to explore, but if you find yourself needing more speed then raw sockets would be worth messing around with.
Good luck.

Sockets are the programmatic interface to OSI Level 4 Transport Layer. Everybody uses them, ie Webservices is a Level 7 Application Layer interface that hides the lower levels.
If you need real-time bidirectional data exchange between your client and server you're better off managing your own TCP sockets. Flex still supports sockets.