hello, Gary!

how can I help you today?

Hi Mark,

I'm having a problem with ViewPager that hopefully you can point me in the right direction to resolve my issue.

I can try

I have a ViewPager with 5 static pages. Swiping horizontally works to move between the pages.

My issue appears when trying to add a new fragment to the ViewPager.

I’ve found a lot of help online about adding a new fragment to the end of the list, but I want to add the new fragment above an existing fragment, so that there are still only 5 pages.

meaning, adding a sixth page?

when you say "above", do you mean in a vertical LinearLayout or something?

I mean stacked, so that the back button will work on that page. Here's a better example....

Here's the base ViewPager [1] [2] [3] [4] [5]

Here it is after adding fragment a to screen 2 [1] [2:a] [3] [4] [5]

Here it is after adding fragment b to screen 2 [1] [2b] [3] [4] [5]

make sense?

and what does [2:a] and [2b] signify?

in particular, I am confused by your use of the verb "add"

are 2, a, and b all visible in the [2b] scenario?

No, they aren't visible. I only want the top fragment to be visible.

OK

In the fragmentTransaction, I've tried both .add() and .replace()

OK, let's back up a step

are you using native fragments, or the backport from android-support-v4.jar?

support library

and the five pages (and hence your five bracketed numbers) are fragments?

yes

and what are you using for a PagerAdapter implementation? FragmentPagerAdapter? FragmentStatePagerAdapter? something you wrote to the PagerAdapter API yourself? something else?

An extended FragmentPagerAdapter that sets up the initial state of [1] [2] [3] [4] [5]

OK

what you want will not work with that setup as it stands

basically, FragmentPagerAdapter/FragmentStatePagerAdapter do not like others messing with their fragments

what should work, at least in theory, is nested fragments

That's kind of what I figured, since I've tried lots of things and nothing has worked.

for page 2, rather than having your FragmentPagerAdapter return fragment 2, you'd return some sort of fragment that itself holds a fragment 2

I've never used Nested Fragments. Is there a chapter in the book describing them?

it's in there somewhere, I think :-)

see "Hosting ViewPager in a Fragment"

in the ViewPager chapter

plus intro coverage of nested fragments in the fragments chapter in the "Fragments Within Fragments: Just Say “Maybe”" section

to use your notation, your FragmentPagerAdapter would set up [1] [[2]] [3] [4] [5]

and you would run your replace() FragmentTransactions against the child fragment manager of the outer fragment wrapped around [2]

makes sense

so you wind up with [1] [[2b]] [3] [4] [5] after two such replace() transactions

now, whether the BACK button will work "out of the box" this way, I can't say

on the whole, I'm not a huge fan of navigation within the page like this, so I haven't tried any of this

Is there an alternative pattern that you'd recommend? This is a client project so I'm trying to implement what they've specified.

either [2] should be launching a separate activity for a:b, or the whole thing shouldn't be in a ViewPager, IMHO

the problem comes in with the BACK button

suppose the user adds a and b

now they switch to page 3

now they press BACK

what happens?

and, do you feel confident that all users will agree that your answer makes sense? :-)

good point

Thanks for the help

you are very welcome!

I'll give these suggestions a try and if I get stuck, I'll be back on Thursday ;)

OK, sounds good

hello again!

Forgot I had one other unrelated question...

I noticed in the latest version of the book you've "de-Sherlocked" everything.

not everything yet

the core chapters are still Sherlock-ful

I have a lot of code that is sherlocked.

though they too will be de-Sherlocked in version 6.0

Wondering your thoughts if I should update legacy code, or just not use it for future projects?

tough to say

de-Sherlocking is not all that tough

at the same time, continuing to use ActionBarSherlock is not a crime, either

I am de-Sherlocking as part of a general push to move the book to be centered on a minSdkVersion of 15

I'll move the Sherlock coverage to a chapter in the trails, next to the AppCompat chapter

hello

OK, thanks again Mark.

if you want to use that legacy code on a min 15 project, you can either keep using ActionBarSherlock, or you can de-Sherlock it

Gary: no problem, happy to help

anil: glad you were able to get in! It's your turn -- do you have a question?

thank you!

how I can get the system to start my service upon startup? On SO and in your book, you have a broadcast receiver listening to BOOT_COMPLETED. Is that the recommended way?

it's pretty much the only way

unless you're making a ROM mod or something

it's certainly the most straightforward solution

at least in most cases

ok

will do

2) In your book, the binder is a static, inner class. How can it access the outer methods in the Service class? In your BshBinder example, it does not.

there is no outer methods of a static inner class

a static inner class is syntactic sugar, identical to having a regular Java class

I meant, if I have a method in the Service.

that doesn't change matters

a static inner class of the service cannot access the service itself

why is this code on the service and not on the binder?

is it kept static because it must be instantiated independent of the outside?

no, it is static to help minimize the coupling between the components

I'm not a huge fan of binding

one of my worries is GC-related concerns

it's entirely possible the Binder will work fine as a regular inner class

in fact, I think I had it that way once

I didn't need it to be a regular inner class, and so in a code cleanup pass a couple of years ago, I made it a static inner class

to your question, should I move the code from the service into the binder?

IMHO, if you're using the binding pattern, more of your business logic probably winds up centered on the binder, not so much on the service itself

I thought a binder should not have functional application logic. I thought the service does the work.

:: shrug :;

that's not how I'd approach it, but I generally avoid binding anyway

why so?

I prefer loose coupling, and binding is tight coupling

I'd rather use startService() and an event bus

but its just an interface. corba etc depend upon interfaces

it is state

state that has to be managed across configuration changes

admittedly, the retained fragment pattern for managing that state is a lot easier than pre-fragment solutions

I noticed the term in your book: configuration changes

and for true IPC scenarios, there are going to be cases where binding is worth it

can you please clarify?

ok

in the "Resource Sets and Configurations" chapter

a configuration is a statement of device capabilities that, in Google's eyes, might cause us to want a particular set of resources

I will read it. but I cant think of state being maintained

a configuration change is when the configuration changes on the fly

such as when the screen rotates from portrait to landscape

the ServiceConnection needs to be used to unbind

and that is state

ok

moreover, you cannot unbind the old activity instance and rebind in the new activity instance, as the service will be destroyed in between (if nobody else is bound to it)

and so you need to pass the ServiceConnection, and the Binder, from the old activity instance to the new one

again, a retained fragment makes this relatively easy

I did not realize that

so you recommend I use a started service?

it's more that *I* would use startService() and an event bus for in-process use

plenty of people use bound services

I have never used an event bus

I added coverage of event buses to the book a couple of versions ago, and the tutorials now demonstrate the use of one

will have to read up on it. hope it isnt complex

it's pretty easy, at least for simple scenarios

ok, will do.

thanks!

you're very welcome

bye