Ewert Technologies Blog

 

PWMinder is a cross-platform Password Management System, that allows users to securely store and manage all of their personal password information.  Currently PWMinder can run on Windows, Linux and Mac (intel), and the password repository files generated are portable from one platform to another.  For example, a password repository file could be created on a Windows computer; the file could then be moved to Mac, opened, edited, and then moved to a different Windows computer to be accessed.

This is great if all you use are desktop computers, but what about password management on your mobile devices, such as a Blackberry or iPhone? Good new! Development is currently underway to create PWMinder for the Blackberry, with plans to follow up with a version for iPhone/iPod.  If there is demand, versions may also be created for Android phones and/or Palm devices.

Once complete, a users could create a password repository at work on a Windows desktop, copy the file to their Blackberry to access passwords on their way home.  They could then copy the file to their Mac at home, add a few more passwords, then copy the file to their iPhone for use on the weekend.  With PWMinder you will be able to have access to all of your passwords, no matter what platform, OS, or handheld device you are on!

Planned features for PWMinder on the Blackberry:

• Password records can be organized into Categories
• Ability to search for password records
• Easy copying of logins and passwords
• Open web links directly from within PWMinder
• Reminders for password expiry can be added to you calendar or todo list
• Includes a Password Generator tool to create secure passwords

If you have any other ideas for what you would like a Password Manager to do for you, on the mobile device, either add comment to this blog, enter a suggestion on the Ewert Technologies support page.

PWMinder on the Blackberry should be available at the end of March, 2010 with development of PWMinder for the iPhone to follow.  Stay tuned for updates.

iPhone Accessories! Get them while they're HOT!

 

 

Note: this article originally appeard in the December 2009 issue of ASPects, The Monthly Newsletter of the Association of Software Professionals.

 

As most Java developers have come to realize, one of the most challenging aspects of developing cross-platform Java applications, is how to deploy them, in the most native way possible, to their various target platforms e.g. Windows, Linux and Mac.  There are several commercial solutions available, but these cost in the range of $500 to $2000, which may be a bit steep for an independent software developer.  In this article, I will provide an overview of how I approached this problem, while developing PWMinder, using a combination of open source tools; and I hope this will provide a framework for those of you facing similar issues.

In my search for a free solution, the first thing I had to accept was, that no single solution would meet all of my needs, and instead, I would need to us a combination of different tools.  This approach requires a lot more work than would be needed using a commercial solution, but this is the price for having something for free.  The following are the tools I used to create the installers.

Apache Ant

Most Java developers should be familiar with Apache Ant.  It is a build tool that comes with many built-in tasks, for things such as moving and deleting files, creating folder structures, archiving files, etc., to build and packages applications.  While it can be used for building any kind of software, it is targeted for Java applications and includes tasks to compile Java code, create jar files, create Javadoc API documentation, etc.   Apache Ant is also extensible, and custom tasks can be created for it.  Many third party tools can be incorporated directly into Ant by using their supplied tasks.  In my process of creating cross-platform installers, ApacheAnt serves the main control center.

Launch4j

Launch4j is a tool that wraps an executable .jar file into a native Windows executable (.exe).  Using Launch4j you can set an icon for your .exe, set Windows file manifests, create a native pre-JRE splash screen, set both environment variables and Java runtime parameters, and more.  Launch4J come with a GUI front end, that is used to set up the configuration parameters.  This configuration is saved as an .xml file that can also be edited by hand.  Launch4j comes with an Ant task, and can, therefore, be easily integrated into an Ant script.  When launching from an Ant script, variables defined in the Ant script, such as build number, etc., can be passed in to Launch4j, providing even more flexibility.  Launch4j basically allows your executable .jar file to act like a Windows .exe.


NSIS

NSIS is a tool used to generate standard Windows based installers.  NSIS is script based and is quite powerful, allowing for a lot of flexibility when creating an installer.  I found that this flexibility comes with some complexity, and found there to be a bit of a learning curve when it comes to using NSIS scripts.  Having said that, there are many examples available, that can help to set up a basic installer quite quickly.  The installer allows for creation of Windows short cuts, creation of an uninstaller, adding and/or updating Windows registry settings.  During the install, It can display panels prompting users for install location, display an license screen and even start he application when the installer has completed.  As mentioned NSIS is script based, and while you can use any text editor, I would recommend either using EclipseNSIS (plugin for Eclipse) or HM NSIS edit, which both include wizards to help get you started.  While NSIS does not come with Ant task, it can be  run from Ant, using Ant's ability to execute commands.


JarBundler Ant Task

