Bit of a mess though. They somehow managed to make a fairly simple (but still a bit weird) library - libusb - into something less than the sum of it's parts (discordant vs syngergistic?). And then you add to that the complex life-cycle of an android app and things get pretty nasty.
Some pretty weird shit to deal with:
- If you don't set the app as the default handler for the device, then you get permission popups which mean you have to put the connect logic in the resume method otherwise nothing works.
- But if it is defaulted, ... then you don't get permission popups, and therefore resume is not called at the right time.
- If you tell a connected device to go into accessory mode, you get a device disconnected message, which sort of makes sense ...
- ... but you don't get a connected message for the accessory device.
- And if you subsequently list the devices connected to the system, a device is still listed with the same vendor id + device id (this is wrong, the device should have changed at this point) ...
- ... but that "device" isn't the same as the "device" you started with.
- And there seems to be no "reliable" way to determine if you have the accessory interface, or the MTP interface (on the machine i'm testing with). (well maybe testing using a no side-effect valid request which fails could be used here).
- If the device rotates it destroys the application ... leaving everything in an unknown state.
- Sometimes nothing works anyway, and the apps on both end need killing.
- The documentation is a bit shit, and amounts to "the [outdated] source is the documentation". And that relies on a USB library which doesn't fudge the device id.
But with all that I did manage to send strings both ways so now the challenge is to sort through the cruft i've ended up with and turn it into something robust and hopefully simple.
In other android news i finally restarted on the ffts-related work and will scale down the initial goals to get something out the door.
2 comments:
Now we just need google (or whoever f* this all up) to read your entries, really nasty
Well to be fair i'm not sure host-mode is really the intention.
But I guess my general feeling of android is that it's moving much faster than it's documentation. And probably moving faster than it can cope with, leading to poorly thought out or unfinished features.
And for all the changes, it still suffers from a heritage of trying to work in 128k of RAM.
Single page re-usable 'mini-applications' were probably a good idea at the start (and have their place), but it doesn't scale very well and forcing every piece of software to deal with it sucks.
I really dislike the lifecycle of applications being tied to a window, and i really dislike the several shitty attempts to address it (loaders, services, fragments, etc). An explicit global lifecycle disconnected from the GUI would be much easier than trying to hide it behind something which makes out it isn't just doing that anyway.
In some ways this gives a competitive edge for app developers who can be bothered dealing with this shit; but it's a pain for the rest of us.
Post a Comment