Hi Mark!

hello, Lucy!

how can I help you today?

Android makes use of a lot of anonymous classes...or at least maybe Parse does and I'm using Parse. My question has to do with how to obtain values generated in the anonymous class. For example, is it an OK pattern when using anonymous inner classes to have a private method on the enclosing class which you can call from the anonymous class and pass values “out”?

that's fine

Hm. Maybe this is more of a Java question than Android.

the heavy leveraging of anonymous classes is largely due to Java's lack of a "closure" concept prior to Java 8's introduction of lambdas

I see. So far I don't need to use this pattern much. But occasionally I do want to keep a value generated in the anonymous class.

My next question pertains to callbacks.

Well, asynchronous callbacks, that is.

For example, my class makes a request and the callback method is Done().

I wondered whether I can set a flag in Done that indicates that it finished? Its a similar question to the above, whereby I want to get news from my anonymous class.

um

what is supposed to happen when it is finished?

IOW, what is supposed to be paying attention to this flag?

Oh...here is what I'm using it for:

I have a user profile. When the user visits this activity I go fetch their data so they can change it. The data is returned asynchronously via the Done() callback. Actually the "flag" I'm using in this case is to hide the Save button and then set it to Visible in Done() when the asynchronous call finishes.

what thread is Done() being called on? the main application thread, or a background thread?

Maybe its normal to do what I'm doing? I'm not sure. :-) I need the user to wait until Done() is called back before filing out fields.

Done is being called on a background thread. We don't know when it will return but hopefully in 30 seconds or less.

well, with respect to "its normal to do what I'm doing", make sure that the user understands why you are trapping them for 30 seconds

The other way to do everything is to put everything inside Done(). Its just that Done() gets very long and spaghetti-like.

in this case, a flag is useless, as you have nothing waiting on the flag

have Done() do something to update the UI on the main application thread: runOnUiThread(), post an event on an event bus, post() on a View or Handler, etc.

Hm. You just gave me a thought. So far the fields with their profile are blank so they will start typing. But they won't get a Save button until Done finishes when, presto, it will appear!

yeah, that does not feel like a good UX

OK actually I see now what I need!

Maybe I can put something on the UiThread that indicates I'm fetching their user profile data.

My final question :-)

I'm using Shared Preferences to save a few values from app instance to app instance. Literally only a few values. But actually there are a bunch of values I'd like to also save. I wonder if, say, 5 arrays of up to 20 values each is too much to store there?

well, SharedPreferences has no direct means of storing arrays

it can handle Set<String>, but that's it

Oh. Hm.

if you need something more complex, you're now looking at something like converting the object graph to JSON and storing the JSON

Oh maybe that's what I saw. My values are actually a Set.

whether the JSON is stored as a string preference, or as a file, or as a BLOB in a database, would be up to you

Initially I was thinking of storing the JSON. Maybe I should still do that because the size of the data could be arbitrary.

Oh! It did not occur to me to save the JSON as a String.

there's a fine line between "keeping the data all in one place" and "cramming everything into a data structure that it is not suited for"

This is very interesting.

so, for example, in my TinyTextEditor sample, I am keeping the recent-documents list (EditHistory) as JSON

as I need ordering, and I lose that with Set<String>

but I still stuff the value in SharedPreferences

My motivation is that the user will have several lists of values that they will always use. I wanted to store them locally rather than fetch them over the network (optimization and reduce number of requests on server)

that's a somewhat dubious decision on my part

:-)

saving the data locally makes sense; whether SharedPreferences is the right container, I cannot say

I don't need ordering and the values are indeed a Set. I may try that!

Yes, agreed. If the data gets "large" then SharedPreferences is not appropriate maybe?

yes

in part, because the whole thing has to get loaded into RAM the first time you access the preferences

and you want that to be quick

OH. I had not thought of that.

OK, I'll need to move these values to a file.

I think that's all my questions for today!

OK

Thank you! Bye for now

Oh p.s. hope to see you at AnDevCon

That is, I hope I'm going. :-)

if you mean AnDevCon Boston, I'll be there

Yes AnDevCon Boston. I saw you will be there. I'll introduce myself if I'm there. Thanks again!

you are very welcome