JarBundler is an Ant extension that is used to create a Mac .app bundle from an executable .jar file, which can be used to run a Java application on a Mac.  An .app bundle is basically a specialized folder structure containing resources, and configuration information to run an application.  When this folder is copied onto a Mac, it appears as a file that is used to start the application.  JarBundler is configured within an Ant script as an Ant task.  The configuration is quite extensive and allows you to control many properties of the .app bundle including its icon, version, working directory, help book location and more.  Most of these properties are mapped to bundle variables defined in Mac OS X Runtime Configuration Guidelines (http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPRuntimeConfig/Runtime_Configuration.pdf)

IzPack

IzPack is a cross-platform installers that creates an installers as an executable .jar file.  Similar to NSIS, it allow for panels to display license information, select installation folder, etc.  It also includes a utility to create short cuts for both Windows and Unix, and supports creating an uninstaller.  Both the installer and uninstaller are .jar files, however, which may not be what users are expecting when installing software.  IzPack is configured using one or more xml files and can then be executed within Ant using an IzPack task.  While it can create installers for Windows, the installer produced by NSIS looks more native and has more Windows specific features, which is why for Windows I use NSIS.

The Diagram below gives the basic flow I used to create the installers.

The first step is to use Ant, to compile the Java source, generate an executable .jar file (app.jar in the figure above) and collect and organize any other files necessary for the application (e.g. library .jar file, and support files such as user guide, release notes, license files, images, etc.) into a staging area.  Starting from app.jar, the library and support files, the paths for each Operating System diverge.

On Windows, most user would expect to download an executable (.exe) setup file, which when executed, would launch an installation wizard, that would lead them through a set of steps to install the application.  The application itself would be available also as an .exe, and shortcuts would be generated in the Start menu.  To accomplish this, I first used Launch4j, to convert the app.jar file to a Windows .exe file (app.exe).  Next, using Ant, I organized app.exe with any necessary library .jar file and support files into a staging location.  I then used NSIS to to create an installer (setup_win.exe) which, when run creates the short cuts, uninstaller, registry entries, etc.  The user can then download setup_win.exe directly and run it.

Linux users are a little more relaxed about how to install software, but I still wanted something more professional, than to simply unzip the files to a desired location.  For Linux, I kept app.jar as it is, and created a bash script to execute it.   Next, using Ant, I organized app.jar with any necessary library .jar files, the bash script and support files into a staging location. I then used IzPack to create the installer, as setup.jar file.  Rather than have the user download a .jar file, which they may not be as familiar with, I put the setup.jar file into a .tar.gz file. The user would download the setup_lin.tar.gz file and extract setup.jar file.  They would then run the setup.jar, which would install the application and create shortcuts.  The user can then either start the application using the short cuts created or by running the bash scripts.

On Mac, users expect use .app bundles to run their applications.  So for Mac deployment, I used the ant based utility call JarBundler to convert app.jar, to a an .app bundle (app.app).  I then used IzPack to take app.app, the library files, and the support files and create an installer .jar file (setup.jar).  I then used IzPack's own utility to convert this setup.jar to an installer .app (setup_mac.app).  Lastly, to facilitate downloading of the setup_mac.app folder structure, I put it into a .zip file (setup_mac.zip).  The user would download the setup_mac.zip file, extract the setup_mac.app.  They would then run setup_mac.app which would install the application, including app.app.  To run the application the user would then double-click the app.app, just as they would for any other application they have.

While there are a lot of steps involved, what is nice about all of the above tools is that they can be all integrated into Apache Ant, so at the end I can  compile the code, create the executable .jar file, organize the files and then create the installers for Windows, Linux and Mac, all from one Ant script.

Resources

Apache Ant - http://ant.apache.org/
Launch4j - http://launch4j.sourceforge.net/
NSIS - http://nsis.sourceforge.net/
JarBundler Ant Task - http://informagen.com/JarBundler/
IzPack - http://izpack.org/

In Part 1, I talked about how to simplify logging to System.out, by creating a set of convenience methods.  In Part 2, I will discuss logging to Blackberry's Event Log.  The Event Log is a log on the Blackberry device itself and is the place, as the name indicates, where applications can write event logs.  This is the place applications should write error logs that can help in troubleshooting problems in the field where the device is not attached to the debugger.  Users can access the Event Log by going to the Home screen then holding down ALT and typing "LGLG"

Before an application can write to the event log, it needs to register itself using a GUID and an Application Name.  The GUID must be unique for the device, and the Application Name will be used in the log.  I suggest setting up some constants for these:

Code:

To register your application use the following method, typically in the main method of your application:

Code:

EventLogger.VIEWER_STRING indicates that you want to log String messages.  This can be changed later to log other message types.

