Greetings again.

hello!

how can I help you today?

I have two questions for you tonight. First up is performance. On my phat, fully loaded MacBook Pro a kotlin program I wrote takes 2 seconds to load ~2Million JSON records from a web site.

I'm impressed you can download a JSON document that large in 2 seconds

When I run that code via a library on an Android app on a Pixel 3 XL it takes ~15 seconds, and on a Nexus 6, fully two minutes.

The disparate times seem out of whack to me. I would have guessed something like, 2s, 5s, 20s would be reasonable. Apparently not the case. What's your take?

when you say "load", what exactly do you mean? you're going to be hard-pressed to have heap space for ~2 million model objects

Why is that?

um, because heaps aren't that big

say, for example, you have a 64MB heap

that leaves you with 32 bytes per model object

while it is certainly possible to have a model object that small that is still useful, frequently JSON will have string properties and stuff that will bump your average up

With a 3G Android device, can I not set the heap to, say, 1G?

so, if you really are loading 2 million model objects into memory simultaneously, IMHO slow speed is the least of your worries -- the OutOfMemoryErrors would be somewhat more catastrophic

no

unless you build your own custom ROM

or root the device, perhaps

I was getting OOM errors until I used the "useLargeHeap" attribute.

there is no guarantee of how large that "large heap" will be

Then it garbage collected like crazy on the N6.

it is probably trying to free up memory from past JSON parsing steps or something

So what would you do to make these ~2M records accessible fast and easy?

eliminate 99% of them

I mean, seriously, downloading and parsing 100+MB is not going to be pleasant

and so I'd start with reconsidering why you are downloading and parsing 100+MB of JSON data

These are records that back narrowing choices, like movie names in my app. Can't be eliminated.

but, why download and parse JSON? why not package this data in your app as a SQLite database?

I hate databases. :-)

Especially SQL ones.

You've got me thinking. I might load the strings and defer parsing.

They are small, always < 100 characters

OK, if you're not putting the data into SQLite... then what *are* you doing with the data? please tell me you are not re-parsing the JSON on every app run

If I could get the re-parsing down to < 2s on every app run (which are infrequent) I would accept that.

neither the network nor on-board flash is likely to be fast enough to sustain what you want

But yes, cacheing the data into a db is viable.

The data changes once per day at the source site, fwiw.

how big is your intended user base?

(BTW, hello, Eric -- I will be with you shortly!)

hey

Could be large.

I certainly want it to be large.

downloading 100+MB daily is going to make you unpopular with people on metered data plans

and I have difficulty believing that the entire dataset is being changed daily

I mean, you could rewrite half your app in C/C++, so that your JSON is only ever touched by native code, as you eliminate the heap limits... but I think you have far more profound data management issues than the speed of the JSON parsing

It's an upscale user base. Not for billions of users. Such a problem to have.

Are these profound issues speed or space or both?

bandwidth and speed, IMHO

I mean, you're talking terabytes a month of bandwidth charges if your user base gets appreciable

at ~3GB/month per user

well, actually, I'm not taking GZip into account, which I assume you have enabled for your Web service and HTTPS client

so, the bandwidth hopefully won't be that bad

but, still, the thought of downloading and parsing that much JSON daily makes me cringe

Interestingly enough, with Kotlin coroutines, the delta between reading in the data from a file or from the next is negligible.

(reading and parsing)

next -> net

that will depend a lot on the network connection

Yes, mine is fast (1G)

anyway, let me take a question from Eric, and I will swing back to you in a bit

Eric: your turn! do you have a question?

That's fair.

I have an activity with a framelayout that acts as a container for dynamically added fragments. One such fragment has swipeable tabs, so it contains 2 fragments itself. When a menuItem is clicked, I want to add or remove these inner fragments. I am using the childFragmentManager to do so and get an error complaining "can't change container ID of <inner fragment>". Since these inner fragments were added with a FragmentPagerAdapter I didn't use the childFragmentManager directly to add them.

FragmentPagerAdapter has always sucked at dealing with trying to add/remove/replace pages

that's why I wrote ArrayPagerAdapter back in the day

you may need to roll your own PagerAdapter that can handle your needs

yeah I created a custom FragmentPagerAdapter

OK, well, that adapter needs to be using the childFragmentManager, if it will manage fragments that are inside another fragment

beyond that, based on the error, it seems like your FragmentTransaction has some container issues

yes it is using that

am I able to use the same framelayout container?

I thought you were changing a page in the ViewPager

