Android-də qlobal dəyişənləri necə elan etmək olar?

Giriş tələb edən bir proqram yaratmaq. Mən əsas və qeydiyyat fəaliyyətini yaratdım.

Əsas onCreate metodunda aşağıdakı şərtləri əlavə etdim:

 public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); ... loadSettings(); if(strSessionString == null) { login(); } ... } 

Giriş formu başa çatdıqda yerinə yetirilən onActivityResult metodu bu kimi görünür:

 @Override public void onActivityResult(int requestCode, int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); switch(requestCode) { case(SHOW_SUBACTICITY_LOGIN): { if(resultCode == Activity.RESULT_OK) { strSessionString = data.getStringExtra(Login.SESSIONSTRING); connectionAvailable = true; strUsername = data.getStringExtra(Login.USERNAME); } } } 

Problem, giriş formasının bəzən iki dəfə ( login() metodu iki dəfə çağırılır), həmçinin telefonun klaviaturası strSessionString giriş forması yenidən görünür və mən problemi strSessionString dəyişən hesab edirəm.

İstifadəçi artıq uğurla təsdiqləndikdən sonra giriş formasının görünüşündən qaçmaq üçün qlobal dəyişənləri necə müəyyənləşdirə bilir?

556
02 апр. Niko Gamulin 02 apr soruşdu . 2009-04-02 04:54 '09 at 04:54 2009-04-02 04:54
@ 17 cavab

Bu cavabı '09'da Android-in nisbətən yeni olduğu zaman yazdım və Android-in inkişafında çox yaxşı olmayan sahələr var idi. Mən bu nəşrin sonunda bir çox əlavə etdim, bəzi tənqidlərə toxunaraq, mənim var olduğum fəlsəfi fikir ayrılıqlarını bir subclassical tətbiq deyil, detallaşdırdı. Öz riski ilə oxuyun.

ORİJİNAL CAVAB:

Qarşılaşdığınız daha geniş bir problem, dövlətin bir çox hərəkətdə və tətbiqin bütün hissələrində necə qorunmasıdır. Statik bir dəyişən (məsələn, singleton) Java tətbiq etmək üçün ümumi bir yoldur. Ancaq mən Android-də daha zərif bir şəkildə dövlətinizi tətbiq məzmunu ilə əlaqələndirmək olduğunu gördüm.

Bildiyiniz kimi, hər bir fəaliyyət, həmçinin, geniş mənada onun icra mühiti haqqında məlumat olan kontekstdən ibarətdir. Ərizəniz də kontekstə malikdir və Android tətbiqinizdə bir nümunə kimi mövcud olmasını təmin edir.

Bunu etmək yolu, android.app.Application öz alt sinfi yaratmaq və sonra bu sinifinizi manifestinizdeki tətbiq etikatında göstərin. İndi Android avtomatik olaraq bu sinifin bir nümunəsi yaradır və bütün tətbiqinizə çatdırılacaq. Context.getApplicationContext() metodunu istifadə edərək, hər hansı bir context istifadə edə bilərsiniz ( Activity də eyni təsiri olan getApplication() metodu ilə təmin edir). Aşağıdakı sonrakı sifarişlərlə son dərəcə sadələşdirilmiş bir nümunədir:

 class MyApp extends Application { private String myState; public String getState(){ return myState; } public void setState(String s){ myState = s; } } class Blah extends Activity { @Override public void onCreate(Bundle b){ ... MyApp appState = ((MyApp)getApplicationContext()); String state = appState.getState(); ... } } 

Bu statik dəyişən və ya singleton kimi eyni effektə malikdir, lakin mövcud Android platformasına olduqca yaxşı birləşdirir. Xahiş edirik unutmayın ki, bu, bütün proseslərdə işləməyəcəkdir (tətbiqiniz bir neçə prosesə malik nadir olanlardan biri olmalıdır).

Yuxarıdakı nümunədən qeydin bir növü; Bir şey etdiyimizi düşünsün:

 class MyApp extends Application { private String myState = ; public String getState(){ return myState; } } 

