We Keep Coding

Android VoIP call implementation

First of all I'm a newbie in VoIP implementation. I need to implement VoIP single and group call in android application. Could you tell me, what is actually the best way to achieve this ? I'm looking for Android SIP library (probably open source) which should:
has good documentation with simple app examples
be ready to use with java
Maybe just native android SIP api will be the best ? But I heard that it doesn't support group calls.

Most of the voip libraries use C/C++ implementation for various reasons. You can use PJSip which is a C voip/sip stack. It has a good documentation but you have to build it yourself using android ndk . It has good documentation and also contains processes to build it for Android and other platforms. But there is no java/android wrapping built in so you should do that yourself. Another option is Liblinphone which is also based on C stack but provides all of the wrapping and implementations out of the box so you don't have to bother so much on native codes. It also has a sample application which you can try yourself. One downside of Liblinphone is that it lacks proper documentation and you have to dig in more.
Regarding the android SIP api, I don't think it is a good option as it has much more limitation and hardly maintained. It is based on Jainsip stack which is a 100% java stack but is too verbose. I personally would like to recomment Liblinphone as I am currently implementing it and am pretty satisfied with it. Best of luck...
Update
Here is the source code of linphone for android if you are interested in it. You can get pretty much idea of Liblinphone for android from it. You have to dig much more into the sources though.

You can have a look at Restcomm Android SDK:
It's open source, with an active community around it
It using SIP for signaling and Webrtc for media so should work nicely with NATs, etc
Comes with 2 sample applications that you can play with and alter their code to experiment
Comes with quick start guide, reference doc
You can check the Olympus sample App right away by installing the .apk from this link
Notice that the SDK doesn't support group calling out of the box, but you could combine it with Restcomm-Connect open source platform to add such functionality very easily. Restcomm-Connect also comes with docker, so you should be able to install it right away.
Please let me know if you have any questions
Best regards,
Antonis

API to integrate with Domino

I am a relatively newbie to Lotus/Domino world and have been tasked with the following Domino task.
Access user's Domino mailbox (from a middleware server) and delete certain malicious emails from the same.
Additional Background: There is a external security tool/process that analyzes all incoming email and can flag the email as malicious. In the event it is flagged as malicious then I want to delete this email from the respective user's inbox.
My solution would be deployed on its own middleware server (Linux based) and will receive incoming notifications as to what emails need to be deleted.
The Domino server deployed in my environment is Lotus/Domino 9.
I want to preferably implement this functionality using Java.
I researched and found the potential options for me for accessing the user's inbox on Domino server.
1) I saw that there is a IBM C/C++ API toolkit for Domino. The C API looks quite complicated to me on first glance. Also I would need to install the Notes client (on my middleware server) so that I could invoke the C API remotely?
2) Is there a Java API that I could use to connect/access Domino? I found:
IBM Knowledge Center - IBM Domino Designer 9.0.1 - API Documentation and
IBM Notes and Domino Application Development wiki.
These seem to indicate there is some Java/REST API interface however I am not sure if I can use this to access inbox/mailbox data. It seems to indicate "Calendar" data but nothing about email/mailbox data as such.
3) I came across the OpenNTF Domino API project while researching and that seems to have a Java API. Should I be using this?
What is the best way to access Domino from an external server standpoint? Am I stuck with the C/C++ API or is there a relatively (easier to understand and use) REST/Java API that I could leverage? Also will I have to have the Notes client installed on my middleware server so that I can invoke the API (C/C++ or Java)?

You should avoid the Notes C and C++ APIs unless:
You know Lotus Notes and Domino really, really well (or are willing to learn a lot very quickly) and
You determine that the only way to solve your problem would be to write a Domino server task or extension. These APIs work with Lotus Notes/Domino data a very low level.
Yes, there is a Java API. It's been around for years. There is also a REST API that can be accessed from Java (or from any other language that can make HTTP connections) but that's only been around for a few years.
The Java API is richer and can get to a lower level than the REST API.
The REST API might be adequate for what you need, but there's a very good chance that the server will have to be set up specifically to enable it to access the mailboxes. That will not necessarily be the case if you use the Java API.
Using Java API will depend on whether you can run your Java code on a machine that has the core Lotus Notes/Domino code installed. Also you'll have to investigate the technical and licensing questions on that.
A good way to get educated on the Java API is to read Bob Balaban's book. It is old and out of date, but it does cover most of what you need to know for the purpose you've described. One caveat is that it was written so early that it did not cover the need for making recycle() calls. But he's posted the chapters here for free download. Now that you know about recycle() I'm sure you can find information about why and when you need it.
The OpenNTF Domino API is an open source replacement for the offical Java API. It has been built to solve a lot of really nagging problems (like recycle()!) and the limitations usage of the official API runs into.
Re: installing the Notes client which I alluded to that when I mentioned the core Lotus Notes/Domino code under point 2. You have two options for the official Java API:
Local:
This uses the core Notes/Domino code to make Notes RPC calls to the server, so you will have to install a licensed version of the Notes client or Domino server code to get the core code.
Note that if you are tied to a 64-bit JVM, you need 64-bit code and that means you need to install the Domino server instead of the Notes client since there is no 64 bit Notes client.
Remote:
You don't need to install any Notes or Domino code but this uses CORBA/IIOP instead of Notes RPC to talk to the server. This requires enabling IIOP on the Domino server.
The last time I checked, the OpenNTF API only supports the "Local" model.
I do have to mention though: this is close to being off topic for this reason:
Questions asking us to recommend or find a book, tool, software
library, tutorial or other off-site resource are off-topic for Stack
Overflow as they tend to attract opinionated answers and spam.
Instead, describe the problem and what has been done so far to solve
it.
Whilst the existence of a Java API can be easily confirmed by searching here on StackOverflow, I have to admit that finding basic references for Domino is quite a bit more challenging. There is literally 25 years worth of information about it that's out there, but is often in fragments and is obsolete. It is really difficult to find information about tools, APIs and libraries that are available and current today. The options are really pretty limited.
As such I think this question deserves an answer since it does not really come down to opinion. I'm not going to make a recommendation though, because that really would be opinion.

