Which, as stated before, didn't look like one.
True, the midlet would die on me when the GPS was forcefully disconnected ... but isn't that what midlets do? You take away their bluetooth connection, they die, right?
Wrong, apparently. And it wouldn't make sense, too - why should an application die just because of lost bluetooth connection?
For some reason, i started thinking about it yesterday, spent a good hour googling for the explanation and found none, so i finally gathered my courage and posted a question on SonyEricsson developer forums.
First answer solved my problem.
Two lessons to be learned here, apart from the "if google doesn't know that a problem exists, there's something wrong with the problem"...
First, Exception isn't the root of all that can go wrong. Throwable is. Replacing my Exception handling code to handle all Throwables revealed that there actually is a Throwable being thrown, and it's an OutOfMemory one.
Which also explained why the application died - when an OutOfMemory condition happens, dying is the sane thing to do. (Really. Trust me on this one.)
And second... well, not really that much of a lesson, except maybe "don't trust (foreign) code, even if you read it and thought that it's fine". That OutOfMemory was caused by a loop that continuously read from the bluetooth link and saved results into a ByteArrayOutputStream (which was rather stupid thing to do in itself, but oh well), until it found a newline.
Except that when the link died, stream did not vanish (that was handled, but honestly, what would you think if a stream just vanished from under your program? i wouldn't write something like that, but when i was reading it, it looked like proper error handling) and instead started reporting "end of stream". Which it did by returning -1.
The loop happily filled the byte array with -1's and happily ran out of memory in the middle of doing that.
Simple bug, simple fix.
Once you realize that it is a bug and not a status quo.
October 6, 2008
bitrot
Last time i did something with openWIG, it was a rather nifty little midlet that did some cool stuff.
When i fired it up today, it didn't do anything. Plus it seemed that it only has parts of my most recent work. Or something.
Apparently, it has gone bitrotten from not being touched in few months. I'll have to dust it off, clean it up, look for the missing parts on my laptop and push out a version.
In other news, i've fixed the bug where the midlet would die instantly if you disconnect the GPS. Funny thing, i never thought that it's a bug in the application, i thought that it's just the way things are. Oh well.
When i fired it up today, it didn't do anything. Plus it seemed that it only has parts of my most recent work. Or something.
Apparently, it has gone bitrotten from not being touched in few months. I'll have to dust it off, clean it up, look for the missing parts on my laptop and push out a version.
In other news, i've fixed the bug where the midlet would die instantly if you disconnect the GPS. Funny thing, i never thought that it's a bug in the application, i thought that it's just the way things are. Oh well.
July 24, 2008
anti-iPhone-DRM campaign
I'm a DefectiveByDesign subscriber, because I have a strong distaste for DRM.
Recently, DefectiveByDesign launched a campaign against iPhone, and generally, they fight against iPod and Apple products, because of the DRM employed in them.
Well.
You know what's sad?
Apple products rock. Seriously, they do. Did you ever hold an iPhone? Touched it? Typed on its wonderful multitouch-aware onscreen keyboard? That thing is damn sexy. And it Just Works (tm). And it's precise. There is no other device with the same degree of input precision on a touchscreen (yes, that is because of the multitouch capability, i.e. completely different principle of touch recognition), few devices with built-in gyrostat to detect device tilt, and none of them use it as well as iPhone does.
I mean, yes, there are "alternatives". They might be more powerful, more open, more compatible, better engineered or whatever.
And none of them holds a candle to iPhone's amazing usability and user experience. Plus, none of them can help you pick up chicks. iPhone can. Because iPhone is sexy.
I have a Cowon D2 player and i wouldn't trade it for an iPod. It has longer battery life, plays basically any format you throw at it, has a true DSP, works as mass storage, its firmware is updated regularly, blah, blah. Oh, and a touchscreen, of course. Yes, it outfeatures iPod in almost everything you can think of. But it's nowhere near as sexy.
And tell you what, average joe user does not give a rat's ass about features of D2. He has his Windows (or Mac) box with songs in mp3 format, and all he wants from a player is to actually play those songs. iPod does, and it does it sexy. Massively sexy.
I could go on for hours and hours about how Apple inovates while looking good. We all know it's true, even though some of us deny it. (Perhaps they are not Apple's original ideas, but it's Apple who shows them to the unwashed mass.)
The folks at DBD can bitch all they want, and they are right. The iPod and iPhone are bad, because they are all locked down and DRMed and stuff.
What is sad is that no other manufacturer takes on the challenge! Show me a single phone as cool as the iPhone. Show me a single player as cool as the iPod. Tell you what, there is none. iRiver Clix2 gets close, but not close enough.
DBD wants to pressure Apple into unlocking - "if you don't unlock, we'll go to the competition".
But the fact is that we won't, because iPhone is so damn cool.
Why, oh why, doesn't somebody pressure the competition into outsexying Apple?
Recently, DefectiveByDesign launched a campaign against iPhone, and generally, they fight against iPod and Apple products, because of the DRM employed in them.
Well.
You know what's sad?
Apple products rock. Seriously, they do. Did you ever hold an iPhone? Touched it? Typed on its wonderful multitouch-aware onscreen keyboard? That thing is damn sexy. And it Just Works (tm). And it's precise. There is no other device with the same degree of input precision on a touchscreen (yes, that is because of the multitouch capability, i.e. completely different principle of touch recognition), few devices with built-in gyrostat to detect device tilt, and none of them use it as well as iPhone does.
I mean, yes, there are "alternatives". They might be more powerful, more open, more compatible, better engineered or whatever.
And none of them holds a candle to iPhone's amazing usability and user experience. Plus, none of them can help you pick up chicks. iPhone can. Because iPhone is sexy.
I have a Cowon D2 player and i wouldn't trade it for an iPod. It has longer battery life, plays basically any format you throw at it, has a true DSP, works as mass storage, its firmware is updated regularly, blah, blah. Oh, and a touchscreen, of course. Yes, it outfeatures iPod in almost everything you can think of. But it's nowhere near as sexy.
And tell you what, average joe user does not give a rat's ass about features of D2. He has his Windows (or Mac) box with songs in mp3 format, and all he wants from a player is to actually play those songs. iPod does, and it does it sexy. Massively sexy.
I could go on for hours and hours about how Apple inovates while looking good. We all know it's true, even though some of us deny it. (Perhaps they are not Apple's original ideas, but it's Apple who shows them to the unwashed mass.)
The folks at DBD can bitch all they want, and they are right. The iPod and iPhone are bad, because they are all locked down and DRMed and stuff.
What is sad is that no other manufacturer takes on the challenge! Show me a single phone as cool as the iPhone. Show me a single player as cool as the iPod. Tell you what, there is none. iRiver Clix2 gets close, but not close enough.
DBD wants to pressure Apple into unlocking - "if you don't unlock, we'll go to the competition".
But the fact is that we won't, because iPhone is so damn cool.
Why, oh why, doesn't somebody pressure the competition into outsexying Apple?
July 12, 2008
f**king firefox 3
In case you wondered why, all of sudden, you can't use Home key to go to top of page, wonder no longer. There is a setting under preferences -> advanced -> general -> accessibility, called something along the lines of "use caret to move around the page" (Not sure about exact english variant, i have only czech translation. It's the first checkbox, anyway.)
For some f**ked up reason, this seems to be checked by defaut. At least on Linux, at least on imported pre-3 profiles.
Go ahead and uncheck the f**king thing for good! Bam there goes the caret, and your old & faithfull Home key brings you to the top of the page.
I can't believe how glad i am for having found this.
For some f**ked up reason, this seems to be checked by defaut. At least on Linux, at least on imported pre-3 profiles.
Go ahead and uncheck the f**king thing for good! Bam there goes the caret, and your old & faithfull Home key brings you to the top of the page.
I can't believe how glad i am for having found this.
May 27, 2008
four quick notes about j2me
one: Obfuscation must be handled with care.
If you choose to obfuscate your midlet, you gain two things: the final size will be reduced, and the contents will be hard to disassemble.
But. If you turn on obfuscation in NetBeans, it will be used for your local debug builds as well. Due to that, you will lose debugging information, notably filenames and line numbers in stack traces.
two: Version strings must be handled with care.
My phone (SE K610i) refused to install a midlet with version "0.2.991", or anything longer than 6 characters. A different phone (Siemens CX65) installed a midlet with version "0.2.99sync1", which then mysteriously crashed with a NullPointerException that wasn't there with version "0.2.99".
This is bad magic. If anyone can explain it, please do.
three: From what i gathered, there is no way to list files contained in a JAR at runtime.
If you want to do that, create a text index at compile time and include it in a known location.
and four: Some older phones, even though MIDP 2.0, don't call Canvas.sizeChanged event.
Or maybe they do, but not (citing the spec) "at least once before the
So don't rely on it.
If you choose to obfuscate your midlet, you gain two things: the final size will be reduced, and the contents will be hard to disassemble.
But. If you turn on obfuscation in NetBeans, it will be used for your local debug builds as well. Due to that, you will lose debugging information, notably filenames and line numbers in stack traces.
two: Version strings must be handled with care.
My phone (SE K610i) refused to install a midlet with version "0.2.991", or anything longer than 6 characters. A different phone (Siemens CX65) installed a midlet with version "0.2.99sync1", which then mysteriously crashed with a NullPointerException that wasn't there with version "0.2.99".
This is bad magic. If anyone can explain it, please do.
three: From what i gathered, there is no way to list files contained in a JAR at runtime.
If you want to do that, create a text index at compile time and include it in a known location.
and four: Some older phones, even though MIDP 2.0, don't call Canvas.sizeChanged event.
Or maybe they do, but not (citing the spec) "at least once before the
Displayable is shown for the first time." [here] Or maybe they even do that, but don't specify the proper size.So don't rely on it.
May 22, 2008
openWIG status report
Version 0.2.99 was released sometime this night, as opposed to what I wrote last week.
It has pretty navigation and crude but functional reading from filesystem. Everything important is on the project page, follow the link on your right.
...oh, and did I mention that we can now decode the GWC format? Well, we can. Feel free to load your memory card with cartridges and head outside.
It has pretty navigation and crude but functional reading from filesystem. Everything important is on the project page, follow the link on your right.
...oh, and did I mention that we can now decode the GWC format? Well, we can. Feel free to load your memory card with cartridges and head outside.
good news about j2me's I/O
Well yes, it is horrible, but not nearly as horrible as I originally thought.
Once again, I misinterpreted a part of the spec. You do need to reopen the InputStream if you want to seek() back, that's true, but. If you keep a FileConnection object for the file in question, you can call getInputStream() on it as many times as you want - the security prompt is shown only for first access, then the phone is supposed to remember that you already have permission to do that (and it appears that many (if not most) phones actually adhere to this).
I assume that this holds true for other functions on a FileConnection as well, but I didn't test that yet.
Oh, and that RMS caching idea I had was slow and stupid.
Once again, I misinterpreted a part of the spec. You do need to reopen the InputStream if you want to seek() back, that's true, but. If you keep a FileConnection object for the file in question, you can call getInputStream() on it as many times as you want - the security prompt is shown only for first access, then the phone is supposed to remember that you already have permission to do that (and it appears that many (if not most) phones actually adhere to this).
I assume that this holds true for other functions on a FileConnection as well, but I didn't test that yet.
Oh, and that RMS caching idea I had was slow and stupid.
Subscribe to:
Posts (Atom)