कक्ष का उपयोग करने के लिए 7 कदम। अपने आवेदन को कमरे में स्थानांतरित करने के लिए पूर्वाभ्यास

कमरा एक पुस्तकालय है जो Android के वास्तु घटकों का हिस्सा है। यह एप्लिकेशन में SQLiteDatabase वस्तुओं के साथ काम करने की सुविधा देता है, मानक कोड की मात्रा को कम करता है और संकलन समय पर SQL क्वेरी की जांच करता है।

पहले से ही एक Android प्रोजेक्ट है जो डेटा स्टोर करने के लिए SQLite का उपयोग करता है? यदि हां, तो आप इसे कमरे में स्थानांतरित कर सकते हैं। आइए देखें कि मौजूदा प्रोजेक्ट को कैसे लेना है और इसे 7 सरल चरणों में रूम का उपयोग करने के लिए रिफलेक्टर करना है।

TL; DR: ग्रेड निर्भरता को अद्यतन करें, अपनी संस्थाएं, DAO और डेटाबेस बनाएं, SQLiteDatabase कॉल को DAO विधि कॉल के साथ बदलें, आपके द्वारा बनाए गए या संशोधित किए गए सभी चीजों का परीक्षण करें और अप्रयुक्त कक्षाओं को हटा दें। वह सब है!

माइग्रेशन के लिए हमारे नमूना आवेदन में , हम टाइप User की वस्तुओं के साथ काम करते हैं। हमने विभिन्न डेटा-स्तरीय कार्यान्वयन प्रदर्शित करने के लिए उत्पाद स्वादों का उपयोग किया:

1. sqlite - SQLiteOpenHelper और पारंपरिक SQLite इंटरफेस का उपयोग करता है।
2. कमरा - कमरे के साथ कार्यान्वयन को प्रतिस्थापित करता है और प्रवास प्रदान करता है।

प्रत्येक विकल्प एक ही यूजर इंटरफेस लेयर का उपयोग करता है, जो UserRepository पैटर्न के लिए UserRepository वर्ग के साथ काम करता है।

साइक्लाइट संस्करण में, आपको बहुत से कोड दिखाई देंगे जो अक्सर डुप्लिकेट होते हैं और डेटाबेस में UsersDbHelper और LocalUserDataSource का उपयोग करते LocalUserDataSource । ContentValues का ContentValues करके क्वेरीज़ बनाई जाती हैं, और Cursor ऑब्जेक्ट्स द्वारा लौटाए गए डेटा को कॉलम द्वारा कॉलम पढ़ा जाता है। यह सब कोड निहित त्रुटियों की उपस्थिति में योगदान देता है। उदाहरण के लिए, आप किसी कॉलम को क्वेरी में जोड़ना या डेटाबेस से किसी ऑब्जेक्ट को गलत तरीके से इकट्ठा करना छोड़ सकते हैं।

आइए देखें कि कमरा हमारे कोड को कैसे बेहतर बनाता है। प्रारंभ में, हम बस वर्गलाइट संस्करण से कक्षाओं की प्रतिलिपि बनाते हैं और धीरे-धीरे उन्हें बदलते हैं।

चरण 1. ढाल निर्भरता को अद्यतन करना

कक्ष के लिए निर्भरताएँ नए Google मावेन भंडार के माध्यम से उपलब्ध हैं। बस इसे अपनी मुख्य build.gradle फ़ाइल में रिपॉजिटरी की सूची में जोड़ें:

 allprojects { repositories { google() jcenter() } } 

उसी फ़ाइल में रूम लाइब्रेरी के संस्करण को परिभाषित करें। हालांकि यह अल्फा संस्करण में है, लेकिन डेवलपर पृष्ठों पर संस्करण अपडेट के लिए बने रहें:

 ext { roomVersion = '2.1.0-alpha03' } 

अपने app/build.gradle कक्ष के लिए निर्भरता जोड़ें:

 dependencies { implementation “android.arch.persistence.room:runtime:$rootProject.roomVersion” annotationProcessor “android.arch.persistence.room:compiler:$rootProject.roomVersion” androidTestImplementation “android.arch.persistence.room:testing:$rootProject.roomVersion” } 

