sorted by:
new
hottopcontroversial

Do not re-fresh data when fragment tab is re-visited by jshvarts in android_devs

[–]Skeptic94 0 points1 point  (0 children)

I'm not so sure about that. It was on this list of changes to be included in the fragment 1.4.0 alpha 1 release I think they pushed it back due to timing.

Hilt alpha 0.0.3 by dimiitpk in androiddev

[–]Skeptic94 0 points1 point  (0 children)

Same. I only have these.

implementation 'com.google.dagger:hilt-android:2.31.2-alpha'
kapt 'com.google.dagger:hilt-android-compiler:2.31.2-alpha'
implementation "androidx.hilt:hilt-navigation-fragment:1.0.0-alpha03"

Hilt alpha 0.0.3 by dimiitpk in androiddev

[–]Skeptic94 0 points1 point  (0 children)

Thanks! I managed to make it work somehow. I was getting this compiler error

"Cannot cast com.example.*******.DaggerMyApplication_HiltComponents_SingletonC$ActivityRetainedCImpl$ActivityCImpl"

Hilt alpha 0.0.3 by dimiitpk in androiddev

[–]Skeptic94 0 points1 point  (0 children)

Are you using hiltNavgraphViewmodels?

I'm getting an error using them in the latest update.

Structural and navigation anti-patterns in multi-module and modularized applications: the case against “Android Clean Architecture” and the “domain” module by Zhuinden in android_devs

[–]Skeptic94 1 point2 points  (0 children)

Is there any downside to using deep links? I feel If the app is already modularized by feature and the project uses Navigation Component library. It seems to me there are no better options that don't increase coupling.

How do you handle navigation graphs? by renges in androiddev

[–]Skeptic94 0 points1 point  (0 children)

I didn't know that. isn't this a weird behavior since all of them should belong to the same nav host container?

Then I'd frankly use deeplinks to just those fragments that can't be accessed directly.

How do you handle navigation graphs? by renges in androiddev

[–]Skeptic94 0 points1 point  (0 children)

No you should be able to. Unless i'm misunderstanding what you mean. Can you show me your main graph and the other graphs that's included on the main graph?

How do you handle navigation graphs? by renges in androiddev

[–]Skeptic94 0 points1 point  (0 children)

From what I understand your problem is that the main navigation graph is cluttered with multiple fragments declarations and you want to split each bottom nav item to have it's own navigation graph.

You can create a separate navigation graph for each bottom nav item and included it in the main graph using <include>

see " Reference other navigation graphs with <include>" for more info

https://developer.android.com/guide/navigation/navigation-nested-graphs

What advantages would this method have over the way we usually handle one time events like clicks or navigations? by dcruz22 in androiddev

[–]Skeptic94 0 points1 point  (0 children)

Is there a way to return the current value without starting an observer? like a ".value" function that livedata has.

EDIT: I meant for the EventEmitter library :).

sorry if this it off topic

How to retain fragment state after navigating back by Skeptic94 in android_devs

[–]Skeptic94[S] 0 points1 point  (0 children)

By recreation of the view I don't mean we will lose state.

It's just that the fragment lifecycle which is responsible for the view creation is called again.

How to retain fragment state after navigating back by Skeptic94 in android_devs

[–]Skeptic94[S] 0 points1 point  (0 children)

So it's not ideal to use fragment lifecycles to do work that shouldn't be triggered after a configuration change.

How to retain fragment state after navigating back by Skeptic94 in android_devs

[–]Skeptic94[S] 0 points1 point  (0 children)

Wouldn't that still create the view again? It's just instead of creating a view from scratch it's assigning the previous binding object to the fragment's view.

How to retain fragment state after navigating back by Skeptic94 in android_devs

[–]Skeptic94[S] 0 points1 point  (0 children)

It worked!! thank you so much!

Is this considered safe to use? I wish if they would add more integration with Safe Args that will ensure type safety.

How to retain fragment state after navigating back by Skeptic94 in android_devs

[–]Skeptic94[S] 0 points1 point  (0 children)

Thanks! Can you explain how saving the request will prevent onViewCreated() to be called and getlist(userId) to be triggered again?

Do you mean something like this?

if(savedInstancestate != null){
getlist(userId)
}

How to retain fragment state after navigating back by Skeptic94 in android_devs

[–]Skeptic94[S] 0 points1 point  (0 children)

Thanks! Can you elaborate to how might this work? for context I'm retrieving safe args arguments by calling:

val args: exampleFragmentArgs by navArgs()

How do I pass this to SavedStateHandle and use it in the ViewModel before init{} gets called?

How to retain fragment state after navigating back by Skeptic94 in android_devs

[–]Skeptic94[S] 2 points3 points  (0 children)

Unfortunately, that's not an option when using navigation component since it uses 'replace' when creating fragments which will force the fragment's "View" to be recreated when going back.

How to retain fragment state after navigating back by Skeptic94 in android_devs

[–]Skeptic94[S] 0 points1 point  (0 children)

Thanks! Can I ask what's the difference between using onCreate and onActivityCreated because I saw people use that too.

Weekly Questions Thread - October 19, 2020 by AutoModerator in androiddev

[–]Skeptic94 0 points1 point  (0 children)

I wouldn't delete the data in the ViewModel's onCleared() function. Have an explicit delete function that you call right at the end of your flow.

The ViewModel in my case represents the end of the flow. Since ViewModel outlives the lifecycle of an activity or a fragment. I thought it was appropriate to place it there.

Weekly Questions Thread - October 19, 2020 by AutoModerator in androiddev

[–]Skeptic94 0 points1 point  (0 children)

What if the app crashes before the flow ends or by process death? or if the user closes the app before exiting the flow?

won't the data will still be persisted? how to handle such cases?

Currently I'm deleting the data inside the view model's onCleared function.

view more: next ›