Tomas Brandalik's Blog: February 2007 Archive

Posted by tbrandalik on February 16, 2007 at 03:46 AM | Permalink | Comments (1)

I'm back to finish this tutorial which started here. So let's have a look at internal structure of a resource file and explain how to work with resources in JSR238. In part1 we talked about directory structure of resource files in the application, but I haven't shown any code for accessing them. Here is it. Main entry point into resource files is ResourceManager class. There's not much to screw up ;-)

	// look for phrases resource file under default locale
	rm = ResourceManager.getManager(“phrases“);

	// look for phrases resource file under en-US locale
	rmUS = ResourceManager.getManager(“phrases“, “en-US“);

	// get device resources
	rmDev = ResourceManager.getManager(““);

Before we dive into resource file structure I have to mention also metafiles accompanying resource files. Metafiles are fairly simple. They contain only plain text, enumerating supported locales for given resource file. Next example is a metafile of phrases resource file from i18nDemo bundled with WTK2.5.

"" en cs-CZ sk-SK he-IL zh-CN ja-JP de-DE it-IT es-ES

Main purpose of the metafile is to speed up look up of supported locales for a resource file. If you call

String[] supLocales = ResourceManager.getSupportedLocales("phrases");

the metafile is read first without need to scan thru a /global subdirectories. However metafile is easily editable plain text file, it's not recommended to update it directly. Better use i18n Resource Manager which provides necessary integrity of metafiles and resource files. If metafile is a plain text file, resource file on the other hand is binary file designed to be efficient in storing and accessing resources. In general there are 2 types of resources in resource file:

text strings (UTF-8 encoded)
binary data (images, sounds etc. stored as a raw data)

Handling text string resources is very simple. Decoding of text strings from UTF-8 is provided by the JSR238 implementation of ResourceManager. Each string and each binary resource is identified by a number (integer in range 0 .. 0x7fffffff)

	ResourceManager rm = ResourceManager.getManager(“phrases“);
	// get string id = 1234
	String s = rm.getString(1234);

On the other hand binary resources are application dependent which means that developer is responsible for further processing of raw data retrieved from resource file. He has to turn raw data of for example png encoded file into an image.

	ResourceManager rm = ResourceManager.getManager(“common“);
	// get image as binary data id = 5678
	byte[] idata = rm.getData(5678);
	Image img = Image.createImage(idata, 0, idata.length);

Evenif it's not necessary for application developer to know the format of the resource file, it's interesting what's behind the scene and of course you can write your own tool for resource file creation. Following picture shows that resource file contains header informations and resource data items. Header informations are necessary for fast access, resource file doesn't have to be read sequentially to find particular resource but the index determines a position in the file. Here is what a structure of resource file looks like:

    4 bytes for signature
    4 bytes for header length
    64-bit header entry
    64-bit header entry
    64-bit header entry
    ...
    64-bit header entry
    resource
    resource
    ...
    resource

Each header entry is composed of a resource ID, Type and Offset:

  bits 63...32   resource ID
  bits 31...0    type and offset

where values for the type are:

0x01 = string
0x10 = binary data
0x00 = end of resources

That's all for today. Next time formatting and sorting ...

Skinning WTK on Linux

Posted by tbrandalik on February 15, 2007 at 03:00 AM | Permalink | Comments (9)

I'm working on Linux release for some time and I feel I need to have a fun little bit. I've googled for a look & feels which would work on linux and found a page http://www.javootoo.com/ with custom L&Fs and tried to plug some of them into wtk toolbar. Some are free, some commercial, some work only on windows ...

Start with jdk linux native look and feel. jdk 6 native L&F shows improvements comparing to jdk 5. But notice separators in the JToolBar, they aren't vertical.

jdk 5

jdk 6

Alternative look and feels
To plug-in L&F just edit ktoolbar script. Put L&F jar on classpath and set property -Dkvem.lookandfeel. An example for synthetica L&F:

-Dkvem.lookandfeel="de.javasoft.plaf.synthetica.SyntheticaStandardLookAndFeel"

Napkin

Synthetica Green and Dream

Tonic slim

Tiny YQForest

L2FProd skins
You can try L2FProd skins if you edit ktoolbar starting script to look like this:

java -Dkvem.home="${KVEM_HOME} \

    -Djava.library.path="${KVEM_HOME}/bin \

