Office Hours — Today, March 6

← Thursday, March 4

Mar 6
3:50 PM
Mark M.
has entered the room
Mark M.
turned on guest access
4:00 PM
Scott W.
has entered the room
Scott W.
Hello
Mark M.
hello Scott!
how can I help you today?
Scott W.
I've got one little problem with my AWS maven repo
My library has 7 modules
one of these modules is the main entry point to the library. hlsdk is the name of that module
hlsdk uses the other 6 modules.
the app that uses the library needs to use the hlsdk module + one of the modules hlsdk uses.
this other module is called "camera"
so I tried declaring the "camera" dependency in "hlsdk" with the api key-word
instead of implementation
Mark M.
that sounds about right
Scott W.
it did not work
sudokai
has entered the room
Mark M.
what specifically did not work, and did you publish the updated POM to your repository before trying what did not work?
(BTW, hello sudokai -- I will be with you shortly!)
4:05 PM
Scott W.
My intention was to publish the updated POM. I completely cleared out my S3 bucket and used the publish task again after I made the change.
but I don't know how to verify that api was used.
Mark M.
did you look at the POM itself? the entry for that dependency should look a bit different
Scott W.
I'll look now. It might take me a few minutes.
Mark M.
OK, let me take a question from sudokai in the meantime, and I will be back with you in a bit
sudokai: hi! how can I help you today?
sudokai
Hi
I have thought of the question yet
Scott W.
the "camera" dependency has scope = compile
my other dependencies have scope = runtime
4:10 PM
Mark M.
that all fits what I would expect
did you bump the version number of the artifact when making this change?
(sudokai: if you come up with a question, let me know!)
Scott: because otherwise, Gradle will keep using the copy of the AAR and POM located in your Gradle cache (e.g., ~/.gradle on macOS and Linux)
unless you use --refresh-dependencies or something to force Gradle to reload
Scott W.
I did not bump
android studio has a "clean cache and restart" button
Mark M.
yeah, that's a different cache, so I don't know if that will help
Scott W.
ok
Mark M.
frankly, I have never found a way to force the dependencies to refresh from inside the IDE, though I have not looked recently
a command-line build would use --refresh-dependencies (e.g., ./gradlew --refresh-dependencies demo:assembleDebug)
(where demo is the name of the module that you wanted to test building)
Scott W.
ok I'll try cleaning this all up. brb
4:15 PM
Mark M.
ooooo... found it!\
4:15 PM
Mark M.
in Studio, open the Gradle tool (docked by default on the right)
on the root element of the tree, right-click, and choose "Refresh Gradle Dependencies"
I think that will do it from within the IDE
4:20 PM
Scott W.
I've never done this. I'll be shocked if nothing breaks.
Mark M.
if by "this" you mean refreshing dependencies, at least for the third-party ones, there is unlikely to be any actual effect, as you already have the right versions
4:25 PM
Mark M.
once you get your environment set up and working, you will need to keep in mind that, effectively, build.gradle is part of your source code, and if you change that, you need to publish a new version of the affected dependency
and, in your case, that might also require publishing a new version of your hlsdk module as well
if you are using semantic versioning, that might be a minor version or patchlevel change
(sudokai: if you have a question, just let me know!)
4:30 PM
sudokai
Hey Mark
I'm investigating this crash
View paste (1 more line) 
Fatal Exception: java.lang.IllegalArgumentException: Cannot setMaxLifecycle for Fragment not attached to FragmentManager FragmentManager{41d8337 in null}}
       at androidx.fragment.app.BackStackRecord.setMaxLifecycle(BackStackRecord.java:245)
       at androidx.fragment.app.FragmentStatePagerAdapter.setPrimaryItem(FragmentStatePagerAdapter.java:240)
       at androidx.viewpager.widget.ViewPager.populate(ViewPager.java:1234)
       at androidx.viewpager.widget.ViewPager.populate(ViewPager.java:1092)
       at androidx.viewpager.widget.ViewPager$3.run(ViewPager.java:273)
       at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1057)
       at android.view.Choreographer.doCallbacks(Choreographer.java:875)
       at android.view.Choreographer.doFrame(Choreographer.java:772)
       at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1042)
       at android.os.Handler.handleCallback(Handler.java:900)
       at android.os.Handler.dispatchMessage(Handler.java:103)
       at android.os.Looper.loop(Looper.java:219)
       at android.app.ActivityThread.main(ActivityThread.java:8347)
       at java.lang.reflect.Method.invoke(Method.java)
