Majimob has introduced a new media player this month, what hasn't been stressed was the fact that it is built from the ground up on LWUIT. In less than 3 weeks this new media player was downloaded 200,000 times and the numbers are rising with the 1.1 version released this weekend. You can read allot about MajiPlayer in the site (which I urge you to do) but what might not be as immediately obvious is just how much LWUIT contributed to this unique player... The whole application was written in under 2 months (including version 1.1 which includes major new features), it works on a ridiculously large number of devices as is evident from the getjar statistics for downloads. The main reason for failures in getjar when such occur, is the need for a signing certificate and even that isn't too bad.
The stunning part is that the application utilizes MMAPI, File connector & restricted API's (digital certificate). All of these are especifically notorious in the porting community as porting "problems", yet MajiPlayer is still able to realize LWUITs vision of one jar for all devices. Resources for themes are downloadable on the fly with a rather cool AJAX based theme uploading tool (I understand downloading user generated themes is "in the pipe"), the selection of themes is also impressive for a small application.
This sort of approach allows majimob to utilize the economies of scale thus reducing prices and deriving profits from ads, the advertising integration in the unregistered version of MajiPlayer is unique for mobile phones and utilizes LWUIT extensively.
LWUITs features are used to the max throughout the application in very obvious ways, transitions, progress, dialogs, themes, fonts etc. are all extensively leveraged.
See more videos of MajiPlayer in action here.
Sunday, November 23, 2008
Thursday, November 20, 2008
New Article About Animations And Transitions
Java.net published another fine LWUIT article by Biswajit Sarkar which deals with animations and transitions this time. This is really great news since I wanted to discuss transition authoring several times in the past and just didn't get the time to do anything in this area.
BTW transitions on components, dialogs etc. are already fully supportted in the latest drop with lots of fixes for that functionality in SVN.
BTW transitions on components, dialogs etc. are already fully supportted in the latest drop with lots of fixes for that functionality in SVN.
Tuesday, November 4, 2008
Round & Round - Infinite Progress And Rotation
When looking at the Makeover demo I posted last week one might assume the rotating wheel animation is a standard animation or gif. This is not the case although I could have gone with that approach I chose to use a different tool to achieve this effect.
I built an infinite progress component which displays a rotating image as an animation, this considerably reduces JAR and heap space usage for an animation that looks quite similar to the one produced by a static animation (which we create from GIF). The reason for this is in the way animations work, animations have no sense of rotation, they store the change to the image (as lines) and when the image rotates the animation sees the entire image as changed and produces a "key frame". Key frames are large both in storage and in memory, to hold a 32x32 pixel animation with 8 keyframes I would need approximately 32x32x8+1024 (1024 for palette). This might not seem big, but with increase in resolution the size rises quite a bit...
Rotation is not always efficient, in fact it can be just as inefficient as a keyframe since it needs to create a new image. However, LWUIT has a special optimization on MIDP (this doesn't not apply to LWUIT on CDC) which uses the platforms built in rotation abilities for square angles (90, 180 & 270) hence removing completely the overhead of the image. This isn't enough since rotating on square angles would produce a jumpy effect, which is why I rotate once to 45 degrees and then rotate 2 images in square angles only thus producing what seems to be 8 images but only paying the cost for 2 images.
Another significant advantage is that unlike animations I can make full use of translucency since the alpha channel isn't removed in these images, this allows for flowing rotation effects.
The rotate method currently makes many assumptions and is mostly useful for square images, however it works rather nicely for all angles which is something that currently plain MIDP doesn't support.
I built an infinite progress component which displays a rotating image as an animation, this considerably reduces JAR and heap space usage for an animation that looks quite similar to the one produced by a static animation (which we create from GIF). The reason for this is in the way animations work, animations have no sense of rotation, they store the change to the image (as lines) and when the image rotates the animation sees the entire image as changed and produces a "key frame". Key frames are large both in storage and in memory, to hold a 32x32 pixel animation with 8 keyframes I would need approximately 32x32x8+1024 (1024 for palette). This might not seem big, but with increase in resolution the size rises quite a bit...
Rotation is not always efficient, in fact it can be just as inefficient as a keyframe since it needs to create a new image. However, LWUIT has a special optimization on MIDP (this doesn't not apply to LWUIT on CDC) which uses the platforms built in rotation abilities for square angles (90, 180 & 270) hence removing completely the overhead of the image. This isn't enough since rotating on square angles would produce a jumpy effect, which is why I rotate once to 45 degrees and then rotate 2 images in square angles only thus producing what seems to be 8 images but only paying the cost for 2 images.
Another significant advantage is that unlike animations I can make full use of translucency since the alpha channel isn't removed in these images, this allows for flowing rotation effects.
The rotate method currently makes many assumptions and is mostly useful for square images, however it works rather nicely for all angles which is something that currently plain MIDP doesn't support.
public class InfiniteProgressIndicator extends com.sun.lwuit.Label {
private Image[] angles;
private int angle;
public InfiniteProgressIndicator(Image image) {
Image fourtyFiveDeg = image.rotate(45);
angles = new Image[] {image, fourtyFiveDeg, image.rotate(90), fourtyFiveDeg.rotate(90),
image.rotate(180), fourtyFiveDeg.rotate(180), image.rotate(270), fourtyFiveDeg.rotate(270)};
getStyle().setBgTransparency(0);
setIcon(image);
setAlignment(Component.CENTER);
}
public void initComponent() {
getComponentForm().registerAnimated(this);
}
public boolean animate() {
angle++;
setIcon(angles[Math.abs(angle % angles.length)]);
return true;
}
}
Subscribe to:
Posts (Atom)