And how many special case HW/SW pair specific statements switches are in there? At least 100+ and growing.
If you gave me code with multiple switch statements 100 cases long that needed to be updated whenever a new hardware/software combo was released I'd either cry or slap you up side the head. Probably both
Every problem has a solution... and the strategy pattern is strong in this one my child.
Um yeah. I''l take that comment as evidence I've hit a nerve.
No, not a nerve. You're just annoying, frustrating, and pathetic. Can you point to a statement by the Tweetdeck developers discussing per-platform tweaks? Did you download the Tweetdeck .apk and examine the dex files? In other words, do you have any actual evidence that per-device customization was necessary?
No, you don't have any such evidence. Of course, this won't stop you from making baseless claims. I'm done responding to you unless you can provide evidence.
If you gave me code with multiple switch statements 100 cases long that needed to be updated whenever a new hardware/software combo was released I'd either cry or slap you up side the head. Probably both
Every problem has a solution... and the strategy pattern is strong in this one my child.
Just because there is at least one difference between a pair to switch between doesn't mean there are 100 differences in every place. Your example is theoretically the worst case, but so unlikely as to be laughable. Worthless to use except as a poor means of trying to make the problem appear smaller than it is.
That's hardly the kind of mistake I would expect an "elder" to make if they actually stopped long enough to think it through or had any actual experience dealing with the messiness of real variable hardware. Kinda glad an "elder" like you isn't working for a "child" like me, because it's a sad thing when the "elder" shows the "child" disdain for solving the problem by trying to be trite and overbearing. Shall we dispense with the poorly executed place-putting, screw our heads back into place and actually examine the problem rather than try to be cutesy?
The real problem is you have small differences all over the place. And those differences will often have cross dependencies. Maybe you can cover many of them via the strategy pattern, but those cross dependencies will make it difficult to get the rest cleanly; now you are back to adding conditionals or switch statements anyway. It's a mess. And now project how many combinatoric combinations of strategy based classes and methods you might need. Gee that might even entail a ton of duplicated code if we are't careful -- man, now we have to encapsulate more code out of the strategy satisfying duplicates into another set of classes. It does not take long for a blind application of patterns to generate an architectural nightmare where you can't keep track of what's doing what. When you have LOTS of special cases to handle it's never as simple as the solution you propose reads. You tradeoff pure OO-design which may be generating architectural messiness against the smaller and less invasive special casing. Assess which makes the most sense where and then implement (usually both flavors) in a mess like this. There isn't an architecture or pattern book anywhere on Earth that will tell you otherwise -- they all tell you that you have to use you head, not always blindly follow a textbook pattern where it doesn't fit well.
And just the fact you have to whip out the strategy pattern (or any other pattern) not to support your core functionality (where it would make sense) but to handle low level deficiencies in the hardware abstraction layer, to do so in multiple places and -- to support a generic app written against one operating system -- says you have a fragmentation issue going on.
Desktop game developers complain about this at times with the various GPUs they need to support. But at least they are already dealing with a voluntary and easily changeable piece of hardware so the fragmentation is acknowledged and embraced by them before they even start. CUDA and OpenCL are growing together and starting to look a lot like an "uber" OpenGL, all to reduce that hardware fragmentation exposed at the application level. Even then the games devs only deal with maybe a dozen well publicized feature lists and the dev is the one that gets to choose which profiles they want to support. In the Android phone biz, you are stuck with all 100+ of them or you get a black eye fast.
No, not a nerve. You're just annoying, frustrating, and pathetic. Can you point to a statement by the Tweetdeck developers discussing per-platform tweaks? Did you download the Tweetdeck .apk and examine the dex files? In other words, do you have any actual evidence that per-device customization was necessary?
No, you don't have any such evidence. Of course, this won't stop you from making baseless claims. I'm done responding to you unless you can provide evidence.
Well if you rule out implication and implied statements you can try to make your case. But that's not living in the real world. Most folks read the blog as a huge riotous mishmash of doublespeak.
Lets see: the blog headline:
Quote:
Android Ecosystem Infoporn Overload
Hmmm. Seems like they don't like that at all.
Quote:
We were really shocked to see the number of custom roms, crazy phones and general level of customization/hackalicious nature of Android.
That very tidily fits the definition of fragmentation, whether you like it or not. Try to distract with avoidance of nightmares and such, but it's still fragmentation.
I'm not going to post the two pie charts, but they scream fragmentation too. It all had to be dealt with, whether they wanted to or not. The public happy face the VP put on it was his public happy face -- good for him. But that still didn't change the fact that they had to manage it and that cost $$ and time. Feel free to ignore reality, that's your option.
Comments
And how many special case HW/SW pair specific statements switches are in there? At least 100+ and growing.
You have zero evidence of this. It's pure speculation. Did the Tweetdeck dev's ever say that they had to add any per-device hacks?
I see this is what you resort to -- when your arguments are rebuked, you just make stuff up. How pathetic.
You have zero evidence of this. It's pure speculation. Did the Tweetdeck dev's ever say that they had to add any per-device hacks?
I see this is what you resort to -- when your arguments are rebuked, you just make stuff up. How pathetic.
And how many special case HW/SW pair specific statements switches are in there? At least 100+ and growing.
If you gave me code with multiple switch statements 100 cases long that needed to be updated whenever a new hardware/software combo was released I'd either cry or slap you up side the head. Probably both
Every problem has a solution... and the strategy pattern is strong in this one my child.
No, not a nerve. You're just annoying, frustrating, and pathetic. Can you point to a statement by the Tweetdeck developers discussing per-platform tweaks? Did you download the Tweetdeck .apk and examine the dex files? In other words, do you have any actual evidence that per-device customization was necessary?
No, you don't have any such evidence. Of course, this won't stop you from making baseless claims. I'm done responding to you unless you can provide evidence.
If you gave me code with multiple switch statements 100 cases long that needed to be updated whenever a new hardware/software combo was released I'd either cry or slap you up side the head. Probably both
Every problem has a solution... and the strategy pattern is strong in this one my child.
Just because there is at least one difference between a pair to switch between doesn't mean there are 100 differences in every place. Your example is theoretically the worst case, but so unlikely as to be laughable. Worthless to use except as a poor means of trying to make the problem appear smaller than it is.
That's hardly the kind of mistake I would expect an "elder" to make if they actually stopped long enough to think it through or had any actual experience dealing with the messiness of real variable hardware. Kinda glad an "elder" like you isn't working for a "child" like me, because it's a sad thing when the "elder" shows the "child" disdain for solving the problem by trying to be trite and overbearing. Shall we dispense with the poorly executed place-putting, screw our heads back into place and actually examine the problem rather than try to be cutesy?
The real problem is you have small differences all over the place. And those differences will often have cross dependencies. Maybe you can cover many of them via the strategy pattern, but those cross dependencies will make it difficult to get the rest cleanly; now you are back to adding conditionals or switch statements anyway. It's a mess. And now project how many combinatoric combinations of strategy based classes and methods you might need. Gee that might even entail a ton of duplicated code if we are't careful -- man, now we have to encapsulate more code out of the strategy satisfying duplicates into another set of classes. It does not take long for a blind application of patterns to generate an architectural nightmare where you can't keep track of what's doing what. When you have LOTS of special cases to handle it's never as simple as the solution you propose reads. You tradeoff pure OO-design which may be generating architectural messiness against the smaller and less invasive special casing. Assess which makes the most sense where and then implement (usually both flavors) in a mess like this. There isn't an architecture or pattern book anywhere on Earth that will tell you otherwise -- they all tell you that you have to use you head, not always blindly follow a textbook pattern where it doesn't fit well.
And just the fact you have to whip out the strategy pattern (or any other pattern) not to support your core functionality (where it would make sense) but to handle low level deficiencies in the hardware abstraction layer, to do so in multiple places and -- to support a generic app written against one operating system -- says you have a fragmentation issue going on.
Desktop game developers complain about this at times with the various GPUs they need to support. But at least they are already dealing with a voluntary and easily changeable piece of hardware so the fragmentation is acknowledged and embraced by them before they even start. CUDA and OpenCL are growing together and starting to look a lot like an "uber" OpenGL, all to reduce that hardware fragmentation exposed at the application level. Even then the games devs only deal with maybe a dozen well publicized feature lists and the dev is the one that gets to choose which profiles they want to support. In the Android phone biz, you are stuck with all 100+ of them or you get a black eye fast.
No, not a nerve. You're just annoying, frustrating, and pathetic. Can you point to a statement by the Tweetdeck developers discussing per-platform tweaks? Did you download the Tweetdeck .apk and examine the dex files? In other words, do you have any actual evidence that per-device customization was necessary?
No, you don't have any such evidence. Of course, this won't stop you from making baseless claims. I'm done responding to you unless you can provide evidence.
Well if you rule out implication and implied statements you can try to make your case. But that's not living in the real world. Most folks read the blog as a huge riotous mishmash of doublespeak.
Lets see: the blog headline:
Android Ecosystem Infoporn Overload
Hmmm. Seems like they don't like that at all.
We were really shocked to see the number of custom roms, crazy phones and general level of customization/hackalicious nature of Android.
That very tidily fits the definition of fragmentation, whether you like it or not. Try to distract with avoidance of nightmares and such, but it's still fragmentation.
I'm not going to post the two pie charts, but they scream fragmentation too. It all had to be dealt with, whether they wanted to or not. The public happy face the VP put on it was his public happy face -- good for him. But that still didn't change the fact that they had to manage it and that cost $$ and time. Feel free to ignore reality, that's your option.
Best Buy Xoom pre-orders
.... Try $ 1200.00 !
best buy xoom pre-orders
bump!
bump!
Don't. We already know and there's nothing more to add.
Don't.
Too late.
A little presumptuous aren't we?
Too late.
A little presumptuous aren't we?
You continue to add zero useful information to the conversation, and no one else has, either.
I wouldn't say so. Instead of replying to me about it, let's stop the madness right here.