Ting 이네 Software 이야기

Log includes "Window is full: requested allocation 2195889 bytes, free space 2096720 bytes, window size 2097152 bytes"

Most case of this kind of issue can be seen when SQLite DB has blob-type field whose data is quite big, and Cursor that includes this field is used at Aadapter.

In this case, Cursor easily exceeds it's maximum Window size (at Android 4.0.3, this value is about 2 MB).

After reaching to maximum Window size, Cursor need to handle Window, and at worse, field size is quite big.
So, whenever move to another row of Cursor, Cursor should handle quite complex disk operation.

So, at this moment, scrolling list becomes very very slow.

To avoid this, main Cursor of Adapter would better not to have big-size field of DB Table.

Instead of it, try to read from DB whenever the field value is demanded.

Then, average time for scrolling list may be increased. But, even at worst cases, list can show reasonable scrolling performance.

When using Adapter (especially list), sometimes(actually very frequently) data of only one item(row) is changed.

In this case, usually, changing one-under-lying data is easy.

But, updating only one list item is different story.

To update that item to the screen, - changing look-and-feel regarding changed item -  easiest way is calling notifyDataSetChanged().

But, this re-bind views of all list items. This is wasteful.

To avoid this, we should get View of item associated, and then modify it directly.

At first glance, it is easy and "Item position to View" map seems to be useful. But, it's NOT.

Why?

AdapterView usually reuse Views. So, several positions become to share same view at "position to View" map.
That is, whenever try to update item at specific item, we need to check that that item has valid visible View or not.

But, this is not-easy at current(API 15) Android API.

My suggestion is using "View to position" map(henceforth VPMap).

At AdapterView, View is reused. So, Adapter doesn't have lot's of different Views.

So, key size of the VPMap is not large (usually at most 20~30).

And we can easily update recent valid visible position of View easily at getView() of Adapter.

See below sample code.

private final HashMap<View, Integer> mView2PosMap = new HashMap<View, Integer>();
...
public void
setItemActive(int pos) {
    if (pos == mActivePos)
        return;
    View v = Utils.findKey(mView2PosMap, mActivePos);
    if (null != v)
        setToInactive(v);
    v = Utils.findKey(mView2PosMap, pos);
    if (null != v)
        setToActive(v);

    mActivePos = pos;
}
...
@Override
public View
getView(int position, View convertView, ViewGroup parent) {
    View v;
    if (null != convertView)
        v = convertView;
    else
        v = UiUtils.inflateLayout(mContext, R.layout.row);

    mView2PosMap.put(v, position);
    ...
}
...
public static <k,v> K
findKey(HashMap<View, Integer> map, V value) {
    Iterator<k> iter = map.keySet().iterator();
    while(iter.hasNext()) {
        K key = iter.next();
        if (map.get(key).equals(value))
            return key;
    }
    return null;
}

Like above, with this VPMap we can easily find associated visible View and can update only one-updated-item-View without calling 'notifyDataSetChanged()'.

Sometimes developer may need to use MediaPlayer directly instead of using VideoView.

In this case, developer should keep belows in his/her mind.

