تغییر UI در زمان اجرا با استفاده از ViewStub

اصول برنامه نویسی و طراحی میگه تا حد امکان باید از کد های تکراری بپرهیزیم و اینکار برای طراحی رابط کاربری هم بسیار مورد نیازه . یه مثال ساده ای که در این مورد همیشه زده میشه جداسازی کد های یک قسمت طراحی بصورت یک فایل جدا layout و استفاده از اون در layout های دیگه است که میشه با تگ های include , merge اون قسمت رو اضافه کرد . البته اگر قسمت ضمیمه شونده منطق خودش رو داشته باشه باید بصورت fragment به اکتیویتی اضافه بشه تا بتونیم برای هر قسمت منطقش رو اجرا کنیم . اینکار هم با تگ fragment , framelayout قابل انجامه . در چنین مثالهایی ما یک بخش ثابت داریم که میتونه در فضاهای بزرگ دیگه مثل فرگمنت یا اکتیویتی تکرار بشه 

حالا بزارید یه فرض دیگه رو هم بررسی کنیم . اگر ساختار اصلی فرگمنت هامون یک شکل باشه ولی یه بخش خاص برای هر فرگمنت تغییر کنه چطور ؟ یعنی فرض کنید چند فرگمنت یا اکتیویتی داریم که شکل ساختاری یکسانی دارند ولی مثلا بخش بالای صفحه در هر فرگمنت متفاوته و شکلش تغییر میکنه . اینجاست که ViewStub به کار میاد . بزارید اول بدونیم ViewStub چیه ؟

ViewStub 

طبق تعریف خود گوگل :

A ViewStub is a zero-sized invisible View which is used to load "layout resource" at runtime.

یعنی ViewStub ویویی بدون سایز و مخفی است که در زمان اجرا به عنوان layout نمایش داده خواهد شد . این یعنی اینکه با اضافه کردن این ویو به layout هیچ جایی رو نخواهد گرفت و زمانی که متد ()inflate یا visible آن اجرا شود ، یه ویو دیگر را در خود نمایش خواهد داد . 

<ViewStub
    android:id="@+id/view_stub"
    android:inflatedId="@+id/replace_view"
    android:layout="@layout/replace_layout"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    />

همانطور که در کد بالا می بینید attribute های ViewStub شامل موارد زیر می باشد :

android:id="@+id/view_stub"

 id مختص خود ViewStub که بتوان بعدا در برنامه به آن دسترسی داشت 

android:inflatedId="@+id/replace_view"

id ویویی که بعد از اجرای متد ()inflate یا visible به ویو جایگزین شده داده خواهد شد 

android:layout="@layout/replace_layout"

layout ای که باید جایگزین شود . البته اینکار را بصورت کد نویسی انجام می دهیم تا بتوانیم همانند مثال گفته شده layout های اختصاصی را برای هر فرگمنت جایگزین کنیم

viewStub.setLayoutResource(R.layout.my_checkbox);
View inflatedView = viewStub.inflate();

میتونید نحوه استفاده از ViewStub رو در اینجا و اینجا و اینجا و اینجا ببینید . با استفاده از ViewStub عملا ما میتونیم یک جایی اختصاصی جدا در layout در نظر بگیریم که برای هر فرگمنت یا اکتیویتی بتونه ویو مختص به خود رو در آن جایگزین کند . اما یکی از کاربرد های مهم دیگه ViewStub نیز لود کردن قسمت های مختلف layout در زمان های مختلفه . فرض کنید layout شلوغی داریم که اگر بخواهیم بصورت یکجا لود بشه زمان زیادی رو میگیره ، در این حالت با استفاده از ViewStub میشه زمان نمایش ویو رو تا زمان اجرای متد ()inflate یا visible به تاخیر بندازیم 

پی نوشت : یکی از ویژگی های ViewStub اینه که زمان inflate شدن ، خود ViewStub حذف خواهد شد و جای آن را ویو تعریف شده خواهد گرفت در نتیجه زمان استفاده از ViewStub در ConstraintLayout بعد از inflate شدن دیگه هیچ قید و بندی به ConstraintLayout نخواهد داشت ، برای حل این مشکل کافیه همانند راه حل ارائه شده در اینجا ، inflatedId رو با id یک مقدار قرار بدیم .

