| 187c8167d77687fbc04237c9ac1e87564b2d5f33 |
|
14-Mar-2012 |
Josh Gargus <jjosh@google.com> |
Miscellaneous contact-detail fixes.
Fix bug in carousel "Updates" tab, which would turn black when swiping
it all the way to the left. This was caused by a small negative alpha
being computed, and some incautious integer arithmetic to transform it
for use in setBackgroundColor(). Fix clamps the alpha value between 0
and 1 (using newly-introduced MoreMath class).
Fix visual glitch where the "Updates" label displays the "pushed" glow
when tapped.
Bug: 6009463
Change-Id: Iee041ee7793f198f1d51ea5e7c5bbcb07b9a41df
/packages/apps/Contacts/src/com/android/contacts/detail/ContactDetailViewPagerAdapter.java
|
| 970454497bcc42e4d9dc5395b2c8ca2f95667893 |
|
28-Nov-2011 |
Katherine Kuan <katherinekuan@google.com> |
Don't use deprecated PagerAdapter methods
Bug: 5658993
Change-Id: I20b8fee09c5ea72de8e01d0ac4c66dfbef733951
/packages/apps/Contacts/src/com/android/contacts/detail/ContactDetailViewPagerAdapter.java
|
| 6feb0d3fcae55524e66edc1bad4e97ac936ec197 |
|
27-Oct-2011 |
Katherine Kuan <katherinekuan@google.com> |
Fix contact details not responding to touch events
- Hide updates page when contact has no social updates by
having the view pager adapter return POSITION_NONE for the
updates page view, and implement destroyItem() to set
the view's visibility to gone.
Bug: 5512400
Change-Id: I20aa7d3fe2c31152fa42cb348531bf63ca9f7764
/packages/apps/Contacts/src/com/android/contacts/detail/ContactDetailViewPagerAdapter.java
|
| 6c0470e21d8506fb53915df7463634fd47288343 |
|
17-Aug-2011 |
Katherine Kuan <katherinekuan@google.com> |
Coordinate scrolling between two lists on contact card
FRAGMENT CHANGES:
- Add a method on each of these fragments to scroll the list by
a given offset (only when the first "fake" item in the list
is at the first visible position on the list). If any other
item (2nd, 3rd, etc..) is the first visible position on the list,
then it gets too complicated to figure out how much to offset the
list, so it's better to just animate the tab carousel to be at the
right spot.
- Add a method that returns the top position of the first item
in the list if the first item in list is visible (to verify
that the offset was done properly). If the offset is not
what we expect, then we know the list couldn't be scrolled.
TAB CAROUSEL:
- Keep track of the Y position of the carousel the last time
the user was on the details page, and the last time the user was
on the updates page. This is because syncing the scroll position
of the 2 lists or animating the tab carousel vertically is only
necessary if the tab carousel position has changed between the
two pages.
LAYOUT CONTROLLER:
- We need to be able to animate the tab carousel to the correct
Y position anyways because if the list in the fragment is not
scrollable (but the other list is scrollable), we need to rely on
animation to hide the big white space below the carousel.
- When a list (i.e. in the ContactDetailFragment) is idle, the user
has stopped interacting with the list, so use the time to sync
its position with the other list (since this may involve a
requestLayout() if a scroll is triggered).
- Because the list may not become completely idle (i.e. the user
flings the list and then starts to swipe), we still need a check
when the user starts swiping the view pager to sync the two lists.
If it's already at the right spot, then do nothing. If we can't
scroll the other list dynamically and we need to animate the tab
carousel, and we should only do this when the view pager has
settled down and is idle.
MISCELLANEOUSE EDGE CASES:
- Fix the tab carousel jumping to the starting position (if a sync
happens and the loader data is refreshed) because the layout is
likely being redrawn and the tab carousel is potentially redrawn
back inside the bounds of its parent. Hence store and reset the
tab carousel position to its previous Y value (which could be
outside the bounds of its parent).
- If the list is scrollable but only by a little bit, allow
the tab carousel to compensate by animating down the rest of the
offset amount
- Tapping on the tab should also work now
- Make photo in updates tab fill the whole tab, change
updates fragment background except for the tablet landscape mode
Bug: 5044680
Change-Id: Icc9445606ea52779dea97b194763c74a0b2a27ee
/packages/apps/Contacts/src/com/android/contacts/detail/ContactDetailViewPagerAdapter.java
|
| 51f1071a1dc91dace0de73be1c5fbba4f091f054 |
|
16-Aug-2011 |
Katherine Kuan <katherinekuan@google.com> |
Allow phone contact card to switch b/t having/not having social updates
- Make phone portrait and landscape layouts have all views necessary
to switch between showing/hiding social updates. Disable swipe
if only the detail fragment is showing.
- Make ContactDetailActivity use ContactDetailLayoutController to
reduce code duplication, add another state for fragment carousel
in ContactDetailLayoutController
- Make fragment widths in fragment carousel configurable based
on screen width instead of fixed dip value
- Make setAlphaLayerValue() save the alpha value if the view
isn't ready yet (otherwise it's a no-op and the caller must
call it setAlphaLayerValue again when the view is attached) -->
this allows us to remove the code to set fragments in the
fragment carousel every time the data is reloaded
- Remove enableAlphaLayer() code and just make the alpha layer
view visible in the XML
Bug: 5164029
Change-Id: I8f28ac27d125502a12221f084ce253611e6f78a1
/packages/apps/Contacts/src/com/android/contacts/detail/ContactDetailViewPagerAdapter.java
|
| 3bbd9a0c3e85262365376ae212f9a8bc521e37d4 |
|
04-Aug-2011 |
Katherine Kuan <katherinekuan@google.com> |
Fix NPE on tablet contact card with social updates
- In tablet portrait, instead of having 3 fragments
on screen (2 fragments for the view pager and
1 detail fragment for contact with no updates), just
have 2 fragments where the view pager adapter has
count = 1 when there are no updates (which disables
the swipe).
- Store whether or not the contact has updates in
the save instance state bundle so it can be
restored in onCreate()
- Set retain instance = true for the ContactLoaderFragment
- There should always be a ContactDetailFragment and
ContactDetailUpdatesFragment after onCreate() of the
PeopleActivity on the tablet
- Basically apply similar logic from the phone CL:
https://android-git.corp.google.com/g/#change,125585
- TODO: Take out duplicated code from ContactDetailLayoutController
and ContactDetailActivity
Bug: 5106878
Bug: 5082871
Change-Id: I3af08bf84072d3d94e4f3a6bc1d01faf3432e3e7
/packages/apps/Contacts/src/com/android/contacts/detail/ContactDetailViewPagerAdapter.java
|
| db0d8669cd1ffaa45827edb65b2b0eecb27561f5 |
|
03-Aug-2011 |
Katherine Kuan <katherinekuan@google.com> |
Reuse fragments when rotating contact card on phone
- Part 1 of refactoring contact card fragment code,
Part 2 will be refactoring the tablet code to fix
bug 5082871
- ContactDetailActivity should always have non-null
fragments after onCreate() (either retrieved from
Fragment Manager or created dynamically)
- New view pager adapter that returns views that contain
existing fragments (instead of generating new fragments)
- The main reason for these changes is that when we
create fragments dynamically (necessary for the ViewPager
otherwise the fragment from XML will already have a parent),
the view ID will be the pager view ID. When we rotate,
the fragments are already defined in XML for the fragment
carousel and already have different view IDs, so it won't
restore properly. We can't put the pager view ID in the
fragment carousel layout, otherwise the ContactDetailActivity
will try to cast it to a ViewPager. Alternatively, if we make
both layouts rely on dynamically created fragments, the problem
becomes the fact that once fragments are added to the fragment manager,
they cannot be retrieved and added again to a different parent if there's a
different layout (exception is thrown). Thus, the solution is to have
the same parent container in both phone portrait and landscape layouts.
- Also it is unclear what was happening to the fragments on
rotation (they weren't being restored but weren't being removed
from the FragmentManager). We can remove the hack now that
would store the ViewPager fragment tags in the saved instance bundle
and manually remove those fragments from the FragmentManager after
an orientation change.
- In onCreate() of the ContactDetailActivity, if this is a
restored instance, then inflate the correct layout right away
so the fragments can find the parent containers.
- Save/restore ListView state on rotation
- Save/restore selected tab for contact with social updates
- Clean up computation code for FragmentCarousel by moving it to
onMeasure() method
Bug: 4976082
Bug: 4686406
Bug: 5082871
Change-Id: I7840b1dd1110da4dcc28ebabe3fc2739ff11c2f2
/packages/apps/Contacts/src/com/android/contacts/detail/ContactDetailViewPagerAdapter.java
|