-cp $KVEM_LIB}/lf/skinlf.jar:${KVEM_LIB}/kenv.zip:${KVEM_LIB}/ktools.zip:${KVEM_BIN}/JadTool.jar:${KVEM_BIN}/MEKeyTool.jar:${KVEM_LIB}/customjmf.jar:${KVEM_API}/j2me-ws.jar:${KVEM_BIN}/schema2beansdev.jar:${KVEM_BIN}/j2me_sg_ri.jar:${KVEM_BIN}/jaxrpc-impl.jar:${KVEM_BIN}/jaxrpc-api.jar:${KVEM_BIN}/jaxrpc-spi.jar:${KVEM_BIN}/activation.jar:${KVEM_BIN}/mail.jar:${KVEM_BIN}/saaj-api.jar:${KVEM_BIN}/saaj-impl.jar:${KVEM_BIN}/xsdlib.jar \

Skinit -pack ${KVEM_LIB}/lf/themepack.zip com.sun.kvem.toolbar.Main "$@"

Evenif this is a linux script I believe you can edit also win32 ktoolbar.bat script acordingly. You just need skinlf.jar on the classpath and download apropriate themepack.zip. Here are some of them:

L2FProd cell shaded

L2FProd Graphite

L2FProd OpusOSDeep

L2FProd AAToxic

Getting started with Mobile internationalization API. Part 1

Posted by tbrandalik on February 09, 2007 at 02:29 AM | Permalink | Comments (2)

Mobile Internationalization API (JSR 238) or shortly called MIA comes as a part of wireless toolkit version 2.5. This entry is a quick start for those who wants to get familiar with this new API. You may object that user won't find devices supporting JSR238 on the current market. Yes, that's true, but the time when MSA replaces current JTWI standard is coming and it's always good to be ready ;-) ...

Briefly JSR238 is a solution for internationalization and localization of MIDP applications. Who likes reading a theory has a chance to read more about both terms here. I personally like one sentence explanation which says that:

internationalization is a process of designing applications that way that it can be localized to various languages and regions."

localization is a process of translating software user interfaces from one language to another and adapting it to suit a foreign culture."

Looking back at CLDC/MIDP it has already introduced essential support for internationalization. I'm sure you remember that:

Characters encoding is Unicode.

Locale identification (see RFC 3066) and microedition.locale property were defined.

Date, Calendar, TimeZone classes are available.

InputStreamReader and OutputStreamWriter allow reading/writing character streams.

JSR238 goes further and addresses following problems:

Separating of resources from the application source code. All localizable resources are stored out of the source code. It helps to easier translate an application without need to recompile and lowers possibility to introduce error.

Formatting of dates, times, numbers, currencies and messages. These items are correctly formatted according to locale set by application.

String collation. Collation is correct for the locale set by application.

Locale identification
Locale is the only way how to tell jsr238 implementation classes to behave according to desired locale. Locale identifier follows pretty same rules like in javaSE and is built as 2 letters of language code followed by 2 letters of country code and optionally a language variant. As a separator both underscore "_" and dash "-" are allowed.

en-US, cs-CZ, zh-CN, ja-JP ...

Interesting thing is that also empty string "" as a locale identifier is valid and signals that neutral formatting is required. I will talk about neutral formatting in next part of the guide ...

Resource files
To allow easy localization of application all localizable resources has to be stored into separate resource file. JSR 238 defines 2 categories of resources. device resources and application resources. The application resources are the resources bundled with the application, device resources are "burned into" the device. Application developer is responsible for creating and maintaining application resources, on the other hand device resources are read only.
Resource files are hold in a structure of folders defined by the specification. If you have WTK 2.5 installed (and I hope you have ;-)), go into apps folder and look into i18nDemo a project which contains JSR238 sample MIDlet. Open MIDlet binary i18nDemo.jar and along with package folders containing classes there is also folder global with resources. Global is a root folder for all resource files. You will notice subfolders which naming follows locale identification schema. These folders then contain localized resource files. Look at following picture:

Resource file "common" appears there in 3 localized versions. Each is identified by the full path to the resource file.

/global/common

/global/en/common

/global/en-US/common

Resource inheritance principle was implemented here to save space. It means resource don't repeat in resource files. If a resource, we are looking for, isn't found in /global/en-US/common next resource file /global/en/common is queried and then as a last try common resource file /global/common is queried. You've probably noticed resource file stored directly under /global folder. It's good strategy to store resources which aren't intended to be translated into resource files right under /global folder. These are called common resources.
Inspecting a structure of resource files and resource files itself just in file browser isn't very comfortable. We prepared small utility i18n Resource Manager which really simplifies the work with resources. Run WTK Toolbar and load i18nDemo project. I18n Resources Manger is right in project menu here:

Another possibility to launch i18n Resource Manager is a script WTK_HOME/bin/i18ntool. Launch it with parameter <path to any resource global folder>

i18ntool ../apps/i18nDemo/res

In the next part we will look closer at resource files structure ...

How to attach new wireless tooolkit to Netbeans MP

