This may not be just software related problem. Usually the network adapter (wifi) is responsible for keeping track of signal levels and deciding when to roam and where to roam to. These algorithms are vendor specific and there might not be a way for you to affect them. Roaming is done by sending 802.11 reassociations frames (requests) from a client and the roaming process is done on L2 level (in your scenario). But the process might not be just that simple. Both APs should be aware if the client roamed and the switch sending frames to those AP should have that update in its CAM table. The AP from which the client is roaming from might buffer all frames destined for a client and send it to a new AP when the client reassociates resulting in no data loss. Since this is not required by 802.11 standard roaming could cause a data loss and plainly reconnecting to an AP with stronger signal would cause a drop in connection because it is not just roaming but a full disconnect and reconnect to the network.
This is probably not helping you solve your problem but I was trying to point out that this is really something that should be done on lower levels (physical, data link or transport) not on application level. Weather the roaming will be virtually seamless depends a lot of the hardware used (on both sides) and the configuration of network, and there is not much you can do to change that. The only thing that comes in mind is sending 802.11 probe requests so that the client is aware of other APs with possibly stronger signals, which you already are doing in your code, and leaving the decision to roam to a network adapter.