I have developed 'Skype 2.0 API for Java' using eclipse SWT library.
http://sourceforge.jp/projects/skype/files/

Supported functions
・Profile API
・Contact List API
・Chat API
・Call API
・Video Call API
・A2A API
・Group API
・Dialog API

Document site(Japanese) is
http://skype.sourceforge.jp/

Please, give me your feed back

Great!

I've just created a project onto IDEA IDE and it works perfectly.
Let me play with your apis a little more.

Thanks,
Luca

hi,

I just try to run your SystemTest in eclipse 3.1, before i update my skype to v2.0, but my Norton Internet Worm Protection has detected and block a Subseven 2.1/2.2 Trojan horse with c:WINDOWSsystem32javaw.exe

It doesn't appear after update...

It seems like some Bugs in somewhere.

[quote]
I just try to run your SystemTest in eclipse 3.1, before i update my skype to v2.0, but my Norton Internet Worm Protection has detected and block a Subseven 2.1/2.2 Trojan horse with c:WINDOWSsystem32javaw.exe

It doesn't appear after update...

It seems like some Bugs in somewhere.
[/quote]

The cause of this problem is previous Skype version?
This library currently supports and is tested on Skype 2.0 only.
Please, gime me your previous skype version information and system environment (Java, Windows, Norton version) for more investigation.

Skype API uses Window message for plugin-to-Skype commnunication.
But previos version's and current version's start-up communication method are different.
Because previos version can't reply to new commnunication method(new type of window message), Norton classified 'Skype API for Java' to Trojan　perhaps.

Additionally, you are able to check the code because 'Skype API for Java' is full open source.

Thank you for trying 'Skype API for Java'.

My System:

Windows XP pro v2002 sp2
skype 1.4.0.84
Noron AntiVirus 2005
Java 1.5.0_04
eclipse 3.1.0


I m not clear about how SWT and Skype lib work together.Did this GUI lib use some special call to windows, then something happens between SWT lib, skype1.4 and your 2.0 lib by accident ?
Anyway, It should be a minor bug until other user reports

Your test classes are very helpful for a Java developer. You have made a great work! It's my pleasure to use it.

Thank you, hisano.

P.S.
Some japanese charaters are not supported in my system, I must remove them manually to run the test. I think many Dever want to see english Strings in next version

[quote=teddyc]My System:

Windows XP pro v2002 sp2
skype 1.4.0.84
Noron AntiVirus 2005
Java 1.5.0_04
eclipse 3.1.0


I m not clear about how SWT and Skype lib work together.Did this GUI lib use some special call to windows, then something happens between SWT lib, skype1.4 and your 2.0 lib by accident ?
Anyway, It should be a minor bug until other user reports
[/quote]

Thank you for your system information in detail.
I will investigate this problem from Norton AntiVirus's detection method .

'Skype 2.0 API for Java' uses SWT's org.eclipse.swt.internal.win32.OS class for calling Win32 API.
Because of this class, 'Skype 2.0 API for Java' has no JNI code(no method with native modifier) in jp.sf.skype.connector.win32.Win32Connector class.
I will check here, too.

[quote=teddyc]P.S.
Some japanese charaters are not supported in my system, I must remove them manually to run the test. I think many Dever want to see english Strings in next version [/quote]

I will i18n this code in the next version.

Thank you very much for your cooperation.

[quote=hisano]I have developed 'Skype 2.0 API for Java' using eclipse SWT library.
http://sourceforge.jp/projects/skype/files/

Supported functions
・Profile API
・Contact List API
・Chat API
・Call API
・Video Call API
・A2A API
・Group API
・Dialog API

Document site(Japanese) is
http://skype.sourceforge.jp/

Please, give me your feed back [/quote]

It's really great! Do you have documentation in English or a brief toturial ? Thanks

The below is a great document from Terry who tried Skype 2.0 API for Java.
Thanks Terry


01. The Skype API on Windows.

These notes assume the reader has:

a. solid experience with the most current JDK;
b. at least browsed the documentation on the Skype 2.0 API; and
c. has looked at the examples from the Skype API Guide.

The notes DO NOT assume that the reader has:

a. actually tried to build an application using any of those other
wrappers or interfaces to the Skype API;
b. an in-depth understanding of the Windows Win32 API; nor
c. an in-depth understanding of SWT.

