Hello

hello, hemanparbhakar!

how can I help you today?

I have one query regarding coroutine and room

what will be the best approach if i want to insert data in room db after every 100ms

Hello

personally, I would try not to do disk I/O that frequently

(hello, Kai! I will be with you shortly!)

ok

i am now taking the data and storing it in an array after some time i m using coroutine and insert all the data into room in single go is that a good approach ?

it sounds better than every 100ms, but it would depend a lot on whether the app is in the foreground or not

basically, you do not want to lose data when your process terminates

its running service

so, presumably it is a foreground service, since background services do not live very long on Android 8.0+

if there is some real-world event that is tied to your data creation, that is less frequent than every 100ms, you might save your data when those events occur

otherwise, a periodic flush of your cached data to disk is reasonable, but I'd aim for something more like every 10 seconds rather than every 100ms

yes foreground service i am using

in terms of doing that sort of periodic work, coroutines on its own will not help, unless I am forgetting an option on Flow for automatically setting up a periodic task

so instead of coroutine uisng you suggest to use flow

I was referring to the Flow that is part of coroutines

if you could go longer -- say, every 15 minutes or so -- WorkManager would be a solution, and there is a CoroutineScope that you can use from your Worker to call suspend functions on your Room DAO

CoroutineScope(Dispatchers.IO).launch

using this coroutine i m performing operation

and that is fine, though Room will provide its own dispatcher

in terms of triggering that launch() call every so often, you will need to do something outside of coroutines, AFAIK

so what would be that ?

ScheduledExecutorService would be the most likely choice if you need something more frequent than what WorkManager supports

unlike RxJava, which has built-in periodic options for things like Observable, coroutines does not, unless there is something that I am forgetting

ScheduledExecutorService is good ?

for periodic work in an already-running process, yes

in your case, you have a foreground service, so an in-process solution should be fine

but i am using timer to call after every 10 seconds

personally, I am a bigger fan of ScheduledExecutorService than Timer/TimerTask, but you are welcome to use either

ok thanks

let me take a question from Kai, and I will come back to you in a bit

Kai: your turn! how can I help you today?

ok

When wanting Dialogs in your App(s), do you have a hierarchy of Dialog classes or do you just do them "ad hoc"?

I tend to use DialogFragment, and ideally I don't have enough that a class hierarchy is needed

in particular, I tend towards DialogFragment classes that handle certain presentation styles, rather than ones tied to specific business logic

We have quite a few, some from DialogFragment, others from AlertDialog, and it's quite confusing imo.

So you want to display a list and have a dialog for that?

And then use it where the business logic requires something in list form?

I almost never do that -- if it is a list, it probably should be a regular-size screen (fragment or activity)

IMHO, dialogs are for things that have to interrupt the user and tend to be fairly small

We have a dialog to choose a user from, for example. Or a dialog to choose a file from the file system.

I doubt that I would do either of those as dialogs

but, that's my preferred UI/UX approach, and that of my clients

if you're going down that sort of "dialog all the things" UI/UX approach, you are more likely going to need some sort of class hierarchy to keep the code manageable

but, that's more of a gut instinct, and the details would certainly vary by project

I see.

I noticed that the result of a dialog is often passed by callback. Is that still the preferred way nowadays?

nowadays, I would try to use shared viewmodels

I was thinking as much, especially if DialogFragment is extensively used.

agreed: callbacks and DialogFragment do not play well together, as you lose the callbacks on a configuration change

let me take another question from hemanparbhakar, and I will be back with you shortly

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

Sure

yes

how to prevent memory leaks in android

and if there are any how to handle them in Profile

that is well beyond the scope of what I can cover in this chat

Profiler is too confusing

so /

?

I have a chapter or two on memory leaks in *The Busy Coder's Guide to Android Development*

personally, I primarily focus on integrating LeakCanary

as that does a nice job of yelling at you when you leak UI elements

beyond that, think through all of your singletons and other static data and make sure that they cannot grow indefinitely

so, overall, I recommend that you review those chapters, and if you have more specific questions, I can try to answer those in some future chat

ok

let me switch back to Kai, and I'll return to you in a bit

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

Yes

