Új hozzászólás Aktív témák
-
thon73
tag
válasz shinodas #649 üzenetére
Ez csak egy bemutató-példa. Mi lenne a cél? Ha két fix alakzatot akarsz mozgatni, akkor azok koordinátáit kell külön tárolni, és egy-egy érintésnél legfeljebb a megfelelő ID-jű érintéshez rendelni.
Egy touchEvent az tényleg egyetlen érintés(sorozatot) ír le. Az ID arra szolgál, hogy EZEN BELÜL egy-egy ujjat kövessen akkor is, ha a többit felemeled (az index uis. csak felsorolja az aktuálisan hozzáérő pontokat, de a sorszám itt változhat.) Az már a Te programod feladata, hogy az alakzatok (és mozgásuk) valamint az érintések közötti logikát megalkossa. A bemutató csak minden mozdulatnál új alakzatokat rajzol az érintési pontokra, nem "gondoskodik" az alakzatokról, ezért is tűnnek el. -
thon73
tag
Nem tudok elszakadni a felszaporodó fragmentek problémájától...
Sehol nem írják ezt a megoldást, pedig nekem minden bajomat megoldotta. Sőt! Portrait-ból Landscape-be való visszafordításnál a másodlagos Fragmentben lévő adatok is megmaradtak! (Lévén ugyanaz a Fragment jelent meg máshol)layout/main.xml
<FrameLayout
android:id="@+id/portrait"
... >
<FrameLayout
android:id="@+id/list_frame"
... />
<FrameLayout
android:id="@+id/edit_frame"
... />
</FrameLayout>layout-land/main.xml
<LinearLayout
android:id="@+id/landscape"
... >
<FrameLayout
android:id="@+id/list_frame"
... />
<FrameLayout
android:id="@+id/edit_frame"
... />
</LinearLayout>Vagyis: ugyanazok az id-k mind landscape,mind portrait módban. Természetesen portrait módban a két frame "átfedi" egymást, tehát a program logikájának kell megoldani, hogy hol az EDIT, hol a LIST fragment legyen felcsatolva a saját (átfedő) Frame-jébe.
Az egész program (ill. ez a része) csak KÉT Fragment Példányt tartalmaz. És egy Activity van (ez volt a cél)Szól ez ellen a megvalósítás ellen vmilyen. érv? Nekem működőképesnek tűnik. Mivel a két layout egyszerre nem valósul meg, az id-k sem akadnak össze. Mindkét frame mindig a "saját" frame-jébe lesz bekapcsolva, mindig a saját tag-jével jelölve. Nincs változás, nincs hibaüzenet. Mivel nem a frame-ek kapcsolnak ki/be, az animációk ugyanúgy látszanak.
Mégsem olvastam ilyen megoldást sehol. Van ezzel vmi baj szerintetek?
Tényleg senkinek nem volt még nehézsége a fragmentek megvalósításával? Tényleg senkinél nem szaporodtak még fel az elforgatások során?[ Szerkesztve ]
-
thon73
tag
válasz shinodas #653 üzenetére
?? Ez azt jelenti, hogy a körök nem mozdíthatóak teljesen szabadon? Vagyis pl. nem keresztezhetik egymást? Mindkettőnek van egy saját területe? Mert akkor jobb lenne egy külön View-t alkotni egy körrel a közepén, amiben a kör - mint egy thumbstick mozgatható. Ha hozzáérsz valahol, akkor arra elmozdul a kör. Ha elengeded, akkor visszaúszik középre. Ez lenne a terv?
-
thon73
tag
válasz shinodas #655 üzenetére
Én lényegesen leegyszerűsíteném ezt a problémát. Készítenék egy speciális View-t, mely egy ilyen joystick-et mutat be. Ebből aztán kettő is elhelyezhető egy layoutban.
A joystick mindig középen áll. Ha megérintem valahol máshol a View-t (vagy a View belül egy kört is kijelölhetek erre), akkor a joystick/kör oda ugrik (és persze ezt az értéket kérdezhetem le). Ha elengedem, akkor visszaugrik középre.
Ez persze nem túl szép, mert a joysticknem ugrál, hanem szépen mozog. Ennek a szimulálására viszont el kell indítani a háttérszálon egy "ütem-adót", ami időnként jelzi a View-nak, hogy mozdítania kell egy kicsit a joystickon. Így úszhat a kör az érintés felé, vagy elengedésnél vissza középre. Az ütemadó nélkül nincs olyan esemény, ami a kör mozgását kiváltaná.
A másik lehetőség, hogy a kör csak akkor mozdul, ha az érintés a középpontjához megfelelően közel következett be. Ilyenkor nem kell ütem-adó, hiszen az "ugrás" megfelelően kicsi. Ez azt is szimulálja, hogy a joystick nem ugrik magától a kezembe, ha nem a tetejét fogom meg. Persze a "visszaúthoz" elengedés után még mindig szükséges az előző módszer.
((Nem dolgoztam még két külön View-val az érintéssel kapcsolatban, de nagy a gyanúm, hogy nem kell törődni, csak az elsődleges érintéssel, mert mindkettő azt kapja meg. Ezt ki kellene próbálnom.))
Ez persze csak az én ötletem, lehet, hogy más tud ennél jobbat is. Külön-külön már minden részét elkészítettem a folyamatnak, csak nem ilyen összefüggésben - ennek alapján szerintem azért el lehet vele játszani, mire összeáll, de megvalósítható. ((Ha nem sürgős, a konkrét megvalósításban is szívesen segítek, a grafika és az időzítés most nálam is pont napirenden van.)) -
thon73
tag
válasz shinodas #657 üzenetére
Pedig az nem nehéz, nekem inkább az időzítéssel gyűlt meg a bajom.
1. KÉT View esetén csak az egy érintéssel kell foglalkozni sztem.
2. KÖZÖS View-ban végig kell menni az összes érintés tömbjén, mint a fenti példában.
Én ellenőrizném a koordináták alapján, melyik ID koordinátája van a joystick körének területén.
A. lehetőség: Továbbra is végigmegyek az indexen, de ennek az ID-nek az alapján mozgatom a kört. Ha az ID eltűnt, akkor ez az érintés befejeződött. Kell keresnem egy újat, v. visszavinni középre a joysticket, és utána keresni.
B. lehetőség: ugyanúgy végigmegyek a tömbön, de nem foglalkozom az ID-vel, hanem ami megfelelően közel van a középpontjához, oda mozdítom a kört. Ha nincs ilyen, mehet vissza középre.Az egész kulcsa az, hogy amíg egy ponton is érinted a képet, az ID megmarad. Ha elengedted a képet, akkor teljesen új érintés kezdődik, új Idkkel. Ezért kell az elején a megf. érintést mindenképp a koord. alapján kiválasztani.
-
thon73
tag
válasz shinodas #661 üzenetére
Itt egy lehetséges megoldás. API10 és AIDE alatt készült, de elvileg bármiben működik. 800x480 pixeles képernyőm van, de persze a méretek a képnek megfelelően változtathatóak. Az egyszerűség kedvéért beágyazott View-t használtam, ill. nem ellenőrzi a View beállításait, ez végleges megoldásnál ildomos!
A kód sok helyen nincs optimalizálva, inkább jól érthetőt akartam írni. ((Pl. én nem is tennék két joysticket egy view-ba, vagy ha igen, akkor két külön objektumként stb.))public class JoystickActivity extends Activity
{
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(new Felulet(this));
}
public class Felulet extends View
{
private float[] origox = {200f, 600f};
private float[] origoy = {180f, 220f};
private float joyx[] = {origox[0], origox[1]};
private float joyy[] = {origoy[0], origoy[1]};
private float joyarea = 150f;
private float joyrad = 40f;
private int joyid[] = {-1, -1};
private Paint area;
private Paint rad;
public Felulet(Context context)
{
this(context, null, 0);
}
public Felulet(Context context, AttributeSet attrs)
{
this(context, attrs, 0);
}
public Felulet(Context context, AttributeSet attrs, int defStyle)
{
super(context, attrs, defStyle);
area=new Paint();
area.setStyle(Paint.Style.STROKE);
area.setColor(Color.RED);
area.setStrokeWidth(5f);
rad=new Paint();
rad.setStyle(Paint.Style.FILL_AND_STROKE);
rad.setColor(Color.GREEN);
rad.setStrokeWidth(5f);
}
@Override
public boolean onTouchEvent(MotionEvent event)
{
switch (event.getActionMasked())
{
case MotionEvent.ACTION_DOWN:
case MotionEvent.ACTION_MOVE:
int pointerCount = event.getPointerCount();
for (int n=0; n<2; n++)
{
if (joyid[n] == -1)
{
for (int cnt = 0; cnt < pointerCount; cnt++)
{
if (distance(joyx[n], joyy[n], event.getX(cnt), event.getY(cnt)) < joyrad)
{
joyid[n] = event.getPointerId(cnt);
break;
}
}
}
else
{
boolean id_flag = false;
for (int cnt = 0; cnt < pointerCount; cnt++)
{
if (joyid[n] == event.getPointerId(cnt))
{
if (distance(origox[n], origoy[n], event.getX(cnt), event.getY(cnt)) < joyarea - joyrad)
{
joyx[n] = event.getX(cnt);
joyy[n] = event.getY(cnt);
this.invalidate();
}
else
{
// aránypárral v. szögfüggvénnyel mozgatható a kerületen
}
id_flag=true;
break;
}
}
if (!id_flag)
reset_joy(n);
}
}
break;
case MotionEvent.ACTION_UP:
reset_joy(0);
reset_joy(1);
break;
}
return true;
}
protected void reset_joy(int n)
{
joyid[n] = -1;
joyx[n] = origox[n];
joyy[n] = origoy[n];
this.invalidate();
}
protected float distance(float x1, float y1, float x2, float y2)
{
float x = x1 - x2;
float y = y1 - y2;
return FloatMath.sqrt(x * x + y * y);
}
@Override
protected void onDraw(Canvas canvas)
{
for (int n=0; n<2; n++)
{
canvas.drawCircle (origox[n], origoy[n], joyarea, area);
canvas.drawCircle (joyx[n], joyy[n], joyrad, rad);
}
}
}
}Az elv: a két index a két külön joysticket jelenti. Origox/y a közepe a két joysticknek, Joyx/y pedig az aktuális helyzete. Joyrad (kiskör) karikán belül lehet csak "megfogni" a joysticket, Joyarea (nagykör) sugaron kívül nem tud mozogni. A távolságot Pithagorasz tétellel számolja, ez nem a legjobb helyen van az osztályon belül.
A JoyId a legfontosabb: ha -1, akkor nincs érintés hozzárendelve (középen van a joystick). Ha egy érintés belelép a kiskörbe, akkor annak id-je lesz a JoyId és azt követi. A nagykör szélén megáll, de az érintéshez továbbra is ragaszkodik. Nem akartam bonyolítani, de az igazi az lenne, ha a köríven menne az ujjad után. (a megjegyzés helyén kezelhető ez)
Ha az Id eltűnik (ezt ellenőrzi a flag), vagyis azt az ujjad felemelted, akkor középre áll. Szintúgy akkor is, ha ACTION_UP lesz, vagyis minden ujj elhagyta a képet. Ilyenkor lehetne ütemadóval visszaúsztatni, de kis méretben az ugrás sem zavaró.
Ilyenre gondoltál? Remélem segít továbblépni, a lényeg úgyis az ID kezelés volt. Ha valami nem tiszta, szívesen segítek. -
fatal`
titán
Egy apró kiegészítés:
switch (event.getActionMasked())
{
case MotionEvent.ACTION_DOWN:Itt, mivel nem csinálsz semmit az ACTION_DOWN ág felesleges. De ha mégis bent akarod/akarjátok hagyni, akkor egy break nem árt utána, mert így action_down esetén is lefut az utána lévő ág.
-
thon73
tag
Módosítok: az elv jó, csak megfogni nehéz így. Ha viszont az "else"-t kivesszük (vagy opt. miatt lehet "if (joyid[n]!=-1)"), akkor értelmet kap a DOWN ág is. Uis. már érintésre arrébb tud ugrani.
API17-ben van egy hypot() függvény, ami a distance számítást leegyszerűsíti (nekem API10-ben még nem működik.)
MATEMATIKUSOK!
Mi a legegyszerűbb számítás ahhoz, hogy a kör - az érintéstől függően - a periméteren keringjen? Csak szögfüggvénnyel megoldható?
-
Sianis
addikt
Azt tudjátok, hogy mitől lehet, hogy elmentek egy emulátort snapshotba, ha mondjuk még aznap használom és indítom akkor semmi baja. Ellenben 24 óra elteltével azt mondja, hogy nem ilyen configgal lett mentve a snapshot, szóval nem lehet onnan indítani. Nem nyúlok semmilyen beállításhoz mégis folyton rákényszerít a lassabb indításra, arról nem is beszélve, hogy a 4.0+ emulátorok általában olyan lassan indulnak, hogy első alkalommal az Eclipse nem is találja meg őket.
Sianis
-
fatal`
titán
A move alapból tartalmazza a downt (mivel hozzáérsz a kijelzőhöz / lenyomod az egeret, másképp nincs Move androidon) így az egész ág teljesen felesleges.
(#672) Sianis: Nem használom az emulátort csak app release előtti tesztre így a problémát nem tudom mi okozza, viszont, ha Intel CPU-d van és tud VT-t, akkor tedd fel a HAXM-et, sokkal gyorsabban indul és fut az emu.
[ Szerkesztve ]
-
Karma
félisten
És megy is a HAXM? Azaz emulátor indításkor írja az AVD Manager, hogy HAX is working and emulator runs in fast virt mode? Mert enélkül nem ér semmit
Nekem egy 4.2.2-es image hidegindítása tíz másodperc jelenleg. Mondjuk elég erős a gépem is - de nagyságrendi eltérésnek nem szabadna lennie. Még a tabletemen is feléled húsz alatt.
[ Szerkesztve ]
“All nothings are not equal.”
-
fatal`
titán
Komplett adb támogatás van (annyi, hogy nem mindig automata, úgyhogy van, hogy kell egy adb connect localhost, hogy lássa az eclipse), úgyhogy gondolom ki. Ha máshogy nem, akkor rootolod
Mondjuk nem tudsz vele mindent tesztelni, nem testreszabható, mint az AVD, igazából felhasználóknak van, nem fejlesztőknek. Én azért kezdtem el használni, mert gyors, nem kell fél órát várnom egy-egy buildnél mire rámásolja az apk-t.
[ Szerkesztve ]
-
thon73
tag
Kötözködés nélkül, és csak a teljesség kedvéért: single-tap esetén csak A_DOWN generálódik először, és csak mozdítás után A_MOVE. A konkrét példában ez nem látható (tehát igazad van), de ha az else-t kivesszük, akkor megfigyelhető, mert közeli érintésre (és nem mozgásra) is mozdul a joy.
A megelőző példában viszont először én sem tettem be az A_DOWN-t, és érintésre nem jelentek meg a karikák, csak mozgatásra. -
pvt.peter
őstag
Sziasztok!
Nem teljesen idevág a kérdésem, de tudja vki azt, hogy egy IMEI azonosítószám hossza az milyen hosszú lehet?
Ez egy .50-es rombolópuska, elég szép visszarúgással.
-
thon73
tag
Fragmentek körében - tud nekem segíteni valaki?
A kód hosszú, de ha kell elküldöm. A kérdések egyszerűbbek.
Ha egy Fragment objektumot létrehozok, az - már bizonyos - örökre megmarad.
Ráadásul, hiába adom ki a remove transactiont (és commit-ot is, persze), utána eltűnik, de az activity újraindulásakor visszalópódzik az elvileg üres View-ba.
A Tag és Id csak akkor él, amikor a Fragment be van rakva a View-ba.- Hogyan lehet ezt a létező Fragment-et (remove, commit után) fellelni? ((Az Activity felleli, mert indításkor visszapakolja! De én csak akkor tudom megtalálni, ha egy globális "változóban" tárolom.))
- vagy hogyan lehetne "destroy"-ra kényszeríteni?
- Tapasztalta-e már valaki a fentieket, ill. okozott-e ez problémát?
- Ti ezt hogyan csináljátok?A hiba akkor bukott ki, amikor egy amúgy jól működő(?) kód, minden fordításkor szaporítani kezdte a menu elemeket. További vizsgálódáskor találtam ezt, amit a doksi nemigen emleget. A neten a fentiekkel csak kérdés formájában találkoztam, választ nem találtam.
Előre is köszönöm, ha valaki fáradozik ezzel! -
thon73
tag
Hm. Úgy látom, a fragmentek kérdéskörével egyedül maradtam. Én végül is változókban (is) tároltam el a visszakapott Fragmenteket. Így sikerült a számukat darabonként egyetlenre korlátozni. Ez az egy példány aztán hol bekerül egy View-be, hol kiveszem onnan. A kód működik, de hogy ez helyes megoldás-e, nem tudom. Gondoltam, azért esetleges későbbi olvasókkal ezt megosztom.
Egy másik problémával kapcsolatban kérnék viszont jó tanácsot: Látszólag jól működik a program, tehát elfordításra is szabványosan leáll és újraindul. De ha az elfordítást kikapcsolt állapotban végzem el, akkor a program - hibaüzenet nélkül - leáll; pontosabban a Log-on jelentkezik egy le nem kezelt exception, amiről fogalmam sincs, hol ered. Az utolsó log-bejegyzés szerint az onPause lefutott. (minden visszahívást log-oltam) A hiba bekapcsoláskor jelenik meg, és ekkor már nem kapok debug üzeneteket.
A programot még tesztelem. A kérdés az, hol találhatok leírtást arról, mi (más) történik a programmal miközben a készülék stand-by-ba (és vissza) kapcsol? Azt gondolom, hogy egy onPause-onResume hívásnak kellene következnie, de erről nem találtam infot. Tud valaki esetleg ilyen jellegű forrást?
[ Szerkesztve ]
-
WonderCSabo
félisten
Sziasztok!
Láttátok, hogy megjelent az új fejlesztőkörnyezet, az Android Studio? Én kipróbáltam, sztem az Eclipse nagyon megveri...
-
fatal`
titán
válasz WonderCSabo #685 üzenetére
Hali!
Még nem próbáltam, már megszoktam az eclipset. Hogy működik? Library projecteket kezeli? GIT support van?
Ha jól látom IntelliJ IDEA-ra épül, ami meg, ha jól tudom, akkor az Eclipsere, szóval olyan nagy varázslat ezekszerint nincs. Ellenben érdekelne, hogy mennyire herélték ki.
[ Szerkesztve ]
-
fatal`
titán
válasz WonderCSabo #687 üzenetére
Vagy csak támogatja a pluginjeit? Mintha ilyesmi rémlene.
De az is lehet, hogy teljes képzavar Amúgy mi a gondod evvel a (totál beta) cuccal?
-
thon73
tag
válasz SektorFlop #684 üzenetére
Köszi!
-
thon73
tag
A kérdésem második felével kapcsolatban - vagyis, hogy mi történik, amikor a telefon elalszik - is érdekes viselkedést találtam:
Elalváskor dob egy onPause-onResume-onPause hármast, ébredéskor uez. visszafelé: -onResume-onPause-onResume.
A tesztet az Eclipse által létrehozott alapprogrammal (sehol egy fragment!) is megcsináltam, eredmény uez.
Tudja valaki, hogy ennek mi az értelme és magyarázata?(((Természetesen elfogadom, hogy minek kell izgasson ez az egész - ha egyszer működik. Csak a személyes gondom az volt, hogy elalváskor a rendszer a második onPause után valamiért belenyúl egy, az onPause-ban már lezárt adatbázisba. Ezt csak úgy tudtam kikerülni, hogy átpakoltam az egészet az onResume-onPause cikluson kívülre, így működik. Ami érdekes, hogy a hiba kizárólag elalváskor, és a második onPause után jelenik meg.)))
-
SektorFlop
aktív tag
válasz WonderCSabo #685 üzenetére
Kipróbálom én is.
"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."
-
SektorFlop
aktív tag
válasz WonderCSabo #689 üzenetére
Nekem nem indul el
"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."
-
Konair
csendes tag
válasz SektorFlop #693 üzenetére
http://www.cypressnorth.com/blog/mobile-application-development/android-studio-not-working-in-windows-7-or-8-fixed/
Weboldal készítés felsőfokon...
-
shinodas
tag
Sziasztok!
Kiszeretném írni egy egyszerű stringbe a bluetooth státuszát. Hova kellene tennem, vagy meghívnom ezt a függvényt, hogy folyamatosan fusson le, és változásnál az oda tartozó stringet írja ki? Ugyanis csak a program indításnál fut le így.
public void BT_stat_Check(){
TextView t = new TextView(this);
t = (TextView)findViewById(R.id.BtStat);
if(bluetooth.isEnabled()){
//kiírom a bluetooth adatait
String mydeviceaddress = bluetooth.getAddress();
String mydevicename = bluetooth.getName();
status = mydevicename + " : " + mydeviceaddress;
t.setText(status); // kirakom a képernyőre a státuszt
}
else{
status = "Bluetooth is disabled.";
t.setText(status);
}
} -
shinodas
tag
Illetve még amit akartam, hogy erre:
public class Discover {
IntentFilter discoveryFilter = new IntentFilter(BluetoothAdapter.ACTION_DISCOVERY_FINISHED);
registerReceiver(_dicoveryReceiver, discoveryFilter);
IntentFilter foundFilter = new IntentFilter(BluetoothDevice.ACTION_FOUND);
registerReceiver(_foundReceiver, foundFilter);...
}
mi a csudáért húzza alá nekem a registerReceiver(_dicoveryReceiver, discoveryFilter); és registerReceiver(_foundReceiver, foundFilter); sorokat? A _dicoveryReceiver, és a _foundReceiver fgv-nyek meg vannak alattuk írva pedig.
Új hozzászólás Aktív témák
- Autós topik
- Óra topik
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- DIGI Mobil
- CASIO órák kedvelők topicja!
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kerékpárosok, bringások ide!
- Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
- További aktív témák...