2012-02-14 3 views
0

В настоящее время я использую ContentProvider в своем приложении. Из-за «слоев» и фактической необходимости для провайдера я работаю над оптимизацией доступа к данным в максимально возможной степени. Вот моя попытка сделать это:Самый эффективный способ доступа/записи данных на SQLite на Android

public static String getPreferenceString(Context context, String key) 
    { 
     DatabaseHelper helper = new DatabaseHelper(context); 
     SQLiteDatabase database = helper.getReadableDatabase(); 
     SQLiteStatement statement = database.compileStatement("SELECT Value FROM Preferences WHERE Key='" + key + "' LIMIT 1"); 

     try 
     { 
      return statement.simpleQueryForString(); 

     } 
     catch (Exception ex) 
     { 
      return ""; 
     } 
     finally 
     { 
      statement.close(); 
      database.close(); 
      helper.close(); 
     } 
    } 

    public static void setPreferenceString(Context context, String key, String value) 
    { 
     DatabaseHelper helper = new DatabaseHelper(context); 
     SQLiteDatabase database = helper.getReadableDatabase(); 
     SQLiteStatement statement = database.compileStatement("INSERT OR REPLACE INTO Preferences (Key, UpdatedOn, Value) VALUES ('" + 
       key + "', '" + 
       Utility.getDateConvertedToUTCDBString(new Date()) + "', '" + 
       value + "'); "); 
     try 
     { 
      statement.execute(); 
     } 
     finally 
     { 
      statement.close(); 
      database.close(); 
      helper.close(); 
     } 
    } 
  1. Это примерно так же близко, как я могу добраться до прямых вызовов SQLite?
  2. Должен ли я иметь все это .close() заявления в моем коде?
  3. В setPreferenceString Я действительно копировал/вставлял и вызывал getReadableDatabase, хотя я пишу данные, и это работает. Зачем?
+0

Что вы подразумеваете под «прямыми звонками»? Запросы AFAIK SQL являются самыми низкими, вы можете пойти против БД. – m0skit0

+0

Да, вот что я имел в виду. Просто хочу проверить, чтобы я делал большинство прямых звонков. Кроме того, мне хотелось узнать, действительно ли этот код - возможности блокировки, и т. Д. – katit

+0

Я не могу найти код, где вы выбираете базу данных для выполнения всех этих запросов, что сделано в расширенном классе DatabaseHelper, не так ли? – Andreas

ответ

0

Это как можно ближе к прямым вызовам SQLite?

AFAIK SQL запросы ближе вы можете пойти против РБДА

Если у меня есть все это .close() заявления, содержащиеся в моем коде?

Лично я не создавал DatabaseHelper, SQLiteDatabase и SQLiteStatement каждый раз, когда вызываю этот метод. Я бы создал все это только до того, как вы им понадобятся, и закройте их, когда они больше не нужны. Также централизация это хорошая идея ИМХО (например, с использованием одного синглета).

Кроме того, ваш SQL заявление может быть написано как

SELECT Value FROM Preferences WHERE Key= ? LIMIT 1 

Таким образом, у вас есть только подготовить его один раз и параметры связывания, как вам нужно заявление. То же самое касается любого SQL-запроса.

+0

Вы бы создали помощник/базу данных/заявления в объекте Application? Я где-то читал, что объект приложения скорее всего будет убит ОС, если я добавлю в него много вещей. – katit

+0

Другое дело. Нет никакого способа сделать параметризованный SQL с SQLiteStatement в Android, если я не пропущу что-то. Я использую API7 – katit

+0

Можете ли вы указать мне на это письмо? Также вы можете использовать синглтон для хранения всего этого и создания/уничтожения по желанию. В любом случае, я не буду использовать этот метод. Вероятно, у вас есть такой же код, клонированный во многих местах, если вы обращаетесь к БД для других вещей, и это определенно не хорошо :) – m0skit0

Смежные вопросы