Currently, the bluetooth broadcast events that are received by the BTConnectionClient class are invoked when any bluetooth events occur, even if invoked by a seperate system process. That includes other apps and system settings. In other words, if the app has been registered to receive events and a search is invoked (via the device's Bluetooth settings, for example) then all the associated events are received and executed. This shouldn't be a big deal in the majority of circumstances due to the m_ActivelySearching flag that is only set when a user invokes a poll from our application. However, if that flag is set and then the user were to initiate a search from somewhere else, or if another bug compromises the state of that flag then bugs like multiple or invalid connections might occur.
It's too late in the semester for me to think of a valid solution for this, since it's complicated and hard to test. Good luck, future devs.
Currently, the bluetooth broadcast events that are received by the BTConnectionClient class are invoked when any bluetooth events occur, even if invoked by a seperate system process. That includes other apps and system settings. In other words, if the app has been registered to receive events and a search is invoked (via the device's Bluetooth settings, for example) then all the associated events are received and executed. This shouldn't be a big deal in the majority of circumstances due to the m_ActivelySearching flag that is only set when a user invokes a poll from our application. However, if that flag is set and then the user were to initiate a search from somewhere else, or if another bug compromises the state of that flag then bugs like multiple or invalid connections might occur.
It's too late in the semester for me to think of a valid solution for this, since it's complicated and hard to test. Good luck, future devs.