Artıq hər bir proqram yaratdığınızda bu yavaş başlatma (məsələn, bir disk vurdu, bir şəbəkə vurdu, bir engelleme və s.) Həyata keçiriləcək! Bu prosesin yalnız bir dəfə olduğunu düşünürsünüz və mən hər halda ödəməliyəmmi? Məsələn, Diana Hackborn aşağıda qeyd edildiyi kimi, prosesin yaradıla bilməsi üçün - sadəcə bir yayım hadisəsini idarə etmək mümkündür. Sizin yayımınızın bu vəziyyətə ehtiyacı olmadıqda, potensial olaraq heç bir şey üçün bir sıra kompleks və yavaş əməliyyatlar seriyası hazırlamışdınız. Burada tənbəl tövsiyə deyə bilərsiniz. Aşağıdakı bir tətbiqdən istifadə etmək üçün bir qədər daha mürəkkəb bir üsuldur, bu heç bir şey üçün daha mürəkkəbdir, amma sadə istifadə:

 class MyApp extends Application { private MyStateManager myStateManager = new MyStateManager(); public MyStateManager getStateManager(){ return myStateManager ; } } class MyStateManager { MyStateManager() {  } String getState() {   ... return state; } } class Blah extends Activity { @Override public void onCreate(Bundle b){ ... MyStateManager stateManager = ((MyApp)getApplicationContext()).getStateManager(); String state = stateManager.getState(); ... } } 

Burada daha çox zərif bir həll kimi istifadə singletons istifadə etmək üçün proqram subclasses üstünlük baxmayaraq, Mən, həqiqətən zəruri olduqda, dövlət və tətbiqi subclass bağlanması çox yivli effektləri haqqında çox düşünmədən, singletons istifadə etmək üçün developers üstünlük verirəm.

QEYD 1: Həmçinin, antifaşşmada göstərildiyi kimi, tətbiqi ərizə faylına manifest faylında düzgün şəkildə bağlamaq üçün bir etiket tələb olunur. Yenə daha ətraflı məlumat üçün Android sənədlərinə baxın. Məsələn:

 <application android:name="my.application.MyApp" android:icon="..." android:label="..."> </application> 

Qeyd 2: user608578 öz obyektlərinin həyat dövründən idarə olunması ilə necə işlədiyini soruşur. Öz kodumu Android-də ən kiçik dərəcədə necə istifadə edəcəyimi bilmirəm və qərarımı necə qarşılayacağına cavab verə bilmərəm. Kimsə bu suala cavab verərsə, mən onlara təşəkkür edirəm və məlumatları maksimum görünürlük üçün bu vəzifəyə qoyuram.

Əlavə:

Bəzi insanlar qeyd etdilər ki, bu daimi bir dövlət həlli deyil və orijinal cavabda daha çox vurğulanmış ola bilər. Yəni, istifadəçilərin və ya digər tətbiqlərin ömrü boyu davam etməsi lazım olan digər məlumatların qorunması problemini həll etmək nəzərdə tutulmur. Beləliklə, aşağıda göstərilən tənqidlərin əksəriyyəti Müraciətlərin istənilən vaxt öldürüldüyü və s. İlə bağlı olduğuna inanıram. Lakin diskdə saxlanılmaq üçün lazım olan hər şey saxlanılmamalıdır, çünki tətbiqin alt sinifində saxlanılmamışdır. diskdə. Müvəqqəti, asanlıqla bərpa oluna bilən tətbiq statusunu (məsələn, bir istifadəçi qeydiyyata alındıqda) və bir nümunə olan komponentləri (məsələn, şəbəkə proqram meneceri) saxlamaq üçün nəzərdə tutulmuşdur.

Dayerman, Reto Meyer və Diana Hackborn ilə maraqlı bir söhbətə toxunmaq üçün kifayət idi. Bu proqramda Subclass istifadə etməsi Singleton lehinə tövsiyə olunmur. Somatik əvvəllər oxşar bir şey də qeyd etdi, baxmayaraq ki, o zaman görmədim. Reto və Dianne'nin Android platformasını dəstəkləyən rolları səbəbindən, mən onların məsləhətlərini görməməyi tövsiyə edə bilmərəm. Onlar dedilər. Singleton'un tətbiqi alt siniflər üstündəki üstünlüyü ilə əlaqədar ifadə ilə razılaşmaq istəmirəm. Mənim fikir ayrılıqlarımda StackExchange Singleton dizayn tərtibatı ilə bu şərhdə ən yaxşı şəkildə açıqlanan konsepsiyaları istifadə edəcəyəm, buna görə də bu cavabdakı şərtləri müəyyənləşdirməyə ehtiyac yoxdur. Davam etmədən əvvəl əlaqəni gizlətməyi məsləhət görürəm. Point by point:

Dianne iddia edir: "Proqramdan alt sinif üçün heç bir səbəb yoxdur, bu tək element yaratmaqdan fərqli deyil ..." Bu ilk bəyanat səhvdir. Bunun iki əsas səbəbi var. 1) Ərizə forması ərizəçi üçün ən yaxşı ömür boyu zəmanət verir; tətbiqin zəmanətli xidmət müddəti. Singleton tətbiqin ömrü ilə bağlıdır (bu effektiv olmasına baxmayaraq). Bu, ortalama proqram geliştiriciniz üçün bir problem ola bilməz, amma bu, Android API təklif etməsi lazım olan müqavilənin növüdür və Android sisteminə daha çox uyğunluq təmin edir və əlaqəli məlumatların ömrünü minimuma endirir. 2) Application class, Singleton statusu sahibindən çox fərqli bir dövlət üçün bir nümunə sahibi ilə ərizəçi proqram təminatını təqdim edir. Fərqlər siyahısı üçün yuxarıda Singleton Açıklayıcı Linkinə baxın.

Dianne davam edir: "... ən başlıcası, gələcəkdə təəssüflənirsiniz, çünki ərizə obyektiniz müstəqil tətbiq məntiqinin nə qədər böyük bir qarışıqlığa çevrildiyini görürsünüz." Bu, əlbəttə, doğru deyil, amma bu, Application subclass üzərində Singleton seçmək üçün bir səbəb deyil. Dianein arqumentlərinin heç biri Singletondan bir tətbiqin alt sinifindən daha yaxşı olduğunu, Singleton istifadə etməyinin, yanlış hesab etdiyim tətbiqi alt sinifdən daha pis olmadığını düşünmür.

O, belə davam edir: "Və daha çox təbii olaraq bu şeyləri necə idarə etməlisiniz - onları tələbatla hazırlayırsınız". Bu, ərizə alt sinfi ilə tələbə başlana bilməyəcək bir səbəb olmadığını nəzərə almır. Yenə də fərq yoxdur.

Dianne "Quruluşun yüklənmiş qaynaqları, obyekt hovuzları və s. Kimi tətbiq üçün dəstəkləyən bütün kiçik ümumi məlumatlar üçün ton və tonlarca ton var." Bu yaxşı işləyir. " Singletons istifadə normal istifadə edə bilməz və ya qanuni alternativ deyil iddia etmirəm. Singletons, Android sistemiylə belə bir güclü müqavilə təmin etmədiyini və tətbiqin alt sinifindən istifadə etdiyini iddia edir və ayrıca Singletons istifadə edərək, adətən asanlıqla dəyişdirilməyən və gələcəkdə bir çox problemə gətirib çıxara bilməyən bir dizaynı göstərir. IMHO, geliştiriciler üçün Android API tərəfindən təqdim edilən güclü müqavilə, Android proqramının ən cəlbedici və xoşagələn istiqamətlərindən biridir və Android platformasını bu gün əldə etdiyi müvəffəqiyyətə yönəldən inkişaf etdiricilərin erkən qəbullarında ona kömək etdi. Singletons istifadə təklifi gizli bir API müqaviləsindən ayrılır və mənim fikrimcə Android çərçivəsini zəifləyir.

Dianne ayrıca, tətbiq alt sinfi istifadə edərək əlavə dezavantajına istinad edərək aşağıda şərh etdi, onlar aşağı bir performans kodunun yazılmasını təşviq edə və ya sadələşdirə bilər. Bu çox doğrudur və bu cavabı burada nəzərdən keçirilməsinin vacibliyini vurğulamaq və tətbiqin alt sinfi istifadə edərkən düzgün yanaşma düzəldirdim. Dianne görə, prosesiniz yüklənildikdə ərizə sinfi hər dəfə yaradılacağını xatırlamaq vacibdir (proses bir neçə prosesdədirsə, bir neçə dəfə tətbiq oluna bilər!), Hərəkət yalnız hadisə fonunda yayımlanması üçün yüklənir. Buna görə də, ərizə sinfinizin tətbiqinizin ümumi komponentlərinə göstəricilər üçün daha çox məlumat bazası kimi istifadə etməsi vacibdir və hər hansı bir emal üçün yer kimi deyil!