कक्ष में माइग्रेट करने के लिए, हमें डेटाबेस के संस्करण को बढ़ाने की आवश्यकता है, और उपयोगकर्ता डेटा को बचाने के लिए, हमें माइग्रेशन क्लास को लागू करना होगा। माइग्रेशन का परीक्षण करने के लिए , हमें स्कीमा को निर्यात करने की आवश्यकता है। ऐसा करने के लिए, app/build.gradle में निम्न कोड जोड़ें:

 android { defaultConfig { ... // used by Room, to test migrations javaCompileOptions { annotationProcessorOptions { arguments = ["room.schemaLocation": "$projectDir/schemas".toString()] } } } // used by Room, to test migrations sourceSets { androidTest.assets.srcDirs += files("$projectDir/schemas".toString()) } ... 

चरण 2. संस्थाओं के लिए मॉडल कक्षाओं को अद्यतन करना

कक्ष प्रत्येक वर्ग के लिए एक तालिका बनाता है जो @ चिह्नित है। कक्षा के क्षेत्र तालिका में स्तंभों के अनुरूप हैं। नतीजतन, इकाई वर्ग, एक नियम के रूप में, मॉडल के छोटे वर्ग हैं जिनमें कोई तर्क नहीं है। हमारा User वर्ग डेटाबेस में डेटा के लिए एक मॉडल का प्रतिनिधित्व करता है। तो, चलिए इसे कक्ष को बताने के लिए अपडेट करते हैं कि इसे इस वर्ग के आधार पर एक तालिका बनाना चाहिए:

• @Entity साथ वर्ग को एनोटेट करें और टेबल का नाम सेट करने के लिए @Entity का उपयोग करें।
• सही फ़ील्ड में @PrimaryKey एनोटेशन जोड़कर प्राथमिक कुंजी सेट करें - हमारे मामले में, यह उपयोगकर्ता आईडी है।
• @ColumnInfo(name = "column_name") एनोटेशन @ColumnInfo(name = "column_name") का उपयोग करके वर्ग फ़ील्ड के लिए कॉलम नाम निर्दिष्ट करें। आप इस चरण को छोड़ सकते हैं यदि आपके खेतों को पहले से ही नाम दिया गया है जैसा कि कॉलम का नाम होना चाहिए।
• यदि क्लास में कई कंस्ट्रक्टर हैं, तो @Ignore एनोटेशन @Ignore बताएं कि कौन सा कमरा इस्तेमाल करना है और कौन सा नहीं।

 @Entity(tableName = "users") public class User { @PrimaryKey @ColumnInfo(name = "userid") private String mId; @ColumnInfo(name = "username") private String mUserName; @ColumnInfo(name = "last_update") private Date mDate; @Ignore public User(String userName) { mId = UUID.randomUUID().toString(); mUserName = userName; mDate = new Date(System.currentTimeMillis()); } public User(String id, String userName, Date date) { this.mId = id; this.mUserName = userName; this.mDate = date; } ... } 

नोट: सुचारू प्रवास के लिए, मूल कार्यान्वयन में तालिकाओं और स्तंभों के नामों पर पूरा ध्यान दें और सुनिश्चित करें कि आपने उन्हें @Entity और @ColumnInfo में सही तरीके से सेट किया है।

चरण 3. डेटा एक्सेस ऑब्जेक्ट बनाना (DAO)

डीएओ डेटाबेस एक्सेस के तरीकों को परिभाषित करने के लिए जिम्मेदार हैं। हमारे SQLite परियोजना के प्रारंभिक कार्यान्वयन में, सभी डेटाबेस प्रश्नों को LocalUserDataSource वर्ग में निष्पादित किया गया LocalUserDataSource , जहां हमने Cursor वस्तुओं के साथ काम किया था। कक्ष में, हमें कर्सर से जुड़े सभी कोड की आवश्यकता नहीं होती है, और हम UserDao क्लास में एनोटेशन का उपयोग करके केवल हमारे अनुरोधों को परिभाषित कर सकते हैं।

उदाहरण के लिए, डेटाबेस से सभी उपयोगकर्ताओं को क्वेरी करते समय, कक्ष सभी "कड़ी मेहनत" करता है, और हमें बस लिखने की आवश्यकता है:

 @Query(“SELECT * FROM Users”) List<User> getUsers(); 

चरण 4. एक डेटाबेस बनाना

हमने पहले ही अपनी Users तालिका और इसके संबंधित प्रश्नों को परिभाषित किया है, लेकिन हमने अभी तक एक डेटाबेस नहीं बनाया है जो कक्ष के इन सभी घटकों को एकजुट करेगा। ऐसा करने के लिए, हमें एक सार वर्ग को परिभाषित करने की आवश्यकता है जो RoomDatabase विस्तारित RoomDatabase । इस वर्ग को @Database रूप में चिह्नित किया @Database , जो डेटाबेस में निहित वस्तुओं और डीएओ को सूचीबद्ध करता है जो उन्हें एक्सेस करते हैं। डेटाबेस संस्करण को मूल मूल्य की तुलना में 1 से बढ़ाया जाना चाहिए, इसलिए हमारे मामले में यह 2 होगा।

 @Database(entities = {User.class}, version = 2) @TypeConverters(DateConverter.class) public abstract class UsersDatabase extends RoomDatabase { private static UsersDatabase INSTANCE; public abstract UserDao userDao(); 

चूंकि हम उपयोगकर्ता डेटा को सहेजना चाहते हैं, इसलिए हमें Migration क्लास को यह बताकर लागू करना होगा कि कमरा 1 से 2 तक स्विच करते समय क्या करना चाहिए। हमारे मामले में, चूंकि डेटाबेस स्कीमा नहीं बदला है, हम बस एक खाली कार्यान्वयन प्रदान करते हैं:

 static final Migration MIGRATION_1_2 = new Migration(1, 2) { @Override public void migrate(SupportSQLiteDatabase database) { //     ,      . } }; 

डेटाबेस नाम और माइग्रेशन को परिभाषित करके उपयोगकर्ता डेटाबेस श्रेणी में एक डेटाबेस ऑब्जेक्ट बनाएँ:

 database = Room.databaseBuilder(context.getApplicationContext(), UsersDatabase.class, "Sample.db") .addMigrations(MIGRATION_1_2) .build(); 

डेटाबेस माइग्रेशन को कैसे कार्यान्वित करें और वे हुड के तहत कैसे काम करते हैं, इस बारे में अधिक जानने के लिए, इस पोस्ट को देखें ।

चरण 5. कक्ष का उपयोग करने के लिए भंडार का अद्यतन करना

हमने अपना डेटाबेस, अपनी उपयोगकर्ता तालिका और क्वेरी बनाई, इसलिए अब उनका उपयोग करने का समय आ गया है। इस बिंदु पर, हम UserDao विधियों का उपयोग करने के लिए UserDao वर्ग को अपडेट करेंगे। ऐसा करने के लिए, हम पहले कंस्ट्रक्टर को अपडेट करते हैं: Context हटा दें और UserDao जोड़ें। बेशक, किसी भी वर्ग जो LocalUserDataSource का एक उदाहरण बनाता है, उसे भी अपडेट किया जाना चाहिए।

इसके बाद, हम LocalUserDataSource विधियों को अपडेट करेंगे जो LocalUserDataSource विधियों को कॉल करके प्रश्न बनाते हैं। उदाहरण के लिए, एक विधि जो अब सभी उपयोगकर्ताओं से अनुरोध करती है वह इस तरह दिखती है:

 public List<User> getUsers() { return mUserDao.getUsers(); } 

और अब लॉन्च करने का समय है जो हमने किया।

कक्ष की सबसे अच्छी विशेषताओं में से एक यह है कि यदि आप मुख्य धागे पर डेटाबेस संचालन करते हैं, तो आपका एप्लिकेशन निम्न त्रुटि संदेश के साथ क्रैश हो जाएगा:

 java.lang.IllegalStateException: Cannot access database on the main thread since it may potentially lock the UI for a long period of time. 

मुख्य थ्रेड से I / O संचालन को स्थानांतरित करने का एक विश्वसनीय तरीका एक नया Runnable बनाना है जो प्रत्येक डेटाबेस क्वेरी के लिए एक नया थ्रेड बनाएगा। चूँकि हम पहले से ही साइक्लाइट संस्करण में इस दृष्टिकोण का उपयोग करते हैं, इसलिए किसी बदलाव की आवश्यकता नहीं थी।

चरण 6. डिवाइस पर परीक्षण

हमने नई कक्षाएं UserDao - UserDao और UsersDatabase और कक्ष डेटाबेस का उपयोग करने के लिए हमारे LocalUserDataSource को बदल दिया। अब हमें उनका परीक्षण करने की आवश्यकता है।

परीक्षण उपयोगकर्ताडॉ

UserDao परीक्षण करने के लिए, हमें एक परीक्षण वर्ग AndroidJUnit4 बनाने की आवश्यकता है। कक्ष की आश्चर्यजनक विशेषता स्मृति में एक डेटाबेस बनाने की क्षमता है। यह प्रत्येक परीक्षण के बाद सफाई की आवश्यकता को समाप्त करता है।

 @Before public void initDb() throws Exception { mDatabase = Room.inMemoryDatabaseBuilder( InstrumentationRegistry.getContext(), UsersDatabase.class) .build(); } 

हमें यह भी सुनिश्चित करने की आवश्यकता है कि हम प्रत्येक परीक्षण के बाद डेटाबेस कनेक्शन को बंद कर दें।

 @After public void closeDb() throws Exception { mDatabase.close(); } 

उदाहरण के लिए, उपयोगकर्ता के लॉगिन का परीक्षण करने के लिए, हम एक उपयोगकर्ता जोड़ते हैं और फिर यह देखने के लिए जांचते हैं कि क्या हम उस उपयोगकर्ता को डेटाबेस से प्राप्त कर सकते हैं।

 @Test public void insertAndGetUser() { //      mDatabase.userDao().insertUser(USER); //        List<User> users = mDatabase.userDao().getUsers(); assertThat(users.size(), is(1)); User dbUser = users.get(0); assertEquals(dbUser.getId(), USER.getId()); assertEquals(dbUser.getUserName(), USER.getUserName()); } 

LocalUserDataSource में UserDao के उपयोग का परीक्षण

यह सुनिश्चित करना कि LocalUserDataSource अभी भी सही ढंग से काम कर रहा है, आसान है, क्योंकि हमारे पास पहले से ही परीक्षण हैं जो इस वर्ग के व्यवहार का वर्णन करते हैं। हमें बस इतना करना है कि मेमोरी में एक डेटाबेस बनाएं, UserDao से एक UserDao ऑब्जेक्ट प्राप्त करें और इसे LocalUserDataSource कंस्ट्रक्टर के लिए एक पैरामीटर के रूप में उपयोग करें।

 @Before public void initDb() throws Exception { mDatabase = Room.inMemoryDatabaseBuilder( InstrumentationRegistry.getContext(), UsersDatabase.class) .build(); mDataSource = new LocalUserDataSource(mDatabase.userDao()); } 

फिर, हमें यह सुनिश्चित करने की आवश्यकता है कि हम प्रत्येक परीक्षण के बाद डेटाबेस को बंद कर दें।

डेटाबेस प्रवासन परीक्षण

आप डेटाबेस माइग्रेशन टेस्ट को कैसे लागू करें, साथ ही साथ MigrationTestHelper कैसे काम करता है, इस पोस्ट में और अधिक पढ़ सकते हैं।

आप कोड को अधिक विस्तृत माइग्रेशन एप्लिकेशन उदाहरण से भी देख सकते हैं।

चरण 7. सभी अनावश्यक को हटाना

किसी भी अप्रयुक्त वर्ग और कोड की पंक्तियों को हटा दें जो अब कक्ष कार्यक्षमता द्वारा प्रतिस्थापित किए गए हैं। हमारे प्रोजेक्ट में, हमें केवल UsersDbHelper क्लास को हटाने की आवश्यकता है, जिसने SQLiteOpenHelper क्लास का विस्तार किया।

यदि आपके पास एक बड़ा और अधिक जटिल डेटाबेस है, और आप धीरे-धीरे रूम में स्विच करना चाहते हैं, तो हम इस पोस्ट की सलाह देते हैं।

अब मानक त्रुटि-प्रवण कोड की मात्रा कम हो गई है, अनुरोध संकलन समय पर जांचे जाते हैं, और सब कुछ परीक्षण किया जाता है। 7 सरल चरणों में, हम अपने मौजूदा एप्लिकेशन को रूम में स्थानांतरित करने में सक्षम थे। आप यहां एक उदाहरण आवेदन देख सकते हैं।