Unintentional object retention. I think that is the official name of the problem. It occurs with managed languges. You have a big application with hunderts of objects referencing each other, it's inevidable that you will forget to null out a reference somewhere. (and by the way this is not exclusively a problem of event handlers, it can happen anywhere). The solution it to use weak references. When I switched from c++ to java, it seemed very obvious to me that this would happen, I just assumed that all experienced coders were using weak references. Out of curiousity, I asked on the forums how many people use weak references, the answer was "what is a weak reference?". Then I explained it's to prevent weak references, they just laughed at me: "dude, we have a garbage collector, we don't have to worry about memory leaks"
Android is a great idea, but the more I hear about it the more it's looking like a heavy weight OS more suitable for bulky PDA-type phones. That would ristrict it to a niche market. Don't think Android will every be able to run on lower mid range phones like Nokia and Sony ericsson are producing now (thinking along the lines of SE K610, or Nokia 6131)... cheap, powerful, slim line phones like this are going to rule the market
Yeah, there's pontentially one or two Hezbollah in a crowded hospital, so the only thing to be done is to bomb the whole building and then it's Hezbollah's fault
The core J2ME API was made by several commities and "evolved" rather than was designed. Those commities were controlled by the operertors who were more concerned about using the API to generator revenue for themselves than advancing technology. Google is right in starting from scratch rather than building on J2ME. However, some extension apis are rather well designed (for instance bluetooth and mg3), it would be not be a bad way to re-use those apis.
(1) It doesn't come with java libraries, they have written their own framework. It pretty big though... I count 2000 classes.
(2) You need a bit of patience to learn eclipse. Don't try to learn it without reading the tutorial. Once you get over the learning curve you probaly will like it.
(3) Yeah, that annoys me too, but only minor annoyance.
If they say bytecode interpreter then they are probably not using jazelle, which is a pity. Jazelle runs java byte code natively on the processor and is much faster than any interpreter. And of coarse it's ARM, practically all mobile devices run on some sort of ARM derived processor (OMAP, XScale, Qualcomm are all ARM based)
> what choice did they have? Umm, openMoko, Symbian, Linux? You discount Symbian and Linux so quickly. While Symbian isn't great, it's not as bad as MS mobile (you don't get those riduclous error messages and unnecesary confirmation prompts for instance.) As regards price, if you don't spend on software then the software on your phone is going to suck. That's all what the artical is about... the software sucks because they didn't want to spend money or effort on it
This restiction is only for operator supplied handsets in the US. In Europe the operators don't do this. If you want to write a multiply player game that uses bluetooth, for instance, you need a certificate supplied from the operator before your midlet will run.
Maybe Mr. Forsyth should keep quite considering considering how slow, buggy and badly designed the symbian OS is. Nokias system 40 phones make their own symbian models look bad. For instance, the 6131 is a lot faster and user friendly than the N73, which is ironic considering how much more expensive it is. Its always been this way. Symbian phones have always been slower and more bug riddled than ones with equivilant hardware.
I'm thinking more of the scripting languages that don't require you to declare a variable before you use it. One subtle typo in a variable name and you can spend hours searching for the bug.
> It's a bitchy language for newbies, because it's unforgiving of the most meek typos.
Pity the newbies can't see that it's better to have compile errors rather than run time errors. Scripting languages appear easier, but try writing a big application with them and you'll see the real value strict rules
For those of you that think that Ajax is the new next generation platform, let's just things in prospective. Ajax is one single function: XMLHttpRequest, a extension to the browser DOM invented by MS. In other words its a propierty hack on the browser API, nothing more.
You're right about the unbundling of WMP. But the EU worked closly with the Samba team so that MS wouldn't try to put any trick loopholes in the agreement. Doesn't matter who funds Samba, they don't sell their software for profit.
The word "explain" normally means that at the end of the explaination the reader should understand it. Sorry, but what you've written is totally unintelliglible to any lay person
Unintentional object retention. I think that is the official name of the problem. It occurs with managed languges. You have a big application with hunderts of objects referencing each other, it's inevidable that you will forget to null out a reference somewhere. (and by the way this is not exclusively a problem of event handlers, it can happen anywhere).
The solution it to use weak references.
When I switched from c++ to java, it seemed very obvious to me that this would happen, I just assumed that all experienced coders were using weak references. Out of curiousity, I asked on the forums how many people use weak references, the answer was "what is a weak reference?". Then I explained it's to prevent weak references, they just laughed at me: "dude, we have a garbage collector, we don't have to worry about memory leaks"
Apparently this works on Windows XP too: http://www.windowsxlive.net/?p=1337
Wow. A nation of gadget freaks
Android is a great idea, but the more I hear about it the more it's looking like a heavy weight OS more suitable for bulky PDA-type phones. That would ristrict it to a niche market.
Don't think Android will every be able to run on lower mid range phones like
Nokia and Sony ericsson are producing now (thinking along the lines of SE K610, or Nokia 6131)... cheap, powerful, slim line phones like this are going to rule the market
Yeah, there's pontentially one or two Hezbollah in a crowded hospital, so the only thing to be done is to bomb the whole building and then it's Hezbollah's fault
> army fighting by the rules, against an enemy that did not
neither side fought by the rules. The Israel dropped cluster bombs on hospitals and residentual areas, which is clearly against the rules:
http://www.boston.com/news/world/middleeast/articles/2006/10/13/unexploded_bombs_sow_fear_in_lebanon/
The core J2ME API was made by several commities and "evolved" rather than was designed. Those commities were controlled by the operertors who were more concerned about using the API to generator revenue for themselves than advancing technology. Google is right in starting from scratch rather than building on J2ME.
However, some extension apis are rather well designed (for instance bluetooth and mg3), it would be not be a bad way to re-use those apis.
(1) It doesn't come with java libraries, they have written their own framework. It pretty big though... I count 2000 classes.
(2) You need a bit of patience to learn eclipse. Don't try to learn it without reading the tutorial. Once you get over the learning curve you probaly will like it.
(3) Yeah, that annoys me too, but only minor annoyance.
The Marketing cost does not have anything to do with the OS behind the phone - the user will not even know what the OS is.
If they say bytecode interpreter then they are probably not using jazelle, which is a pity. Jazelle runs java byte code natively on the processor and is much faster than any interpreter.
And of coarse it's ARM, practically all mobile devices run on some sort of ARM derived processor (OMAP, XScale, Qualcomm are all ARM based)
Yeah, that would justify destroying the entire companies customer data
It might be worth checking out the device called "sexy vixen" appearing now in the bluetooth radar:
http://www.bluetoothtracking.org/livedata.php
> what choice did they have?
Umm, openMoko, Symbian, Linux?
You discount Symbian and Linux so quickly.
While Symbian isn't great, it's not as bad as MS mobile (you don't get those riduclous error messages and unnecesary confirmation prompts for instance.)
As regards price, if you don't spend on software then the software on your phone is going to suck. That's all what the artical is about... the software sucks because they didn't want to spend money or effort on it
This restiction is only for operator supplied handsets in the US. In Europe the operators don't do this.
If you want to write a multiply player game that uses bluetooth, for instance, you need a certificate supplied from the operator before your midlet will run.
Maybe Mr. Forsyth should keep quite considering considering how slow, buggy and badly designed the symbian OS is.
Nokias system 40 phones make their own symbian models look bad. For instance, the 6131 is a lot faster and user friendly than the N73, which is ironic considering how much more expensive it is. Its always been this way. Symbian phones have always been slower and more bug riddled than ones with equivilant hardware.
I'm thinking more of the scripting languages that don't require you to declare a variable before you use it. One subtle typo in a variable name and you can spend hours searching for the bug.
The answer is simple: It hasn't been released yet. Expect a price change on the GTS when it does get released.
> It's a bitchy language for newbies, because it's unforgiving of the most meek typos.
Pity the newbies can't see that it's better to have compile errors rather than run time errors. Scripting languages appear easier, but try writing a big application with them and you'll see the real value strict rules
Apple know that it's wrong to make so much from the iPhone and they are going to donate half the profits back to charity shortly
I thought SSDs are slower than regular disk drives when making lots of small writes (like when you're installing software, for instance)
http://en.wikipedia.org/wiki/Solid_state_drive#Disadvantages
For those of you that think that Ajax is the new next generation platform, let's just things in prospective.
Ajax is one single function: XMLHttpRequest, a extension to the browser DOM invented by MS. In other words its a propierty hack on the browser API, nothing more.
You're right about the unbundling of WMP. But the EU worked closly with the Samba team so that MS wouldn't try to put any trick loopholes in the agreement. Doesn't matter who funds Samba, they don't sell their software for profit.
The word "explain" normally means that at the end of the explaination the reader should understand it. Sorry, but what you've written is totally unintelliglible to any lay person
> at a bulk level - Each individual block still takes longer, but unlike HDDs you can basically read/write every block in the device at once
yes, but unfortunately software (for instance an installation program) makes lots of small individual writes, rather than one big one
He's taling about poor write speeds in comparison to regular disk drives.
http://en.wikipedia.org/wiki/Solid_state_drive#Disadvantages
"Slow random write speeds - as erase blocks on SSDs generally are quite large, they're far slower than conventional disks for random writes."