jSyncManager Labs Prototypes Cocoa jSyncManager.
In just a few hours, the jSyncManager goes
from Swing to Cocoa inside the jSyncManager Labs.
Welcome to the first of hopefully many articles
on what I like to call the jSyncManager
Labs. While we don't really have any lab
facilities (yet), the jSyncManager Labs is more of a state-of-mind, and is where
I undertake various experimental jSyncManager-related projects, which aren't
ready for prime-time. Some jSyncManager Labs projects get folded into the core
Open Source jSyncManager (for example, the
Deleter
jConduit), some get treated as mini
sub-projects (such as the CDK-J
Bridge classes), while others go nowhere (like
my attempt to create a native OS/2 USB
Transport).
This weekend, I spent several hours on my lovely 12" PowerBook trying to see if I could put a Cocoa (the major object-oriented API used in Mac OS X) user interface atop the pure Java jSyncManager API. Apple provides a system known as Cocoa/Java which allows you to create native OS X GUI widgets, and then access them from Java.
Now if you haven't worked in Cocoa before, it may seem a bit odd at first. The Interface Builder application allows you to draw your GUI components on screen, and connect them together with other classes through a serious of "outlets" and "targets" (or sometimes "actions"). Anyone who has worked with an interface construction tool before knows how this works, but where Interface Builder differs is that instead of creating a pile of source code that closely approximates what you designed that requires building and execution at runtime, in IB you're working with live instances of your objects. When you save them, IB doesn't generate code, but instead serializes these live objects into a file which is automatically deserialized at runtime. No code is generated, and nothing needs to be compiled. I've become so enamoured with this system, I think that Sun should adopt it for Swing now that Java 1.5 has standardized Swing serialization. But that's a topic for a different discussion.
Saturday evening I sat down and started to play with Cocoa/Java, and after a few oddities (eg: if you're using Cocoa/Java, and some class initiates even one Swing class, even if it isn't drawn on screen, you'll cause all sorts of oddities (I'm guessing due to the event thread interaction between the two subsystems)), I was actually able to create a working synchronization application from the jSyncManager API, using all native Mac GUI widgets.
Part of this experiment was to see how hard it is to create custom sync applications with the jSyncManager API (the answer is: it's dead simple). Part of it was so I could become more familiar with Cocoa components (I've also been teaching myself Objective-C). And part of it was to create an experimental platform for coming up with next-generation GUI concepts for the jSyncManager.
The result? See for yourself:
The Main Window
Yup -- that's it. No more frame with just a "traffic" graphic. This main window combines elements of the synchronizing window, making it unnecessary. Other than the frame controls (top left) and the window title, the frame has only four elements: the image view, a status overview, a barber-pole (which animates during sync), and a hidden status label for more specific status information. You can see these in effect better in the next screen shot.
Connecting:
Here a connection is being made. The barber-pole starts rotating, and the status details comes out of hiding. The major status label is likewise updated. (Note that in this shot the barber-pole appears grey because it wasn't the active window when I made the screen capture).
Synchronizing:
Once the connection has been made, the synchronizing phase occurs. The function of this depends on what is selected by the user prior to synchronization.
Completion:
The synchronization completed successfully.
Log Panel:
Just as in the Swing version of the jSyncManager, Cocoa jSyncManager has a pop-up log you can request at any time:
What Works:
Cocoa jSyncManager supports the same Standard Sync, Backup Sync, and Restore Sync mechanisms used in the pure Java jSyncManager. It also supports an imbedded version of the Installer jConduit for installing PRC, PDB, and PQA files, and the Default jConduit (which is used for backing up and restoring databases which don't otherwise have their own jConduits).
What Doesn't Work:
Some major areas of functionality currently don't work. Most important of these is the ability to plug-in jConduits. Indeed, jConduits have presented one of the biggest problems in implementing this project. Recall that I mentioned above that Cocoa/Java and Swing don't mix well at all -- and all the existing core jConduits provide their configuration GUIs as Swing elements. This has meant that I've had to rewrite the two jConduits currently in use (Installer and Default), and have had to give them completely new GUIs and mechanisms for loading and accessing them. Both are currently hard coded into the system (although the DefaultConduit always has been in the pure Java jSyncManager as well). It's quite possible that any publicly-released version won't even have the ability to load pluggable jConduits (at least not in version 1.0) -- any such jConduits would have to deviate from the jSyncManager specification, making jConduits written for one system incompatible with those written for the other. Fragmentation like this will be bad for the jSyncManager as a whole, so the best way to avoid it may be to provide very specific hard-coded features in the Cocoa jSyncManager.
There is also currently no preferences, other than the ability to change the sync type from the menus. It is also currently impossible to work with logs -- they can't be copied, saved, printed, or cleared. These features are the next to be implemented on my list.
Finally, currently only TCP/IP-based sync is supported. This will be rectified once the javax.usb API is ported to OS X (another project of mine).
What's Still to Come:
Two major features are still yet to be implemented:
- PalmOS Photos application to iPhoto support. The existing FotoReader jConduit should be easy to modify for this task, once I figure out how to interact with iPhoto.
- Create a new jConduit to integrate with the new iSync application in Mac OS X 10.4 (Tiger). iSync provides sync services of address, to do, and calendaring data with .Mac, iPods, handhelds, and selected mobile phones. It doesn't have its own built-in system for connecting to PalmOS handhelds, however -- it relies on an external synchronization system for the actual data exchange. It does, however, determine what data needs to be updated where, and is capable of some serious multi-way synchronization tasks.
- Create a way to synchronize the PalmOS Memo Pad application with a set of Stickies (a Mac application that creates on screen coloured sticky notes).
Conclusion:
Cocoa jSyncManager isn't going to be taking over from the core Open Source jSyncManager anytime soon. It's still my own little closed-source experimental technology which isn't going to be made available outside the doors of the (fictional) jSyncManager Labs anytime soon. It may, however, eventually influence some of the GUI directions we take with the Swing GUI atop the jSyncManager engine (I'm hoping to do a GUI redesign for the jSyncManager v4.0 release sometime in late 2005/early 2006). There is the possibility that the Cocoa jSyncManager may be released as Shareware to help fund some of the continuing jSyncManager Development fixed costs, but it isn't intended as a replacement. The jSyncManager itself is Open Source, runs everywhere, and has a ton of built-in flexibility, allowing you to easily write and deploy your own jConduit plug-ins. Cocoa jSyncManager, on the other hand, has a closed-source interface atop the Open Source (LGPL) jSyncManager API, runs only on Mac OS X 10.3 and above, and has no flexibility to accept external jConduit plug-ins. What Cocoa jSyncManager is currently is an experiment -- and it will remain in the jSyncManager Labs until such time it can stand on its own.
This weekend, I spent several hours on my lovely 12" PowerBook trying to see if I could put a Cocoa (the major object-oriented API used in Mac OS X) user interface atop the pure Java jSyncManager API. Apple provides a system known as Cocoa/Java which allows you to create native OS X GUI widgets, and then access them from Java.
Now if you haven't worked in Cocoa before, it may seem a bit odd at first. The Interface Builder application allows you to draw your GUI components on screen, and connect them together with other classes through a serious of "outlets" and "targets" (or sometimes "actions"). Anyone who has worked with an interface construction tool before knows how this works, but where Interface Builder differs is that instead of creating a pile of source code that closely approximates what you designed that requires building and execution at runtime, in IB you're working with live instances of your objects. When you save them, IB doesn't generate code, but instead serializes these live objects into a file which is automatically deserialized at runtime. No code is generated, and nothing needs to be compiled. I've become so enamoured with this system, I think that Sun should adopt it for Swing now that Java 1.5 has standardized Swing serialization. But that's a topic for a different discussion.
Saturday evening I sat down and started to play with Cocoa/Java, and after a few oddities (eg: if you're using Cocoa/Java, and some class initiates even one Swing class, even if it isn't drawn on screen, you'll cause all sorts of oddities (I'm guessing due to the event thread interaction between the two subsystems)), I was actually able to create a working synchronization application from the jSyncManager API, using all native Mac GUI widgets.
Part of this experiment was to see how hard it is to create custom sync applications with the jSyncManager API (the answer is: it's dead simple). Part of it was so I could become more familiar with Cocoa components (I've also been teaching myself Objective-C). And part of it was to create an experimental platform for coming up with next-generation GUI concepts for the jSyncManager.
The result? See for yourself:
The Main Window
Yup -- that's it. No more frame with just a "traffic" graphic. This main window combines elements of the synchronizing window, making it unnecessary. Other than the frame controls (top left) and the window title, the frame has only four elements: the image view, a status overview, a barber-pole (which animates during sync), and a hidden status label for more specific status information. You can see these in effect better in the next screen shot.
Connecting:
Here a connection is being made. The barber-pole starts rotating, and the status details comes out of hiding. The major status label is likewise updated. (Note that in this shot the barber-pole appears grey because it wasn't the active window when I made the screen capture).
Synchronizing:
Once the connection has been made, the synchronizing phase occurs. The function of this depends on what is selected by the user prior to synchronization.
Completion:
The synchronization completed successfully.
Log Panel:
Just as in the Swing version of the jSyncManager, Cocoa jSyncManager has a pop-up log you can request at any time:
What Works:
Cocoa jSyncManager supports the same Standard Sync, Backup Sync, and Restore Sync mechanisms used in the pure Java jSyncManager. It also supports an imbedded version of the Installer jConduit for installing PRC, PDB, and PQA files, and the Default jConduit (which is used for backing up and restoring databases which don't otherwise have their own jConduits).
What Doesn't Work:
Some major areas of functionality currently don't work. Most important of these is the ability to plug-in jConduits. Indeed, jConduits have presented one of the biggest problems in implementing this project. Recall that I mentioned above that Cocoa/Java and Swing don't mix well at all -- and all the existing core jConduits provide their configuration GUIs as Swing elements. This has meant that I've had to rewrite the two jConduits currently in use (Installer and Default), and have had to give them completely new GUIs and mechanisms for loading and accessing them. Both are currently hard coded into the system (although the DefaultConduit always has been in the pure Java jSyncManager as well). It's quite possible that any publicly-released version won't even have the ability to load pluggable jConduits (at least not in version 1.0) -- any such jConduits would have to deviate from the jSyncManager specification, making jConduits written for one system incompatible with those written for the other. Fragmentation like this will be bad for the jSyncManager as a whole, so the best way to avoid it may be to provide very specific hard-coded features in the Cocoa jSyncManager.
There is also currently no preferences, other than the ability to change the sync type from the menus. It is also currently impossible to work with logs -- they can't be copied, saved, printed, or cleared. These features are the next to be implemented on my list.
Finally, currently only TCP/IP-based sync is supported. This will be rectified once the javax.usb API is ported to OS X (another project of mine).
What's Still to Come:
Two major features are still yet to be implemented:
- PalmOS Photos application to iPhoto support. The existing FotoReader jConduit should be easy to modify for this task, once I figure out how to interact with iPhoto.
- Create a new jConduit to integrate with the new iSync application in Mac OS X 10.4 (Tiger). iSync provides sync services of address, to do, and calendaring data with .Mac, iPods, handhelds, and selected mobile phones. It doesn't have its own built-in system for connecting to PalmOS handhelds, however -- it relies on an external synchronization system for the actual data exchange. It does, however, determine what data needs to be updated where, and is capable of some serious multi-way synchronization tasks.
- Create a way to synchronize the PalmOS Memo Pad application with a set of Stickies (a Mac application that creates on screen coloured sticky notes).
Conclusion:
Cocoa jSyncManager isn't going to be taking over from the core Open Source jSyncManager anytime soon. It's still my own little closed-source experimental technology which isn't going to be made available outside the doors of the (fictional) jSyncManager Labs anytime soon. It may, however, eventually influence some of the GUI directions we take with the Swing GUI atop the jSyncManager engine (I'm hoping to do a GUI redesign for the jSyncManager v4.0 release sometime in late 2005/early 2006). There is the possibility that the Cocoa jSyncManager may be released as Shareware to help fund some of the continuing jSyncManager Development fixed costs, but it isn't intended as a replacement. The jSyncManager itself is Open Source, runs everywhere, and has a ton of built-in flexibility, allowing you to easily write and deploy your own jConduit plug-ins. Cocoa jSyncManager, on the other hand, has a closed-source interface atop the Open Source (LGPL) jSyncManager API, runs only on Mac OS X 10.3 and above, and has no flexibility to accept external jConduit plug-ins. What Cocoa jSyncManager is currently is an experiment -- and it will remain in the jSyncManager Labs until such time it can stand on its own.
Posted: Monday - April 18, 2005 at 12:49 AM
Quick Links
Statistics
Total entries in this blog:
Total entries in this category:
Published On: Aug 30, 2007 08:14 PM
Total entries in this category:
Published On: Aug 30, 2007 08:14 PM