تغییر نام package اپلیکیشن اندروید

شاید برای شما هم پیش اومده باشه که بخواهید نام package اپ اندروید رو تغییر بدید ولی نمی دونید از کجا باید شروع کنید و چی رو باید تغییر بدید که پروژه تون از دست نره . با هم روش درستش رو می بینیم :

فرض کنید میخواهیم com.example.app به com.my.application  تغییر بدیم :

• در Project pane ایکون تنظیمات رو کلیک کرده و تیک کنار Compact Empty Middle Packages رو بردارید . با اینکار فایل پروژه بصورت درختی نمایش داده میشه و می تونید ببینید com , example , app بصورت پوشه در میان

• حالا رو پوشه example راست کلیک کرده و Refactor - > Rename رو انتخاب کنید 
• در پنجره باز شده Rename Package رو انتخاب کنید و نام my رو وارد کرده و Refactor رو بزنید 
• در پنل باز شده که لیست تغییرات مورد نیاز را نمایش میدهد نیز Do Refactor رو بزنید . اندروید استدیو باقی کار ها رو انجام میدهد 
• همین کار رو برای پوشه app و تغییر نام به application  انجام بدید 
• فایل manifest رو بازکنید و   "package="com.example.app رو به  "package="com.my.application تغییر بدید
• فایل (build:gradle (app رو باز کنید و "applicationId "com.example.app را نیز مثل بالا تغییر دهید 
• حالا پروژه را sync کنید و لذت ببرید

پی نوشت : احتمالا پوشه اصلی پروژه به نام قبلی app باقی مانده که فقط کافیه اون رو تغییر نام بدید هر چند در پروژه تاثیری نداره

دیباگ مستقیم اپ روی گوشی

حتما برای دولاپر های عزیز اندروید پیش اومده که بعد از آماده سازی اولیه اپ و نصب روی گوشی ، در حالی که به نظر میاد همه چیز داره خوب کار میکنه اپ کرش می کنه و یه سوال بسیار بزرگ عین شاخ از سرشون بیرون میزنه  ! اگر مثل من دسترسی به محیط دیباگ android studio به سرعت در اختیارتون نیست و یا نمیدونید کجا خطا اتفاق افتاده تا سریع برید همون خط رو دیباگ دوباره کنید و میخواید که خطا روی خود گوشی بهتون نمایش داده بشه ، این روش کارایی خوبی خواهد داشت .

Android Global Exception Handler

اینکار به سادگی با java.lang.Thread.UncaughtExceptionHandler قابل انجامه ولی باید یکی از دو روش زیر رو انتخاب کنید :

1.خطایابی در سطح Application که در این صورت نمی توانید dialog باز کنید و یا اکتیویتی جدیدی اجرا کنید با این حال هر نوع خطایابی قابل اجرا خواهد شد 

2.خطایابی در سطح Activity که به راحتی میتوان dialog یا اکتیویتی دیگری باز کرد ولی باید در یک کلاس ارث بری شده توسط اکتیویتی ها نوشته شود ( مثلا BaseActivity )

خطایابی در سطح Application

در این روش log ایرور بصورت فایل روی دستگاه ذخیره خواهد شد تا در اجرای دوباره اپ بتوان از آن استفاده کرده و متن خطا را نمایش داد 

public class LoggingExceptionHandler implements Thread.UncaughtExceptionHandler {
    private final static String TAG = LoggingExceptionHandler.class.getSimpleName();
    private final static String ERROR_FILE = MyAuthException.class.getSimpleName() + ".error";
    private final Context context;
    private final Thread.UncaughtExceptionHandler rootHandler;
    public LoggingExceptionHandler(Context context) {
        this.context = context;
        // we should store the current exception handler -- to invoke it for all not handled exceptions ...
        rootHandler = Thread.getDefaultUncaughtExceptionHandler();
        // we replace the exception handler now with us -- we will properly dispatch the exceptions ...
        Thread.setDefaultUncaughtExceptionHandler(this);
    }
    @Override
    public void uncaughtException(final Thread thread, final Throwable ex) {
        try {
            Log.d(TAG, "called for " + ex.getClass());
            // assume we would write each error in one file ...
            File f = new File(context.getFilesDir(), ERROR_FILE);
            // log this exception ...
            FileUtils.writeStringToFile(f, ex.getClass().getSimpleName() + " " + System.currentTimeMillis() + "\n", true);
        } catch (Exception e) {
            Log.e(TAG, "Exception Logger failed!", e);
        }
    public static final List<String> readExceptions(Context context) {
        List<String> exceptions = new ArrayList<>();
        File f = new File(context.getFilesDir(), ERROR_FILE);
        if (f.exists()) {
            try {
                exceptions = FileUtils.readLines(f);
            } catch (IOException e) {
                Log.e(TAG, "readExceptions failed!", e);
            }
        }
        return exceptions;
    }
}

حالا باید ان را به سطح Application ضمیمه کنیم

public class MyApp extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        new LoggingExceptionHandler(this);
    }
}

یادتان نرود که در فایل AndroidManifest  نیز تغییرات زیر را انجام دهید 

<application
    android:name=".MyApp"

خطایابی در سطح Activity

در این روش با استفاده از ApplicationContext می توان log ایرور را بصورت مستقیم نشان داد و یا حتی اکتویتی جدیدی را اجرا کرد 

public class MyExceptionHandler implements Thread.UncaughtExceptionHandler {

    public static final String EXTRA_MY_EXCEPTION_HANDLER = "EXTRA_MY_EXCEPTION_HANDLER";
    private final Activity context;
    private final Thread.UncaughtExceptionHandler rootHandler;

    public MyExceptionHandler(Activity context) {
        this.context = context;
        // we should store the current exception handler -- to invoke it for all not handled exceptions ...
        rootHandler = Thread.getDefaultUncaughtExceptionHandler();
        // we replace the exception handler now with us -- we will properly dispatch the exceptions ...
        Thread.setDefaultUncaughtExceptionHandler(this);
    }

    @Override
    public void uncaughtException(final Thread thread, final Throwable ex) {
        if (ex instanceof MyAuthException) {
            // note we can't just open in Android an dialog etc. we have to use Intents here
            // http://stackoverflow.com/questions/13416879/show-a-dialog-in-thread-setdefaultuncaughtexceptionhandler

            Intent registerActivity = new Intent(context, AuthActivity.class);
            registerActivity.putExtra(EXTRA_MY_EXCEPTION_HANDLER, MyExceptionHandler.class.getName());
            registerActivity.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
            registerActivity.addFlags(Intent.FLAG_ACTIVITY_NEW_DOCUMENT);

            context.startActivity(registerActivity);
            // make sure we die, otherwise the app will hang ...
            android.os.Process.killProcess(android.os.Process.myPid());
            System.exit(0);
        } else {
            rootHandler.uncaughtException(thread, ex);
        }
    }
}

برای ضمیمه کردن این Handler باید یک کلاس ایجاد کرد تا اکتیویتی های دیگر از آن ارث بری کنند 

public abstract class BaseActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        new MyExceptionHandler(BaseActivity.this);
    }
}

خودم از این روش در پروژه هام استفاده میکنم و معمولا وقتی ایرور جدید غیر قابل پیش بینی اتفاق می افته خیلی بدردم خورده ... البته چون از روش دوم استفاده میکنم بعضی از ایرور های که قبل از activity اتفاق می افتن رو نمیشه catch کرد که زیاد چنین اتفاقی نمی افته . من برای نمایش متن ایرور از اکتویتی جدید و یک TextView استفاده میکنم . البته نمی دونم بدلیل محدودیت String و یا TextView کل متن ایرور نمایش داده نمیشه که زیاد فرقی نمیکنه و معمولا از همون خطوط اول مشخص میشه خطا برای چیه