Dan Calinescu

Ahead of the game now, but I expect widespread solutions to emerge within the next year or two.Why? Well for once, the mobile device is the most ubiquitous medium out there. Secondly, it lives right in the user’s pocket, next to the keys and wallet. Of course spam could be a problem but as with regular online marketing, smart solutions have emerged and have been popularly accepted and used. I expect to see the same for wireless. One solution would be to sell advertising space within an application or a game. It’s being done on the console, there’s no reason why it wouldn’t work on the mobile device.

Of course there are those who are beginning to try it out, but until widespread data connectivity hits, there’s not much future in this. But, as consumers start surfing the wireless web more often and start downloading content more and more often, these mobile marketing pioneers will be poised for action.

Big opportunities for mobile marketing up ahead…

The Problem

Mobile operators are the rulers of the wireless world. They control the last-mile, the link to the end-consumers, through their private mobile portals. Due this massive control, they have the final say as to what sells and what does not. Users have a wide variety of content available in the mobile catalogue but browsing the products is difficult, and the true value of the product is not truly visible. Especially for games, a game title, a small text description and an optional screen shot is all the user gets. It is no wonder that it is the branded content that wins the user’s attention, and thus large publishers focus on large brands, spending large amount of money for development. The small developers are left out the operator decks, since they cannot afford big brands. In many cases, the end users are disadvantaged since unbranded content does not necessarily imply lower quality.

A Potential Solution

A disruptive, end-to-end mobile distribution model, giving small developers a fair playing field, while empowering end users with more control over the process of browsing and purchasing content, such as ring-tones, wall-papers, games and applications. This model would compete directly with mobile operators.

How it would work

1. The user joins the community by creating a profile on the community web site.
2. The user enters information such as email address and device information (i.e. phone #)
3. The user receives a WAP push message on the device, to download the mobile client.
4. The user may buy credits on the web-site, for later use in buying mobile content.
5. The user starts up the mobile client and logs into the community network.
6. The user browses for content, which is downloaded on demand by the mobile client.
7. The client makes requests and receives content responses from an HTTP server.
8. The mobile client displays text and images and plays sounds and animations.
9. The mobile client may also download short demo packs.
10. When the user decides to buy a product, the client checks if the user has enough credits.
11. If enough credits are available, a one-click button completes the transaction.
12. The client sends a request to the HTTP server signaling the transaction.
13. The server sends a WAP push SMS message to the user device.
14. The client displays a message telling the user to wait for an SMS message, then exits.
15. The user receives a WAP push SMS and clicks the URL.
16. The device opens a web browser and starts a download.
17. The user may follow the on-screen instructions to complete installation.

What happens if the Carrier blocks access to and from our servers?

Glad you asked. Let’s put it these way. They can block one, two, three, dozens of servers but not thousands. And where would we get thousands of servers? This is where P2P would come in. In a community-driven effort, P2P can always offer us a list of carrier “white-listed” addresses to and from our mobile clients.

If only the carriers would smarten up… Oh well, it’s up to the community - once again - to solve this problem.

In Eclipse plug-in development you may need a java.io.File reference to a file which resides in your plug-in distribution location.

For example, to get access to the following file

com.mycompany.myproduct/files/sample_data.xml

you might do the following:

File file = new File(FileLocator.toFileURL( FileLocator.find(MyPlugin.getDefault().getBundle(), new Path("/files/sample_data.xml"), null)).getFile() );

where MyPlugin is your plug-in activator

Modifying the Java class path at runtime is conventionally impossible. In practice though, such a mechanism is often badly needed when a library needs to be loaded dynamically at runtime.

There is actually a way of achieving this, with a little bit of Java class loading and reflection knowledge.

The bit of information we need to know is the fact the the Java system class loader is actually a URLClassLoader:

URLClassLoader sysloader = (URLClassLoader) ClassLoader.getSystemClassLoader()

Now that we have the system class loader, here’s where reflection comes in:

Method method = URLClassLoader.class.getDeclaredMethod("addURL",parameters);

This will give us the addUrl method which is responsible for adding URLs to the list of URLs to search for classes.

Using reflection, we can add a new URL to the list of URLs as follows:

method.setAccessible(true);
method.invoke(sysloader,new Object[]{ url });


where url is a java.net.URL.

For more information on this, refer to this post.

Eclipse class loading is not quite intuitive for the beginner Eclipse developer. If you’re a plug-in developer and if your application is comprised of two or more plug-ins you’ve likely encountered class loading issues. For example, if plug-in A contains a library say a.jar and plug-in B depends on plug-in A and needs to use a class found in a.jar, then that’s a likely situation to run into a plug-in class loading problem.

A simple way of fixing such an issue would be to pair the two plug-ins as “buddies”. Eclipse has uses a concept called Buddy Class Loading whereby a plug-in is allowed to load classes from its buddies. In our example above, plug-in A would require the following entry in its manifest file:

Eclipse-BuddyPolicy: registered

which essentially means that any plug-in that will register with plug-in A as a buddy, will be allowed to load classes from plug-in A. In our scenario then plug-in B would register with plug-in A with the following manifest entry:

Eclipse-RegisterBuddy: A

For more details on Eclipse class loading, here’s an article I like.