no

"When a menuItem is clicked, I want to add or remove these inner fragments" -- what are the inner fragments?

I thought those were the ones referred to as "2 fragments itself" in the preceding sentence

when I click on a menuItem in the toolbar, I want to go from showing 2 tabs to one of the fragments in the tab (I want to replace the parent fragment with the child fragment)

the parent fragment is the tab fragment

the child fragment is one of two in the parent tab fragment

"I want to replace the parent fragment with the child fragment" -- you would need to completely remove the child fragment before adding it to a new container, I think

I have never tried what you are attempting (move a nested fragment out to be a top-level fragment), but once a fragment is managed, AFAIK you need to unmanage it before you can switch containers

am I able to use the framelayout that is currently occupied by my parent fragment? This container is in an activity. It holds a tab fragment. The tab fragment has child fragments. So I want to replace the tab fragment with its child. Do you understand

in theory, what you want can work -- it is mostly a question of what fragments you need to remove along the way

I would start by removing *everything* -- remove the child fragments from the tab fragment, remove the tab fragment from the FrameLayout

then add the desired fragment to the FrameLayout

and see if that runs

the stacktrace seems to indicate I can't use the same container

from the error message you cited, my assumption is that the fragment is already *in* a container

"can't change the container id of the child fragment"

and you need to remove it from that container before putting into another container

hmm alright

it's entirely possible that there is something about nested fragments that prevents this sort of reuse, and you will wind up needing to create a new instance of the fragment

that would be the fallback plan

wait but container is it currently in?

the container represented by the tab fragment

the nested fragment is part of tabs, which does not explictly have a container, no?

ah

ViewPager is a container (subclass of FrameLayout IIRC)

how do i remove it from the container, then?

I don;t know how to acccess this special container?

you remove it from the PagerAdapter, I think

somewhere, your custom PagerAdapter should be committing FragmentTransactions for adding and removing the fragments

ViewPager itself knows nothing about fragments -- it works in terms of Views

let me take another question from Paul, and I will switch back to you in a little bit

Paul: your turn! do you have another question?

ok

yes

I have a Kotlin object that has an init block. I would like to "inject" a parameter into this init block for testing. First, is my scenario clear and second, do you have a solution?

init blocks don't get parameters, only constructors do

object as in singleton

are you using a dependency injection framework?

Can the block reference a companion variable?

probably, though I haven't tried it

Me either, at least not yet.

companion objects are roughly analogous to Java statics, so I would think it would work

but if you're not using dependency injection, that may be a better answer anyway

personally, I've been using Koin for Kotlin projects

I'll play with that idea. Any other thoughts?

you could have some sort of secondary constructor that is used in testing

(I am assuming that you cannot provide this parameter via the regular constructor for some reason)

Would "secondary constructor kotlin" be a good search expression for Google, do you think?

I cover it in "Elements of Kotlin", but yes, that should work from a search expression standpoint

or, https://wares.commonsware.com/app/public/bookse...

having full-text search of my books is handy on occasion :-)

Ah, you are imaging an factory to create the object. No?

an -> a

I was assuming that your test was creating the object

Not till now. :-)

if this object is several layers removed from the test code... definitely look into Koin or other dependency injection, as that is precisely the problem that they were created to solve

I'll be covering Koin some in *Elements of Android Jetpack* and *Exploring Android*, though my pace is slow at the moment

BTW, the official docs for secondary constructors are part of https://kotlinlang.org/docs/reference/classes.html

I'll take a look at Koin and ping you later if need be.

I am eminently pingable

except, not literally, due to my firewall configuration

anyway, let me take another question from Eric, and I'll return to you if there is time

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

A quick look tells me that is promising.

I'm all set now. Thanks.

you're welcome!

yea it has a problem removing the inner fragment and gives the same error

what is "it"? the PagerAdapter?

childFragmentManager

childFM.beginTransaction().remove(adapter.getItem(position)).commit()

is the PagerAdapter using the childFragmentManager?

yes

then I cannot explain the error

it has to because the fragments inside the tablayout are nested

agreed

ok

"can't change the container id of the child fragment" simply does not make sense for a remove() operation

are you also removing the fragment from the PagerAdapter? perhaps it is trying to re-add it as a page

no

you will need to do that, as you do not want the PagerAdapter to be working with this fragment anymore

and the PagerAdapter should be doing the remove() as part of that work

ok ill add a method to it that removes the fragment from the list

goodnight

have a pleasant evening!