howdy, Mark!

how can I help you today?

Nice to be here.

I've been looking through your code for quite awhile...

and I've finally bought a Warescription. I am now a part of the team. I do have some questions.

cool! ask one, and then we can give Justin (howdy!) a turn

Your OrderedActivity demo design pattern covers about 73% of what I've been working through, which is quite remarkable.

My main activity will be going through a cycle of tasks that are triggered by the repeating alarm.

More accurately, the activity would be reminding the user of a task the user needs to do at that alarm time.

What is the cleanest way to have the task index increment, if the activity is in the background? I think I'm missing a simple technique in which the notification manager can send a note to the background activity to have it increment.

the cleanest way is not to do it that way, IMHO

I'm all ears.

activities that are not in the foreground may not even exist, if Android terminated your process

hence, there may not be an activity to update

Good point. Can we catch that?

instead, background activities should pull updated data when they return to the foreground, such as in onResume()

as to where to put the task index, that would need to be in a persistent store (database, SharedPreferences, or other file)

you might elect to cache it in a static data member, in the off chance that the process sticks around long enough to be reused

and, you might use the ordered broadcast pattern to trigger an update of the foreground activity, if you have one

SharedPreferences were what I was thinking of. Glad to get a confirmation, although I'

I'll try the static member approach as well.

let me take a question from Justin, and I'll swing back to you in a bit

Thanks. I'll send my next question later on.

Justin: do you have a question?

Hey there Mark..

Sort of...

I've asked about Parcelable before. I know it's used for IPC with bound services....

(not just bound services)

I know someone on my team is trying to use it to pass complex objects between activities in Inents

Intents

I can't see where anyone is doing that

I do not completely understand what you mean by "I can't see where anyone is doing that"

OK, fair enough. Just been searching Google for examples of people using Parcelables to package up complex objects to pass between Services to Activities, or between Activities

oh

well, I definitely know people are using it, as I see questions on it from time to time

I do not think that it is a terribly popular approach

It seems like it could be a bad approach especially with really complex objects whose data you aren't even going to be completely using....

By bad I mean it will be slow

"slow" is a relative term

Agreed

it will be way faster than persisting them to disk, for example

So using a parcelable for this wouldn't necessarily be an incorrect approach then?

That's really what I'm trying to determine

Was that the intent (no pun intended) of parcelable usage?

Parcelables in Intent extras is a code smell IMHO, but not because it is Parcelable, but rather because it is a custom Parcelable, suggesting that the model layer needs a bit o' work

To pass complex objects around anywhere? Not just for IPC?

Parcelable is used in IPC, but not just bound services

Bundle is Parcelable

PendingIntent is Parcelable

RemoteViews (think app widgets) is Parcelable

those don't scare me much

So it's meant for IPC, but if I'm passing data from a service to an activity in the same process, I'm not using IPC, so does it still make sense? I don't want to use something just because it will work, but rather because it was intended for that purpose.

And if it isn't, I'd like to know what the proper tools are to use

That's really my question

can you give me a somewhat more concrete example of what one of these Parcelables would be?

It would contain lists of complex types, like List<AComplexClass>

OK, then what is AComplexClass?

It would have a lot of primitive member types, maybe some more List<T> objects as well

OK, this isn't working...

let's try this...

suppose you were creating an app that was displaying restaurants

you have a ListActivity to show the restaurants

you have a separate activity to show information about a restaurant

and you have a service that does something in the background related to the restaurant

none of those components should "own" a restaurant

there should be something else that manages the restaurants, outside of these components

so an activity would not pass a restaurant to a service, but pass an identifier that would allow the service to go get the restaurant that is needed

out of a content provider or just a sqlite database

right?

or some sort of POJO cache, perhaps in a RestaurantManager singleton

backed by a content provider or SQLite database

or JSON file

or "the cloud"

or whatever

In your example, they're trying to put the POJO into the intent using Parcelable and pass that from the service to the activity

and if the POJO is part of the model of the app, I wouldn't do that

now, if the POJO is, say, the contents of a lengthy form that the user filled in (e.g., complex search criteria), where it is not part of the model, then a Parcelable wouldn't faze me too much

