Office Hours Transcript: 2021-07-13

Kai_H joined


hello, Kai!


how can I help you today?

I noticed Kotlin has a lot of functionality like "list.last" and "val thirdChar = string[4]", compared to Java. Does something in Kotlin make it easier to implement those or did the authors of the language and stdtlib just take the timer?

"just take the timer"?

tldr: Kotlin has a lot of small convenience that Java lacks. How come?


Take the time, make the effort.

ah, OK


in the case of string[4], the answer is that Kotlin has first-class support for defining implementations of operators, and [] and []= are considered operators


[] maps to get() and []= maps to put()


I have not paid much attention to newer versions of Java (e.g., java 15) to see if they have added anything similar

They have added a lot and made it more similar to Kotlin in a lot of regards, but I think a lot is still missing. And I wondered how come that Kotlin has so much "convenience" and how much effort that was.

Tad joined

As I mostly program Java but learned Kotlin on the side I find msyself thinking quite often "this would be easier in Kotlin, I would just do <…> and use <…>".

I cannot really answer to the motivations of either the Java or the Kotlin teams


(BTW, hello Tad – I will be with you shortly!)


I know that the Kotlin team made a concerted effort to implement as much of Kotlin in Kotlin as possible


so, a lot of the relatively obscure stuff in Kotlin syntax (e.g., tailrec) are there more for the developers of Kotlin than they are ordinary developers like us


and, Kotlin has the benefits of an additional 20 years of advancement in software development to lean on

And less cruft to work around, less old decisitions.

yeah, stuff like that


anyway, let me take a question from Tad, and I can come back to you in a bit


Tad: hi! how can I help you today?

Hi Mark - I’ve got a question related to some Espresso tests, is that something you can help with?

I think you need to advance your state

Well, ok - but the problem is that the launch activity is never called in the latter case with scenarioRule.


So - advance it to what?

in the above link, see the block of code, specifically the first "After:" section


you get your scenario from your rule by getScenario(), rather than needing a manual launch() call


but I think you still need to wrap your checks in onActivity()

I actually had originally written this with .launch(), and it failed in the same way


But I’ll review and try

right, with ActivityScenarioRule I do not think you need that, but you still need onActivity()


think of the activity launch as being lazy and asynchronous


you can’t run the tests until the activity is ready to be tested

Sorry - I mean I originally wasn’t using a rule, I was getting the scenario in @Before and doing the launch

oh, OK

Thanks for the link though. I have another question when it’s my turn again


Kai: back to you! do you have another question?


gotta remember the @ here… @Kai: back to you! do you have another question?

I have nothing like Crashlytics or Firebas in my app, only the normal reporting that comes with the Play Console. I wondering if I should have something like that. What do you think?

personally, I would use something beyond the Play Store, but that’s an opinion

(which is what I’m asking for :) )


The Play Store usually offers very little information about crashes and such, so I wondered and wanted your opinion.

@Kai - fwiw I’m using Crashlytics/Firebase, and it does give some more details.

with a lot of API questions, I can fall back on concrete rationale; with app distribution concerns like "what should I use for crash logging?", my reaction is far more of ¯\_(ツ)_/¯, because my background there is very atypical

But I can also tell you that I know some folks at Twitter, and at least as of a year or so ago they were not using it - they were using home-grown stuff (larger, highly technical and advanced dev team though).

Well, we have a dev team of 1, so… ;-)


But thanks for the opinions

@Kai: let me take another question from Tad, and I will be back with you in a bit


@Tad: over to you for your next question!

Sure - this is a pretty strange one I think. Also related to Espresso stuff.


They recently updated a number of their libraries, also JUnit dependencies.


So I updated my gradle dependency as normal


All of a sudden, my .aab file gained weight - ~7MB.


I did some painful (one at a time, backing up to the prior version) of all the new dependency versions.


Turns out from that exercise it was espresso-contrib


My question: although my sleuthing did in fact point directly to this as a problem, I find it hard to believe.


Is there anything I could be doing that would introduce a dependency to include the jdk11 source?

nothing that I can think of


your test, though, seems to be based on your regular app – have you tried creating a scrap project and seeing if you reproduce your espresso-contrib findings there?

