# Rebase d01f70f39..5efe76189 onto d01f70f39 (4 commands) # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # . create a merge commit using the original merge commit's # . message (or the oneline, if no original merge commit was # . specified). Use -c <commit> to reword the commit message. # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted.
In case ORIG_HEAD is no longer useful, you can also use the branchName@{n} syntax, where n is the nth prior position of the branch pointer. So for example, if you rebase featureA branch onto your master branch, but you don’t like the result of the rebase, then you can simply do git reset --hard featureA@{1} to reset the branch back to exactly where it was before you did the rebase. You can read more about the branch@{n} syntax at the official Git docs for revisions.
So internally RemoteViews is simply a set of actions that are
“serialized” and sent to another process. Each time you make a call
to something like setDouble(), you’re adding an additional action to
RemoteViews’ internal list.
Because there isn’t a way of clearing these actions from a RemoteViews
object, all of your successive setImageViewBitmap() calls, along with
their Bitmaps, remain in the internal list, and are actually
“serialized” and applied each time your send it. :(
In this case it’s best to just create a new RemoteViews object every time.
/** * Return the number of views available. */ publicabstractintgetCount();
/** * Create the page for the given position. The adapter is responsible * for adding the view to the container given here, although it only * must ensure this is done by the time it returns from * {@link #finishUpdate(ViewGroup)}. * * @param container The containing View in which the page will be shown. * @param position The page position to be instantiated. * @return Returns an Object representing the new page. This does not * need to be a View, but can be some other container of the page. */ public Object instantiateItem(ViewGroup container, int position) { return instantiateItem((View) container, position); }
if (mCurItem == ii.position) { // Keep the current item in the valid range newCurrItem = Math.max(0, Math.min(mCurItem, adapterCount - 1)); needPopulate = true; } continue; }
/** * Called when the host view is attempting to determine if an item's position * has changed. Returns {@link #POSITION_UNCHANGED} if the position of the given * item has not changed or {@link #POSITION_NONE} if the item is no longer present * in the adapter. * * <p>The default implementation assumes that items will never * change position and always returns {@link #POSITION_UNCHANGED}. * * @param object Object representing an item, previously returned by a call to * {@link #instantiateItem(View, int)}. * @return object's new position index from [0, {@link #getCount()}), * {@link #POSITION_UNCHANGED} if the object's position has not changed, * or {@link #POSITION_NONE} if the item is no longer present. */ publicintgetItemPosition(Object object) { return POSITION_UNCHANGED; }
If you try to use maxLines=1 with ellipsize, you shall get the following lint error (refer to this discussion)
Combining ellipsize and maxLines=1 can lead to crashes on some devices. Earlier versions of lint recommended replacing singleLine=true with maxLines=1 but that should not be done when using ellipsize
I faced what I suspect is the same problem in my own app. For me, it was happening because I was using android:ellipsize="start"without also using android:singleLine="true".
We had switched all of our android:singleLine="true" attributes to the recommended android:maxLines="1", but it turns out that there’s a bug in how the system calculates the ellipsis that is triggered if singleLine isn’t present.
So I believe you can solve this issue by simply adding android:singleLine="true" to your TextViews that are using ellipsize attrs.