(though I'd probably just use a bunch of individual Intent extras in that case)

noodle on that a bit, let me take questions from others, and I'll swing back to you

Tom: do you have a question?

OK, that's what I wanted to know. I've been taking the approach of having the service put the relevant data into a database and passing an ID from the service to the activity. I like your explanation of good usage, I'm good now, thanks.

Just curious about some stuff regarding the lifecycle of a fragment

In particular setRetainInstance()

As I think about it, I have visions of leaks happening with careless use of .setRetainInstance(true).

is there any sort of guidance?

um, well, not really

I mean, I don't know how to address abstract "visions of leaks"

can you be a bit more specific about your concerns?

Well, if the fragment instance isn't destroyed, it becomes "orphaned" does it not? I mean, there is an instance of a fragment that isn't associated with an Activity.

no

setRetainInstance() only matters with configuration changes

Ahhhhh! That makes more sense now.

once the activity is permanently destroyed (e.g., BACK button), the retained fragment goes "poof"

(though you need to supply your own "poof" sound effect)

I thought that when the activity is destroyed, the fragment could, in theory, live on.

nope

Mark: do you have another question?

OK

Yes. I have an app that uses a mapview, but uses it in two activities. In the main activity, the mapview takes up the entire screen, and in a separate activity, the mapview takes up a small portion. When I go from my 2nd activity to my first...

Justin: do you have another question?

I'm still noodling :-)

Mark: please continue (though you can't have two activities with a MapView in a process)

That might partially explain my issue. When I go from my main activity to activity number 2, everything's hunky dory...

But when I backtrack to my first activity, the mapview no longer takes up the whole screen.

The size of the mapview on the returned activity matches the smaller mapview on activity 2.

Quoting the docs: "Only one MapActivity is supported per process. Multiple MapActivities running simultaneously are likely to interfere in unexpected and undesired ways."

Well, this is certainly unexpected and undesired. I'll do some redesign. I do have another question, but I'll get back in the queue.

yeah, the Google Maps add-on has lotsa warts

Justin: you done noodling yet?

OK, so let me ask this again about Parcelable....

When making a class Parcelable and passing the parcelable between process boundaries, is the only real purpose to serialize and deserialize the object, or is there other things happening as well? (not sure if that question is clear or not)

AFAIK, it is just serialization

OK, sounds good. No other questions for now. I'll chime in to get readded to the queue if something comes to mind

OK

Tom: do you have another question?

No, just watching and learning. :)

OK

if anyone has any questions, chime in

I got one.

I've been looking for some example code that shows the use of gestures to move objects around on a screen. Think of a solitaire game, or chess, etc...

Most examples I've seen deal with transposing an entire canvas, not an individual view.

well, I have not done much outside of GestureDetector, which simply detects gestures and does not apply them

I also ripped a drag-and-drop ListView implementation out of the AOSP Music app a couple of years ago, but because I don't grok all the touch events, I discontinued support for it

the only code I have that resembles what you are describing is the drag-and-drop MapView one

Examples are few and far between. My guess is that one could create a collection of views that implement GestureDetector methods.

I'll take a look at your dNd MapView. And I'll get back in line for another question.

you might create a collection of *containers* that do that, but I am skeptical

and we're in a free-for-all mode right now, so feel free to ask away

(BTW, the map sample is https://github.com/commonsguy/cw-advandroi…)

Yeeha.

Here's a simple one, regarding the precedence of onRestoreInstanceState() and onResume(). I could figure this out myself with some Toast calls (but I'm lazy). I hope that onRestoreInstanceState() happens *before* onResume().

I think you are correct, though I am not 100% certain -- let me check

hmmmm...

On a similar note, I've seen conflicting opinions on the call to super.onSaveInstanceState() or super.onRestoreInstanceState(). Should the super be called first? Don't worry about that precedence. I'll do the Toast.makeText() thing to figure it out.

I am having difficulty tracking down when onRestoreInstanceState() is called

my understanding is that it should be shortly after onCreate()

with regards to chaining to the superclass in onSaveInstanceState()/onRestoreInstanceState(), I do not expect it matters whether you call that first or last

Ok. Thanks, Mark!

Thanks for the advice. I'll catch you at another office session some time.

if anyone has a question, chime in

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

next one is 10am Eastern on Tuesday

have a pleasant day!

Great, see you then, take care!