The key characteristics of the Skype API are:

a. it uses a Windows interprocess communication protocol based
on Messages;
b. the protocol is basically asynchronous and stateless.

There is no particular send-receive sequence that your Java Client
application can use in 'blocking mode' to obtain a known copy of the
Skype Client's state. The Skype client must effectively be treated as
a 'black box' that sends messages to your client either in response
to specific requests for information or as unsolicited notification events.

02. The Java Skype Interface Architecture.

A Connector class object is used to encapsulate the communication
between the Skype Client and your Java Client. The Windows version
of that abstract class is W32Connector. That is where the SWT wrapper
for Microsoft's Win32 API is used to establish and maintain a path by
which message requests can be sent to the Skype Client and messages
received from the Skype Client can be passed back to your application
as simple Strings. This 'Loop Forever' listening code runs as a
separate Thread, "Win32EventDispatcher".

NOTE # 1 for SWT Programmers: The loop used is the standard SWT
event processing loop. If you are using this library in a true SWT
application, you already have a well-known place where you invoke
this loop logic. If this library's use of that loop causes your application
to fail, it might be better to replace it with Thread.wait logic that could
be notified when your application is ready to shutdown. If your
application does not use any SWT U/I, it is a daemon-like service,
this method of loop-waiting should work just fine.

NOTE # 2 for SWT Programmers: Messages sent from your Java
Client application to the Skype Client are scheduled through the
SWT event-handling thread. I don't think this approach is really
necessary as the sendCommand code does not 'touch' any
Display-managed code. If your use of this library involves a lot
message sending, you may want to reduce some of the overhead
by removing the dependence upon 'Display.asychExec'; otherwise,
there is probably no harm in this 'protective' programming approach.

03. Java Skype Callbacks.

The 'hooks' for your Java Client application to respond to what is
going on with the Skype Client are constructed as Listeners.
Depending upon what Skype Client activity you want to handle,
you will add one of these Listeners:

a. Connector.
b. Call.
c. CallReceived.
d. MessageReceived.
e. Application.
f. Stream.

The Connector Listener Interface is the most import one. Its
messageReceived method is called back for every message
sent by the Skype Client. However, because it is so important,
the Java Skype library performs some automatic processing on
the messages in addition to whatever processing your application
might require.

One such 'automatic processing' is debugging. If you turn on
debugging, incoming message traffic is written to stdout.
I recommend you change that to write to stderr. Output to
stdout is buffered, so what you write does not always
immediately make it to your screen. When trying to understand
low-level message flows, if input and output debugging text
is sometimes buffered, it is almost impossible to understand the
real sequence of events represented by the flow of control in
the code.

Alternately, and probably better for gaining understanding, do
not turn on debugging mode, instead catch all the incoming
messages and examine them in your own code. It turns out,
at least with the present code, that you have to examine all
incoming message traffic in order to know when a call has
ended.

The Call Listener Interface provides a statusChanged callback
method. At the present time, that call back never seems to
be made. It is apparently intended as a convenience for keeping
track of Call Status without having to intercept and process
messageReceived on the Connector Listener Interface.

The Call Received Listener Interface is clearly just such a
convenience; the callReceived method is invoked when the
Connector Listener Interface detects the RINGING state change.

The Message Received Listener Interface is a similar
convenience whose messageReceived callback will only be
invoked when a new Instant Message is received from the
Skype Client.

The Application Listener Interface may be a little confusing if
you think that you are writing an application. You are writing
an application, but the 'attaching' and 'unattaching' of your
Java Client to the Skype Client IS NOT handled here. The
attach-unattach state changes are handled through the
Connector Listener Interface. This interface's connected and
disconnected methods are only called back when you try to
use the APP2APP part of the Skype API.

The Stream Listener Interface's textReceived and
datagramReceived methods are only called back when message
traffic through the APP2APP protocol is received by your
Java Client.

04. Java Skype Thread Issues.

As mentioned above, because the Java Skype library borrows
its COM interface from SWT, there are already a couple of
threads involved as soon as your Java Client application gets
a Connector instance. That multi-threading, however, is just
a by-product of the way a typical SWT application needs to
be built in order to have fast screen rendering along with
fast event processing; it is not really germane to our concerns.

