+++ to secure your transactions use the Bitcoin Mixer Service +++

 

We need Your Support. Make a Donation now! or Buy Me A Coffee

Svetlin Ankov's Blog

Bugs are by far the largest and most successful class of entity, with nearly a million known species. In this respect they outnumber all the other known creatures about four to one. —Professor Snopes' Encyclopedia of Animal Life

New Book Renderer in Albite 3

Sample book rendering in Albite 3. First is with a light effect applied, suitable for night mode, after that without the effect. Note that it looks a bit choppy in the video but actually would be very smooth. The problem was in the video recording software not in my app.

I'm experimenting with a new renderer which will look a bit more realistic. Also, I'm planning to have a different kind of night mode: instead of having a black background, the overal contras will be decreased and a few light effects will be added so as to simulate reading under the light of a night lamp.

Of course, there will be an option to switch back to the classic renderer as well.

New UI in Albite 3

(download)

I've been working on a custom GUI for Albite 3 which would be a lot slicker, faster and far more useable than what J2ME provides by default. The graphics content mainly comes from Android 2.x, though there are some thematic touches from ICS.

Read the rest of this post »

Next project: a wireless driving wheel!

Ever wanted to use that mobile as a driving wheel? Or a keyboard? Touchpad? Well, why not?

Using your touchscreen and bluetooth connection, it would be possible to use your Java Mobile phone as:
  1. Wireless mini keyboard
  2. Wireless mini touchpad
  3. Wireless driving wheel (if the phone's got an accelerometer)
Have a look at those prototype images of the 'keyboard' and 'touchpad' modes. The code for the 'driving wheel' is also almost ready, though there's nothing to show at the moment.
The driving wheel will be available only for Windows through a virtual joystick driver: PPJoy. I've tried that and the driver was working just perfectly (even under Vista).

It is still a prototype, but I'm having high hopes that I'd finish it before the middle of January.

Read the rest of this post »

Albite READER

The Albite Project is finally ready!
  1. Albite READER is an ebook reader for Java Mobile that supports EPUB books and more.
  2. Albite BOOKS is the home of the reader where one could also find more than 2000 free ebooks from the public domain that have been specially processed to be read on mobile devices. It's got a mobile-friendly version, too.

Why storing resources right in the class file is so very bad

Let me tell you a story.

As I wanted to add good Unicode support in my J2ME Reader app, I needed some of the original functionality of the Character class and that wasn't hard to do using some sources from Java 1.3. While trying to rewrite as little as possible I ended up with a class that had three huge arrays defined right in the java file. These were a byte array, consisting of 1000 elements, a short array consisting of 4000 elements and an int array of 600 elements.

So where does the negative side come? Firstly, even tough my Samsung s5230 had no problems with the class, nor did the WTK emulator, Nokia S40 phones raised an OutOfMemoryException, even though they had memory to spare. So what was wrong? The class file was 44KB, and the actual data to load was 11KB, and therefore it needed a really little amount of memory (at least according to modern standards) to load the class.

The solution? Easy. Just load the data from a resource file. I did just that and everything started working again.

In conclusion: keeping resource data in external files is vital for compatibility. Apart from that, however, I also saved a few bytes. In other words: class files are not very efficient for storing large amounts of data.

Reading characters from encodings in J2ME, not supported natively supported by Java's InputStreamReader.

AlbiteStreamReader provides the ability to read characters from encodings, not supported natively supported by Java's InputStreamReader:

  1. UTF-8,
  2. ASCII,
  3. ISO-8859-1,
  4. ISO-8859-2,
  5. ISO-8859-3,
  6. ISO-8859-4,
  7. ISO-8859-5,
  8. ISO-8859-7,
  9. ISO-8859-9,
  10. ISO-8859-10,
  11. ISO-8859-13,
  12. ISO-8859-14,
  13. ISO-8859-15,
  14. ISO-8859-16,
  15. WINDOWS-1250,
  16. WINDOWS-1251,
  17. WINDOWS-1252,
  18. WINDOWS-1253,
  19. WINDOWS-1254,
  20. WINDOWS-1257,
  21. KOI8-R,
  22. KOI8-RU,
  23. KOI8-U
And it works in J2ME, too.

Sources & binaries can be found at github.

java.util.zip in J2ME

Well, as I'd been working on my ebook reader for the java mobile platform, and had decided upon having EPUB as the standard book format for it, I bumped into the problem of decompressing zip files in Java Mobile. Well, thanks to the guys from GNU (and, respectively, their Classpath project) and some minor modifications from my side, here goes the mobile version of java.util.zip. I've called it AlbiteZIP for it's actually implemented using the RandomReadingFile class from my API as a substitute for the original RandomAccessFile.

Source-code, binaries and javadoc, one can find at github. There is also a tiny readme there (i.e. two examples) about reading and writing zip files.

Of course, along with all, there are the other classes, too. That is, Checked streams and GZIP streams.

It's worth mentioning that after obfuscation, the lib is 42K big. And, after further obfuscation, it's very likely that it'll get even a bit smaller in one's project.

Cheers!

Random reading for J2ME

The lack of the RandomAccessFile class in J2ME's File API is quite a trouble when implementing something more advanced. It's especially true, if one needs to read some binary file in a more random way. So I made the AlbiteRandomReadingFile API in order to have some similar functionality.

The important part of the implemented functionality is in the ability to seek and obtain the pointer, i.e. the current position in the currently open file.

The RandomAccessFile class extends InputStream and implements DataInput and Connection interfaces.

It's based on the FileConnection from the File API. Unfortunately, there is no way to have effective seeking using this API, so seeking is actually achieved through opening the InputStream anew and skipping bytes (which itself isn't optimally implemented either, but that is not my fault). However, there is at least the fact, that some skipping can be avoided, if the seeking position is at or after the current position of the file pointer. In such cases the stream doesn't have to be reopened, and there is less bytes to skip. This optimization is integrated in the API.

Note that it's made for CLDC 1.1 and in order to make it work in CLDC 1.0, one has to remove the readDouble() and readFloat() methods.

The code is open source and is available at github (source code, obfuscated library and javadoc).

Hope it'll be useful to someone.

We need Your Support. Make a Donation now! or