> From: Luiz Augusto von Dentz [mailto:luiz.dentz@xxxxxxxxx] > Sent: Friday, August 17, 2018 10:32 AM > >> I wonder how this is suppose to work since what you are suggesting is > >> to not auto-connect matching profiles/services, but that would leave > >> the ACL link with no channels in use (at least on BR/EDR) so the link > >> would disconnect anyway. > > > > In my use case, the client application will wait for the appearance of > > a device object with a matching address to appear on the Device1 > > interface. If that device contains a profile that that the application > > supports, it will call ConnectProfile on the device object. In general, > > the link won't time out before the application has a chance to > > respond, but it would be fine if it did - the ConnectProfile call would > > end up re-establishing the link in that case. > > > > I could note that behavior in the adapter api document if you think > > It would help to clarify the intent. > > Wouldn't it be better to have a list of profiles to connect then? That > would make a nice addition to the API since ConnectProfile only > connect one profile at time, that way we could have auto-connect be a > list and in case it is empty we connect all otherwise we just connect > the profiles in that list, how about that? I agree - that is a nice improvement. Applications that use this approach will be a lot simpler - monitoring the device object list would not be strictly necessary for basic functionality. I will start on that today.
