MIDP Application Signing

Part 2 of 2

For details on the background of this project, and details about the overall Java Verified process, see part 1 of this article. This post will exclusively deal with signing MIDP applications, irrespective of whether you’ll also be going through the Java Verified process.

Why sign your MIDP application?

• Some devices might restrict certain functionality to those applications with valid signatures.
• Some security policies reject the installation of any unsigned application.
• Other devices will warn users about an application being “untrusted” if it’s not signed.
• Security pop-ups on phones can get really annoying, and these can be lessened with signed applications.
• Ensures that no one but you can distribute his or her applications or updates to your application under your name.

In short, you want your application signed.

[Read more]

Java Verified: What it is, and how you do it

Part 1 of 2

I’m putting the finishing touches on a little side project (to be announced in a few days) I’ve been working on for the past couple of weeks. The purpose of this project is to exercise the new J2ME Polish 1.3 beta release and get an application listed on mobile.java.com at the same time. To keep things simple, I decided to port a bluepulse widget (Amazon-OnTheGo) for this purpose.

I also promised to post my experiences with the listing process here. And apparently, at least one of you (one of the scant few readers of this blog) is looking forward to the outcome of this project.

The biggest hurdle is really the signing process, and while this is not overly difficult to do, there are such a large number of considerations, that application signing appears more difficult than it is. Of course, signing is one of the prerequisites of getting Java Verified, so I thought I’d break down my experience / research into two posts: one covering Java Verified and one covering signing MIDP applications (Part 2).

Java Verified Process

What is Java Verified?

It essentially boils down to a testing process that results in a widely accepted digital signature. The intent behind this initiative is to eliminate as much redundant J2ME application testing as possible, relying instead on unified testing done for Java Verification. The certification process ensures that applications being distributed via carriers, vendors, and other channels are of a consistent quality.

[Read more]

J2ME Polish 1.3: FramedForm

What could be an incredibly useful feature is marred by bugs in the beta release of Polish 1.3. The concept behind the FramedForm class is similar to the Border Layout in Java Swing. You can append items to the FramedForm body, and designate other items to be anchored at the frame top, bottom, left, or right.

For example, you can display an anchored query as search results are scrolled. Or you can display an anchored search box while the rest of the screen content is scrolled. Maybe even use a ChoiceGroup to dynamically filter or change the content on the screen.

Using the FramedForm is as easy as building any MIDP form.

