Singleton gebruik in een android project

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • nowherebound123
  • Registratie: Mei 2009
  • Laatst online: 16:47
Dag medetweakers, voor mijn opleiding ben ik bezig de wondere wereld van native android development uit te vogelen. Om dit voor mijzelf context te geven heb ik een appje bedacht dat ik graag zou willen maken. De app is redelijk eenvoudig in opzet:

- Een gebruiker kan met een druk op de knop een willekeurig land genereren/kiezen
- De app toont op een kaart informatie over het land, en in cardviews wordt straks informatie getoond over het land dat via verschillende publieke apis wordt opgehaald

Vervolgens kan een gebruiker de traditionele gerechten van een land zien, en hier recepten van opvragen. Vervolgens kan de gebruiker wanneer hij een gerecht gemaakt heeft dit invoeren in de app en historisch terugzien wat hij/zij allemaal heeft gegeten door middel van de app.

Het idee is om de culinaire horizon te verbreden ;)

TLDR

Dat gezegd hebbende, ik loop tegen een aantal pijnpunten aan bij het ontwikkelen van de app. Ik weet niet of dit komt omdat mijn implementatie gebrekkig is, of dat de manier waarop ik het probeer te doen gewoon niet aan te raden is.

Het volgende:

Om de land en gerecht informatie op te slaan gebruik ik een lokale sqlite database. Hiervoor heb ik een database helper klasse geschreven die de objecten wegschrijft naar database en ook weer ophaalt.

Wanneer de app start wordt een lijst met landen en gerechten uit de database opgehaald en in een arraylist gezet. Omdat ik dit niet voor elke activity opnieuw wil hoeven doen, en de 'putextra' methode van een intent me wat gebrekkig leek, heb ik alle data die gedeeld moet worden in een statische singleton klasse gezet. Iedere activity vraagt vervolgens een instantie van de singleton op en heeft zo toegang tot de opgehaalde data.

Het probleem is dat je altijd een context mee moet geven aan de singleton en aan ook aan de database helper. Bij het starten van mijn mainactivity roep ik nu een zelfgeschreven functie aan op de singleton die de context van de mainactivity in een variabele opslaat. De singleton geeft deze vervolgens ook weer door aan de databsehelper klasse.

Probleem is dat bij het herstarten van een activity (bijvoorbeeld bij het veranderen van portrait naar landscape) de app altijd crasht met 'out of memory' achtige errors.

Na wat onderzoek op het internet heb ik een vermoeden dat dit komt omdat ik dus een copy van mijn context bewaar, en deze door de garbage collector dus niet wordt vernietigd.

Mijn vraag is eigenlijk, is mijn opzet met singletons aan te raden/ gebruikelijk binnen het android landschap?

Sorry voor het lange verhaal

Volledige broncode is te vinden op:

https://github.com/nilsk123/CulinaryWorldTour.git

Acties:
  • 0 Henk 'm!

  • YakuzA
  • Registratie: Maart 2001
  • Niet online

YakuzA

Wat denk je nou zelluf hey :X

Het makkelijkste is om de instancing naar je DatabaseHelper te verschuiven.

Zoals beschreven in http://www.androiddesignp...your-sqlite-database.html

Java:
1
2
3
4
5
6
7
8
9
10
11
12
  private static DatabaseHelper sInstance;
  public static synchronized DatabaseHelper getInstance(Context context) {
     
    if (sInstance == null) {
      sInstance = new DatabaseHelper(context.getApplicationContext());
    }
    return sInstance;
  }

  private DatabaseHelper(Context context) {
    super(context, DATABASE_NAME, null, DATABASE_VERSION);
  }

Death smiles at us all, all a man can do is smile back.
PSN


Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 15:36

Janoz

Moderator Devschuur®

!litemod

Wanneer de app start wordt een lijst met landen en gerechten uit de database opgehaald en in een arraylist gezet. Omdat ik dit niet voor elke activity opnieuw wil hoeven doen
Waarom? Je hebt een lokaal draaiende database waarin deze gegevens staan. Waarom zou je daar bovenop nog een eigen homebrew datastore gaan maken?

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • 0 Henk 'm!

  • nowherebound123
  • Registratie: Mei 2009
  • Laatst online: 16:47
Janoz schreef op dinsdag 12 april 2016 @ 13:28:
[...]

Waarom? Je hebt een lokaal draaiende database waarin deze gegevens staan. Waarom zou je daar bovenop nog een eigen homebrew datastore gaan maken?
Er kunnen tot een paar honderd landen in de database staan, en ieder van deze landen kan in theorie een oneindig aantal gerechten aan zich gekoppeld hebben. Het ophalen van deze data en het omzetten naar objecten kan dus wel even duren.

Aangezien de data in principe uitwisselbaar is tussen activities, leek het me niet erg efficient voor iedere activity dit proces opnieuw uit te voeren. Of sla ik hier de plank mis?

Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 15:36

Janoz

Moderator Devschuur®

!litemod

Ik vermoed dat je de plank mis slaat. Je hebt immers alle landen en de oneindig gerechten nu al tot je beschikking, en je hebt ook niet alles tegelijk nodig.

Wat ik in je beschrijving zie zijn de volgende gegevens vragen:

Slechts 1 random land
Alle gerechten bij een land

Deze beide vragen kun je elk keurig met een query op je database doen. Je bent dan nooit gegevens dubbel aan het onthouden (in de db en in het geheugen) die je niet nodig hebt.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • 0 Henk 'm!

  • nowherebound123
  • Registratie: Mei 2009
  • Laatst online: 16:47
Janoz schreef op dinsdag 12 april 2016 @ 14:39:
Ik vermoed dat je de plank mis slaat. Je hebt immers alle landen en de oneindig gerechten nu al tot je beschikking, en je hebt ook niet alles tegelijk nodig.

Wat ik in je beschrijving zie zijn de volgende gegevens vragen:

Slechts 1 random land
Alle gerechten bij een land

Deze beide vragen kun je elk keurig met een query op je database doen. Je bent dan nooit gegevens dubbel aan het onthouden (in de db en in het geheugen) die je niet nodig hebt.
Ik snap je punt, volgens mij heb ik hier inderdaad een denkfout gemaakt. Ik ga mijn code nog eens met deze gedachte herzien :) bedankt
Pagina: 1