問題1.

使用者在 portrait 時切換到 Tab 2，翻轉螢幕成 landscape 時卻回到 Tab 1 (應該要停在 Tab 2)。

問題2.

軟體啟動時為 portrait(A)，使用者在 Tab 1 先後運行了 Page1-1、Page1-2、Page1-3，在 Tab2 也同樣運行了 Page2-1 ~ Page2-4，這時候使用者翻轉螢幕變成landscape(B)，BackStack 全部被清光光，使用者看到的畫面變成軟體剛啟動時的空白畫面。

針對問題1小蛙直接使用 onSaveInstanceState, onRestoreInstanceState使用 這個方法複寫了 onRestoreInstanceState 及 onSaveInstanceState 兩個方法。

但是今天發現了一個新的東西叫作「android:configChanges」，這應該算是一個蠻基礎的設定，小蛙真是太失敗了…下面這個設定方法可以一併解決上述問題 1,2，也就是說上面的方法不需要用到。用小蛙簡單白話的說明就是：

當使用者翻轉螢幕時，就歷經了一次舊 Activity 的死亡及新 Activity 的誕生，透過 android:configChanges 可以使得翻轉螢幕的動作不用歷經這一個過程，取而代之的是呼叫 onConfigurationChanged 方法。

好吧！總而言之就是只要在 AndroidManifest.xml 的 Activity 敘述中加入android:configChanges=”orientation”，如此一來，當發生螢幕翻轉事件的時候，就可以保留各個 Tab 的狀態以及 BackStack 囉！另外可以透過複寫 onConfigurationChanged 方法來做更進一步的處理。例如官方範例：

附上 Android Activity Lifecycle 圖 (圖片來源：http://developer.android.com/reference/android/app/Activity.html)。

由於小蛙看到 横竖屏切换时候Activity的生命周期 @ Android开发教程 ( http://android.tgbus.com/Android/tutorial/201103/346550.shtml 連結已失效) 及 【亲测】Activity中的 ConfigChanges 属性以及横竖屏切换时候 Activity 的生命周期 @ 漫步云端 (http://www.cnblogs.com/charley_yang/archive/2011/04/17/2018940.html 連結已失效) 這兩篇文章中的 Lifecycle 感覺有點奇怪，於是自己測了一下，所得到的結果似乎不太一樣，可能是模擬器的行為跟手機的不同，也有可能是 Android 版本不同 (小蛙是用 HTC Desire + MIUI2.3 測試的，android:minSdkVersion=”4″)，以下是測試結果供參考。

今天用模擬器測試了一下，android:configChanges=”orientation” 在模擬器上沒法正常使用，必須要改成 android:configChanges=”orientation|keyboardHidden”，有遇到問題的網友不妨試試看。

最後memo一下，小蛙在官網連結中看到 onRetainNonConfigurationInstance 這個東西，查了三篇文章大概看了一下內容看起來應該蠻實用的，之後有空實作完再把結果Post上來。

[Android] 煩人的螢幕旋轉 @ 生活藝術 ● 藝術生活
activity状态的保存和保持(onRetainNonConfigurationInstance和getLastNonConfigurationInstance) @ chengbs
[Android] 比較onSaveInstanceState() 與 onRetainNonConfigurationInstance() 函式 @ 我思故我在

這篇文章 Android Screen Orientation Event螢幕方向處理+Acitivity Liftcycle 最早出現於 記下來。

onSaveInstanceState跟onRestoreInstanceState的官方說明如下(截錄自Activity | Android Developers)：

protected void onSaveInstanceState (Bundle outState)

Since: API Level 1

Called to retrieve per-instance state from an activity before being killed so that the state can be restored in onCreate(Bundle) or onRestoreInstanceState(Bundle) (the Bundle populated by this method will be passed to both).
This method is called before an activity may be killed so that when it comes back some time in the future it can restore its state. For example, if activity B is launched in front of activity A, and at some point activity A is killed to reclaim resources, activity A will have a chance to save the current state of its user interface via this method so that when the user returns to activity A, the state of the user interface can be restored via onCreate(Bundle) or onRestoreInstanceState(Bundle).
Do not confuse this method with activity lifecycle callbacks such as onPause(), which is always called when an activity is being placed in the background or on its way to destruction, or onStop() which is called before destruction. One example of when onPause() and onStop() is called and not this method is when a user navigates back from activity B to activity A: there is no need to call onSaveInstanceState(Bundle) on B because that particular instance will never be restored, so the system avoids calling it. An example when onPause() is called and not onSaveInstanceState(Bundle) is when activity B is launched in front of activity A: the system may avoid calling onSaveInstanceState(Bundle) on activity A if it isn’t killed during the lifetime of B since the state of the user interface of A will stay intact.
The default implementation takes care of most of the UI per-instance state for you by calling onSaveInstanceState() on each view in the hierarchy that has an id, and by saving the id of the currently focused view (all of which is restored by the default implementation of onRestoreInstanceState(Bundle)). If you override this method to save additional information not captured by each individual view, you will likely want to call through to the default implementation, otherwise be prepared to save all of the state of each view yourself.
If called, this method will occur before onStop(). There are no guarantees about whether it will occur before or after onPause().

protected void onRestoreInstanceState (Bundle savedInstanceState)

Since: API Level 1

This method is called after onStart() when the activity is being re-initialized from a previously saved state, given here in savedInstanceState. Most implementations will simply use onCreate(Bundle) to restore their state, but it is sometimes convenient to do it here after all of the initialization has been done or to allow subclasses to decide whether to use your default implementation. The default implementation of this method performs a restore of any view state that had previously been frozen by onSaveInstanceState(Bundle).
This method is called between onStart() and onPostCreate(Bundle).

看得懂的就看，看不懂的google一下，對岸有很多網站對於這兩個function都有翻譯。小蛙這邊直接講照照明星臉相機及相簿無法使用的原因。
點選從使用相機拍照及從相簿選擇的同時，小蛙先建了一個tmpFile，在丟入相機的參數中增加imageUri = Uri.fromFile(tmpFile);，正常情況下若從相簿挑選照片回來，小蛙會把得到的相片轉存到tmpFile(如此是為了避免修改或刪除原始照片)；假設從相機回來，可以從剛剛設定的imageUri中取得圖片，但偏偏這兩個回來的東西在一台Arc S上面正常，在另一台Arc S上面卻回傳java.lang.NullPointerException。
Override了onSaveInstanceState及onRestoreInstanceState這兩個function印出Log訊息發現，兩台都會呼叫onSaveInstanceState，但是只有其中一台會呼叫onRestoreInstanceState，而這台恰巧就是會發生錯誤的那台。小蛙猜測當使用Intent開啟內建相機時(MediaStore.ACTION_IMAGE_CAPTURE)，由於手機內部的記憶體不夠使用，造成照照明星臉主程式必須先暫時關閉，當照相動作完成後才會再回到照照明星臉，這時候照照明星臉之前建立的變數，例如：tmpFile, imageUri。就會變成null，解決的方法只要在Override onSaveInstanceState並且在該function中加入要保存的變數及其值，當主控權又回到照照明星臉時再呼叫onRestoreInstanceState把剛剛存起來的值還原，就可以避免掉onActivityResult()中有時候會出現java.lang.NullPointerException，有時候卻又可以正常使用的問題了！

這篇文章 onSaveInstanceState, onRestoreInstanceState使用 最早出現於 記下來。