Office Hours — Today, October 3

Saturday, September 30

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!
how can I help you today?
Steve S.
Hi, Mark!
I have some followup questions from our chat last week
Mark M.
OK
4:00 PM
Steve S.
Here is some code that I have based on our chat:
View paste (9 more lines)
private class ConnectThread extends Thread {
    final private BluetoothAdapter mmAdapter;
    final private WeakReference<BluetoothService> mmService;
    private boolean mmIsCanceled = false;

    ConnectThread(BluetoothService s) {
        mmService = new WeakReference<BluetoothService>(s);
        mmAdapter = BluetoothAdapter.getDefaultAdapter();
        if (mmAdapter == null) {
            postStatus(Status.UNSUPPORTED);
            if (mmService.get() != null) mmService.get().stopSelf();
        } else if (!mmAdapter.isEnabled()) {
            postStatus(Status.DISABLED);
            if (mmService.get() != null) mmService.get().stopSelf();
        }
...
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!
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
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
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
it's not really a thread's responsibility to do that sort of thing
4:05 PM
Steve S.
ok. i'm definitely open to improving the organization
Mark M.
is ConnectThread being used by BluetoothService?
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
only have a service running when it is actively delivering value to the user
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
i've considered doing that - and that might be the best approach
the only reason for not doing that has to do with keeping track of the service's state
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
ok, i'll rethink things to see about passing in the adapter to ConnectThread after the checks have been made
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
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
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
too much Windows C/C++ programming
ppszOMGPleaseMakeItStop and all that
Steve S.
i see
ok, no more questions today
Mark M.
OK
Steve S.
i'll follow up your suggestions on the service
thank you so much for your helpful comments!
Mark M.
good luck!
you're welcome!
Steve S.
thanks
have a good rest of the day!
Steve S.
has left the room
4:55 PM
Mark M.
turned off guest access

Saturday, September 30

 

Office Hours

People in this transcript

  • Mark Murphy
  • Steve S