Are there any good Java cross platform SIP / VOIP dev kits that you have personally used? I've found one or two that seem like they could be worthwhile pursuing, but I'm still not 100% sold on them.
http://www.voipdevelopmentkit.com/
That seems to be the leader at the moment. However, it doesn't look like they are developing still. I've had a few emails with them and the answers provided were great.
I have a Java application that requires an inbuilt SIP endpoint. I'd like to avoid wrapping native libraries if possible, as this application needs to run on Windows, Mac OS X, and potentially Linux systems.
Something with third party call control (3pcc) would instantly top the list, but it's not a 100% requirement as I figure I can implement that myself without too much worry.
try peers, this is a java sip client I developed. It is typically used to add telephony feature in an already existing application. It is 100% pure java and cross platform (works on windows, linux and mac).
Check JAIN SIP it is the reference implementation of JSR 32, free and public domain and very active https://jsip.java.net/
Related
What I'd like to ask is if anybody knows about an hardware USB-dongle for software protection which offers a very complete out-of-the-box API support for cross-platform Java deployments.
Its SDK should provide a jar (only one, not one different library per OS & bitness) ready to be added to one's project as a library.
The jar should contain all the native stuff for the various OSes and bitnesses
From the application's point of view, one should continue to write (api calls) once and run everywhere, without having to care where the end-user will run the software
The provided jar should itself deal with loading the appropriate native library
Does such a thing exist?
With what I've tried so far, you have different APIs and compiled libraries for win32, linux32, win64, linux64, etc (or you even have to compile stuff yourself on the target machine), but hey, we're doing Java here, we don't know (and don't care) where the program will run!
And we can't expect the end-user to be a software engineer, tweak (and break!) its linux server, link libraries, mess with gcc, litter the filesystem, etc...
In general, Java support (in a transparent cross-platform fashion) is quite bad with the dongle SDKs I've evaluated so far (e.g. KeyLok and SecuTech's UniKey).
I even purchased (no free evaluation kit available) SecureMetric SDKs&dongles (they should've been "soooo" straighforward to integrate -- according to marketing material :\ ) and they were the worst ever: SecureDongle X has no 64bit support and SecureDongle SD is not cross-platform at all.
So, has anyone out there been through this and found the ultimate Java security usb dongle for cross-platform deployments?
Note: software is low-volume, high-value; application is off-line (intranet with no internet access), so no online-activation alternatives and the like.
-- EDIT
Tried out HASP dongles (used to be called "Aladdin"), and added them to the no-no list: here, too, there is no out-of-the-box (out-of-the-jar) support: e.g. end-linux-user has to manually put the .so library (the specific file for the appropriate bitness) in the right place on his filesystem, and export an env. variable accordingly.
Full disclaimer: I work for a company that makes software-protection dongles (CodeMeter). But I believe we might have a solution that meets your requirement: we have a single API for all platforms (Win, Mac, Linux, etc both 32- and 64-bits). Each end-user machine merely requires a runtime (service on Windows; daemon on Linux). We use a native Java API which uses TCP/IP to call our runtime, so no special device drivers are required. You can do activations either before you ship the dongle (pre-programming), or via file exchange (NikeNet) on deployments with no Internet access, or you can remove the dongle, take it to a machine that DOES have Internet connectivity and update the license there.
At a higher level than the API we have AxProtector, which is an automated protection/encryption tool that you can use to test our protection system with no source code changes. This would let you test the implementation on all platforms you are interested in--you don't need to create multiple versions for different platforms.
We had a Fortune 100 company use this to protect a Java app that ran on non-Intel Solaris, so we know it's been stress-tested as a cross-platform solution.
We have a free fully-functional eval system which we can get you asap. If you email me at the email address in my profile we can ship you out an SDK and help you quickly determine if this will solve your problem.
You can use Dinkey Pro dongles to achieve exactly this. While they do use separate native libraries for each operating system and architecture you just need to call their Java API and it takes care of any platform specific bits. Wrap the libraries up in a JAR file with the .class (the API) and you've got a neat solution. The dongles themselves are driverless.
I can only recommend to avoid the SecuTech UniKey system. During evaluation the product met all requirements we needed. We started integrating this solution and discovered one issue after another.
Here is a short list of the major issues that are part of the SDK 6.2.7:
Enveloper settings change randomly when saving and loading the same solution (Video).
DLL files that are wrapped with the enveloper do not load.
The console version of the enveloper for script based builds does not work. It is unable to wrap exe/dll's that can be wrapped with the GUI based version of the enveloper.
Support is reactive but does not really tackle the problems.
After all we wasted almost a month of work integrating this protection system, but now have to switch due to the massive quality issues.
We are starting some new app development but because of special business requirements, need to support back to Mac OS X 10.3 as well as PPC/Intel CPUs.
The latest Xcode 4 isn't an option, from what I can tell it only goes back to 10.5 and doesn't support PPC at all. Is Xcode 3 an option? Would it be easier to just use Java?
P.S. From anyone experienced in either, can you please comment on some of the pros and cons you've bumped into?
EDIT
As requested, here's a brief overview of the app:
The app needs to talk to a server which will expose JSON web services. The app itself needs to be built in a way that will allow plugins (not 3rd party, but in-house with the ability to customize which features the customer owns). Each plugin will gather specific information about the host OS - such as running apps, users, CPU usage, etc.
If you can find a way to make Objective-C work with your requirements, it is worth it in my opinion.
I myself am a former Java developer who has moved into the creation of native Mac OS and iOS apps. I tried using Java for some of my early Mac OS projects and always found the support to be lacking. It can be done, but it was always more difficult than it should've been and never worked as well as a native app.
Here is a link to another SO post that describes some workarounds for getting older SDK versions working in Xcode 4. I can't vouch for how well they work with current versions of Xcode, but it's worth trying.
In view of your requirements, especially the need to do some system evaluation, I would strongly recommend to use Objective-C and the Apple development environment. You will have a lot of difficulties using Java to retrieve the neccessary information about the host OS, that you want to use in your application.
You could try to run Xcode with older SDK versions, but I have virtually no experience on OSX to give you solid advice on how to do this.
EDIT: My Xcode 4 gives me an option to select a "Deployment Target", where I can go back to supporting 10.1, but I have no idea, if this is the right thing...
Well,
Apple isn't a Java friendly company. You don't have all the bindings you may need on their JVM.
So I strongelly recommend (given that your project will be Mac OS X only) Objective C instead of Java
I program in Java but on Mac OS X, Objective-C is better than Java because it is faster and developed by Apple itself. Moreover, if you develop a program in Objective-C, you can sell it on the Mac App Store while if you develop it with Java you can't.
So go with Objective-C.
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).
I'd like to communicate with a USB device under Windows and Java but I can't find a good library to do so. I don't want the user to have to install any extra hardware or device drivers to make this work. That is, I want to be able to interact with USB just like other Windows applications do.
I am familiar with jUSB and JSR 80 but both seem to be dead projects (at least for Windows).
libusb-win32 requires you to install their generic driver, which then makes a USB device available to you. I'm not sure that it's possible to do driver-less access of an USB device unless the device belongs to one of several standard classes (storage and HID, in particular).
There is a Java wrapper for libusb-win32 which might work for you. I haven't used it myself, though.
I did quite a bit of research on this some time ago, and the unfortunate fact was that all the useful free USB+Windows+Java projects were dead. There is commercial and expensive (price $39.99 is not per developer, but per copy of your software sold!) JCommUSB library which probably works, although I have no experience of it; we had to build our own custom C wrappers to the USB drivers and communicate with them through JNI.
The fastest and easiest way is to hack some native code :)
I wrote a small wrapper for HID devices that enabled my Java applications to read data from CalComp digitizers, so it's definitely doable and not too hard. The bad thing is that my work is still proprietary code owned by my former employer, so for legal reasons I can't release that as open-source -- yet.
The good thing is that you can get a flying start with the HID example code from the Microsoft DDK :)
Communication between Windows and a USB device by java.
http://javausbapi.blogspot.com/2010/05/java-usb-api.html
An example is conducted for a Freescale microcontroller
I was wondering what are the benefits of using anything else but Java for Mobile Application Development.
I do think that yes, Java is the most common language for devices, with two exceptions:
Windows mobile applications, that are frequently built in C++ but that will be built more on the .NET framework in the future.
iPhone applications, that use Cocoa and Objective-C.
Java is the most ubiquitous and for that alone it is your best choice.
You have to use whatever the phone vendor(s) that you intend to support will provide. As most provide Java, but only some provide other things, if you want to support a range of handsets, you probably need to use Java for at least some of them.
Your client (be they internal or external) will need to decide what handsets to support, and you then need to base your decision on supported handsets.
It's not entirely impossible that you'll have to ship versions in different programming languages, which may make code reuse more "challenging". It all depends on your requirements. Nobody on this site can tell you what they are :)
It really depends on what you're trying to do.
Java, whilst ubiqutious does have speed disadvantages. Also it's not "write once, run anywhere" as it is on the desktop space, as different manufactureres, even different devices have different sub-sets of java installed each with differening inclusions of APIs.
Using native code is going to be more efficient, whilst more difficult to port. It provides a more direct representation of the devices capabilities without the sandboxing of a VMs Apis.
Alternatively, you could use a language like C which whilst isn't strictly portable, will have implemenations on many devices with minor tweaks to make, whilst retaining a lot of the speed beenifts of such a language. (OpenC on S60/Symbian), C on Palm etc.
It depends on what you see as the future of the the mobile space. If the iPhone turns out to be as popular as the iPod, then no, Java probably wouldn't be the best choice.
One thing to consider is that at some point there may no longer be such thing as an iPod Nano, perhaps the Touch will be the only iPod available. In that case, every single iPod out would support Apple's iPhone OS and the number of iPhone OS mobile devices would far exceed those of Java.
Five years from now perhaps "Cocoa vs. Android" will be the new Mac vs. PC. In that case, Java could be just as good as Cocoa.
The only reason I can think of is that you wouldn't need a Java runtime on the target device.
Palm, for instance, allows you to code in C and talk directly to the OS routines in ROM. The C code compiles directly to the machine language without needing a runtime.
before one can provide a speculative answer to such a trivial question there are other variables that need be answered. What kind of phone application does one want to develop.
e.g. you can use xhtml for something that does not need to connect to the phones' core features.
and when you need to connect to the phone software or hardware you have can use java,python,c++,windows mobile or the new kid on the block android.
Java is the best if you want to support multiple phones, however J2ME is a limited environment. If you are doing homebrew development then develop for whatever your own phone uses, for commercial development then Java is the most widespread (and there are companies that can port Java to other platforms).
One of the advantages of using native code is your are closer to the hardware, on a mobile phone this means you might be able to take advantage of features which are not exposed to the virtual machine upon which your Java application is running, the promise of Android is that everything is a lot more exposed that it is with a typical Java Mobile implementation
Best is to go to nokia, apple microsoft or google web sites or whaterver and see what developer tools and resources are available and choose the one you want to develop for all of them are very good as good mobile app developers can help increase their market share.
Depends on what Application you are trying to write.
If its a simple service / data provider I would use HTML and CSS via a framework like
jqTouch, jQuery Mobile, or http://www.sencha.com/ as these will run on mostsmart phones and you can package them into a binary app using something like http://www.phonegap.com/ this will allow for sliding, GPS, local file storage using HTML5
If you need to a database, motion sensing, bluetooth, game type application then you could look at
http://monotouch.net/
http://monodroid.net/
That lets you write c# .net code and deploy onto any platform do you should be covered for windows mobile, android and iPhone.
There is also http://rhomobile.com/ that lets you write applications for all mobile platforms using Ruby.