Sizi əvvəlki StackExchange linkindən oğurlandıqları təkliklər üçün aşağıda sadalanan siyahılardan buraxıram:

  • Abstract və ya interface dərslərindən istifadə etmək mümkünsüz;
  • Subclass üçün qeyri-mümkün;
  • Ərizələr arasında yüksək əlaqələr (dəyişdirmək çətin);
  • Doğrulaması çətindir (modul testlər yaratmaq / soxmaq mümkün deyil);
  • Dəyişkən bir dövlət halında paralelləşmək çətindir (geniş bloklama tələb olunur);

və özünüzü əlavə edin:

  • Android (və ya digərlərinin) inkişafına uyğun olmayan həyat üçün qeyri-səlis və idarəolunmayan müqavilə;
926
02 апр. cavab tezliklə veriləcək 02 Apr 2009-04-02 07:34 '09 saat 07:34 'da 2009-04-02 07:34

Bu alt sinfi yaradın

 public class MyApp extends Application { String foo; } 

AndroidManifest.xml da, Android əlavə edin: adı

border=0

Misal

 <application android:name=".MyApp" android:icon="@drawable/icon" android:label="@string/app_name"> 
151
26 июля '10 в 23:31 2010-07-26 23:31 Cavab ebuprofen tərəfindən 26 iyul 'da 23:31' də verildi 2010-07-26 23:31

Soonil'in tətbiqi üçün dövlətin saxlama üsulu yaxşıdır, amma bir zəif nöqtəyə malikdir - OS bütün tətbiq prosesini öldürən zamanlar var. İşdə bu məsələyə dair sənədlər - Proseslər və Həyat dövrü .

Bir işi nəzərdən keçirin - ərizə aranızda gedər, çünki kimsə sizə zəng edir (indi telefonda proqram ön planda). Bu halda bəzi digər şərtlərdə (yuxarıdakı linkləri ola bilərlər) yoxlayın. OS, tətbiq alt sinfi nümunəsi də daxil olmaqla, tətbiq prosesini öldürə bilər. Nəticədə, dövlət itirdi. Tətbiqə daha sonra qayıtdığınızda, OS əməliyyat yığını və Application nüsxəsini bir alt myState , lakin myState sahəsi null olacaq.

AFAIK, bir dövlətin təhlükəsizliyini təmin etmək üçün yeganə yol, hər hansı bir dövlətdən istifadə etməkdir, məsələn, xüsusi bir ərizə faylını və ya SharedPrefernces (son olaraq daxili fayl sistemində qapalı ərizə faylını istifadə edir).

136
10 янв. Cavab 10 yanvar Vit Khudenko tərəfindən verilir 2011-01-10 00:49 '11 at 0:49 2011-01-10 00:49

Yalnız qeyd edin.

əlavə edin:

 android:name=".Globals" 

və ya alt sinif etiketinizi mövcud bir <application> olaraq adlandırdığınız kimi. Manifestə başqa bir <application> əlavə etməyə çalışırdım və istisna etdim.

25
14 апр. cavab Gimbl 14 apr tərəfindən verilir . 2011-04-14 00:29 '11 at 0:29 2011-04-14 00:29

Proqram etiketini necə göstərəcəyini də tapa bilmədim, ancaq bir çox googling sonrasında bu açıq sənəd fayllarından aydın oldu: Android istifadə edin: adı, tətbiq lövhəsində default simvol və etiketi əlavə edin.

Android: adı Ərizə üçün tətbiq olunan ərizə alt sinfi tam adı. Tətbiq prosesi başlandıqda, bu sinif tətbiq komponentlərindən əvvəl yaradılır.

Alt sinif isteğe bağlıdır; ən çox müraciət etməyiniz lazım deyil. Bir alt sinif olmadığı halda, Android əsas tətbiq sinfi nümunəsini istifadə edir.

13
14 янв. Jan 14-də Mike Brown tərəfindən verilmiş cavab 2010-01-14 08:26 '10 at 8:26 AM 2010-01-14 08:26