<NOTE : Gingerbread and ICS are a little different (ICS is more flexible. But, the more strict is the better.>

 - setDisplay Should be called after surface of SurfaceHolder is created.

 - video should be started after it's video size is known (after onVideoSizeChanged is called.)

 - setDisplay() should be called before prepare()

Let's summarize it.

onSurfaceCreate -> setDisplay() -> prepare()/prepareAsync()

: onVideoSizechanged

: onPrepared

=> Now, MediaPlayer is fully prepared to be started.

Tested and verified at Android 4.0.3

When using SlidingDrawer over SurfaceView, SlidingDrawer is cropped by SurfaceView while opening and closing even if SlidingDrawer is over SurfaceView.

Try with below layout.

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    >
    <SurfaceView
        android:id="@+id/surface"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_centerInParent="true"
        />
    <SlidingDrawer
        ...
        />
</RelativeLayout>

In my opinion, that's because SufaceView holding the visible region and display on it.

And, in case of SlidingDrawer, opening and closing area is not known by WindowManager.
So, it may not be considered when holding region by SurfaceView.

Based on above hypothesis, I tried with below layout and confirmed that it works as expected.

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    >
    <SurfaceView
        android:id="@+id/surface"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        />
    <View
        android:id="@+id/touch_ground"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        />
    <SlidingDrawer
        ...
        />
</RelativeLayout>

I don't want to tell that this is a kind of bug of Android framework. It's just common-type of issue when things are in together.

I hope that this post is helpful to others.

In case that sqlite database is quite big, preparation for using cursor requires lots of time-consuming-operation.

So, developer may considering about asynchronous way - showing progress while preparing cursor in background.

Then, what is 'Really' time-consuming-operation in preparing cursor?

As my understanding, in Android sqlite cursor, the answer is first 'fillWindow' operation of SQLiteCursor.

Notable thing is, at sqlite cursor, creating cursor doesn't do any real (or practical) thing.

So, creating cursor is done very quickly.

By the way, Sqlite cursor do 'fillWindow' operation at the moment of first 'getCount()' call - See SQLiteCursor.java.

Therefore, to prepare cursor in background, not only creating cursor but also calling first 'getCount()' function are required.

Here is sample function for reference.

    public void
    reloadCursorAsync() {
        DiagAsyncTask.Worker worker = new DiagAsyncTask.Worker() {
            private Cursor newCursor;
            @Override
            public void onPostExecute(DiagAsyncTask task, Err result) {
                changeCursor(newCursor);
            }
            @Override
            public Err doBackgroundWork(DiagAsyncTask task, Object... objs) {
                newCursor = createCursor();
                newCursor.getCount();
                return Err.NO_ERR;
            }
        };
        new DiagAsyncTask(mContext, worker,
                          DiagAsyncTask.Style.SPIN,
                          R.string.loading, false)
        .execute();
    }

Android document says several advantages of android:targetSdkVersion. But, I faced following issue.

Here is my case.

android:minSdkVersion="10"

android:targetSdkVersion="15"

...

<activity ...

android:configChanges="orientation|keyboardHidden"

...

Since v3.2 ScreenSize is additionally required at configChanges to handle orientation change.

But, in this case, minSdkVersion is "10" so, ScreenSize cannot be used.

The problem is that targetSdkVersion is "15".

So, framework doesn't call onConfigurationChanged() callback when orientation is changed.

This is unavoidable and unexpected.

Eventually, I gave up using 'targetSdkVersion'.

I'm not sure there are any other workarounds for these cases, but after experiencing above case, I am trying to Not-To-Use targetSdkVersion option...

This post is history of registering Android App to Google Play.

I hope that this post is useful to developers who has a plan to register App to Google Play.

I registered one free App. to Google Play and after some time - about a-week-after? - I received below E-mail from Google.

This is a notification that your application, Youtube Music Player, with package ID free.yhc.youtube.musicplayer, has been removed from the Google Play Store.

REASON FOR REMOVAL: Violation of the intellectual property and impersonation or deceptive behavior provisions of the Content Policy.

All violations are tracked. Serious or repeated violations of any nature will result in the termination of your developer account, and investigation and possible termination of related Google accounts.

If your developer account is still in good standing, you may revise and upload a policy compliant version of your application as a new package name. Before uploading any new applications, please review the Developer Distribution Agreement and Content Policy.

If you feel we have made this determination in error, you can visit the Google Play Help Center article for additional information regarding this removal.

The Google Play Team

Issued application is the one below

YoutubeMusicPlayer-v1.3.0-2.apk

Main feature of this application is "making playlist of youtube videos and play those continuously without video (only audio) in background.

Actually at that moment, I didn't have any idea regarding what are problems.

So, some E-mails are additionally sent/received

Here is E-mail thread between Google and me.

Hi Google

I received below mail.

Could you describe details about the violations of application free.yhc.youtube.musicplayer.

Actually, I do not know what are issued points.

My developer account is yhcting77@gmail.com.

Thank you in advance and sorry for inconvenience.

YH Cho.

Hi Ting,

Thank you for your note.

We appreciate the opportunity to review your appeal regarding the removal
of your app from Google Play. After an investigation, we affirm our
initial decision and will not be reinstating your application at this
time.

If your developer account is still in good standing, and the nature of
your application allows for you to upload a new, compliant version of this
application to Google Play; please apply the following Content Policy
guidelines to future releases:

Google Play Android Developer Program Policy
(see "Impersonation or Deceptive Behavior"):
http://play.google.com/about/developer-content-policy.html

Regards,
The Google Play Team

Hi Google.

Hi Ting,

Thank you for your note. Your application's icon and title could be
misleading to some users and lead them to think that your app is
authorized by another organization. Please be aware of the "Impersonation
or Deceptive Behavior" section of the Content Policy as you publish your
applications:
http://www.android.com/us/developer-content-policy.html#impersonation

Developer cannot guess when Java GC is run. So, in Android, Bitmap class has special interface 'recycle' to reuse memory as soon as possible when Bitmap is not used anymore.

Based on similar reason, we need to recycle ImageView.

But, here are some points to consider when recycling memory of ImageView.

* ImageView has drawable - most case it is instance of BitmapDrawable - regardless of it's input-resource-type - ex setImageResource(),  setImageURI() or setImageBitmap(). And, ImageView has BitmapDrawable not only the case of setImageBitmap but also some other cases - ex setImageResource.

* Sample code to recycle Bitmap of ImageView is something like below

        // true == (v instanceof ImageView)

        Drawable d = v.getDrawable();

        if (d instanceof BitmapDrawable) { // to make sure.

            BitmapDrawable bmd = (BitmapDrawable)drawable;

            Bitmap bitmap = bmd.getBitmap();

            bitmap.recycle();

        }

* setImageDrawable(), setImageResource() and setImageURI() compares new-input and current used one.

So, if new one is same with current one, ImageView doesn't do anything. (See ImageView.java for details.)

* ImageView doesn't provide any interface to compare that given one is same with current one or not.

Because of above 4 reasons, recycling memory of ImageView is not straight-forward.

Simplest way, in my opinion, is feed newly-created-Bitmap-instance to ImageView whenever changing drawable, and recycle old one.

Because drawable is newly-created-instance, we don't need to compare new one with old one.

So, blind recycling old one, is ok in this case.

Here is sample function.

    public static void

    setThumbnailImageView(ImageView v, byte[] imgdata) {

        Bitmap thumbnailBm;

        if (null != imgdata && imgdata.length > 0)

            thumbnailBm = BitmapFactory.decodeByteArray(imgdata, 0, imgdata.length);

        else

            thumbnailBm = BitmapFactory.decodeResource(Utils.getAppContext().getResources(),

                                                       R.drawable.ic_unknown_image);

        // Recycle old Bitmap

        Drawable drawable = v.getDrawable();

        if (drawable instanceof BitmapDrawable) { // to make sure.

            BitmapDrawable bmd = (BitmapDrawable)drawable;

            Bitmap bitmap = bmd.getBitmap();

            bitmap.recycle();

        }

        // change to new one.

        v.setImageBitmap(thumbnailBm);

    }