Office Hours — Today, December 13

← Yesterday, December 12

Dec 13
3:55 PM
Mark M.
has entered the room
Mark M.
turned on guest access
Steve S.
has entered the room
4:00 PM
Steve S.
Hi, Mark!
Mark M.
hello, Steve!
how can I help you today?
Steve S.
Let me paste in a question:
I recently saw a crash due to a TimeoutException in a call to a finalize() method made by the OS. Based on Stackoverflow, this seems to be due to a bug in the Android garbage collection code that can't be avoided, though it can be made less frequent. Do you know anything about this bug beyond what's on Stackoverflow? Would this be a reason to use 5.0 instead of 4.3/4.4 (we provide the devices our customers use)?
Mark M.
um, I can't really comment on that in the abstract
having never seen that exception personally
do you have a stack trace?
Steve S.
ok. so this isn't a problem you were aware of?
one moment
Mark M.
I believe that this is the first that I've heard of it
Steve S.
View paste (7 more lines) 
19:26:45.629 22403-22413/com.ssimon.groundcontrol2 E/AndroidRuntime: FATAL EXCEPTION: FinalizerWatchdogDaemon
                                                                             Process: com.ssimon.groundcontrol2, PID: 22403
                                                                             java.util.concurrent.TimeoutException: android.bluetooth.BluetoothSocket.finalize() timed out after 10 seconds
                                                                                 at libcore.io.Posix.fstat(Native Method)
                                                                                 at libcore.io.ForwardingOs.fstat(ForwardingOs.java:56)
                                                                                 at libcore.io.BlockGuardOs.close(BlockGuardOs.java:60)
                                                                                 at libcore.io.IoUtils.close(IoUtils.java:43)
                                                                                 at libcore.io.IoUtils.closeQuietly(IoUtils.java:69)
                                                                                 at android.os.ParcelFileDescriptor.closeWith