Belə qlobal strukturlar ilə daxili yaddaşın toplanmasını necə təmin etmək olar?

Eylemler, onPause/onDestroy() bir onPause/onDestroy() yöntemine malikdir, lakin Uygulama sınıfının eşdeğerleri yoxdur. Qlobal strukturların (xüsusilə də quraşdırılmış yaddaşa aid olanları əhatə edənlər) tətbiqi ya öldürüldüyündən və ya vəzifə yığını arka planda yerləşdirildikdən sonra müvafiq zibil toplamaq üçün hansı mexanizm təklif olunur?

13
25 февр. cavab 25 fevralda user608578 tərəfindən verilir. 2011-02-25 21:32 '11 'da 21:32' də 2011-02-25 21:32

Aşağıda göstərildiyi kimi proqramın adını yalnız müəyyənləşdirməlisiniz:

 <application android:name="ApplicationName" android:icon="@drawable/icon"> </application> 
5
07 янв. Anand 07 yanvar cavab verdi 2011-01-07 08:57 '11 at 8:57 2011-01-07 08:57

Bəzi dəyişənlər sqlite saxlanılırsa və tətbiqinizdə əksər tədbirlərdə istifadə etməlisiniz. sonra ərizə onu əldə etmək üçün ən yaxşı yol ola bilər. Tətbiqə başlandıqda veritabanından dəyişənləri istəyə və onları sahədə saxlaya bilərsiniz. Sonra bu dəyişənləri hərəkətlərinizdə istifadə edə bilərsiniz.

Beləliklə doğru yolu tapın və daha yaxşı bir yol yoxdur.

4
20 апр. cavab user716653 20 apr tərəfindən verilir . 2011-04-20 10:32 '11 at 10:32 'da 2011-04-20 10:32

Yuxarıda qeyd edildiyi kimi, OS bildiriş vermədən APPLICATION'i öldürə bilər (heç bir DStroy hadisəsi yoxdur), bu qlobal dəyişənləri saxlamaq üçün heç bir yol yoxdur.

SharedPreferences bir EXCEPT həlli ola bilər, siz COMPLEX STRUKTURAL dəyişənləriniz var (mənim vəziyyətdə istifadəçi artıq işləyən identifikatorların saxlanması üçün bir tam sıra var idi). SharedPreferences ilə problem, zəruri hallarda bu strukturları hər dəfə saxlamağı və əldə etməsi çətindir.

Mənim vəziyyətimdə bir yardım masası var idi, buna görə də bu dəyişənləri orada hərəkət edə bilərik və xidmət bir onDestroy hadisəsi olduğundan asanlıqla bu dəyərləri xilas edə bilərəm.

4
02 нояб. Cavab Adorjan Princz 02 noyabr. 2012-11-02 11:53 '12 at 11:53 2012-11-02 11:53

Bu vəziyyəti saxlamaq üçün statik bir sahəyə sahib ola bilərsiniz. Və ya Resurs Bundle'ına yerləşdirin və onCreate-ə bərpa edin (Bundle savedInstanceState). Yalnız Android tətbiqləri tərəfindən idarə olunan həyat dövrünü tam başa düşdüyünüzə əmin olun (məsələn, klaviatura orientasiyası dəyişdirildikdə niyə login () adlanır).

3
02 апр. cavab verildi yanchenko 02 Apr 2009-04-02 05:19 '09 at 05:19 AM 2009-04-02 05:19

MƏLUMAT faylında fərqli bir <application> istifadə edin. Mövcud <application> üçün bir dəyişiklik edin, bu xətt əlavə edin android:name=".ApplicationName" , burada ApplicationName siz yaratacağınız alt sinifinizin adı olacaqdır (qlobal saxlama üçün istifadə edin).

nəhayət, manifest faylında BİR və yalnız <application> aşağıdakı kimi olmalıdır: -

 <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:theme="@style/Theme.AppCompat.NoActionBar" android:name=".ApplicationName" > 
2
22 июня '15 в 14:20 2015-06-22 14:20 cavab 22 iyun 'da 14:20' de qumar gündan verilir 2015-06-22 14:20

Bunu iki yanaşmadan istifadə edə bilərsiniz:

  • Application Class istifadə
  • Ümumi parametrlərdən istifadə

  • Application Class istifadə

