Configuration d’Ormlite sans utiliser les activités de base

J’utilise ORMLite dans un projet Android et je ne souhaite pas utiliser les activités étendues car j’insère des valeurs dans la firebase database sur une tâche asynchrone.

Dans la documentation, il est écrit:

“Si vous ne souhaitez pas étendre OrmLiteBaseActivity et d’autres classes de base, vous devez dupliquer leurs fonctionnalités. Vous devez appeler OpenHelperManager.getHelper(Context context, Class openHelperClass) au début de votre code, enregistrer l’aide et l’utiliser. autant que vous le souhaitez, puis appelez OpenHelperManager.release() lorsque vous avez terminé. ”

Il est également indiqué d’append la classe d’assistance de firebase database dans le ssortingngs.xml , que j’ai. Donc, je ne suis pas sûr de ce que je fais mal.

J’utilise une classe appelée DataAccess pour mon niveau de données qui ressemble à ceci:

 public class DataAccess { private Context context; private DBHelper dbHelper; public DataAccess(Context _context) { this.context = _context; dbHelper = getDBHelper(_context); } private DBHelper getDBHelper(Context context) { if (dbHelper == null) { dbHelper = (DBHelper) OpenHelperManager.getHelper(context, DBHelper.class); } return dbHelper; } }

Et j’utilise la classe d’assistance étendue:

 public class DBHelper extends OrmLiteSqliteOpenHelper { private static final Ssortingng DATABASE_NAME = "database.db"; private static final int DATABASE_VERSION = 1; private Dao someObjectTable = null; private ConnectionSource connectionSource = null; public DBHelper(Context context) { super(context, DATABASE_NAME, null, DATABASE_VERSION); } @Override public void onCreate(SQLiteDatabase db, ConnectionSource connectionSource) { this.connectionSource = connectionSource; try { TableUtils.createTable(connectionSource, SomeObject.class); } catch (SQLException e) { throw new RuntimeException(e); } } @Override public void onUpgrade(SQLiteDatabase db, ConnectionSource connectionSource, int oldVersion, int newVersion) { } public Dao getSomeObjectDao() throws SQLException { if (someObjectTable == null) { dateTable = getDao(SomeObject.class); } return someObjectTable; }

L’idée est de créer la classe DataAccess et de lui créer le DBHelper s’il ne l’a pas déjà fait.

Quelqu’un peut-il me dire si cela est vrai ou faux ou si je suis sur la bonne voie?

Merci!

J’utilise ORMLite dans un projet Android et je ne souhaite pas utiliser les activités étendues, car j’insère des valeurs dans la firebase database sur une tâche asynchrone.

Vous êtes sur la bonne voie mais un peu en retrait de @Matt. Franchement, je n’avais jamais réalisé de projet sans élargir nos classes de base. Mais comme c’est un bon exercice, j’ai donc créé cet exemple de projet ORMLite qui utilise une Activity et gère son propre assistant.

Votre classe DBHelper va bien, mais vous n’avez vraiment pas besoin de votre classe DataAccess . Dans chacune de vos activités (ou services …), vous aurez besoin de quelque chose comme:

 private DBHelper dbHelper = null; @Override protected void onDestroy() { super.onDestroy(); if (dbHelper != null) { OpenHelperManager.releaseHelper(); dbHelper = null; } } private DBHelper getHelper() { if (dbHelper == null) { dbHelper = (DBHelper)OpenHelperManager.getHelper(this, DBHelper.class); } return dbHelper; }

Vous [évidemment], puis utilisez ceci dans votre code en faisant quelque chose comme:

 Dao someObjectDao = getHelper().getSomeObjectDao();

Ainsi, chaque fois que vous appelez getHelper() la première fois, l’assistant passe par le gestionnaire, établissant la connexion à la firebase database. Chaque fois que votre application est détruite par le système d’exploitation, elle libère l’assistant – éventuellement, ferme la connexion à la firebase database sous-jacente s’il s’agit de la dernière version.

Notez que OpenHelperManager.getHelper() besoin du Context comme premier argument au cas où vous le feriez sans même une classe de base Activity .

Modifier:

Si vous souhaitez créer une classe de type DataAccess pour centraliser la gestion de la classe d’assistance, vous devez rendre les méthodes statiques et créer votre propre compteur d’utilisation. S’il existe plusieurs activités et tâches en arrière-plan appelant getHelper() la question est de savoir quand vous appelez releaseHelper() ? Vous devrez incrémenter un nombre pour chaque get et appeler uniquement la libération lorsque le compteur reviendra à 0. Mais même dans ce cas, je ne suis pas sûr à 100% du nombre de lignes que vous auriez sauvegardées dans votre classe d’activité.

Je pourrais nitpick mais essentiellement vous le faites correctement.

L’appel

 dbHelper = (DBHelper) OpenHelperManager.getHelper(context, DBHelper.class);

Recherche la classe DBHelper et l’instancie pour le contexte. Si vous l’avez défini dans votre fichier ssortingngs.xml, vous pouvez laisser le fichier DBHelper.class à la fin.

onUpgrade dans votre DBHelper.java , vous pouvez envisager de supprimer la table créée dans onCreate , puis d’appeler onCreate (pour vous assurer que vous n’avez pas de problèmes de conversion entre mises à jour). Vous pourriez faire une mise à jour plus complexe si vous le souhaitiez.

A part ça, ça a l’air bien. Si vous finissez par vouloir des méthodes d’accessoires de données pour vos objects de firebase database autres que les méthodes DAO de base, vous souhaiterez éventuellement créer des implémentations plus complètes de vos DAO d’objects, mais c’est un bon début.