Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Push Your MIDlets to Do a Lot More with MIDP 2.0 PushRegistry : Page 3

Learn how to push your MIDlets up to first-class status on a range of mobile devices using the PushRegistry.


advertisement
Registration Is Simple, but Not so Simple
So far I've covered how a MIDlet can be associated with an inbound connection. The steps are rather straightforward, but there are a number of reasons why push registration can fail. When a connection is registered with a MIDlet suite it is reserved exclusively for that one suite. No other MIDlet suites will be allowed to register the same connection or open the connection using Connector.open() at runtime. An IOException is thrown at runtime if a PushRegistry conflict is detected.

The device must also support the type of connection you are registering and you must have proper security to use the connection. In these cases a ConnectionNotFoundException or SecurityException is thrown at runtime if the connection is not available or the MIDlet suite does not have proper permission to use the connection. Furthermore, static connections are registered with the PushRegistry at install time. If any of these problems are encountered during installation, the installation can fail.

There are pros and cons to registering a push connection either statically or dynamically. A static registration allows a push connection to be registered upon installation and does not require the user to run the application in order to complete the registration. However, if a conflict occurs, the application cannot be installed until the conflicting application is removed from the device. Furthermore, if an application does not have proper permission to use the PushRegistry or the connections specified, the installation can fail as well.



Dynamic registration, on the other hand, has the advantage of installing without failure. However, the user must run the application at least once to invoke the dynamic registration. Because dynamic registration is done at runtime there is more flexibility in how connections are registered. For example an application can scan for an available connection to better ensure push registration success. The following code shows how this might be accomplished, by attempting up to four different connection strings:

String base = "55"; String name = "PushMIDlet"; for(int ccnt=5; ccnt < 9; ccnt++) { try { String temp = base + Integer.toString(ccnt); PushRegistry.registerConnection( "datagram://:"+temp, name, "*"); break; } catch (IOException x) { continue; }

This code shows how dynamic registration can be an advantage if there is a potential for push registration conflicts. Dynamic registration also provides a way to ensure the suite installs without push registration conflicts. So, if your application can make use of push, but does not absolutely require push to be useful, you should consider registering the connection dynamically. If there is a conflict or some other registration problem, the application can still be installed and must adapt to the lack of push in certain cases. However, if your application depends on a specific push connection to be useful, registering the connection statically is a good way to go since the user is informed about problems at installation time.

The following table describes the most common ways that push registration can fail. If the condition is encountered for a statically registered connection, the installation is aborted. For dynamic registrations the response can vary and is listed in the corresponding column.

Condition

Dynamic Registration Response

Connection string syntax is not valid

An IllegalArgumentException is thrown

The device does not support the specified connection type (e.g. socket) or has not made the connection type available to push

A ConnectionNotFoundException is thrown

The connection is already registered by another MIDlet suite or there are insufficient resources to handle the registration request

An IOException is thrown

The MIDlet name specified in the push connection string is not declared in the application descriptor of the MIDlet suite

A ClassNotFoundException is thrown

The MIDlet suite does not have permission to register or use the specified connection

A SecurityException is thrown

The port specified by the connection string is reserved by the device

Undefined by the MIDP specification, but an IOException is most likely.

When connections are reserved in the PushRegistry, they are reserved for a MIDlet suite, not a single MIDlet. If a MIDlet suite defines several MIDlets, all MIDlets in the suite have access to the connections in the PushRegistry. However, the MIDlet specified in the PushRegistry with the connection is the MIDlet that is started by the AMS in response to an incoming connection notification. Once a MIDlet suite is running, the suite has complete control as to how the PushRegistry connections are used.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date