Məsələn:

 class SessionManager extends Application{ String sessionKey; setSessionKey(String key){ this.sessionKey=key; } String getSessisonKey(){ return this.sessionKey; } } 

Aşağıda göstərildiyi kimi MainActivity-ə daxil olmağı yuxarıdakı sinifdən istifadə edə bilərsiniz. Kod belə bir şeyə bənzəyir:

 @override public void onCreate (Bundle savedInstanceState){ // you will this key when first time login is successful. SessionManager session= (SessionManager)getApplicationContext(); String key=getSessisonKey.getKey(); //Use this key to identify whether session is alive or not. } 

Bu üsul müvəqqəti saxlama üçün işləyəcək. Həqiqətən əməliyyat sisteminin aşağı yaddaş səbəbiylə ərizəni öldürdüyünü bilirsiniz. Ərizə arka planda olduğunda və istifadəçi daha çox yaddaşın istifadəsini tələb edən başqa proqram vasitəsilə hərəkət edərsə, əməliyyat sistemi əməliyyat sisteminin arxa plan proseslərinə daha çox diqqət yetirdiyi üçün öldürülür. Buna görə, istifadəçi oturum açmadan əvvəl tətbiq obyektiniz boş olacaq. Buna görə də, bunun üçün yuxarıda göstərilən ikinci üsuldan istifadə etməyi məsləhət görürəm.

  1. Ümumi parametrlərdən istifadə.

     String MYPREF="com.your.application.session" SharedPreferences pref= context.getSharedPreferences(MyPREF,MODE_PRIVATE); //Insert key as below: Editot editor= pref.edit(); editor.putString("key","value"); editor.commit(); //Get key as below. SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE); String key= getResources().getString("key"); 
1
19 дек. Cavab 19 dekabrda Krishna tərəfindən verilir . 2015-12-19 16:03 '15 'da 16:03' de, 2015-12-19 16:03

Fəaliyyətin nəticələrinə əsasən bərpa edilməzdən əvvəl çağırılır. Buna görə də, girişə keçmək üçün girişin köçürülməsi və ikinci girişiniz secomd fəaliyyəti müsbət nəticə vermədiyi anda bloklana bilər. Каждый раз, когда вызывается о возобновлении, вызывается о том, что он не вызывает беспокойства в первый раз.

0
ответ дан user3044482 11 окт. '14 в 10:36 2014-10-11 10:36

Подход к подклассу также используется базой BARACUS. С моей точки зрения подклассы Приложение предназначалось для работы с жизненными циклами Android; это то, что делает любой контейнер приложений. Вместо того, чтобы иметь глобальные значения, я регистрирую beans в этом контексте, позволяя им вводиться в любой класс, управляемый контекстом. Каждый инъецируемый экземпляр bean на самом деле является одноэлементным.

Подробнее см. в этом примере

Почему ручная работа, если вы можете иметь гораздо больше?

0
ответ дан gorefest 11 нояб. '14 в 16:01 2014-11-11 16:01

Вы можете создать класс, который расширяет класс Application , а затем объявит вашу переменную как поле этого класса и предоставит метод getter для нее.

 public class MyApplication extends Application { private String str = "My String"; synchronized public String getMyString { return str; } } 

И затем, чтобы получить доступ к этой переменной в вашей Деятельности, используйте это:

 MyApplication application = (MyApplication) getApplication(); String myVar = application.getMyString(); 
0
ответ дан Amit Tiwari 28 нояб. '15 в 16:05 2015-11-28 16:05

вы можете использовать Intents, Sqlite или Shared Preferences. Когда речь заходит о медиа-хранилище, например о документах, фотографиях и видео, вы можете создавать новые файлы.

0
ответ дан Raju yourPepe 16 июля '13 в 4:35 2013-07-16 04:35
 class GlobaleVariableDemo extends Application { private String myGlobalState; public String getGlobalState(){ return myGlobalState; } public void setGlobalState(String s){ myGlobalState = s; } } class Demo extends Activity { @Override public void onCreate(Bundle b){ ... GlobaleVariableDemo appState = ((GlobaleVariableDemo)getApplicationContext()); String state = appState.getGlobalState(); ... } } 
0
ответ дан Vaishali Sutariya 17 июля '14 в 13:31 2014-07-17 13:31

Другие вопросы по меткам или Задайте вопрос