Have not.


I’m sure they will ask for it though - I filed an issue with the androidx.test team

right, that’s kinda where I was heading

But I have to have it in the regular app because I’m using idlingResource

certainly, but unless your regular app is open source, that doesn’t help the androidx.test team

So a test won’t start until my splash activity launches the "main" activity and it makes it through the onResume() stuff.


yes understood

and if the problem is tied to some combination of effects – the espresso-contrib plus something else in your regular app’s setup – they may have difficulty reproducing the problem

ok I have one more when it’s back to me


@Kai: over to you! do you have another question?

Yes, another great and easy one: What’s advice that you would give someone that wants to be an Android freelander? :D

do you mean "freelancer"?



(Item 1: Learn to type…) ;-)

how are you defining "freelancer"? do you mean somebody who is working contracts in general? or do you mean somebody who only does short-term projects?

More the first.


Even though it would probably mean the second one too.

make sure you have clear "proof of ability" (e.g., portfolio of open source work that you’re happy with), and make sure that you have access to all necessary stuff that you ordinarily get from employers (e.g., in the US, health insurance)


@Kai, @Tad: free-for-all time! if you have any questions, just fire 'em off and I’ll field them as best I can!

OK here is one


So in my pre-launch report for my app on Open Beta I see 20 warnings being reported having to do with a "StrictMode policy violation", example:


StrictMode policy violation: android.os.strictmode.NonSdkApiUsedViolation: Landroid/graphics/FontFamily;->abortCreation()V
at android.os.StrictMode.lambda s t a t i c static 1(
at android.os.-$$Lambda S t r i c t M o d e StrictMode lu9ekkHJ2HMz0jd3F8K8MnhenxQ.accept(Unknown Source:2)
at java.lang.Class.getDeclaredMethodInternal(Native Method)
at java.lang.Class.getPublicMethodRecursive(
at java.lang.Class.getMethod(
at java.lang.Class.getMethod(
at Source:0)
at androidx.appcompat.widget.AppCompatTextView.setTypeface(
at android.widget.TextView.resolveStyleAndSetTypeface(
at android.widget.TextView.setTypefaceFromAttrs(
at android.widget.TextView.applyTextAppearance(
at android.widget.TextView.<init>(
at android.widget.TextView.<init>(
at androidx.appcompat.widget.AppCompatTextView.<init>(
at androidx.appcompat.widget.AppCompatTextView.<init>(
at java.lang.reflect.Constructor.newInstance0(Native Method)
at java.lang.reflect.Constructor.newInstance(
at android.view.LayoutInflater.createView(
at android.view.LayoutInflater.createViewFromTag(
at android.view.LayoutInflater.createViewFromTag(
at android.view.LayoutInflater.rInflate(
at android.view.LayoutInflater.rInflateChildren(
at android.view.LayoutInflater.inflate(
at android.view.LayoutInflater.inflate(
at android.view.LayoutInflater.inflate(
at com.reddragon.intouch.ui.SplashActivity.onCreate(


And the layout it is complaining about



    app:layout_constraintGuide_percent="0.5" />




yeah, Google needs to learn how to talk to Google

Is this anything I need to worry about? How do I "fix" it?

in this case:

  • one Google team is using an undocumented API
  • another Google team declared that API off-limits
  • yet another Google team isn’t filtering this sort of problem out of their reports

OK - so as I suspected, it’s out of my control, it’s only a warning, so don’t lose any sleep over it, right?

Is this anything I need to worry about?

In terms of this specific one, no. A Google library is having problems with a Google-developed framework. There isn’t much you can do, other than to keep up with updates to AppCompat and related libraries.


a NonSdkApiUsedViolation coming from a third-party library is the responsibility of the developers of that library, not you


so, other than perhaps filing an issue if there isn’t one out there already, there is not much for you to do

Which team should get this issue? Or do I just file a general bug?


(i.e. using the frown face in the IDE)

this one probably goes to, against either AndroidX Core (if that exists as a category) or AndroidX AppCompat


that’s a wrap for today’s chat

Thanks Mark!

the next one is Thursday in the 7:30pm US Eastern time slot


have a pleasant day!

Thanks for your time. Have a good time and stay healthy.