Posted by tbrandalik on February 08, 2007 at 05:33 AM | Permalink | Comments (1)

Netbeans Mobility Pack comes with already bundled WTK. The catch is that this is not current final version 2.5. Beginners sometimes can't find the way how to attach separately downloaded WTK. Don't worry this is really easy. The trick is to use Java Platform Manager wizard hidden in Tools menu. Mobility Pack offers nice Quick Start Guide between others topics addressing also this problem. Look for section Changing the Emulator Platform.

Wireless Toolkit 2.5 is Final!

Posted by tbrandalik on February 05, 2007 at 07:38 AM | Permalink | Comments (8)

Contributed by: Richard Gregor WTK engineering manager.

After quite a long development, Sun Java Wireless Toolkit 2.5 for CLDC (oh man what's a long official name) is final, everybody can download it here:
http://java.sun.com/products/sjwtoolkit/download-2_5.html .

This is a really great release bringing the support for the Mobile Service Architecture (MSA). For those of you who are not aware, Mobile Service Architecture is a definition of a new Java platform for the mobile devices. It specifies what all APIs should be supported on the mobile phone that is MSA compliant. MSA is is a really rich platform that specifies essential client components of an end-to-end wireless environment. In comparison to its predecessor Java Technology for the Wireless Industry, MSA includes many more exciting APIs and I don't want to describe them all because it is long list and I need to do also something real for my living.

Let's take a look at what's new and cool in the toolkit.

Forget about Flash, now we have SVG!

SVG is powerful language for describing two-dimensional vector and mixed vector/raster graphics in XML.

SVG API implementation as specified in JSR 226 is included in the toolkit and contains also optional parts not demanded by specification. Toolkit comes with 2 SVG demos that should help you start with SVG programming.

SVG Demo

SVG Demo includes simple demos that you can use as a start point. You can browse and display your svg files located on device's filesystem, render simple svg picture, play svg animation, create svg picture from scratch, work with events and manipulate svg images - all basic stuff you can do with SVG API.

* Location Based Service :

SVG Contact List Demo

If you wanna see something more advanced in SVG, then please check this demo. You can also try to run it on Nokia S40 phones with SVG support -looks amazing and comes with 2 skins.

* SVG Contact List:

Payment or how to make money

Payment API allows your MIDlet to initiate payment transaction in a secure manner. Nice example of monetization is a JBricks game included in toolkit. You can buy additional lives or advanced levels of the game and pay either with your credit card or by sending a Premium Priced SMS. Payment implementation comes with very nice support.

* You can manage the price for a certain feature e.g. live or level in the update file (*.jpp). To change data in this file, toolkit includes Payment Update File Editor:

Utilities by the way were redesigned - should be seen on the picture, isn't it? You can choose when new prices are taking place. There is not only client side for Payment but also the Payment Server. Payment console allows you to see payment communication, you can track details of network communication in the Network Monitor. Of course preview of all transactions and their status is available as well. For Payment API details please check Payment API - JSR 229

Good Morning, Buenos dias, Dobry den - Mobile Internationalization in Action

With continuing globalization, the necessity for producing localized application is raising rapidly. Even though internationalization for !JavaSE and !JavaEE applications is well known process, with a lot of support from various tools, the situation in !JavaME/MIDP was not satisfactory for a long time, because there was no standard solution for solving internationalization issues. With the introduction of JSR 238 (Mobile Internationalization API), !JavaME application developers can leverage it to create truly internationalized applications.

Basic ideas behind JSR 238 are here:

* For multicultural/global applications
* Allows developers to internationalize their MIDP applications
* Central Concept – resource, data that is localized
* String
* Image
* Object
* Application - specific and Device - specific resources
* Application Resources are bundled as part of MIDlets suite jar file
* Includes support for cultural conventions

Resources are in binary resource file, in format defined by JSR 238. Toolkit includes resource manager that makes it easy create and maintain different types of resources.

Session Initiation Protocol (SIP)

There is few good reasons for this API to be included:

* It is a standard way how applications can set up communication
* Cost savings
* Security

SIP is used e.g. in Instant Messaging, Text and Voice Chat and Video Conferencing. Except API implementation, the Wireless toolkit includes demo SIP server (proxy and registrar). It is of course up to you, if you would rather use your real SIP server, no problem. Network Monitor has been extended so now you can track SIP communication too. There are 2 nice demos for SIP.

* SIP Demo - for basic peer-to-peer communication
* GoSIP Demo - advanced demo using Built-in SIP server for simple chat between 2 devices

There is a lot more in new Sun java Wireless Toolkit 2.5. Don't wait, go and review it yourself!

Powered by
Movable Type 3.01D

java.net RSS Feeds