Any pointers on how to best conntect a ViewModel to a Dialog?

Like won't I be making a lot of custom Dialogs that are only used in one place?

While I could be making reusable ones

well, that's a bit like asking if you will be making a lot of custom activities/fragments :-)

Current Example would be a Dialog with a Title, a Description and an Inputfield (EditText)

if you want a general-purpose dialog like that, you will create a matching general-purpose viewmodel

so, if we have an SimpleInputDialogFragment, we have a SimpleInputViewModel

And then I share the SimpleInputViewModel with the ComplexFormularFragment

yes

where the SimpleInputViewModel has a LiveData<SimpleInputResult> or something, where SimpleInputResult tells you if the dialog was accepted or cancelled, and what the contents of the EditText were

And I guess that would be a Sealed Class if one was using Kotlin

yes

alternatively, you could just have a single SimpleInputResult with a status field (such an wasAccepted boolean) and a field with the EditText contents

About LiveData: I would get the SimpleInputViewModel in my ComplexFormularFragment and observe the SimpleInputResult from SimpleInputViewModel?

I am still not sure how LiveData works ;-)

yes

let me switch back to hemanparbhakar, and I will come back to you later

hemanparbhakar: your turn! do you have another question?

what the differences between when we intialize Alertdialog(this) and Alertdialog(getApplicationContext())

do not do the second one

y so ?

when it comes to UI stuff, always use the activity as the Context

Application does not know anything about themes

reason ?

whereas Activity does

ok so always to this right ?

yes: if you are showing a dialog, use the activity as the Context

using the Application as the Context for things like file I/O (getFilesDir()) or even getting at string resources is fine

but anything that might be affected by styles and themes needs to use an activity that has those styles and themes

ok

let me take another question from Kai

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

Let's say you have a form and that needs a user. How would you go about picking one from a list of users?

choose the user before showing the form, probably

IOW, use more of a wizard style than a window-and-dialogs style

if the form has to be presented first, then I would have the choose-a-user button bring up a regular-size fragment, even if it happens to be wrapped in a DialogFragment for control flow

IOW, there is "dialog as a small window" and "dialog as an interrupt to the existing screen", which aren't strictly tied

So as much full screen as possible?

yes, because not everyone has large phones

wasting screen space for a dialog aesthetic IMHO isn't user-friendly

So I guess quite a few of our Dialogs would be Fragments if it was your app

Like the "select file dialog" and "select user dialog"

if those are true "small window" dialogs, then yes

but, bear in mind that most of the time, I'm not the one coming up with the UI designs -- professional designers are

most of *them* only use small-window dialogs for simple messages and confirmations

(at least, of the designers that I have worked with)

and so to an extent I have adopted their design patterns

We have Dialogs with Tabs in them, for folder selection for example :D

yeah, I'm not a fan

thanks for the input, I guess I have some more to think about now

Our BaseDialog class that extends DialogFragment has callbacks in them btw. I wonder how or rather why it works :D

if your development team is like many development teams, they don't think about configuration changes much :-(

for example... does your app support landscape?

It saves two DialogInterface.on*Listeners

It actually does

Which makes me wonder why it works.

then make sure you test those DialogFragments where you display them, then rotate the screen

the activity (or parent fragment) displaying the DialogFragment needs to know to reconnect any callbacks after the configuration change

Test those? You mean test them by rotating the screen or write tests for them?

I'd settle for "test them by rotating the screen"

Maybe that is how it's done, that the Fragment reconnects

that's certainly doable, but it's easy to forget

part of the advantage of the ViewModel+LiveData approach is that getting the core functionality to work also covers you for configuration changes

I think I really like the idea of having my ViewModel in my Dialogs

I guess it would make quite a few things easier

personally, I think of it less of "easier" and more of "more likely to do the right thing in more scenarios"

Well, yes

if it happens to be less typing or otherwise easier, that's a nice side benefit :-()

"Easier" in "less to forget and less places to look at"

(sorry, that was :-) with an emoticon typo...)

right

I am lazy and forgetful, so I need to make things "simple"

and that's all the time I have for now, so that's a wrap for today's chat

the next one is Saturday at 4pm US Eastern

have a pleasant day, and stay healthy!

Same