روشی راحتتر برای بازکردن یک Activity

روش گفته شده مناسب نیست، چون خود ActionActivity یک متد static نیست ( راستی actionActivity درسته ) پس نمیشه از هر جایی صداش کرد و اول نمونه باید ساخته بشه که نمونه رو Framework می سازه. راه خوب این هست:

class G extends Application {
    ...

    public static void startActivity(Class<? extends Activity> clazz){
        Intent intent = new Intent(G.currentActivity, clazz);
        G.currentActivity.startActivity(intent);
    }
}

و صدا می زنیم:

G.startActivity(SomeActivity.class);

اضافه شد :

class G extendsApplication{
...
public static void startActivity(Class<? extends Activity> clazz) {
        Intent intent = new Intent(G.CurrentActivity, clazz);
        G.CurrentActivity.startActivity(intent);
    }


    public static void startActivity(Class<? extends Activity> clazz, Bundle bundle) {
        Intent intent = new Intent(G.CurrentActivity, clazz);
        intent.putExtras(bundle);
        G.CurrentActivity.startActivity(intent);
    }
}

و صدا میزنیم  ..

G.startActivity(SomeActivity.class);

و یا ..

Bundle b = new Bundle();
b.putString("sameString", "sameValue");
G.startActivity(ActivityArticle.class, b);

این تاپیک مخصوص MVC نبود اما چرا شد نمی دونم، عیب نداره ادامه بدیم :)

در پاسخ به دوست عزیز آقای حسین زاده:

نکته همینجاست. چرا C نباید به Data دسترسی داشته باشه؟ ما میگیم V باید از C جدا باشه، منطقیه چون قراره Artist طراحیش کنه و فقط می دونه که یک سری متغیر داره و سر جاشون می چینه. یا اینکه در فرمش یک Url رو صدا می زنه و پارامترها رو بهش ارسال می کنه. دیگه کاری نداره که این تو دیتابیس میشینه یا نه. آرتیست کارش مشخص شد. اما کسی که M رو می نویسه چی قراره بدونه؟ اینکه یک سری ورودی داره که قراره رو Data اثر بذاره و یک سری خروجی بده. اینم قبول، اما C چی می خواد؟ اینکه V رو به M وصل کنه. همین! خوب پس یا C اضافه هست یا M . آیا برای وصل کردن V به M نیاز هست یک رابطه دیگه هم باشه. مثل این می مونه که بگیم می خوایم زنجیر لوستر رو به لوستر وصل کنیم، پس یه تیکه دیگه زنجیر می خوایم! نه میشه ته زنجیر رو به لوستر وصل کرد و تکه دیگری از زنجیر نمی خوایم. البته این نظر من بود و ممکنه اشتباه باشه.

دو حالت داره :

1- تو خیلی تیم های برنامه نویسی تیم دیتابیس جداس و با استفاده از روش Codefirst که فرا گیر شده ، تیم دیتابیس عهده دار نگهداری کد لایه Model میشه

2- جدا سازی منطقی این دو لایه حتی در مواردی که یک تیم روی هر دو لایه کار میکنه برای نگهداری برنامه لازمه. تو این حالت میشه با بررسی نوع خطا ( منطق / دیتا ) لایه مربوطه رو بررسی کرد.

بسته به نوع برنامه و گستردگی تیم هر کدوم از M , C ممکنه به لایه های ریز تر هم تقسیم بشن .

یکی از دلایل اینهمه تقسیم بندی تو محیط های عملیاتی اینه که هر تیمی باید نسبت که کد خودش و باگهاش پاسخگو باشه. این تقسیمات کار تیم دیتابیس و منطق رو هم جدا میکنه پس خطاهای دریافت شده از سوی مشتری هم سریعتر جواب داده میشه.

رفرنس هم که برای دلایل وجود MV* زیاده. ولی تو همه موارد صرف نظر از مدل و ویو حتما بخشی برای منطق جداگانه در نظر گرفته میشه . در MVC : controller و در MVVM : ViewModel و ...