Oct 3 | 3:55 PM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Steve S. | has entered the room |
Mark M. |
hello, Steve!
|
Mark M. |
how can I help you today?
|
Steve S. |
Hi, Mark!
|
Steve S. |
I have some followup questions from our chat last week
|
Mark M. |
OK
|
Oct 3 | 4:00 PM |
Steve S. |
Here is some code that I have based on our chat:
|
Steve S. |
View paste
(9 more lines)
|
Steve S. |
The first question is whether you see any glaring problems with it
|
Mark M. |
oooo, is [etc] some new Java 8 stuff? :-)
|
Steve S. |
Java 9
|
Mark M. |
aw, man, I'm still catching up to 7!
|
Mark M. |
gonna have to binge-update
|
Steve S. |
they don't make it easy
|
Mark M. |
your constructor seems odd
|
Steve S. |
ok
|
Mark M. |
I would not expect business logic related to adapter states and stopping of the service to be in a constructor
|
Mark M. |
that's a code organization issue, more so than anything else
|
Steve S. |
right. that's a change I made to avoid the potential race condition we discussed
|
Mark M. |
the WeakReference might help with that
|
Steve S. |
how so?
|
Mark M. |
oh, sorry, never mind
|
Mark M. |
getting my concepts crossed
|
Steve S. |
so one thing i'm wondering about is getting rid of the calls to stopSelf()
|
Mark M. |
that's an odd spot to have that code, IMHO
|
Mark M. |
it's not really a thread's responsibility to do that sort of thing
|
Oct 3 | 4:05 PM |
Steve S. |
ok. i'm definitely open to improving the organization
|
Mark M. |
is ConnectThread being used by BluetoothService?
|
Mark M. |
or is there some intermediary class involved here?
|
Steve S. |
if Bluetooth isn't supported, the app will shut down. in that case, could I simply leave the service running (with no running threads) and let the OS deal with shutting down the service (so I don't have to call stopSelf())?
|
Mark M. |
oh, I wouldn't do that
|
Mark M. |
only have a service running when it is actively delivering value to the user
|
Mark M. |
but if BluetoothService is the one creating the ConnectThread, BluetoothService should have most of that logic from your ConnectThread constructor
|
Steve S. |
ok. so then i end up having to call stopSelf().
|
Mark M. |
pass in the BluetoothAdapter into the ConnectThread constructor, instead of (or in addition to) the BluetoothService
|
Steve S. |
ok
|
Steve S. |
i've considered doing that - and that might be the best approach
|
Steve S. |
the only reason for not doing that has to do with keeping track of the service's state
|
Oct 3 | 4:10 PM |
Steve S. |
if the logic goes in the thread, then i can tell when the service has been started by seeing if ConnectThread has been instantiated. otherwise, i think i would need a flag.
|
Mark M. |
ummm... who, other than BluetoothService, would be able to see if ConnectThread has been instantiated?
|
Steve S. |
right
|
Steve S. |
ok, i'll rethink things to see about passing in the adapter to ConnectThread after the checks have been made
|
Steve S. |
another question: should i call super.run() ?
|
Mark M. |
I don't think it does anything
|
Steve S. |
ok
|
Mark M. |
but, since it's a class that you're extending, it's probably a good practice
|
Oct 3 | 4:15 PM |
Steve S. |
ok - as a defensive measure?
|
Mark M. |
better safe than sorry
|
Steve S. |
sure
|
Mark M. |
but, I suspect that most Thread subclasses don't call super.run(), which is why I'm fairly certain that you're safe either way
|
Steve S. |
ok
|
Steve S. |
on another topic, i'm curious as to why you don't like Hungarian notation?
|
Mark M. |
got burned out on it in the 1990's
|
Mark M. |
too much Windows C/C++ programming
|
Mark M. |
ppszOMGPleaseMakeItStop and all that
|
Steve S. |
i see
|
Steve S. |
ok, no more questions today
|
Mark M. |
OK
|
Steve S. |
i'll follow up your suggestions on the service
|
Steve S. |
thank you so much for your helpful comments!
|
Mark M. |
good luck!
|
Mark M. |
you're welcome!
|
Steve S. |
thanks
|
Steve S. |
have a good rest of the day!
|
Steve S. | has left the room |
Oct 3 | 4:55 PM |
Mark M. | turned off guest access |