Android Apps using python

I found that Android development can be done through Python from the link http://www.linuxplanet.com/linuxplanet/tutorials/7157/1. My question is whether all the libraries that are available in Java are also available in python.
Any of you already started with python on Android if so please indicate links to help get our group up to speed.

No, not all the libraries have been exposed. You can look at the SL4A project on google-code for more information regarding the support it has.
Is this a complete API bridge, or are there restrictions?
BeanShell, JRuby, and Rhino basically give you a complete API bridge (you can invoke Java calls directly). See the documentation for those interpreters for instruction on how to accomplish this. Cross compiled languages like Lua are more restricted. They only have access to the APIs exposed through the RPC layer. See the API reference for a list of currently supported APIs. The RPC layer is easy to extend.

How to create a mobile oriented, multiplatform, shared library in Java?

I have a Java application that runs on BlackBerry (JDE 4.5). I want to port this application to Android, and be able to maintain the 2 applications simultaneously. I may also want to port this application to other Java platforms (J2ME ?).
I understand that a good part of the code will have to be specific to each platform (UI and other stuff). But I also feel that a lot of the code could (should) be shared (domain related classes).
What is the best way to achieve this, and what are the pitfalls to avoid?
I have been able so far to create a JAR with all my shared classes, that I have been able to integrate into my BlackBerry application (using preverify and rapc). But:
The JAR is a J2SE library. How can I make sure that it will run (or even compile) on BlackBerry, Android or J2ME?
I am also using a JSON library targeting J2ME (https://github.com/upictec/org.json.me/). This library seems to make use of some kind of preprocessing directives (CLDC, see https://github.com/upictec/org.json.me/blob/master/src/main/java/org/json/me/JSONObject.java#L392). How can I use (or convert) this library using the right preprocessing definitions?

This is likely to be difficult:
As you have already identified, the UI code will have to be different for each platform.
There are major differences between Java SE / Android and Java ME-based platforms. For example, ME doesn't have the Collections framework, or the java.io or java.nio stacks.
It is hard to predict from the information you've provided, but there's a fair chance that you'll spend more time fighting the platform dependencies than you are saving by sharing the code-base.

These days, the biggest stumbling block to sharing code this way is that the BlackBerry VM and Android VM both support different versions of the Java language. BlackBerry uses a subset of Java 1.3, Android uses a subset of Java 1.5. (As an aside, neither platform implements a Java VM, both use their own VMs. Java is used as the programming language. Java bytecodes must be transformed to the appropriate native VM format before they can run on the platform.)
The biggest difference you will find as a library implementor is that the BlackBerry lacks the things that were introduced in 1.5, very important things like generics and enums. Even worse, the Collections classes are missing from the BlackBerry. It is unfortunate, but that is the way it has been for a long time now.
This means that to be truly portable you have to write to the lowest-common denominator, which means using (very) old-style classes like Hashtable and Vector, not having generics, rolling your own enums (as in the 1st edition of Effective Java) and so on.
Or you build two libraries, a modern version for Android and a stripped-down version (with just the bare stuff you need) for the BlackBerry.
Hard to say what`s right for you.

Rather than prepackage your shared library, I would consider sharing the library project and having it as a dependency in your mobile applications' build process. That would allow you to share the code base, but have it built by the appropriate builders for your target devices. With a bit of IDE magic and some attention to detail, you should be able to pick up errors before anything is shipped out.
Alternatively, set up your library project to use two separate builders to pick up errors. That would allow cleaner distribution, but you may run into problems trying to convince your IDE to treat the project as being device specific in order to identify problem areas.
It would be likely that you would end up supporting the lowest common denominator device (cough Blackberry), and forgoing the additional facilities of the more extensive Java implementation on Android.
Unfortunately the answer will be one of experimentation. Try it and see what happens.

The article Porting Android code to BlackBerry has some good detail on how to work with code shared between the two platforms.

it will be very difficult to create shared library for blackberry and android.
if you want simple method, create your application as web app.
using
phonegap with jQtouch

How much of Java can I really use with GWT?

I'd like to learn GWT, and I like the fact that it compiles to Javascript. My question is, how much of Java I can really use with GWT? My guess would be that limitations apply mostly for client side, while on the server side I should be able to make use of any existing Java library, right? Or, will I be only able to use a small subset , because of the compilation to Javascript thing?
What are it's limitations? I am interested in what it's not able to do, or things that require too many workarounds to implement. I need to know if learning GWT is a good choice for a possible freelance carrier in web development.

The GWT website has this documentation exactly to answer that question.

See the JRE emulation docs. Those are the supported out of the box emulated classes that you can use.
"Google Web Toolkit includes a library that emulates a subset of the Java runtime library. The list below shows the set of JRE packages, types and methods that GWT can translate automatically. Note that in some cases, only a subset of methods is supported for a given type."
You can also provide your own emulation for other classes using <super-source/> in your gwt.xml to point to a package that will provide replacement Java classes for those that can't be directly compiled to JavaScript.