App utveckling

Hej jag har ett litet problem håller på att göra en app men jag lyckas inte med att spara strängar och filer, mellan olika klasser i min android app, hur gör jag detta funkar det med scanner och skapa ett text dokument eller finns det sätt att spara saker globalt ?

 

Spara saker på minneskortet är väl det smartaste sättet. Om du inte ska ladda upp de på någon server.

 

Du kan ha en statisk klass eller kanske överlagra i din Application-klass?

Code:

public class MyApplication extends Application {
     private boolean data;

    public boolean getData() {
        return data;
   }

   public void setData(boolean a_data) {
      data= a_data;
   }
}

och i din manifestfil deklarera den nya applikationsklassen:

Code:

[...]
android:icon="@drawable/icon"
android:label="@string/app_name"
android:name="com.exempel.MyApplication"

 

Vad är det för klasser du inte kan utbyta data mellan?

Är det olika Activities? I så fall använder du Intents se http://developer.android.com/reference/android/app/Activity.html#StartingActivities

Att lagra saker i statiska variabler är bara att lura sig själv eftersom dessa försvinner NÄR systemet dödar din process.

Ska du lagra data mellan tillfällen applikationen används finns ett antal sätt att göra men det enklaste är nog SharedPreferences se http://developer.android.com/guide/topics/data/data-storage.html

 

Dom två bästa sätten att spara data i din applikation är SharedPreferences eller SQLite. Inbyggt stöd finns för dessa. Googla lite och du skall hitta bra tutorials och jämförelser. Vi hjälper dig när du fastnar!

 

Om du endast vill ha åtkomst till data mellan olika aktiviteter så kan du använda dig av Application-kontextet som någon skrev här ovan. Du ska dock skippa en statisk klass där du delar data mellan dina aktiviteter eftersom den statiska instansens information försvinner allt för ofta vid en längre paus från ditt program.

Om du ska spara data så råder jag dig till SQLite och SharedPreferences som även en annan skrev ovanför.

 

Även Application-objektet försvinner ju när processen dödas av systemet (vilket är bortom din kontroll) så om du vill vara säker på att din applikation fungerar bör du använda de metoder google rekomenderar d.v.s Intents för att skicka data mellan activities och något av datalagringsalternativen för att lagra data mellan användarsessioner.

Google rekomenderar att inte använda subklasser till Application

(källa)

 

Då dör även hela programmet så att vid nästa uppstart så får man börja om ändå. Sålänge en aktivitet lever i ett program så finns Application-kontextet tillgängligt, varav jag själv föredrar att då slippa Intent.putExtra()-metoder till förmån för Application-kontextet.

Nej, det är normalt sett ingen större idé att använda en subklass av Application vid ett eventuellt enstaka fall - då kan man lika gärna köra Intent.putExtra(), men om det är mycket data eller information som ska delas mellan ett flertal aktiviteter är en subklass av Application att föredra. Jag tolkar inte det som en rekommendation om vad man ska göra, utan för hur man själv kan välja strukturen och därefter väljer de att berätta att normalt sett (vid enstaka Intent.putExtra()-metoder) så behöver man inte ha en egen instans som ärver Application.

Vad jag har tolkat det som så dör först aktiviteter och sedan dör programmet (Application), varav Application-informationen finns tillgängligt tills alla aktiviteter förstörs och programmet stängs ner.

 

Att använda Application som en slask för diverse global data känns inte helt optimalt. Bättre att ha det som statics i respektive klass där det hör hemma.

Det man måste tänka på i båda fallen är hur och när man initierar variablerna. Ett vanligt misstag är att initiera t ex från start-aktivitetens onCreate() och utgå ifrån att den alltid startas före andra aktiviteter. Det är inte nödvändigtvis fallet om processen har dödats och man därefter går tillbaka till appen via en notifiering eller bakåtknappen.

Använder man däremot data via intents så skickar Android om det även efter att processen har dödats. Man kan testa det genom att långklicka på hemknappen för att gå över till någon task manager, döda appen och sedan trycka på bakåtknappen.

 

Om du har globala static-fält i respektive aktivitetsklass så försvinner dessa när aktiviteten dör. Med Application så består de tills hela applikationen har dött.

Jag körde själv med static-fält för att enkelt skicka vidare data i en applikation och alltför ofta kom rapporter om en NPE där mitt static-fält härjade, med application har det upphört.

 

Det där är ett vanligt missförstånd. Static-fält försvinner dock bara när appen dör (eller när man explicit sätter fältet till null). Det du råkade ut för har troligtvis att göra med att appen har startats om och att appen då har försökt använda static-fält som inte har initierats ännu. Jag har själv råkat ut för det och löst det genom att initiera fälten på rätt ställen.

 

