hello, MyWay!

how can I help you today?

hello Mark, how are you? :P

oh, I'm becoming crazy with this: http://stackoverflow.com/questions/38856176/tab... maybe you have some idea about it

" I have a button, Close, which calls mAdapter.remove(position); "

what PagerAdapter are you using?

I'm using your implementation

oh

the ArrayPagerAdapter :P

I'm loyal eheh

so, if you click Close, the TabLayout scrolls back to Tab 1?

yes

that's bizarre

now, the ViewPager folk probably aren't testing with my adapter or other places where pages come and go dynamically

so, I won't be shocked if there's a bug here

I'd file a bug report at http://b.android.com

I've placed many breakpoint and everything seems fired correctly

does this happen for every remove(), or are there certain criteria for which remove() calls break?

to let it happen I had to add a bit of fragments

"a bit of fragments" -- do you mean a lot of fragments?

probably there are others way, but I've found this one always happening

in the example on github there are 50

but I haven't tried with 30

I'll try it now

OK

I have used TabLayout, but nothing past a book demo

eheh

either I'll use a different tab implementation, or in some cases I have moved over to RecyclerViewPager

happening with 30 too, yes

with 20 too

what positions? 45 -> 46 were towards the end of the range

mPager.setCurrentItem(16);

hello, Ivano! I will be with you in just a moment!

(with 20 tiotal)

total*

MyWay: OK, so again, it's towards the end of the range of possible positions

(hello Mark and MyWay)

if I had to guess, TabLayout or ViewPager has a bug

now I've tried with mPager.setCurrentItem(6);

and it's showing from test14 to test18

like the opposite :P

I'll kick the tires on your sample later and see if I see anything -- if I do, I'll chime in on the SO question

let me take a question from Ivano, and I'll be back with you shortly

Ivano: your turn! do you have a question?

well is quite a generic one...

thank you

:) basically I want to sync my app. i mean of course the db local with one server. I am runingh trough long difficulties

after exhaustive research i decided to go ith firebase, but i discovered that is not the best solution when you have complex sql queries( fb is nosql) so i decided between php and node and i decided php for time constraint...i would like to know conceptually in which phase i should insert a sync adapter

my architectural steps are 1) host php pages 2) call a connection from the db 3 retrieve results with retrofit. where the syncadapter fits?

it might not "fit", depending on what you are doing

mmh?!

personally, I have not implemented a sync adapter, as I don't like a lot of the constraints around it (no control over timing, tight tie into Android authentication system, etc.)

i see

and how you manage efficiency battery from an user prospective?

a sync adapter is not free of battery cost

it will have roughly the same battery cost as a non-sync adapter approach

as the battery cost will be driven by CPU and radio time, mostly

yes

and that should not change dramatically whether you are using a sync adapter or a JobService or something from AlarmManager or something from a GCM/FCM push request or anything else

but a service underground that continously connect to the internet can be disastrous

I think the risk is that "many small requests from various app" vs "one large request together"

and none of the things that I listed have anything to do with a continuously-running service

ok i need to go more deep on that

yes I saw the magnificent udacity video on this subject:)

MyWay: correct, though JobService/JobScheduler would address that, at least on Android 5.0+

nice, I didn't know it

but i read from your blog that the new/old android n does not support alarmManager

all versions of Android support AlarmManager

Doze mode and app standby make things complicated on Android 6.0+

but then only if you are trying to do frequent work

ok thanks

if you're thinking a sync adapter, then pretty much you are saying that you do not care how frequently the sync occurs, in which case Doze mode should not be an issue

and so long as "once a day" is sufficient, even app standby should not be an issue

so, you have two somewhat-separate issues:

1. how are you implementing the actual synchronization logic, in terms of each side telling the other what changed?

2. what is your trigger for executing that synchronization logic?

(once a day is not sufficient, think over a listener that post to external db when new items are added locally)

that s a mckinsey approach:)

however, that flow is one way (client->server) and assumes that the user is actively using your app

OK thanks need to study more and will come soon back to you eventually

OK

let me take another question from MyWay, and I will be back with you shortly

MyWay: back to you! do you have another question?

no need for other questions but thanks

oh, no I'm reading and still playing with that bug! :P

OK, if either of you come up with another question, feel free to ask

(:))

time to eat for an Italian in the Netherlands. thanks Mark and MyWay, good whatever to everyone!hasta luego

ah, you're italian too :P

have a pleasant evening!

thanks. my way segui sempre la tua strada( follow always your way)

ciao

bye

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

as usual, the transcript will be posted to http://commonsware.com/office-hours/ shortly

the next chat is Tuesday at 7:30pm US Eastern

have a pleasant day!