When the "Win32EventDispatcher" does receive some incoming
traffic from the Skype Client, it does fork a new Thread,
"Win32MessageSender", for each message.

Note that it DOES NOT fork a new Thread for
each Listener queued up to handle messageReceived; all
such callbacks are handled 'first-in-first-out' in a single Thread.
So, if your application's processing of any incoming traffic
incurs delays, you need to fork a separate Thread to handle
that work with the least interference for other Listeners behind
you in the queue.

Beware that Connector's listener List can grow in ways that
that you probably would not expect. Every message sent
to the Skype Client [Connector.execute] pushes a new
Listener on to the List. So, for example, if your Call Received
Listener does something as simple as ask for the Call Type,
a message will have to be sent to the Skype Client to obtain
that information. That will push another Listener on to the
List. The Call object really only has one field, ID, that it can
provide without a round-trip through the message-processing
protocol.

There are obviously some changes to the Skype API that
would be beneficial, but without those enhancements,
there is little that the Java Skype library can do. We could
imagine some 'intelligence' in the message-receiving layer
that would, for example, upon receipt of a new Call, cache
that information, make additional requests of the Skype
Client, and only 'release' a new call to our application after
the Call object had been populated with the additional fields.
That would definitely make our work easier, but it would
also delay Call notification and increase the error handling
logic.

So, for now, the important guideline is: Fork a separate
Thread for non-trivial message handling code, and even then,
be careful about generating additional message traffic in
your message handling code.

Thank you so much. It helps

I have the following java code for automatically picking up the incoming call. The problem is the ringing tone won't stop after the call is answered.

Do we need to do something else besides call.anwswer() ? Can some one help me about this ? Thanks in advance.

Hisano, thanks for the work you have put into this project. I have downloaded it and started testing this API for whether to use it to integrate Skype into a large project I am working on. What I have tested works well so far, however I have found a couple classes/functionalities that seem to be incomplete. For example, there is a CallListener interface but there seems to be no CallEvent class or any class that has a addCallListener(CallListener) method.
Maybe I don't have the most up-to-date classes.... I downloaded the 'Skype 2.0 API for Java' from the previously posted link:
http://sourceforge.jp/projects/skype/files/
Does anyone know whether work is being continued on this project? I would be interested in contributing to this project whether it be through testing or code contribution.

Any information would be greatly appreciated.

Thanks,

[quote=mengbuaa]I have the following java code for automatically picking up the incoming call. The problem is the ringing tone won't stop after the call is answered.

Do we need to do something else besides call.anwswer() ? Can some one help me about this ? Thanks in advance.

[/quote]

I have got the same problem in my environment (2.0.0.97).
Perhaps, I think it is a Skype bug of timing.

Please, insent Thread.sleep(1000) before call.answer() though it is not a good solution.

[quote=paulsson]
Does anyone know whether work is being continued on this project? I would be interested in contributing to this project whether it be through testing or code contribution.[/quote]

Yes, the development of it is continued slowly.
Please, use the latest code by getting it from CVS.

