hello, Derek!

how can I help you today?

Hi Mark

I have a question regarding app widgets

OK, I can probably help with that

the onEnabled method of an app widget gets called the first time a user adds the widget to the home screen. Another way it is called is if the device reboots with the widget already on home screen.

My question is whether can I distinguish between how the onEnabled method is called?

I doubt it

so if the onEnabled method is called on device reboot (instead of user interaction), I want it to be handled differently

you could keep track of whether you have ever been enabled before (e.g., SharedPreferences)

on the first onEnabled() call, that will be false, so you do whatever logic you need for being added to the screen

(in addition to setting the preference to true)

later onEnabled() calls would see a value of true, so you do whatever logic you need for reboots or other major launcher changes

okay, I think this is an idea I can integrate into my application.

thank you for your time

happy to help!

hello, trocchietto!

how can I help you today?

ciao Mark, ik zou graag weten iets over RXJava en LiveData

ops sorry

I spoke too much Dutch today

I want to ask you something about RXJava in combination with LiveData

OK, I can probably help with that

namely my team usesrxjava everywhere

sorry

no problem!

namely in short I have the feeling that all the error we get due to IllegalStateException are due to the fact that we should use LiveData to wrap Observable and. Single from RXJava

what is triggering the IllegalStateExceptions?

onSavedInstance

is a well known old school issue

I would be surprised if onSaveInstanceState() is somehow affected by a choice of reactive frameworks, though

yes is the combination

rxjava was not tough to manage the SDK from Android

causing every kind of side effects if used in the wrong way

but the point is:

do you think that wrapping Rxjava inside Live data could be a way

to prevent this kind of errors

I guess live data viewModel is a solid construction Android engineer use to prevent some issues

well, again, I do not really understand how onSaveInstanceState() is affected by your use of RxJava

oh is something caused by startActivity for result

when go back to the previous activity fragment often crashes

our crashlytics has often this kind of issue

¯\_(ツ)_/¯

I typically use LiveData for delivering updates to activities and fragments, for viewstates to be rendered to views

where RxJava handles everything else, from the viewmodel on back

sometimes, though, I will expose RxJava from a viewmodel, such as for events, since LiveData does not model events well

is this issue IllegalStateException cannot perform this action after onSaveInstanceState

there are numerous blog that describe this lifecycle issue

because activity already saved UI state and could be destroyed

that feels like you are doing navigation at inopportune times

mmh

I use Anko

I have never used Anko, so I know very little about it

that has these sugar explicit intents

and furthermore is deprecated

and then we use on top of everything rxjava

I have the feeling android is built on layers

a layered architecture is typical in modern Android app development, if that is what you mean

no

I do not speak about uncle bob thing

I say that Android imo junior opinion is built as pompei

from palm os idea as broadcast, to java xml and old school patterns, adding above fragments, then one uses also not official libraries as dagger and rxjava and boom crashes everything

again, ¯\_(ツ)_/¯

if using Dagger and RxJava always crashed apps, nobody would be using those libraries, because they would have a terrible reputation

true

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

please take care of Daniel is fine with me

OK

Daniel: hi! how can I help you today?

I think I'm ok at the moment, just re-subscribed and saw there were office hours and figured I'd check it out

thanks for renewing!

I may ask about testing or something shortly but right now I'm just reading. Appreciate your resources.

glad you like them!

but, yes, these chats are mostly for getting answers to your specific questions

in any case, if either of you have a question, go right ahead!

Have you any resources on Jetpack compose at the moment?

in terms of books, no

I run a Compose newsletter: https://jetc.dev/

That's great actually, thank you

I hope to write more about Compose in the coming months

the dev releases were *really* fluid in terms of APIs, so I eventually got fed up and decided to wait until the alphas started shipping

so, with luck, I'll have something in early 2021

I was gonna say, I figured I'd start learning once the API was stable, I hope alpha has been more stable than the dev preview thus far

there hasn't been nearly as many big API changes

I'll get out of here. Thanks for providing this. You two have a good day

you too!

Thanks for that by the way, I'll give it a look son

have a nice week end Daniel

So is not a good practice, dear Mark, to wrap RXJava inside LiveData

I am not certain what you mean by "wrap"

you would rather use them separately in the same app

and, I am not certain what you mean by "separately" :-)

well use case 1

namely : Expose your Rx Observable from the repository, and subscribe() to it in the ViewModel. In the subscriber's onNext(), use setValue() to wrap your viewstate object in a MutableLiveData, and expose that as a non-mutable LiveData to the UI. Manually dispose the subscription in onCleared().

that's pretty much what I've done on the projects that I have been helping on for the past couple of years

so this is a wrap right?

you have the Observable kinda inside LiveData

so LiveData is the superhero start that speaks with ViewModel

and take care that the lifecycle and the reactive magic works as a charm

and BTW do you have in your repository something as RXJAva with Live Data I can pull

I would not use "wrap" as the verb for that pattern, but otherwise, I have had reasonable luck with the pattern

?

I see

I have not written about RxJava in the second-generation books

is a pattern Like, I learnt from a really opinionated GDE, never do strange thing

I have some RxJava samples in *The Busy Coder's Guide to Android Development*, but that is getting a bit old

so I do not have a public repository to point you towards that demonstrates the pattern that we are discussing

yeah that is the problem with development, but should be fine I am a fun of SICP in Lisp

long term, I hope that coroutines can replace all of this

well thank you anyway, you gave me a reasonable tunnel light exit

you're welcome!

as I told you some other sat ago I am going into the magnificent world of pseudo declarative reactive flutter

OK -- I won't be able to help you with Flutter, other than at a theoretical level

in December google should release a plugin official that can be officially interoperable with existing android native apps

I know but android is far to go away

and a good flutter dev have to know android and objective c to write plugins

I praise god for the complexity of Android that makes every other ecosystem easy to catch

btw my senior does not want to migrate to coroutines :(

hope they will make rxjava deprecated

well, migrating to coroutines *is* a fair bit of work

and since RxJava 3 is out, it is not going away any time soon

zucht!

you know I hate the idea that OO paradigm should become kinda functional/reactive

focus in the k in life, I am turning almost fifty and I learned that

use scala if you want a functional feeling

mixing things is really not good imo

coroutines are really cool

they definitely have their advantages

and match OO sequence, selection, iteration

because make concurrency sequential

where I have all these rxjava publisher and Jake Wharton behaviour relay that make the poor Dijkstra crazy from the other world

is like we are coming back to the games you were programming in the eighties with GOTO

OK, that's a wrap for today's chat

the next one is Tuesday at 8:30am US Eastern

have a pleasant evening!

have a nice day

thanks