FramedForm myForm = new FramedForm(”Search Results”);
StringItem item = new StringItem(”You’d Prefer an Astronaut”, null);
/* more items */
TextField search = new TextField(”", “”, 25, TextField.ANY);
myForm.append(item);
/* repeat */
myForm.append(Graphics.TOP, search);

But the results are less than spectacular on the beta release. Anchoring anything on the bottom frame doesn’t work. Anchoring on the top frame suffers from frame boundaries not being respected, and styles not being properly applied.

Even with these current bugs, I imagine there’s still some utility to be had by using this class, if for nothing else than layout help. For example, you could add an image or icon to the left or right frame of a screen, and use Polish styles to sufficiently pad that edge of the screen, perhaps to be used in an image viewing application or to create a graphical navigation menu of some sort.

I love the concept behind the framed form, so I’m hopeful that future releases of J2ME Polish will address some of these issues. In the meantime, I’ll continue looking for workarounds and ways to use the current functionality.

My overall experience using Polish in this test project has been similar to using this framed form. On paper, it sounds like a major boon to productivity and compatibility, and on the whole, I can’t imagine starting a product without Polish as the build tool, because it largely comes through on its promises. But I have been mildly disappointed with execution. I find myself wishing for fewer features, but features that work smoothly; versus a wealth of features, and finding annoyances in some of them.

J2ME Polish 1.3: ScreenInfo class

IMPORTANT UPDATE Nov. 23, 2006: The below approach will almost surely fail on your implementations. After this post was written, I learned that the package I was experimenting in had been significantly altered by a colleague to make ScreenInfo work as intended. I don’t recall the specifics of the approach, but will post them if I can find them. If anyone has had any success with an undecorated ScreenInfo, please share.

---

I’ve been working with the J2ME Polish 1.3 beta over the past week and a half. I had several goals when I began this mini-project, one of the primary goals being to exercise some of the new features in the 1.3 release.In several areas in my sample application, I’ve spawned background threads to do some processing, and I wanted to provide the user with some visual feedback of the processing status. I also wanted to avoid the traditional gauge-based approach, so as to keep these events relegated to the background. GUI programming using MIDP is painful, but J2ME Polish makes a task like this very short work with the new ScreenInfo class.

A word of warning: depending on which beta release I use, and in which screen I use this class, I have varying degrees of success, and I’m at a loss to explain why I can get it to work in some areas, but not in others. Based on what I see on the discussion boards, there are a good number of other problem areas in the beta release, which is to be expected. I wouldn’t let it discourage you from trying out this product.

To use ScreenInfo, first add the corresponding variable declaration to your build.xml file:

<variable name=”polish.ScreenInfo.enable” value=”true” />

Setting this preprocessing variable enables this element for your entire application, but you can use various static methods of the ScreenInfo class to set its visibility and change its appearance (image and/or text). For example, I might choose to display an idle indicator, which changes to an hourglass during background operations; or I may choose to display a connection icon when I’ve established a connection to an external resource, and hide it when the connection is released.

Remember to import the ScreenInfo class:

import de.enough.polish.ui.ScreenInfo;

Image image = null;
try {
image = Image.createImage(”/clock.png”);
} catch (IOException ex) {
//#debug
System.out.println(ex);
}
ScreenInfo.setImage(image);
//w is defined as the screen width in my class
ScreenInfo.setPosition(w-10, 10);
ScreenInfo.setVisible(true);

You can also style this element in polish.css by using the “screeninfo” predefined style:

screeninfo {
font-style: plain;
font-size: small;
font-color: primaryDarkColor;
}

From painful to painfully simple in just a few short steps.

Tags: J2ME, Java ME, J2ME Polish, mobile software, mobile development

J2ME Polish 1.3: InitializerSplashScreen

J2ME Polish contains a neat splash screen convenience feature in version 1.3, currently in beta. Implementing the ApplicationInitializer interface, and calling the InitializerSplashScreen with the appropriate arguments is all you need to do to create your splash screen.

Polish then creates a background thread, calls your initialization code in that thread, and creates and displays your splash screen. You can specify a canvas background color, a splash screen image, message text, and message color. If you choose to include message text, when your initialization code returns, the message is displayed to the user, and a new displayable is served after a click, similar to the popular interaction mode in many mobile games. A null message text will indicate to Polish that the next displayable should immediately be shown to the user.

Import the Polish splash package:

import de.enough.polish.ui.splash.*;

Use preprocessing to determine if ApplicationInitializer is defined in build.xml. You do not want to define the preprocessing variable in build.xml and implement the interface.

public class AmazonController extends MIDlet
//#if !polish.classes.ApplicationInitializer:defined
implements ApplicationInitializer, CommandListener {
//#else
implements CommandListener {
//#endif

You will place all of your initialization code in the initApp() method, rather than in the constructor or in startApp(). Your initApp() method must return a Displayable (the screen to be displayed when the thread completes its business).

public Displayable initApp() {
mainMenu = new MainMenu(this);
/** @todo add your initialization code */
return mainMenu;
}

In startApp(), call InitializerSplashScreen with the appropriate arguments: Displayable screenToShowOnLoad, Image splashImage, int backgroundColor, String messageToDisplayAfterLoad, ApplicationInitializer midletImplementingInitializerInterface).

try {
Image splashImage = Image.createImage(”/splash.png”);
InitializerSplashScreen splashScreen = new InitializerSplashScreen(display, splashImage, 0xFFFFFF, null, 0×359AA8, this);
display.setCurrent(splashScreen);
} catch (IOException e) {
//#debug error
System.out.println(”Unable to load splash image.” + e);
}

Pretty slick. Nothing earth shattering, but just another way that J2ME Polish can save you some time developing mobile applications. The best part is that, like most Polish classes, the splash screen will function on a large number of MIDP implementations without requiring any tuning on your part.

Tags: J2ME, Java ME, J2ME Polish, mobile software, mobile development

Project: Publish a Polish-built App on mobile.java.com

It’s time for a little side project.

Rationale behind the project

1) J2ME Polish is currently released at version 1.2.4, but version 1.3 is in beta, and it offers several new features that I’d like to exercise, namely: Palm and Blackberry support, a framed form custom item, Spritetems, a splash screen helper, and several other productivity features. What better way to exercise these than in the wild?

2) mobile.java.com has launched, and I’ve got a bee in my bonnet about getting something (anything) out there, just to see what the process is like to get something listed on their portal.

3) I need a real, customized application that can be used to test features that are being built into another J2ME/J2EE application (this is part of my full-time job in a mobile start-up).

Project Approach

