Bob Ebert wrote:
>
> [...]
> In this case, note that we might have been able to leave it in, since it
> would have been sort of cool to briefly flash the display off to get
> attention or in some kind of game... but there was enough code out there
> that assumed the display would be readable with the backlight off that we
> HAD to no-op this out to make the device useable. <sigh>
>
> So now the cycle continues, and people writing cool hacky games for the
> IIIc will have to find some other way to flash the backlight. Then we'll
> have to figure out what THEY did and make sure IT doesn't break the NEXT
> product. The wheel of life turns on...
As you've presented this vicious cycle, the solution seems to present
itself quite easily. If you allow a method of accessing each device's
hardware specifics and present it as an official--even a pseudo-official--
method, then code that would be considered "hacky" by current standards
would become standard. I'm currently delaying porting a hack to the 3.5
API's until a method for toggling the backlight becomes available, and I'd
rather not tweak the hardware directly.
The only reason hacky-code exists is because it's not supported in the
first place. With some measure of support, you instantly remove the need
to be hacky.
[from another post WRT compability among devices that share API's]
> I'm open to suggestions.
It doesn't seem infeasible IMHO to provide a hardware library with
each device that provides code access to that device's specific hardware
requirements. For example, PalmV's would have access to the contrast
hardware, IIIc's would provide access to the brightness setting, etc.
I believe app authors have learned to determine which device they're
running on before attempting to access device hardware, thanks to a lot
of (cough) encouragement from Palm (thanks, David ;). With more support
for device internals irresponsible code could be eliminated altogether.
Best regards,
Daniel.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html