mboost-dp1
Java hjælp...
Yep, så er jeg blevet kastet ud i noget java (Android) !
OPg for en der kun har arbejdet med C/C++ er det noget ret mærkeligt noget.. so.. I need help to understand the philosophy...
hvis der står:
getApplication() er slet ikke i Application filen...
Nogen der gider forklare hvad det er for noget? og hvad mSerialPortFinder bliver for et objekt?
OPg for en der kun har arbejdet med C/C++ er det noget ret mærkeligt noget.. so.. I need help to understand the philosophy...
hvis der står:
mApplication = (Application) getApplication();
mSerialPortFinder = mApplication.mSerialPortFinder;
getApplication() er slet ikke i Application filen...
Nogen der gider forklare hvad det er for noget? og hvad mSerialPortFinder bliver for et objekt?
Qw_freak (1) skrev:getApplication() er slet ikke i Application filen...
Det skal den heller ikke være, den skal være i den klasse du koder. I dette tilfælde får du den via arv, dvs. den klasse du koder skal arve fra Activity.
Qw_freak (1) skrev:og hvad mSerialPortFinder bliver for et objekt?
Det kan dit IDE fortælle dig når du kommer så langt. Hvis du bruger Eclipse vil den fortælle dig at mSerialPortFinder ikke findes. Vælg autofix (CTRL-1) og lad den oprette variablen, så får den automatisk den rigtige type.
Jeg udspensler lige lidt hvad der foregår i den første linje:
"getApplication()" - kalder metoden getApplication i den klasse du er i, evt. via arv.
"(Application) getApplication()" - det som getApplication returnerer castes til at være en Application.
"mApplication = (Application) getApplication()" objektet fra getApplication - som nu er en Application uanset hvad det var før - bliver gemt i variablen mApplication. (Kan den ikke castes til en Application vil du få en exception inden du kommer her til. Enten runtime eller compile-time.)
"getApplication()" - kalder metoden getApplication i den klasse du er i, evt. via arv.
"(Application) getApplication()" - det som getApplication returnerer castes til at være en Application.
"mApplication = (Application) getApplication()" objektet fra getApplication - som nu er en Application uanset hvad det var før - bliver gemt i variablen mApplication. (Kan den ikke castes til en Application vil du få en exception inden du kommer her til. Enten runtime eller compile-time.)
#3
Så getApplication har ikke noget at gøre med den fil der hedder Application?
Det er foriøvrigt dette eksempel jeg forsøger at gøre mig klog på,,..
Serial-Example
Så getApplication har ikke noget at gøre med den fil der hedder Application?
Det er foriøvrigt dette eksempel jeg forsøger at gøre mig klog på,,..
Serial-Example
Qw_freak (4) skrev:Så getApplication har ikke noget at gøre med den fil der hedder Application?
Korrekt.
Qw_freak (4) skrev:Det er foriøvrigt dette eksempel jeg forsøger at gøre mig klog på,,..
Serial-Example
Der kan du se i Application.java:30:
public SerialPortFinder mSerialPortFinder = new SerialPortFinder();
Der defineres mSerialPortFinder som et public field (som ellers er lidt dårligt design men okay til så lille et projekt), og et objekt gemmes i variablen.
SerialPortPreferences arver fra PreferenceActivity, som arver fra ListActivity, som arver fra Activity. Dvs. SerialPortPreferences er en Activity (og burde egentlig hedde noget med Activity), og Activity indeholder getApplication().
#6
Hvis det var en almindelig application ville der være en main-metode et eller andet sted. Men sådan er det ikke i en Android-app.
Den første måde du skal lære at lave en kørende Android-app er via activities, som du allerede er i gang med.
Det er MainMenu-klassen der indeholder din "main"-metode.
Det er en meget simpel klasse, kun én metode. Men i en mere komplet/avanceret activity er der en del flere. Jeg kan godt lide dette diagram: http://developer.android.com/reference/android/app...
Så kort sagt - main-metoden svarer til onCreate. Men du skal også lære de andre, hvis det skal køre godt når det bliver mere avanceret.
Men hvordan finder OS'et så den klasse?
Hvis du kigger i AndroidManifest.xml i dit projekt kan du se at der er angivet flere activities. Én af dem er markeret som MAIN (dvs. den der skal køres når man bare vil starte din app) og som LAUNCHER (dvs. den får et ikon i launcheren). De andre startes først når man beder specifikt om dem.
Der er ingen pakke-navn på, så den leder i app'ens standard-pakke, som er angivet længere oppe i samme fil.
Hvis det var en almindelig application ville der være en main-metode et eller andet sted. Men sådan er det ikke i en Android-app.
Den første måde du skal lære at lave en kørende Android-app er via activities, som du allerede er i gang med.
Det er MainMenu-klassen der indeholder din "main"-metode.
Det er en meget simpel klasse, kun én metode. Men i en mere komplet/avanceret activity er der en del flere. Jeg kan godt lide dette diagram: http://developer.android.com/reference/android/app...
Så kort sagt - main-metoden svarer til onCreate. Men du skal også lære de andre, hvis det skal køre godt når det bliver mere avanceret.
Men hvordan finder OS'et så den klasse?
Hvis du kigger i AndroidManifest.xml i dit projekt kan du se at der er angivet flere activities. Én af dem er markeret som MAIN (dvs. den der skal køres når man bare vil starte din app) og som LAUNCHER (dvs. den får et ikon i launcheren). De andre startes først når man beder specifikt om dem.
Der er ingen pakke-navn på, så den leder i app'ens standard-pakke, som er angivet længere oppe i samme fil.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund