Sunday Jan 24, 2010

Where are my logs .. ?

It is nice and polite when application writes log. Especially when something went wrong it can help to track down the source of problem.  JMESDK has several components which produce their own log files. Here they are:

Device-manager

  • This is core component for the product. It starts automatically and registers all devices and emulators. Since all communication goes through device-manager this log contains always the most important information.
  • Log file is placed into /user's home/javame-sdk/3.0/log/device-manager.log (windows) or /Users/username/Library/Application Support/javame-sdk/3.0/log/device-manager.log (MacOSX)

Emulator

  • Emulator loads its skin and starts cldc or cdc virtual machine (VM). Emulator and VM write log under the emulator instance working directory /user's home/javame-sdk/3.0/work/(instance ID)/device.log. How to get the instance ID? When emulator starts, ID is displayed in window caption after the name of device.

mini IDE

  • JMESDK contains simple IDE which is built on top of Netbeans platform and thus uses platform logging mechanism. It writes log into /user's home/javame-sdk/toolbar/3.0/var/log/messages.log

Friday Jan 15, 2010

How to create a custom device

I've got a question how to create custom emulator skins several times. It can't be answered in a few words, a short tutorial with an example will be the best way of explanation. Skin800x480The zip bundle here contains an example of standard CLDC/MIDP device with a display of 800 x 480 pixels and a few buttons. Due to lack of creativity I call the device "Skin800x480" and I have to admit it looks quite ugly.  I will use it as a reference throughout this tutorial. You can use it as a base for your further customization. Before we get to a details I need to say a few words about the installation of the device.

Installation

It is fairly simple. You just need to unzip Skin800x480.zip bundle into JMESDK 3.0 installation directory. (C:\\Program Files\\Java ME SDK 3.0 on windows or /Applications/Java_ME_SDK_3.0.app/Contents/Resources on MacOS) Restart of the device-manager is required.

Device definition and device instances

Files which you've just unzipped into JMESDK is a definition of a device. JMESDK installation directory contains only device definitions. Device definitions are during launch of the device-manager used to create device instances. After you have restarted the device-manager you can check that an instance of "Skin800x480" device has been really initialized. Have a look into your user home Library/Application Support/javame-sdk/3.0/work (MacOS) or Application Data/javame-sdk/3.0/work (windows). Device instances are identified by numbers from 1 to 6 (MacOS) or 1 to 11 (Windows). One more instance No. 7 or No.12 has been initialized by the device-manager after the "Skin800x480" installation. It's more less obvious what all files inside instance directories mean. I will let it up to you inspecting them and finding it out.

Test it

 Let's check that the installation has been successful now. Open command line and and call emulator to list properties of the new device. Usually you don't have to use -Xdevice switch but because the default device is "DefaultCldcPhone1" and not our "Skin800x480" you will have to specify always device name for every emulator command. Write:

emulator -Xquery -Xdevice:Skin800x480

Command will list profile and configuration of the device along with other properties like bootclasspath, screen width and height etc. It's time to start the device now, this time star it without an application. Write:

emulator -Xjam -Xdevice:Skin800x480

or with an application

emulator -Xdescriptor:../apps/Demos/dist/Demos.jad -Xdevice:Skin800x480

Use the device and you will see how buttons behave when pressed or when mouse goes over the button.

The device

JMESDK is highly customizable and lets you define new devices without touching a code. Flexibility is necessary since there is a big number of handsets out on the marked and they differ in many aspects. A display size or a color depth, controls, number and type of keyboards (midp, qwerty, sliding keyboard), number of displays (2 displays in case of clamshell phones),  hardware modules (GPS, battery level sensor, motion sensor), external memory card just to name a few of them. JMESDK can literally assemble a device from particular components to match as close as possible desired handset. Here is what we can use as a building blocks of our device:

  1. skin (a picture of the handset)
  2. display (number of displays, size, color depth)
  3. device states (open, closed)
  4. keyboards (keyboard layout and key codes mapping)
  5. JVM (runtime associated with a device)
  6. device properties (fonts, default locale, BT address, phone number, heap size, security domain and many more)
  7. hardware modules (GPS, accelerometer, sensors, memory card etc.) 

Making a device

Look into a zip file into devices/Skin800x480/conf. You need 3 skins (png bitmaps) of the device. 1st one displays device in "normal" state, 2nd in "highlighted" (how the button should look like when mouse goes over it) and 3rd one in "pressed" state (how button should change when it is pressed). In our case we have 4 buttons A,B,C,D and "joystick" in the middle with buttons Left, Right, Up, Down and Select.  Important part is the display. You have to ensure that the size of display fits perfectly 800x480 pixels. You will need to write down boundaries of each button and of the display as well.  We will use them later on in mapping of buttons and in dislpay setup.

Besides of 3 skin bitmaps mentioned above the folder contains a few other files:

  1. index.html, bg.jpg, skin-test-small.png - these files compose a device information page which appear in our small IDE when you double click a device in device selector.
  2. networkIndicatorOn.png - you need this if the device has a small light (network indicator) which blinks when there is a network traffic.
  3. modules file - devices are sharing some functionality across them. This file describes what support should be loaded for this device. Each row is a path to particular module. For example modules/emulator-cldc is generic cldc-hi runtime, skin/single-state-shared is a module common to all devices which have only single state, emulator/generic/ui/touch-screen-support is a module which enables touch screen support etc.
Display setup

We have bitmaps with a space for display ready. What we have to do now is just to place a screen buffer properly on the bitmap and set screen buffer size. We will do this in .bean files. These files are being read when device and its runtime starts. Each .bean file represents an object with given setters.

  • ScreenGraphics.bean::dimension is a setter for a width and height of a screen buffer. Proper value for our device is 800, 480
  • Screen.bean::position sets x,y location of screen buffer on a skin bitmap. In our case 21,21
  • NetworkIndicator.bean::bounds location and width of network inicator
  • NetworkIndicator.bean::image a name of network indicator png bitmap
Button mapping

Our simplified device has four-way joystick, select button in the middle and four soft buttons A, B, C, D. ButtonsMapping file is called default-state.xml. It defines one single state of the device. For example Clamshell phone has 2 states opened and closed and need 2 mapping files.

Here are parts of the file:

<device-state name="Default" defaultSkin="skin-test-normal.png" 
pressedSkin="skin-test-pressed.png" 
highlightedSkin="skin-test-highlighted.png" 
networkIndicator="NetworkIndicator">

device-state references 3 skin bitmaps -- normal, highlighted, pressed and a network indicator object. You need to put correct bitmap names here.

<button activators="VK_F1" vmKeyCode="-6" 
x="259" y="509" width="88" height="22"/> 

Each button is defined by its bounds (x, y, width, height) a vmKeyCode (integer sent to the runtime when button was pressed) and activator (keyboard activator for this button are VK_\* constants, as defined in java KeyEvent class)

vmKeyCodes are defined as follows:

    UP           = -1,
    DOWN         = -2,
    LEFT         = -3,
    RIGHT        = -4,
    SELECT       = -5,
    SOFT1        = -6,
    SOFT2        = -7,
    CLEAR        = -8,
    SEND         = -10
    END          = -11
    POWER        = -12
    KEY_0 .. KEY_9, #, \*, etc = ASCII code of the character. 
                               (vmKeyCode for printable character
                                is its ASCII code)

We don't have a button with printable character on our device but here is an example for number '1'.

 <button activators="VK_1 VK_NUMPAD1" 
vmKeyCode="0x31" keyChar="1" 
x="36" y="493" width="76" height="31"/>

Device adapter

Here I will talk about files related to the device manager. Device manager recognizes any device when its corresponding device adapter is installed. For every device adapter, there is a corresponding .bean file in process/device-manager/device-adapter.  Among other things adapter references runtime which should be used with this device. In our case it is cldc-hi-fx runtime (cldc/midp runtime with built-in JavaFX extension).  Since there is no other option for a runtime, I won't go deeper into settings of runtime in the adapter. You will better leave adapter files untouched. Just copy all files to use them for your own device, do the search through all files and replace Skin800x480 with a name of your own device. Although one thing has left to be mentioned here. You can add as many device instances as you wish. We have 1instance for Skin800x480. Instance .bean file is in process/device-manager/device-adapter/Skin800x480/1.bean. But can be copied to 2.bean, just change the setter deviceName to for example Skin800x480_1.

The end

I think we are done with simple customization. Definitely there's much more options to setup like device states etc. I've mentioned them all above. We can get back to them later if somebody needs them. I hope this entry will help to everyone who wants to create his own skin. Don't forget to share with us any skin you would create ...

Saturday Dec 26, 2009

Use Mac AirPort to work with WinMobile handsets

As you probably know we ship Java ME SDK with cldc java runtime for Windows Mobile. You can deploy MIDlets onto Windows Mobile handset as easy as it was an emulator. Connecting a WinMobile handset from Java ME SDK is very straightforward using activesync on windows. It's really just a matter of plugging device and runing jvm on it.

Situation is different on Mac since there's no free activesync support. Fortunately most of WinMobile handsets come equipped with Wi-Fi and we can take advantage of Mac's AirPort networking. What we need is to create computer-to-computer network and let WinMobile handsets connect to the network. Only trick is to find out IP address of the handset. When you have the IP and you have started jvm let Java ME SDK look up the handset. Since it's recognized you can deploy MIDlet on it an also debug your applications right on the handset using Netbeans Mobility Pack. 

Before you start with this tutorial copy .cab file from Java ME SDK installation folder named "on-device" to your WinMobile handset and install it.

Create computer-to-computer network and give a name to it (in our example "MyNetwork").

On handset look into Settings->Conections->Wi-Fi and search for computer-to-computer networks and connect to network. After your handset is successfully connected to "MyNetwork" look at details of Wi-Fi adapter where you find assigned IP address. Just to be sure open terminal and try to ping the handset

ping 169.254.205.222

if your handset is reachable you can continue in Java ME SDK. Launch JMESDK and look at Device Selector window where 2 new buttons have been added in version 3.0 for Mac. Look at the image below where the buttons are highlighted

The first one  opens a wizard which helps you to connect to handset. All you need is to specify IP address. When the jvm on handset responds to look up from JMESDK it is added under the device node "Other" as you can see on the image above. Second button  refreshes connection to handset. My htc diamond falls asleep after some time and when it is awake I need to refresh connection. Device registration can be made also from command line

device-address add ip 169.254.205.222

or on device-manager. Click on device manager icon  in status bar and choose manage device addresses.

Now with the handset connected you can deploy MIDlet on it. Just open one of the sample projects right click on CldcWinceEmu1 node and choose "Run Project".

Of course all of this you can do also without Mac AirPort simply over the Wi-Fi router if you have one available. About debugging on-device using Netbeans Mobility Pack I will write soon. I suppose after you're successfull with this setup you will figure out how to make it work for Netbeans MP as well.


Monday Oct 26, 2009

Preverify: VERIFIER ERROR

If you are running Java ME SDK 3.0 Early Access for Mac OS X you might experience preverify problem and got VERIFIER ERROR message. To fix it run following command in /Applications/Java_ME_SDK_3.0.app/Contents/Resources/bin path:

lipo preverify -output preverify -extract i386

It leaves only 32-bit version in the preverify file and takes out the 64-bit version.

Tuesday Oct 13, 2009

Device manager autostart

There is a new component device-manager in Java ME SDK 3.0 which is a cornerstone of the SDK. It runs in background and only a small icon in notification are on taskbar shows that it is up and running. It keeps running even if you're not working with Java ME SDK and it's launched along with start of the system. Not very nice ... You can easily get rid of autostart just open regedit and remove entry "Java(TM) ME Platform SDK 3.0" under
HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run

Monday Jul 13, 2009

1 update found

Have you started Java ME SDK 3.0 and see a small icon in the bottom right corner?

Update Notification

It appeared there about a month ago and some of you maybe asked what it means. The icon notifies you about available updates for Java ME SDK. This is a new feature in 3.0 release and allows delivery of updates faster than regular releases.

It is very easy and simple to install new updates, just click on the icon and follow instructions.

This first update contains updates of BD-J libraries from HDcookbook project and a few small fixes in Blu-ray development support. During the updating process you can see a message that plugins are signed but not trusted. You can trust them. This issue is also solved in the update and if you install the update this warning will not appear again in the future for next updates.


Tuesday Jun 23, 2009

Java ME wireless on-device debugging

There is a geeky alternative to the common on device debugging process. You usually take a cable, connect your device to the computer and wait until Active Sync connects your device and your computer. After it your device appears in the Device Selector in the GUI and in the emulator -Xquery command output.
There is an other (a bit unusual and untested ;) ) way, that requires no cable, no Active Sync. You just needs a Windows Mobile device that supports Wi-Fi and that a Wi-Fi enabled computer or a wireless router. Here is a simple HOWTO.
  1. Install a Java(TM) ME runtime on your device. You can find it in the on-device/winmobile-arm subdirectory of your Java ME SDK 3.0 installation directory. More info about this in the previous blogpost.
  2. Make sure that your computer is running and somehow accessible via Wi-Fi. There is no difference between plugging it into Wi-Fi enabled router and starting an ad-hoc network on the computer.
  3. Turn the WiFi on your device on, write down it's IP address. (This can be different for different vendors and models a good point to start your search is START -> Settings -> Connections -> WLAN Settings -> Connection Status. Otherwise you should check documentation shipped with your device.)
  4. Check, that the phone is accessible from the computer. Run ping <IP_OF_THE_DEVICE> or tracert <IP_OF_THE_DEVICE>.
  5. Run the Sun Java CLDC Emulator runtime, that you have installed on device.
  6. Go to the bin subdirectory of SDK installation. Run device-address.exe add ip <IP_OF_THE_DEVICE> command here.
  7. Wait a few seconds, check that emulator.exe -Xquery output contains a newly connected device. (Or run the GUI shipped with the SDK and have a look at the Device Selector)
  8. Now you are done, the device should work as any other device or emulator. You can for example run emulator.exe -Xdescriptor:../apps/FPDemo/dist/FPDemo.jad -Xdevice:<NAME_OF_THE_DEVICE_FROM_XQUERY> that installs an example midlet on the device. For debbuging you can use NetBeans Mobility or run emulator.exe -Xjam:install=<YOUR_JAD> -Xdevice:<NAME_OF_THE_DEVICE_FROM_XQUERY> -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=12345,suspend=n and connect any debugger to the port 12345

And some smaller tips at the end:

  • if you use a wireless router, you probably can configure it's DHCP server to provide all the time the same IP to your device. In such a situation, you don't need to run the device-address command every time. Your device is detected and connected every time, it appears in the wireless network.
  • it is possible to connect multiple phones to the computer at the same time. It is great for debugging on several different devices.

Friday May 29, 2009

Creating new emulator instances

Each emulator has 2 instances by default in Java ME SDK. For example DefaultCldcPhone has 2 instances DefaultCldcPhone1 and DefaultCldcPhone2. Developers ussualy don't need to run more than 2 instances simultaneously, but if it's necessary you can easily add new instances.

  1. go to toolkit-lib/process/device-manager/device-adapter/DefaultCldcPhone and copy file 2.bean into 3.bean, 4.bean etc.
  2. edit new bean to contain name of DefaultCldcPhone3 and link to DefaultCldcPhone3.properties
  3. go to toolkit-lib/process/device-manager/conf and copy DefaultCldcPhone.properties into DefaultCldcPhone3.properties
  4. stop device-manager and remove <userhome>/javame-sdk/3.0/work
  5. start again device-manager
Now you should have more instance of the same emulator. 

 

 

Sunday May 24, 2009

VisualVM understands Java ME Profiler Snapshot

Java ME SDK 3.0 supports offline profiling. Data is collected during the emulation session. After you close the emulator a profiler data snapshot is written to a .prof file which you can load and view in the SDK.

Since last Friday it is possible to load and view Java ME SDK profiler file also in VisualVM 1.1. VisualVM is a tool to monitor and troubleshoot Java applications. For more information about VisualVM visit its homepage.

How to view Java ME SDK profiler file in VisualVM? It's easy. Everything you have to do is to install Java ME Profiler Snapshot Viewer module from VisualVM update center.

  1. Start VisualVM.
  2. Open Plugins manager from Tools->Plugins menu.

    Tools->Plugins menu

  3. In Available Plugins tab select Java ME Profiler Snapshot Viewer and click Install button.

    VisualVM Update Center


When the module is installed, new action Import Java ME SDK Snapshot... is added to the application File menu.

Import Java ME SDK Snapshot...

Java ME SDK profiler file can be opened and shown in VisualVM by this action. Default location of Java ME SDK profiler file is <user_home>/javame-sdk/3.0/work/<device_number>/data.prof.

Tuesday May 05, 2009

PhoneME Feature MR4 plugin

We've made a plugin for phoneME developers which helps to integrate their custom builds into Java ME SDK. PhoneME plugin is available on sdk autoupdate. A short notice will popup automatically when sdk is started or go to Tools -> Plugins and look for Java ME SDK 3 binding to PhoneME MR4. Choose to install plugin if you are phoneME developer and you're building your own virtual machine (VM). The plugin itself doesn't contain phoneME VM it's expected that developer will install the one which he build himself. Instructions are provided with the plugin. Here they are summarized with some more details added:

First, install phoneME plugin from autoupdate. Two additional emulator instances named DefaultPhoneMEPhone1 and DefaultPhoneMEPhone2 will be created in sdk. They are bound to new runtime which can be found in SDK_INSTALL_DIR/runtimes/phoneME Although if you look there the runtime is almost empty. Emulator can't run with default phoneME runtime you will need to use latest phoneME Feature release MR4 and modify your build in order to use jmesdk-odt.jar library delivered in plugin. Following are instructions how to update your phoneME makefile:

  1. Add variable: SDK_INSTALL_DIR=<path-to-javame-sdk-install-dir>
  2. Set following switches for midp component: PRECOMPILED_ODD=true and ODD_JAR=$(SDK_INSTALL_DIR)/runtimes/phoneME/jmesdk-odt.jar
  3. Add install rule which will install phoneME runtime into sdk:  cp -r $(BUILD_OUTPUT_DIR)/midp/SDK/runtimes/cldc-hi/\* $(SDK_INSTALL_DIR)/runtimes/phoneME

Now phoneME emulator can be launched with your customized phoneME runtime. Congratulations ;) It can be used from a command line or from Java ME SDK User Interface (UI). If you use UI both phoneME emulators appear in the device selector under a node named Phone ME Feature. If you prefer a command line, a device name must be specified through an option: -Xdevice:

Here is an example:

emulator.exe -Xdescriptor:../apps/Demos/dist/Demos.jad -Xdevice:DefaultPhoneMEPhone1

Here is also basic troubleshooting:

  1. Stop device manager
  2. Delete work directory in Java ME SDK users directory <windows-userhome>/javame-sdk/3.0/work
  3. Start <javame_sdk_install_dir>/bin/device-manager.exe. New work directory will be recreated.

Wednesday Apr 29, 2009

Hot-deployment feature saves your time

I would like to highlight an important behavior of  Java ME SDK here which might be useful to any developer. You don't need to exit from emulator fully, exit only your MIDlet and redeploy new one into already running emulator. This will increase your productivity because of saving time on emulator restarts. I use it always and it's real help.
Unfortunately this feature stays often undiscovered. Give it a try ...
I usually run emulator once without specifying a MIDlet - only to open AMS.

emulator.exe -Xjam

and then deploy my application again and again without exiting emulator - just exiting from a MIDlet.

emulator.exe -Xdescriptor:..\\apps\\Demos\\dist\\Demos.jad

Several things happen behind the scenes. MIDlet is deployed, launched and after exit it is removed. It works from command line and from UI and for real device as well.

Thursday Apr 23, 2009

Blu-ray Disc Application Development with Java ME

Java ME SDK 3.0 integrates CLDC, CDC and Blu-ray Disc Java (BD-J) technology into one SDK. BD-J is a new member of Java ME SDK family ... so it is the right time to try it and create your first Blu-ray Disc Application. How to do it? It's easy, just follow this tutorial.

Sunday Apr 19, 2009

Vista 64-bit

Java ME SDK fails to start on Vista 64-bit with 64-bit JRE. This can be workarounded by using 32-bit JRE on 64-bit Vista. So far, it looks that workaround works well.

When something goes wrong ...

When JME SDK device manager starts for the first time it creates emulator instances under <user_home>/javame-sdk/3.0/work. If something bad happens to instances settings and emulator does not start the first aid is:

  1. stop device manager
  2. delete working directory <user_home>/javame-sdk
  3. launch <sdk_install_dir>/bin/device-manager.exe
Emulator instances will be recreated in its default state.
About

Java ME Platform SDK is a toolbox for developing mobile applications. Java ME SDK Download

Search

Categories
Archives
« August 2015
SunMonTueWedThuFriSat
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     
Today