I’d really like to tackle this with the minimum effort possible, so I’m going to leverage some work I did on a Bluepulse widget (Amazon OnTheGo). There are a large number of things about the widget that I would like to improve, and several of those are best addressed by a full-scale MIDP application, rather than a widget.

So I’m going to port Amazon OnTheGo to an MIDP application. I haven’t decided yet if I’m going to build this just for MIDP2 phones or also MIDP1 phones. I want to specialize enough to exercise and test Polish’s build framework, but not enough that I have to devote a lot of time to making this work on a large number of devices.

What to Expect

In theory, over the next several weeks, I’ll be able to post some insights into using the new features of J2ME Polish 1.3, some code samples, and some firsthand knowledge of adding an application to Sun’s mobile portal. Then again, in theory, there is no difference between theory and practice, but in practice, there is.

Tags: J2ME, Java ME, J2ME Polish, mobile software, mobile development, Sun

J2ME Polish, Just the Facts

I’m taking on a quick side project, which will begin in the next day or so, and I’ve decided to document a few pieces of that project. I’ll write more on that project later, but because most of those posts will make mention and use of J2ME Polish, I thought I’d introduce it today for those who aren’t familiar with it.

What is J2ME Polish?

J2ME Polish is a collection of open source tools used for creating wireless Java applications. Much of J2ME Polish is focused on MIDP applications, but recent releases also address Palm and RIM devices. The primary facets of J2ME Polish (from my perspective) are:

1) Build framework

J2ME Polish enables you to create builds targeted to certain devices or groups of devices. Using the device database and preprocessing, you can query for device capabilities and limitations, and fork your code at build time. Resource assembling enables you to conditionally include things like images or sound files targeted to certain devices.

Building for a device with a full color resolution of 240 x 320? Include large, full color icons. Building for a Motorola? Conditionally include an RMS size attribute in the JAD, and include 15 x 15 list icons. Want to display a fullscreen canvas? Query for fullscreen mode or Nokia UI support.

J2ME Polish also packages an extendable logging framework, giving you access to errors via emulators or the actual device; a localization framework; and takes care of the details of compiling, preverifying, obfuscating, and packaging your application.

2) GUI framework

J2ME Polish interlaces its UI classes with MIDP UI classes, enabling you to use traditional CSS techniques to style the interface of an MIDP application. This is a huge productivity booster. If your application must support MIDP1 devices, J2ME Polish transparently adjusts the MIDP2 to provide that support.

Some new custom items available include a SpiteItem, used to make animated menus, similar to web mouseover effects; a tabbed form; and a framed form, where a screen can be split into scrolling and non-scrolling frames.

J2ME Polish also packages a game engine, enabling you to quickly port MIDP2 games to MIDP1 phones.

3) Tools & Utilities

J2ME Polish brings ArrayLists to MIDP applications, and its TextUtil class offers functionality similar to that found in JavaScript array functions and Java’s StringTokenizer. The BitMapFont class and standalone editor enable you to create image-based fonts to use in your applications. Forget about Motorola’s 20 pixel system font!

J2ME Polish is available under both GPL and commercial licenses, depending on your project. Read more about J2ME Polish here.

Tags: J2ME, Java ME, J2ME Polish, mobile software, mobile development

Opera Mini 2.0 Released

Wow, version 2.0 already?

I’ve been very impressed with Opera Mini 1.2 — my only complaint was the lack of download support. Find something you want to download, wait 20 seconds to get a “downloads not supported” error, fire up my carrier’s WAP browser, and proceed. Version 2.0 now supports downloads directly to the phone, and the footprint is still under 100KB.

Skins are also on the menu, if you’re so inclined, as well as a “speed dial” feature that I have yet to try myself.

Get it while it’s hot: Point your WAP browser here to download it, or check out the download wizard to view details specific to your phone.

Tags: cell phones, Opera, mobile applications

Opera Mini Kicks Ass

I’ve been using Opera Mini ever since its release was announced, and I’ve been wildly satisfied with it. It’s a J2ME application that interacts with a full Opera browser on a remote Opera Mini Server. The server grabs the page, formats it for your screen, eliminating 70-80% of the file size along the way, and sends it to your phone. This gives the installation a footprint of under 70KB on my phone.

On my Sony-Ericsson s710a, it is absolutely stunning. It’s available to all Sprint and Cingular
customers, and availability for T-Mobile customers is dependent on the subscription plan. BREW-enabled phones, including Verizon, are currently not supported.

Point your WAP browser here to download it, or check out the download wizard to view details specific to your phone.

Tags: cell phones, Opera, mobile applications

« Previous Page