Dec 11 | 9:50 AM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Dec 11 | 9:55 AM |
Guy W. | has entered the room |
Mark M. |
hello, Guy!
|
Mark M. |
how can I help you today?
|
Guy W. |
Hello
|
Guy W. |
struggling with a custom spinner adapter
|
Guy W. |
customising the Drop Down
|
Oleg T. | has entered the room |
Dec 11 | 10:00 AM |
Mark M. |
(BTW, hello, Oleg -- I will be with you shortly!)
|
Mark M. |
Guy: could you be more specific?
|
Oleg T. |
Good day
|
Guy W. |
I think it works now :-)
|
Mark M. |
um, OK, let me take a question from Oleg, and I'll be back with you in a bit
|
Mark M. |
Oleg: do you have a question?
|
Oleg T. |
Cheers. I do have a somewhat weird one
|
Oleg T. |
When we store instancestate in a Bundle. Where does the data actually live and for how long?
|
Mark M. |
the instance state is sent back to a core OS process, one that manages the tasks and back stack for each
|
Mark M. |
it will "live" as long as that instance state is still reachable, such as via the recent-tasks list
|
Mark M. |
your process, of course, may go away, which is why the state is held in a central OS process
|
Oleg T. |
Does it ever happen so that the data will be wiped out before we get back to it? say, something odd happens while the phone is being rotated?
|
Mark M. |
I don't know how to answer that
|
Oleg T. |
no worries. it must be a silly one since I'm an amateur
|
Mark M. |
I have never seen the saved instance state Bundle be lost during a configuration change, if that's what you mean
|
Dec 11 | 10:05 AM |
Oleg T. |
ok. i guess i'll pass the mic
|
Mark M. |
Guy: do you have another question?
|
Guy W. |
yes. thanks
|
Guy W. |
I have an intent that goes to Intent i = new Intent(Settings.ACTION_WIRELESS_SETTINGS);
|
Alex F. | has entered the room |
Mark M. |
(BTW, hello, Alex, I will be with you shortly!)
|
Guy W. |
after pressing back where do I need to refresh the view? app lifecycle
|
Mark M. |
onResume() is a typical spot, as that is called after both onCreate() and when you are about to return to the foreground from an input standpoint
|
Dec 11 | 10:10 AM |
Mark M. |
I assume that you are looking to refresh based upon changes the user made in Settings?
|
Guy W. |
yes
|
Mark M. |
I would start with onResume(), moving it elsewhere (e.g., onStart()) if needed
|
Mark M. |
let me take questions from the others, and I will be back with you in a bit
|
Mark M. |
Alex: do you have a question?
|
Alex F. |
Yes.
|
Alex F. |
When adding Fragments to a FrameLayout, the newest Fragment is stacked on top of the oldest. Is this stacking behavior dictated by the FrameLayout? My goal is to change this behavior so that Fragments are added behind the oldest Fragment.
|
Guy W. |
I tried onResume with a toast, and noticed it refreshed twice without going to the settings.
|
Mark M. |
yes, FrameLayout (and RelativeLayout) treat later children as being higher on the Z axis, therefore floating over earlier children
|
Mark M. |
(Guy: I will be back with you in a bit)
|
Guy W. |
thanks
|
Mark M. |
Alex: off the cuff, I do not know how you would go about running a FragmentTransaction that would add a fragment under an existing one
|
Mark M. |
what is your use case for having two fragments visible in the same container at the same time, anyway?
|
Dec 11 | 10:15 AM |
Mark M. |
OK, let me take questions from others, and I will be back with you in a bit
|
Mark M. |
Oleg: do you have another question?
|
Oleg T. |
i do
|
Oleg T. |
let me know is it's more than one and i'll wait. there you go:
|
Oleg T. |
View paste
|
Mark M. |
"Are there any standards on which implicit intents the standard apps must support?" -- whatever is documented in the Android SDK
|
Mark M. |
unfortunately, Intent structures tend to be documented all over the place
|
Oleg T. |
so it is a bit of a problem since different vendors ship different apps
|
Mark M. |
ah
|
Mark M. |
the Compatibility Definition Document will help there
|
Mark M. | |
Mark M. |
it lists the core apps whose implicit Intents are considered to be mandatory to be supported by the device when it ships
|
Oleg T. |
i'll have a go at it, thanks
|
Alex F. |
Mark, the idea is to show a fragment (most likely nesting a ViewPager inside this fragment) and after a specific action (swiping past an x number of pages), load a new fragment behind the current and when reached at the end of the ViewPager, detach the top fragment and revealing the added fragment.
|
Mark M. |
Oleg: that being said, devices sans legal copies of the Play Store will not necessarily honor the CDD, users might install third-party replacement apps, and the Compatibility Test Suite does not necessarily catch all device manufacturer bugs in this area
|
Mark M. |
(Alex: I will be back with you shortly)
|
Dec 11 | 10:20 AM |
Oleg T. |
understood, Mark
|
Mark M. |
Guy: onResume() is called after onCreate(), on configuration changes, and when your activity is returning to the screen after having been in the background
|
Mark M. |
your job in onResume(), as with all callback methods like the lifecycle methods, is to be quick and cheap
|
Guy W. |
thanks. I'll try it again later
|
Mark M. |
Alex: why not replace() the ViewPager with the alternative fragment "when reached at the end"?
|
Mark M. |
IOW, why does it have to be there in advance? and why does it have to be there *after* the ViewPager was added?
|
Alex F. |
To animate the top fragment out of view, revealing the added fragment
|
Mark M. |
then put the to-be-revealed fragment in place before adding the ViewPager fragment
|
Mark M. |
why do you have to delay adding it until "after a specific action"?
|
Mark M. |
or, why can't you have a container for the to-be-revealed fragment put in place ahead of time?
|
Dec 11 | 10:25 AM |
Mark M. |
FrameLayout holding onto another FrameLayout and the ViewPager
|
Mark M. |
put the to-be-revealed fragment in the nested FrameLayout
|
Mark M. |
that way, you can add the to-be-revealed fragment when you need to, but from a Z-axis standpoint, it is under the ViewPager, because its FrameLayout is under the ViewPager
|
Guy W. | has left the room |
Guy W. | has entered the room |
Alex F. |
that would work if the new fragment is known ahead of time. or at least the data that the new fragment will contain. lets say there's a stack of fragments that represents pages in a book and the contents of each page is fetched from some server. i can load up the first 10 pages but lets say after swiping away 8 pages, i'd like to load more pages behind the current one.
|
Mark M. |
IMHO, that would be adding pages to the ViewPager, not swapping in some other fragment
|
Mark M. |
let me take questions from the others, and I will be back with you in a bit
|
Mark M. |
Oleg: do you have another question?
|
Oleg T. |
yes
|
Oleg T. |
View paste
|
Oleg T. |
where would I start digging in terms of documentation?
|
Mark M. |
in terms of what is and is not exported, look at the manifest of the app in question (e.g., Contacts)
|
Dec 11 | 10:30 AM |
Mark M. |
in terms of filter patterns, same thing
|
Mark M. |
in terms of eligible extras, these should all be in the Android SDK somewhere, documented wherever the Intent action string is
|
Oleg T. |
are those documented?
|
Mark M. |
what is "those"?
|
Oleg T. |
manifest files for core apps
|
Mark M. |
they are in the AOSP source code
|
Oleg T. |
ok
|
Mark M. | |
Mark M. |
that's the one for Contacts, for example, from the GitHub mirror of the AOSP
|
Mark M. |
these change over time, with different Android versions, which makes this a bit tedious to document
|
Oleg T. |
thanks. that would be all from me for the night(day). cheers
|
Mark M. |
OK
|
Mark M. |
Guy: do you have another question?
|
Oleg T. | has left the room |
Dec 11 | 10:35 AM |
Mark M. |
OK, if either of you have a question, go ahead
|
Dec 11 | 10:40 AM |
Guy W. | has left the room |
Dec 11 | 10:45 AM |
Mark M. |
Alex: if you have another question, go ahead
|
Dec 11 | 11:00 AM |
Mark M. |
that's a wrap for today's chat
|
Mark M. | |
Mark M. |
the next chat is tomorrow at 4pm Eastern
|
Mark M. |
have a pleasant day!
|
Alex F. | has left the room |
Mark M. | turned off guest access |