The following distinctions might be useful:
what can be installed via the amazon store (by a regular, simple user)
what can be installed by rooting (by an intermediate user) then via the google store after loading that store to the Fire
what can be done by rooting and installs via shell or indie app stores (care-free tech savvy users)
and, the anything goes category via complete reinstalls (hack-the-device users, which also requires basic dev knowledge to install prewritten software, or a really good installer).
To use the device features most directly and most easily installable, best write the most easily installed GUI app, and that's one which will be on the regular Android app store. The best minimal design approach using my suggestion would be to build basic analog-only hardware circuits, then allow the progressive stream of lower cost tablets (un-modified, plus a simple app store install) -- that's the design boundary which constantly evolves to better capabilities at lower price points-- to be the user-facing front panel of the analog sensors and circuitry. The idea of *tactile electronic paper* is an old one, this is just a price-sensitive realization of that concept, and in the future, implementing voice controls. The open question today is if it requires hardware hacking to couple the interface cleanly. Building well-working prototypes for home hacking is one occupation, while building near ready-made product is another. An embedded project works great as long as you remember the technical details of how to use it by tweaking the project-specific knobs, and after a year of forgetfulness, the developer is the same as an uninformed user. Web apps are never as good as native apps by definition, whether locally served or remote. Installing a local web server to act with a browser as an interface is a common avoidance technique instead of learning the platform-specific GUI development software. It's better to write the native GUI app and then allow exporting the data to a data cloud somewhere.
I may be the odd one out, however I don't want to use a personal smartphone in a lab as an instrument, whether it's physically plugged into a device or by browsing to a web device (unless it's for status notifications). Even if I owned a smartphone, which I don't. I like where WebI2C has been going, it's been a work in progress for a while, though the proof will be in the browsers (coupled with both the hardware support and O/S support). It should be noted that there is no way to query I2C devices on an address bus, I mean, it is not communication for arbitrary plug-and-play, the communication is designed for purpose-built hardware only, so any web apps would have to ask the browser which would have to ask the O/S which devices exist and what their device addresses are; and hardware-hacking a new device on the chain won't make it magically available to the web app if the O/S doesn't know it's there.
what can be installed via the amazon store (by a regular, simple user)
what can be installed by rooting (by an intermediate user) then via the google store after loading that store to the Fire
what can be done by rooting and installs via shell or indie app stores (care-free tech savvy users)
and, the anything goes category via complete reinstalls (hack-the-device users, which also requires basic dev knowledge to install prewritten software, or a really good installer).
To use the device features most directly and most easily installable, best write the most easily installed GUI app, and that's one which will be on the regular Android app store. The best minimal design approach using my suggestion would be to build basic analog-only hardware circuits, then allow the progressive stream of lower cost tablets (un-modified, plus a simple app store install) -- that's the design boundary which constantly evolves to better capabilities at lower price points-- to be the user-facing front panel of the analog sensors and circuitry. The idea of *tactile electronic paper* is an old one, this is just a price-sensitive realization of that concept, and in the future, implementing voice controls. The open question today is if it requires hardware hacking to couple the interface cleanly. Building well-working prototypes for home hacking is one occupation, while building near ready-made product is another. An embedded project works great as long as you remember the technical details of how to use it by tweaking the project-specific knobs, and after a year of forgetfulness, the developer is the same as an uninformed user. Web apps are never as good as native apps by definition, whether locally served or remote. Installing a local web server to act with a browser as an interface is a common avoidance technique instead of learning the platform-specific GUI development software. It's better to write the native GUI app and then allow exporting the data to a data cloud somewhere.
I may be the odd one out, however I don't want to use a personal smartphone in a lab as an instrument, whether it's physically plugged into a device or by browsing to a web device (unless it's for status notifications). Even if I owned a smartphone, which I don't. I like where WebI2C has been going, it's been a work in progress for a while, though the proof will be in the browsers (coupled with both the hardware support and O/S support). It should be noted that there is no way to query I2C devices on an address bus, I mean, it is not communication for arbitrary plug-and-play, the communication is designed for purpose-built hardware only, so any web apps would have to ask the browser which would have to ask the O/S which devices exist and what their device addresses are; and hardware-hacking a new device on the chain won't make it magically available to the web app if the O/S doesn't know it's there.
## Jonathan Cline ## jcline@ieee.org ## Mobile: +1-805-617-0223 ########################On 12/3/15 4:21 PM, Bryan Bishop wrote:
On Thu, Dec 3, 2015 at 6:10 PM, Nathan McCorkle <nmz787@gmail.com> wrote:
I've never implemented any of the Android app ideas because of this. I
just can't remember how to do it, and when I have a cool idea, I can't
I seem to have entered into an alternate universe where Jonathan and Nathan have both forgotten everything they know about software. Amazon Fire and other Android tablets can run debian chroots and a number of other alternatives are possible with the android kernel kvm branch. You don't need to write Android apps to use an originally-Android device. Your flask web application can just as easily run in an chroot under Android as er, I guess you were wanting to run python stuff on an Arduino but not sure.
Additionally, if you really preferred the embrace of the web and web browsers for some reason, there are some WebGPIO and WebI2C standards floating around:
0 comments:
Post a Comment