...
It's not immediately evident what's going on
4:35 PM
Mark M.
what version of the androidx.fragment:fragment library are you using?
sudokai
androidx.fragment:fragment-ktx:1.2.5
I think it happens when some fragment gets destroyed
Mark M.
https://issuetracker.google.com/issues/137209870
that has your crash, but it should have been fixed by 1.2.5
sudokai
Thanks that's helpful
Do you think it might be a library bug?
Mark M.
it is certainly possible, given that stack trace
4:40 PM
Mark M.
stack traces where the spot of the crash and the calling statements all come from a library frequently are due to library bugs
assuming that your own code appears nowhere in the stack trace
sudokai
I think I can reproduce the crash
Mark M.
now, sometimes, the "library bug" is insufficient documentation or defensive programming, and the real cause is something that we did that used the library
that certainly helps!
(BTW, Scott: let me know if you have results from your testing!)
Scott W.
:: everything is working well with the maven repo now! ::
Mark M.
Scott: great!
Scott W.
there were multiple issues left to work through, but cleaning the gradle cache was one of them. Good tip
Mark M.
back when I used to regularly publish libraries, every time I did a release, one of my release steps was to do a --refresh-dependencies build, to better simulate what a consumer of my library would see and confirm that things built successfully
4:45 PM
Mark M.
(to be clear, a --refresh-dependencies build of my demo app module)
usually it was fine, but every now and then it pointed out when I botched something
sudokai
The crash happens when a fragment is still being created in a viewpager
And you hit back
Mark M.
sudokai: that feels like the library should be able to handle that, so I'm back to "it's a library bug"
tactically, you might be able to intercept back navigation and figure out something avoid the crash
and, androidx.fragment:fragment is up to 1.3.0, so this might be fixed in the new version
sudokai
So it's inside this androidx.fragment.app.BackStackRecord.setMaxLifecycle(BackStackRecord.java:245)
View paste 
if (fragment.mFragmentManager != mManager) {
    throw new IllegalArgumentException("Cannot setMaxLifecycle for Fragment not attached to"
            + " FragmentManager " + mManager);
}
Scott W.
:: I'm signing off. Thanks for help Mark! ::
sudokai
Both fragment.mFragmentManager and mManager are null
Mark M.
(Scott: you're welcome!)
sudokai
And since we know that null != null
It crashes :)
4:50 PM
Mark M.
yeah, I'm definitely back to "it's a library bug"
try 1.3.0 -- but, if you still see it there, and are in position to create a sample project that reproduces the problem, file a bug report!
sudokai
Okay I'll check it out
Do you usually keep your dependencies up-to-date_
Mark M.
if they crash, yes :-)
sudokai
No, I mean, in general
Mark M.
it depends a bit on the project
for my book samples, I usually update them all as part of a release
for my primary consulting customer, we upgrade sporadically and need to get better about it
what I dislike is being forced to upgrade a dependency at an unplanned point, so I would prefer to "keep ahead of the curve"
sudokai
I don't know if I should only upgrade when something breaks
Or keep updating
4:55 PM
Mark M.
IMHO, you do not need to be on the absolute latest version, but being years out of date is bad too
in this case, 1.2.5 is not that old, so I would not have worried about it right now outside of it possibly fixing your crash
if we were having this discussion next year at this time, I would be nudging you to upgrade that dependency
sudokai
So, when do you upgrade your libraries
As a separate release
Or bundled with other changes
Mark M.
for professional projects, ideally, I like to do it as a separate Jira ticket and pull request, just because there can be a lot of ancillary changes, such as fixes due to new Lint rules
for example, for a recent bug fix, I had to upgrade us to the latest Material Components for Android, and that meant that I had a whole bunch of unrelated changes in a bug-fix PR, just because they changed Lint rules on us
now, sometimes, to implement Feature X, we need a new version of a dependency, and so upgrading in that ticket+PR is unavoidable
but, in terms of making sure we are not stale, I try to handle that as a separate ticket+PR
in terms of releases, those dependency changes just roll into the regular release process
5:00 PM
Mark M.
(and therefore ideally are happening in a regular release, not some hot-fix)
sudokai
That's a great idea
Thanks Mark!
Mark M.
you're welcome
and that's a wrap for today's chat
the next one is Tuesday in the 8:30am US Eastern slot
have a pleasant rest of your weekend!
Scott W.
has left the room
sudokai
has left the room
Mark M.
turned off guest access

← Thursday, March 4

 

Office Hours

People in this transcript

  • Mark Murphy
  • Scott Wehby
  • sudokai