Som jag har tolkat det; när aktiviteten dör. Eller i alla fall som jag har upplevt det.

Alla mina static-fält initieras vid deklarationen, grejen är att värdena försvinner när aktiviteten dör och vid en senare omstart av applikationen så är den ändå initierad, men med tomma värden.

Jag föredrar Application främst för att oavsett om en aktivitet dör består värdet, hursomhelst, det är ju upp till varje utvecklare givetvis - det som funkar funkar.

 

Skumt. Menar du att du har exempelvis...

Code:

public static Point sPoint = new Point();

...och efter att aktiviteten har dött så har sPoint värdet null?

Eller menar du att du har t ex...

Code:

public static Point sPoint = new Point();
...
sPoint.x = 15;

...och efter att aktiviteten har dött så har sPoint.x värdet 0;

 

Jag menar att den aldrig är null, men min ArrayList jag en gång hade när jag körde detta var tomt med värden när endast en aktivitet hade dött. Med application så lever den (inlusive alla värden) tills alla aktiviteter har dött.

 

static skall man undvika så långt det går, enbart för sådant som sätts per omgående och inte för att använda som placeholders.

om/när man börjar skriva trådade applikationer och om androidappar kunnat instanseras i fler versioner så skulle ni sett vilket skit static medför.

 

Konstigt i så fall att folk från Google (Dianne Hackborn) rekommenderar att man använder static istället för Application. Jag skrev ett litet testprogram (bifogat) där en aktivitet skapas och dödas om och om igen och lyckas inte återskapa någon form av tömning av static-fält. Något jag har missförstått kanske.

 

Håller med, men tycker mer att det är trådning man ska undvika. Det kan ställa till med mycket problem även utan static-fält. Problemet med trådar är dels att det är svårare att implementera rätt och dels att fel som uppstår är svårare att debugga. Hjälpmedel som AsyncTask och Service gör det dock användbart och hanterbart i många situationer.

Fast det är förstås en smaksak också, precis som valet mellan static-fält och Application. Det som funkar funkar

 

Det jag tänker på är när man har den som global över alla aktiviteter, det vill säga att du sätter public static på din fältvariabel, för att skicka vidare data över flera aktiviteter.

Till exempel:

1. Jag har en grundaktivitet, aktivitet ett samlar ihop en ArrayList full med strängar, denna sätter jag nu public static på.

2. Användaren klickar på "nåt som tar en vidare" för att läsa någon utav listans strängar i en annan aktivitet. Denna aktivitet använder den statiska instansen från den föregående aktivitetens klass som referens.

3. Användaren går tillbaka till aktivitet ett och trycker "Home". Efter, låt oss säga tre timmar, dör aktivitet ett medan aktivitet två består. Användaren startar nu applikationen -> aktivitet ett startas, denna gång hämtas inte någon information för det är något användaren själv väljer när det ska göras.

4. När användaren klickar vidare på "nåt som tar en vidare" så möts användaren av en sträng som inte visar nånting, alternativt NPE beroende på struktur.

Nu blev jag även osäker på om vi menar samma sak, om vi gör det och du syftar på även det jag skrev här så får jag kolla runt en gång till - för 9 månader sen fungerade inte public static som en bra lösning för min applikation.

 

Punkt 1 och 2 låter som en situation där man normalt ska låta grundaktiviteten skicka över den info som behövs i intentet till andra aktiviteten istället för att använda static.

Punkt 3 och 4 låter märkligt. Jag är tveksam till att Android kan bete sig exakt så. Däremot kan följande ha inträffat. Användaren hoppar ur programmet från aktivitet 2. Android dödar efter ett tag hela processen. Användaren hoppar tillbaka på ett eller annat sätt. Android skapar då aktivitet 2 eftersom det var där användaren var senast. Aktivitet 1 har nu inte skapats ännu. Aktivitet 2 försöker använda det statiska fältet i aktivitet 1. Det statiska fältet initieras och aktivitet 2 kom då åt den som en tom array.

Jag har inte hittat någon exakt dokumentation på hur Android ska bete sig när man går tillbaka till en app som har dödats. Det beteendet jag beskriver är vad jag ser på min Nexus S med Android 2.3.4. På min HTC Hero med Android 2.1 hamnar jag istället alltid i aktivitet 1 efter att appen har dödats. Får också lite olika beteende i olika appar.

 

Mjo, grejen för mig är att jag tycker det blir jobbigt att skicka vidare när man kanske har tre, fyra aktiviteter som ska ha samma information, därav att jag använder mig av Application istället.

I detta fall pratar jag bara utifrån mina egna erfarenheter och observationer.