I was thinking about our various of expectations or different devices to be able to: 1. suck it up and use what i'm given (my microwave or smoke detector) 2. write programs for a device but with a hefty license fee and controlled distribution (Nintendo Wii etc.) 3. write programs for a device and controlled distribution (Apple iPhone) 4. write programs and distribute any old how 5. replace the operating system and remain within warranty (hardcore FSS people) 6. code to non public APIs 7. create background tasks, interfere with other apps, flatten the battery and annoy the user unexpectedly
We as developers might not like it because we are used to having such control. And it seems like i'm siding with Apple on their controlling behaviour, but I'm just trying to suggest we think of these devices as what they are. Consumer appliances. But I do agree with Josh that the concern is that the devices become more important over time and take over the roll of desktop machines (iPad is good example). Now while I see the risks, I do think developers can't just assume they are going to write desktop apps with a smaller GUI. Maybe the answer is to solve the technical concerns, not just ignore them. Maybe the answer to background tasks is to make it a first class concept and put limits around it. Say, the phone can support 5 apps with background tasks and each can only use x% of CPU and memory. Then ensure that every app is tested with only 100-(5*x)% of resources. I don't know I just made that up. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