...
Mark M.
are you sure that you are closing all of your BluetoothSockets yourself?
before they go out of scope and become eligible for GC?
beyond that, this feels like a bug in BluetoothSocket, more so than the GC engine
Steve S.
No, that's not something I do since the Bluetooth code is supposed to be running all the time. But maybe it's something I should be doing.
Mark M.
some BluetoothSocket is going out of scope; otherwise, nothing would be calling finalize() on it
Steve S.
Here's a link to the Stackoverflow post:
https://stackoverflow.com/questions/24021609/ho...
I had thought what I saw was the same bug, but maybe not
4:05 PM
Mark M.
it's certainly possible that there's a problem with the GC stuff
however, GC is used in 100% of Android apps
Bluetooth is used in <1% of Android apps
that leads me to blame Bluetooth over GC
Steve S.
ok. you suggested i might need to close the socket myself when BluetoothSocket goes out of scope. If I implement
Bluetooth using a service, could I accomplish that by closing the socket in onDestroy()?
Mark M.
sure
either onDestroy() will be called, your process will be terminated, or you had an unhandled exception
IIRC, your app is on a device that is constantly on power -- correct?
Steve S.
yes
Mark M.
then the scenario in the "Now consider the following scenario:" section of the top-rated answer shouldn't be one you encounter
as the device should not be going to sleep
4:10 PM
Steve S.
right. this is something i saw when i was doing something else, so it's not representative of the intended use case
ok. so it sounds like a strategy for avoiding the problem i saw could be to close the BluetoothSocket in onDestroy() in case that gets called, but to always keep the device on in case it's the problem described on Stackoverflow
Mark M.
well, the decision of whether or not to keep the device powered on is probably going to be made based on something other than an occasional GC-triggered TimeoutException :-)
basically, I can think of two reasons why that TimeoutException occurs:
1. GC itself blocks, which is the "device falling asleep" scenario outlined in that answer
2. BluetoothSocket's finalize() gets stuck
my hope is that if you close the BluetoothSocket, the odds of finalize() getting stuck decrease
but, that's just an educated guess
4:15 PM
Steve S.
ok. we have independent reasons for keeping the device on all the time. so maybe between that and closing the socket in onDestroy we'll be ok.
i have a second question on a different topic. i'll paste it in:
I'm working on an activity with a large number of views. For performance reasons, I'd like to avoid repeating calls to findViewById() for the same views, but having a member field for each view gets messy due to the large number of views. Do you have any general suggestions about how to approach this? Would the Android data binding framework be something to look at?
Mark M.
um, well, you could use the data binding framework if you wanted
in the end, what it will do (among other things) is code-generate a Java class with fields that will hold all of your widgets that have distinct android:id values
and fill those fields in when you inflate the layout using the associated Binding class
Buttter Knife would be another option: https://github.com/JakeWharton/butterknife
leastways, I think it has an option to have your annotated fields be on a separate POJO from the activity
4:20 PM
Mark M.
usually, my reaction to this is: are you really sure that having all of those widgets in a single unit of UI (activity, fragment) is the right answer?
Mike F.
has entered the room
Mark M.
if it's tedious for you to have lots of fields, it's probably tedious for the user to wade through all of the widgets
let me take a question from Mike, and I'll return to you in a bit
Steve S.
sure
Mark M.
Mike: hi! welcome to the chat! do you have a question?
Mike F.
hi! Yes, something I was wondering about Mark. Look at the section of the book where you discuss Retroft, i.e. p 730 or so...
Mark M.
OK
Mike F.
I was wondering where one would look up more methods that an object has, such as the so rest adapter.
would you find that on the Retrofit site?
Mark M.
yes, in one form or another
for example, here are the JavaDocs for Retrofit 2.x: http://square.github.io/retrofit/2.x/retrofit/
I got those by visiting the GitHub repo (https://github.com/square/retrofit), not seeing them there, then clicking on the "the website" link (leading to http://square.github.io/retrofit/)
4:25 PM
Mark M.
there's a "JavaDoc" link in the nav area on the right
which leads to the JavaDocs
RestAdapter is a Retrofit 1.x thing, so you won't see that in those JavaDocs
Mike F.
OK, nice, thanks. For the API info, i.e. the format of the JSON from Stackoverflow, that would be in the developer area somewhere on the so site?
Mark M.
yes
http://api.stackexchange.com/ in this case
now, documentation quality and availability is... variable
ideally, all Android libraries have great documentation
and, ideally, all Web services have great documentation
ideally, I'd be less balding
Mike F.
Great. I want to practice more with this so that I can get familiar with how to use Retrofit.
me too!
lastly, what are you plans for handling the transition to Kotlin in your book, over the longer term?
Mark M.
clearly, as our heads illustrate, it's not an ideal world
probably nothing until 2019 at the earliest
even then, I expect that Kotlin will mostly be in separate books
there is no way that I am rewriting a 4500-page book to be all Kotlin, for example
Mike F.
it seems like it will be complicated as people doing Android will have to know both languages moving forward, as legacy code bases will need to be maintained.
Mark M.
"have to know" is a bit of a strong term
it would be helpful to know Kotlin
Mike F.
Got it.
Mark M.
but lots of Android developers are not in position to spend the time on that, or lack resources in their native languages, and such
Java isn't going anywhere
4:30 PM
Mark M.
in iOS, Objective-C is a horrible language, which is why everybody ran to Swift
I don't think that Java is considered nearly as bad as Objective-C
Mike F.
interesting. So you see the transition for Android being different, maybe slower and will take longer?
Mark M.
whereas with iOS, it's difficult to actually use Objective-C now (from what I can see), I expect that Kotlin and Java will be peers eventually, once Kotlin catches up
I don't expect Java to evaporate, in part because Java is used outside of Android, and some of what we do is designed to run in those environments as well
Retrofit itself, IIRC, does not require Android, for example
I expect rapid uptake of Kotlin in wealthy nations by a lot of developers
Mike F.
OK, thanks Mark. Gotta run. Thanks so much for the book, it is amazing. I am preparing for an interview, and it has been very helpful.
Mark M.
you're very welcome!
Steve: back to you!
(Mike: and good luck in the interview!)
Mike F.
thank you. :)
Steve S.
regarding the large number of views, a lot of them are TextView's, which is why i was wondering about the data binding framework
Mark M.
you're certainly welcome to use it
I like it, personally
particularly now that we're in a Jack-free world, and Java 8 works with the data binding framework
Steve S.
but it sounds like one option would be to create my own class to hold the views in a structured way?
4:35 PM
Mark M.
your fields can be anywhere you want, relatively speaking
if you want them directly on the activity or fragment, fine
if you want to use a separate class -- akin to how we use the view-holder pattern in RecyclerView -- go right ahead
Steve S.
from a software engineering perspective, do you have a preference for any of the options we discussed (or would that depend on the details of the specific use case)?
Mark M.
well, again, I haven't really found the number of fields to be the limiting factor
usually, I run out of screen space first
but your app may not have that particular limitation
Steve S.
sure
we are using a tablet
Mark M.
I don't know that I'd use the data binding framework just to get a code-generated class to hold widgets
Steve S.
ok
Mark M.
but, I'd use the data binding framework for other reasons (like, say, data binding)
and I'm happy to get the code-generated class to hold widgets as a side benefit
though usually with data binding you don't need to reference those widgets as much anyway, as data binding expressions handle that for you
Steve S.
ok, no more questions today
i saw that you're coming out with some material about Bluetooth in the next book update. i'm looking forward to that!
4:40 PM
Mark M.
it'll mostly be demonstrating https://github.com/IvBaranov/RxBluetooth
with callouts to the actual Bluetooth API
and I made a note to double-check that I'm closing my BluetoothSockets... :-)
Steve S.
right!
thanks for all the help!
Mark M.
you're welcome!
Steve S.
have a great rest of the day!
Mark M.
you too!
Steve S.
has left the room
Mark M.
Mike: if you have additional questions, go right ahead
4:45 PM
Mike F.
just lurking. gonna sign off - see you another time. Thanks again.
Mark M.
you're welcome!
Mike F.
has left the room
5:00 PM
Mark M.
turned off guest access

← Yesterday, December 12

 

Office Hours

People in this transcript

  • Mark Murphy
  • Mike F
  • Steve S