[sip-comm-dev] [GSoC09] Java interface for Mac OS X's Growl

Egidijus Jankauskas egidijus.jankauskas at email.lt
Thu Jul 9 17:10:00 CEST 2009


Hi all,

Here is my midterm progress report:

The goal for the first term was to create a Java API for the Mac OS X  
Growl notification daemon. API should allow SIP Communicator to:

1) Display messages with Growl
2) Set a message image through a byte array
3) Receive notifications for clicks on the growl popups
4) Determine exactly which message was a mouse click pertaining to.

I started my GSoC project by creating a dirty JNI test that allowed  
all of the above and added the code to growlnotification bundle in my  
SIP Communicator branch to test it. The next step was to develop a  
generic API that could be used in other Java projects. It turned out  
to be a bit harder that I thought in the beginning, but I have a  
reasonably working generic API. You can check a screenshot attached  
that shows a console app using it.

Most of the problems I had writing the API were because Growl  
framework is intended to be used in properly bundled Mac OS X  
applications and not in some dynamic library which acts as an  
intermediary between an application and Growl daemon. Because of that  
there are some issues/limitations:

1) Growl uses a registration dictionary to register an application  
with it. Documentation says that you must provide three keys in the  
registration dictionary: GROWL_NOTIFICATIONS_ALL,  
GROWL_NOTIFICATIONS_DEFAULT and GROWL_TICKET_VERSION. However, when  
registration happens from dylib, Growl also requires a GROWL_APP_ID to  
be provided. Since GROWL_APP_ID is a bundle identifier of your app, I  
guess that Growl checks this ID itself, but in our case the dylib does  
not have an associated bundle and Growl cannot find one. I provide an  
empty string instead, which works fine, but I don't know what side  
effects this could have.

2) If Growl API is used in a Java application that uses AWT and is run  
in headless mode, it works, but Growl Daemon complains in the console  
with the following message "in copyCurrentProcessURL in  
CFGrowlAdditions: Could not get application location, because  
GetProcessBundleLocation returned -606".

3) The most bizarre thing is that the order of the keys in the  
registration dictionary actually matters. I don't know why, but I had  
situations when my Java test application was not properly registered  
because its name entry in the registration dictionary was one of the  
last. I also had a similar issue with application icon. Now it works  
in all cases I could think of, but I can't be sure that there are no  
situations that would require a different order in registration  
dictionary.

I tried to make sure there are no memory leaks in the library. I used  
Apple Instruments to track object allocations and memory usage. I am  
total newbie in memory management issues, so I might have  
misinterpreted something. :)

Regards,
Egidijus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jitsi.org/pipermail/dev/attachments/20090709/cd93d272/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot.jpg
Type: image/jpeg
Size: 28717 bytes
Desc: not available
URL: <http://lists.jitsi.org/pipermail/dev/attachments/20090709/cd93d272/attachment.jpg>


More information about the dev mailing list