To log an event, use the logEvent() method of EventLogger as follows:

Code:

EventLogger.ALWAYS_LOG sets the logging level.  The following levels are available:

DEBUG_INFO
INFORMATION
WARNING
ERROR
SEVERE_ERROR
ALWAYS_LOG

By default, only events at WARNING or lower are logged, but the default level can be changed by calling the setMinimumLevel() method.  See the EventLogger API for more details.

To simplify logging to the event log, I have added the following static methods (modelled after log4j) to the Logger class from Part 1:

Code:

So to log an information message, in my code, I use:

Code:

Much simpler!

In the future, I might look into incorporating changing the viewer type, but so far I mainly just use the STRING_VIEWER.

Hope this is helpful, and happy coding!

I have recently started developing a version of PWMinder, for the Blackberry, using the JDE plugin for Eclipse.  When developing applications, especially when starting out, developers often like to send debug/log statements to System.out, to test or check certain values.  My first problem was, when I ran my programs using the simulator, I didn't see any of my System.out messages going to the console.  After searching on the Blackberry Developer forums, I found that in order to see messages on the console, the program needs to be run in debug mode.  That was fine, until I realized that not only my messages were going to the console but a lot of message produced by the simuator; messages like:

VM:+GC(F)w=9
VM:-GCt=3,b=1,r=0,g=1
VM:+CR
VM:TI2Rv=31
VM:-CR=1
VM:IGCSc=0
JVM: bklt @15785: timer
JVM: bklt @15787: idle 23

So the problem became finding my messages among all those others.  One tip I learned was to add some unique constant value in front of all messages like: *** to make them stand out.  While a good idea, this means extra work every time I want to send a log message.  To get around this, I decided to make a couple methods that I could use to log messages to System.out in a standard format.

Firstly, I created a Class called Constants where I store several Global constants and I declared the following:

Code:

Next, I created a class called Logger, which contains several static methods to used for logging messages.

Code:

Now, when I'm coding, whenever I want to send a message to System.out I used the following:

Code:

Which when run would give:

***PWMinder - 2009-12-17 10:30:46.577 America/Los_Angeles: This is my message

In the same way, I could send something to System.err:

Code:

This makes logging to the console easier, and provides consistent output, making it easier to search for my messages among all the other message.  It also allows me to easily make changes to my logging format (e.g. change my date format, etc.) by only changing the code in one place.

Hope this was helpful.

Environment:
Eclipse 3.5
Blackberry JDE plugin 4.2.1

In Part 2, I will discuss logging to the Event Logger, on the Blackberry and/or simulator

While creating the UTM Coordinate Converter applet, I was looking for examples on how to get a Java Applet, to call a Javascript function in the html. I found various bits of information and some examples (that didn't always work), and so decided I would pool the information and try to give a clear tutorial on how to do this. This tutorial assumes Java6 but should work for Java5 as well. I'm not too sure about earlier version of Java.

Step 1: Get plugin.jar

plugin.jar contains the classes needed for an applet to call javascript functions. It is necessary to have plugin.jar in the classpath of your development environment. Plugin.jar can be found in /lib directory of your java installation (example on Windows: C:\Program Files\Java\jre6\lib). It is not necessary to specify plugin.jar in the classpath when putting your applet on your webpage, since the Java plugin will already have plugin.jar (see example in Step 5)

Step 2: import required classes

In the Applet Code add the following import:

Code:

Don't worry about 'netscape' in the package name, it works for IE just fine.

Step 3: create your javascript function for your webpage:

Code:

In this example, the javascript just displays an alert box, but it could do anything you want. This function also accepts parameters, to show how parameters can be passed in. Note: the javascript can either be included directly in the HTML from a separate .js file.

Step 4: Add a call to the javascript in the applet java code

Code:

This Java function creates a JSObject object called window. It then sets up a couple of parameters (as Strings) and puts them into an Object array. It finally calls the javascript function created earlier using the call() method and passes in the name of the javascript function, and the params array.

Step 5: Add applet to html page

Below is the way I add applets to HTML pages, which seems to work across all browsers. The key for the javascript to work is to include the param name="MAYSCRIPT value="true"

Code:

Step 6: Try it out!

In your Java Applet code, when you make a call to callJavaScriptFunction(), it will call the Javascript function, and if everything works correctly, it will display an alert box as follows:

To see a live working example of calling javascript from an applet, you can go to the UTM Coordinate Converter tool. In this tool, when clicking on a Convert button, the applet calls a Javascript function, passing in the coordinate, and the javascript updates the Google Map.

Link to JSObject API documentation: https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/LiveConnect/JSObject#getWindow