StringUtils.hash(), Serialization, Float/Double: really needed?

Smack Smack Dev
1

While porting the smack library to J2ME (CLDC+MIDP2) I ran into 3 problems to which I can’'t immediately see a solution.

The first problem is the StringUtils.hash() method. MIDP2 doesn’'t support MessageDigest. How important is hashing a string for Smack? Is it possible to skip it? If not, is there another (MIDP2 compatible) way of hashing a string?

The other problem regards Object Serialization, another thing MIDP2 doesn’'t support. Is it really needed?

The third problem is the use of Float/Double. These are not available in MIDP2. Why are they used, and can we do without it?

It might be that I have to leave out some core functionality, but it wouldn’'t be really problematic to end up with a ‘‘smack light’’ version, as long as there is a basic MIDP2 jabber client based on Smack in the end.

Any help would be really appreciated.

Cheers,

Berco

2

On second thought I realized that I might skip the possibility of adding ‘‘properties’’ (which are serializable objects or native types). Adding binary properties don’'t make much sense in a MIDP2 world I guess. I might be wrong of course.

Anyway, would it be possible to cut away that functionality? Or can I expect a major overhaul if I do that?

3

Berco,

You can follow this link for previous experiences with Smack under J2ME. http://www.jivesoftware.com/jive/thread.jspa?forumID=39&threadID=8160

Below you can find two links that will show you how to implement or use hashing in J2ME/MIDP. With this info you will be able to modify the method StringUtils.hash().

Links

Securing your J2ME/MIDP apps

http://www-106.ibm.com/developerworks/library/j-midpds.html

J2ME and cryptography

http://www-106.ibm.com/developerworks/library/wi-tip14.html

As you realized in your second post you can cut off the avility to transmit objects to avoid the serialization problem.

It seems that many people are trying to use Smack under CLDC/MIDP and they all had some problems. It would be great to have a definitive list of what needs to be changed so we can add it to the Knowledge Base.

Regards,

– Gato

4

Hi Gato,

Thanks for the EXCELLENT links for porting StringUtils.hash() to CLDC1.0/MIDP2.0. I’'ll check them out and will try to use it.

I’‘ve skipped the whole properties idea since that requires serialization of objects, which won’'t happen until CLDC1.1. Skipping properties also took care of the problems with Float and Double. They were only part of the properties mechanism, not for the core Jabber functionality.

I know that there have been more that tried to port the API to CLDC/MIDP, but I haven’‘t had a reply from anyone that really succeeded. When it all works I’'ll post a definite list of the things that need to be changed.

Anyway, I’‘m well on my way I think. One of the last things I’'m struggling with is:

MessageEventManager.fireMessageEventRequestListeners()

and

MessageEventManager.fireMessageEventNotificationListeners()

Both methods make use of Class.getDeclaredMethod(), another function that isn’'t available in CLDC/MIDP. It appears that the methods to be called on the listeners are determined dynamically. Any tips how to do that without mentioned methods would be very welcome!

Regards,

Berco

5

Berco,

I know that there have been more that tried to port

the API to CLDC/MIDP, but I haven’'t had a reply from

anyone that really succeeded. When it all works I’'ll

post a definite list of the things that need to be

changed.

Great! I would like to document the list so we can easily share it with the community.

Anyway, I’'m well on my way I think. One of the last

things I’'m struggling with is:

MessageEventManager.fireMessageEventRequestListeners()

and

MessageEventManager.fireMessageEventNotificationListeners()

Both methods make use of Class.getDeclaredMethod(),

another function that isn’'t available in CLDC/MIDP.

It appears that the methods to be called on the

listeners are determined dynamically. Any tips how to

do that without mentioned methods would be very

welcome!

Below you can find a possible modification that could work for your case. You can apply the same idea to the method #fireMessageEventRequestListeners.

private void fireMessageEventNotificationListeners(
        String from,
        String packetID,
        String methodName) {
        MessageEventNotificationListener[] listeners = null;
        synchronized (messageEventNotificationListeners) {
            listeners =
                new MessageEventNotificationListener[messageEventNotificationListeners.size()];
            messageEventNotificationListeners.toArray(listeners);
        }
        for (int i = 0; i < listeners.length; i++) {
            if ("deliveredNotification".equals(methodName)) {
                ((MessageEventNotificationListener)listeners+).deliveredNotification(from, packetID);
            }
            else if ("displayedNotification".equals(methodName)) {
                ((MessageEventNotificationListener)listeners+).displayedNotification(from, packetID);
            }
            else if ("composingNotification".equals(methodName)) {
                ((MessageEventNotificationListener)listeners+).composingNotification(from, packetID);
            }
            else if ("offlineNotification".equals(methodName)) {
                ((MessageEventNotificationListener)listeners+).offlineNotification(from, packetID);
            }
            else if ("cancelledNotification".equals(methodName)) {
                ((MessageEventNotificationListener)listeners+).cancelledNotification(from, packetID);
            }
        }
    }

Let me know if you need anything else.

Regards,

– Gato

6

Gato,

Thanks for the fast and accurate response! I appreciate that.

Your solution works, except that:

((MessageEventNotificationListener)listeners).deliveredNotification(from, packetID);

should be:

((MessageEventNotificationListener)listeners+).deliveredNotification(from, packetID);

but that’‘s just a detail. I didn’'t know the names for the methods, thanks for that.

The whole package now compiles against CLDC1.0/MIDP2 so now is the time to test the API with an application. I’'ll post to this list whenever I got that working. Thanks for now!

7

Aahhhhh! Actually your code was correct, but this forum interprets an ‘‘i’’ between square brackets the same as HTML’‘s ! So that’'s why our text suddenly skips to italic.

This just for later reference. In case sombody wants to use the code he/she should add an ‘‘i’’ between square brackets right where the star is in the next line of code

((MessageEventNotificationListener)listeners*).deliveredNotification(from, packetID);