My focus is on Linux and MacOS support (Java's good point) and bug fixing now.
I will be happy of your contribution.

hisano,

Can you provide us with the details on checking out 'Skype 2.0 API for Java' from CVS please (CVS server URL, project path under cvsroot, username, password, etc)? I look forward to working on and using this API.

Thanks,
Erik

[quote=paulsson]
Can you provide us with the details on checking out 'Skype 2.0 API for Java' from CVS please (CVS server URL, project path under cvsroot, username, password, etc)? I look forward to working on and using this API.
[/quote]

You can check out the latest code by the below CVS commands.
(It is better to use the eclipse's CVS functions.)



This information is from http://sourceforge.jp/cvs/?group_id=2072.

hisano,

How can I start sending you classes to review for incorporating into this API? I have written a CallStatusListener interface which is used to get notifications on any Calls whose status has changed and a CallStatusNotifier class which implements ConnectorListener and is used to notify all CallStatusListeners that are registered with it about Call status changes.
These 2 classes work basically the same as your CallReceivedListener implementation works except the CallStatusNotifier separates the code for listening to the incoming messages out of the Skype class, instead of doing doing what you did in the method Skype.addCallReceivedListener(CallReceivedListener) (the ConnectorListener is add in the client code being developed not in the Skype class). This can be changed as you see fit.
Please let me know if you are interested in reviewing these classes and how I can send them to you.

Thanks,

There seems to be an alternative java API project called "JSA". I presume this is an entirely separate project, or are they somehow related?

To try to clear up confusion I've slapped some information on a new wiki page here: https://developer.skype.com/wiki/Java_API
Please edit that page to provide more information if you know more about it.

[quote=paulsson]
How can I start sending you classes to review for incorporating into this API? I have written a CallStatusListener interface which is used to get notifications on any Calls whose status has changed and a CallStatusNotifier class which implements ConnectorListener and is used to notify all CallStatusListeners that are registered with it about Call status changes.
[/quote]

Oh, great! Thank you very much.
Please, send me (hisano@gmail.com) a patch file (on eclipse, select right click menu [Team - Create Patch] on skype project directory.).

[quote=gh-hwo]There seems to be an alternative java API project called "JSA". I presume this is an entirely separate project, or are they somehow related?

To try to clear up confusion I've slapped some information on a new wiki page here: https://developer.skype.com/wiki/Java_API
Please edit that page to provide more information if you know more about it.[/quote]

There is no relation between 'Skype API for Java' and 'JSA'.

Used technology is different.
'Skype API for Java' - SWT's Win32 classes (org.eclipse.swt.internal.win32.OS)
'JSA' - JNI

Thanks a lot hisano, I load it into Eclipse and run perfectly. Try to dive in it
more:)
BTW, I find the getInstance() method in Connector should be moved to Win32Connector.java.

-polis


[quote=hisano]I have developed 'Skype 2.0 API for Java' using eclipse SWT library.
http://sourceforge.jp/projects/skype/files/

Supported functions
・Profile API
・Contact List API
・Chat API
・Call API
・Video Call API
・A2A API
・Group API
・Dialog API

Document site(Japanese) is
http://skype.sourceforge.jp/

Please, give me your feed back [/quote]

Sorry for not posting something sooner. Below is my code for answring a call with Hisano-san's latest code. Like adding a one second wait, it may not be the perfect answer. It does correctly accept the incoming call; my problem is that it does so IMMEDIATELY. In fact I want the code to answer after N number of rings so that, as with most implementations of an answering machiine, the user can do a little call screening. So I hope what is below will be of some help to you. [You might very likely also be interested in why I have not been attentive to these postings for the last month. Since I think Hisano-san's package is doing a good job, my focus has been on mimicing the behavior of the SAM product via the javax.sound.sampled.* packages. I like the fact that their use of VAC is entirely unseen; I have not been able to get VAC to behave that nicely. While trying to get Sun to ship the most current source for javax.sound.*, I have gone through the process of getting Mustang's latest beta working with the lastest Eclipse SWT packages. Thanks to quick IBM turn-arounds, that is now working, so I am testing all of this with the most current javax.sound.* under Java 6.]




Notes:

01. My checking of currentCall prohibits the handling of multiple incoming calls in parallel, but that's not my design goal, so it is valid as shown.
02. P.rintlnT is just an embellishment of System.err.println, but the embellishemt is pretty important -- it tells me what threads are producing what output in what chronological sequence. Below is some actual output. I think it explains the 'race condition', but I am not knowledgable enought about Skype to understand/explain it.

Win32MessageSender[59] 06-05-01 18:53:08.552 >>CallReceivedListener.callReceived;Call 861 Accepted.<<
Win32MessageSender[60] 06-05-01 18:53:07.972 >>Connector.fireMessageReceived;1 / 2<<
Win32EventDispatcher[51] 06-05-01 18:53:08.552 >>W32Connector.sendCommand;SET CALL 861 STATUS INPROGRESS<<
Win32MessageSender[61] 06-05-01 18:53:08.552 >>Connector.fireMessageReceived;1 / 2<<
Win32MessageSender[61] 06-05-01 18:53:08.552 >>Connector.fireMessageReceived;2 / 2<<
Win32MessageSender[61] 06-05-01 18:53:08.552 >>ConnectorListener.messageReceived;MESSAGE 864 STATUS READ<<
Win32EventDispatcher[51] 06-05-01 18:53:08.562 >>W32Connector.messageReceived;74;65756;61143100<<
Win32EventDispatcher[51] 06-05-01 18:53:08.562 >>W32Connector.messageReceived;CALL 861 STATUS INPROGRESS<<
Win32MessageSender[60] 06-05-01 18:53:08.552 >>Connector.fireMessageReceived;2 / 2<<
Win32EventDispatcher[51] 06-05-01 18:53:08.683 >>W32Connector.messageReceived;74;65756;61143100<<
Win32EventDispatcher[51] 06-05-01 18:53:08.773 >>W32Connector.messageReceived;CALL 861 STATUS INPROGRESS<<
Win32MessageSender[60] 06-05-01 18:53:08.773 >>ConnectorListener.messageReceived;MESSAGE 864 STATUS RECEIVED<<
Win32MessageSender[62] 06-05-01 18:53:08.592 >>Connector.fireMessageReceived;1 / 3<<
Win32MessageSender[63] 06-05-01 18:53:08.773 >>Connector.fireMessageReceived;1 / 3<<
Win32MessageSender[63] 06-05-01 18:53:08.773 >>Connector.fireMessageReceived;2 / 3<<
Win32MessageSender[63] 06-05-01 18:53:08.773 >>ConnectorListener.messageReceived;CALL 861 STATUS INPROGRESS<<
Win32MessageSender[63] 06-05-01 18:53:08.773 >>Connector.fireMessageReceived;3 / 3<<
Win32MessageSender-59: Setting Call Status: INPROGRESS
Win32MessageSender[59] 06-05-01 18:53:08.773 >>CallReceivedListener.callReceived;Call 861 Answered.<<

I think it will be very helpful to post this on the sourceforge site as well, if it hasn't been posted already. Thank you.

[quote=hisano][quote=mengbuaa]
It's really great! Do you have documentation in English or a brief toturial ? Thanks[/quote]

The below is a great document from Terry who tried Skype 2.0 API for Java.
Thanks Terry


01. The Skype API on Windows.

These notes assume the reader has:

a. solid experience with the most current JDK;
b. at least browsed the documentation on the Skype 2.0 API; and
c. has looked at the examples from the Skype API Guide.

The notes DO NOT assume that the reader has:

a. actually tried to build an application using any of those other
wrappers or interfaces to the Skype API;
b. an in-depth understanding of the Windows Win32 API; nor
c. an in-depth understanding of SWT.

The key characteristics of the Skype API are:

a. it uses a Windows interprocess communication protocol based
on Messages;
b. the protocol is basically asynchronous and stateless.

There is no particular send-receive sequence that your Java Client
application can use in 'blocking mode' to obtain a known copy of the
Skype Client's state. The Skype client must effectively be treated as
a 'black box' that sends messages to your client either in response
to specific requests for information or as unsolicited notification events.

02. The Java Skype Interface Architecture.

A Connector class object is used to encapsulate the communication
between the Skype Client and your Java Client. The Windows version
of that abstract class is W32Connector. That is where the SWT wrapper
for Microsoft's Win32 API is used to establish and maintain a path by
which message requests can be sent to the Skype Client and messages
received from the Skype Client can be passed back to your application
as simple Strings. This 'Loop Forever' listening code runs as a
separate Thread, "Win32EventDispatcher".

NOTE # 1 for SWT Programmers: The loop used is the standard SWT
event processing loop. If you are using this library in a true SWT
application, you already have a well-known place where you invoke
this loop logic. If this library's use of that loop causes your application
to fail, it might be better to replace it with Thread.wait logic that could
be notified when your application is ready to shutdown. If your
application does not use any SWT U/I, it is a daemon-like service,
this method of loop-waiting should work just fine.

NOTE # 2 for SWT Programmers: Messages sent from your Java
Client application to the Skype Client are scheduled through the
SWT event-handling thread. I don't think this approach is really
necessary as the sendCommand code does not 'touch' any
Display-managed code. If your use of this library involves a lot
message sending, you may want to reduce some of the overhead
by removing the dependence upon 'Display.asychExec'; otherwise,
there is probably no harm in this 'protective' programming approach.

03. Java Skype Callbacks.

The 'hooks' for your Java Client application to respond to what is
going on with the Skype Client are constructed as Listeners.
Depending upon what Skype Client activity you want to handle,
you will add one of these Listeners:

a. Connector.
b. Call.
c. CallReceived.
d. MessageReceived.
e. Application.
f. Stream.

The Connector Listener Interface is the most import one. Its
messageReceived method is called back for every message
sent by the Skype Client. However, because it is so important,
the Java Skype library performs some automatic processing on
the messages in addition to whatever processing your application
might require.

One such 'automatic processing' is debugging. If you turn on
debugging, incoming message traffic is written to stdout.
I recommend you change that to write to stderr. Output to
stdout is buffered, so what you write does not always
immediately make it to your screen. When trying to understand
low-level message flows, if input and output debugging text
is sometimes buffered, it is almost impossible to understand the
real sequence of events represented by the flow of control in
the code.

Alternately, and probably better for gaining understanding, do
not turn on debugging mode, instead catch all the incoming
messages and examine them in your own code. It turns out,
at least with the present code, that you have to examine all
incoming message traffic in order to know when a call has
ended.

The Call Listener Interface provides a statusChanged callback
method. At the present time, that call back never seems to
be made. It is apparently intended as a convenience for keeping
track of Call Status without having to intercept and process
messageReceived on the Connector Listener Interface.

The Call Received Listener Interface is clearly just such a
convenience; the callReceived method is invoked when the
Connector Listener Interface detects the RINGING state change.

The Message Received Listener Interface is a similar
convenience whose messageReceived callback will only be
invoked when a new Instant Message is received from the
Skype Client.

The Application Listener Interface may be a little confusing if
you think that you are writing an application. You are writing
an application, but the 'attaching' and 'unattaching' of your
Java Client to the Skype Client IS NOT handled here. The
attach-unattach state changes are handled through the
Connector Listener Interface. This interface's connected and
disconnected methods are only called back when you try to
use the APP2APP part of the Skype API.

The Stream Listener Interface's textReceived and
datagramReceived methods are only called back when message
traffic through the APP2APP protocol is received by your
Java Client.

04. Java Skype Thread Issues.

As mentioned above, because the Java Skype library borrows
its COM interface from SWT, there are already a couple of
threads involved as soon as your Java Client application gets
a Connector instance. That multi-threading, however, is just
a by-product of the way a typical SWT application needs to
be built in order to have fast screen rendering along with
fast event processing; it is not really germane to our concerns.

When the "Win32EventDispatcher" does receive some incoming
traffic from the Skype Client, it does fork a new Thread,
"Win32MessageSender", for each message.

Note that it DOES NOT fork a new Thread for
each Listener queued up to handle messageReceived; all
such callbacks are handled 'first-in-first-out' in a single Thread.
So, if your application's processing of any incoming traffic
incurs delays, you need to fork a separate Thread to handle
that work with the least interference for other Listeners behind
you in the queue.

Beware that Connector's listener List can grow in ways that
that you probably would not expect. Every message sent
to the Skype Client [Connector.execute] pushes a new
Listener on to the List. So, for example, if your Call Received
Listener does something as simple as ask for the Call Type,
a message will have to be sent to the Skype Client to obtain
that information. That will push another Listener on to the
List. The Call object really only has one field, ID, that it can
provide without a round-trip through the message-processing
protocol.

There are obviously some changes to the Skype API that
would be beneficial, but without those enhancements,
there is little that the Java Skype library can do. We could
imagine some 'intelligence' in the message-receiving layer
that would, for example, upon receipt of a new Call, cache
that information, make additional requests of the Skype
Client, and only 'release' a new call to our application after
the Call object had been populated with the additional fields.
That would definitely make our work easier, but it would
also delay Call notification and increase the error handling
logic.

So, for now, the important guideline is: Fork a separate
Thread for non-trivial message handling code, and even then,
be careful about generating additional message traffic in
your message handling code.[/quote]

Did a Skype staff respond to this?

[quote=hisano][quote=mengbuaa]I have the following java code for automatically picking up the incoming call. The problem is the ringing tone won't stop after the call is answered.

Do we need to do something else besides call.anwswer() ? Can some one help me about this ? Thanks in advance.

[/quote]

I have got the same problem in my environment (2.0.0.97).
Perhaps, I think it is a Skype bug of timing.

Please, insent Thread.sleep(1000) before call.answer() though it is not a good solution.[/quote]