Hirdetés
- Milyen okostelefont vegyek?
- Telekom mobilszolgáltatások
- Xiaomi 15T Pro - a téma nincs lezárva
- Poco X8 Pro Max - nem kell ide sem bank, sem akkubank
- One mobilszolgáltatások
- A Redmi is hozott kompakt táblagépet
- Hivatalos a OnePlus Watch 4
- Samsung Galaxy S26 Ultra - fontossági sorrend
- Samsung Galaxy A57 - kecses test, lusta lélek
- Távozik az Apple vezérigazgatója
Új hozzászólás Aktív témák
-
-
Karma
félisten
válasz
#39560925
#3404
üzenetére
Szóltam neki, az appContextModule valószínűleg kimaradt és kiegészíti vele a guide-ot. "Jogos kritika", idézem. Hamarosan...
A második felére én is tudok reagálni: szerintem nem sérül az OOP ettől (hiszen az objektumod a külvilágtól várja a dependenciái érkezését), mondjuk igazából a public helyett a package private bőven elég a Daggernek is.
Ez az ára annak, hogy egyszerűbb az egész injektor, mint mondjuk a Springé. Például a ButterKnife is csak public vagy package private mezőkkel hajlandó foglalkozni, hogy spóroljon a reflexióval a generált kódban.
-
Karma
félisten
válasz
#39560925
#3400
üzenetére
Ez a guide (amit egyébként az öcsém írt, szóval ha van bármi kérdés, gyorsan tudom delegálni) az onCreate metódusban injektál mezőkbe. Ez a megközelítés szerintem Fragmentekkel ugyanúgy működhet.
-
#39560925
törölt tag
válasz
#39560925
#3385
üzenetére
Fogtam és konvertáltam az appomban minden Java fájlt Kotlin fájlra Android Studioval, és működik minden faszán. Most olvasgatom miket tud a nyelv, és eléggé bejön. Ha tippmixelnék, megtenném többszáz forintban, hogy 1-2 év múlva ez lesz a hivatalos nyelv az Androidhoz.

-
Karma
félisten
válasz
#39560925
#3342
üzenetére
Mi biztosan jobban tudjuk, mint a Google

Egyébként itt a kapcsolódó forráskód, ez biztosan nem hazudik. -
Karma
félisten
válasz
#39560925
#3272
üzenetére
Az OpenShiftnél nem nagyon tudod olcsóbban kihozni, ingyenesen futtathatsz egy kis gépet. Én oda szoktam fellőni a Boot projekteket általában.Bronze módban (ami ingyen van, de már meg kellett adni hozzá a bankkártyádat) már nem alszik el a gép soha; sima freeben inaktivitás esetén leáll és az első bejövő hívásnál ébred fel - késleltetve a választ.
Már másfél hónapja mondjuk nem néztem, de a Java 8-at kézzel kellett megoldani, van rá bejáratott házi sablonom. De egy kicsit több munka, nem egészen plug and play.
A Heroku 7 dolláros hobby dynoja se rossz, bár 7 dollárral több, mint az előbbi példa
Ott a free dyno sajnos többet alszik, kötelezően. Viszont frissebbek a buildpackek és amúgy nagyon király az egész. -
Karma
félisten
válasz
#39560925
#3238
üzenetére
Megoldható persze, csak a kérdés nem jó. A ThreadEnforcer.ANY konstruktorparaméter is kell hozzá — ez biztosítja, hogy a buszra bármely szálról lehessen üzenetet küldeni —, viszont a szálak közötti átpasszolást neked kell megoldanod. A legegyszerűbb ehhez a Bus osztályból leszármaztatni. Mindjárt megkeresem a megfelelő kódot, csak mobilról nem gyors

Meg is van: [link]
-
WonderCSabo
félisten
válasz
#39560925
#3214
üzenetére
Bocs, nem ismerem a use-caset, igazad van, nem kéne így tanácsot adnom ezzel kapcsolatban.
Két dolgot tehetsz:
* custom Preference osztály, amiben megírod, hogy benne legyen a Facebook button, majd a preferences.xml fájlba berakod
* nem rakod be az xml-be, hanem addPreferencesFromResorce hívása után kódban hozzáadod a VIew-t.Az első megoldás sztem sokkal szebb.
-
Karma
félisten
válasz
#39560925
#3218
üzenetére
Azt semmiképp se tartom jó ötletnek, hogy a MainActivity közvetlenül ismerje az ExceptionsFragment példányt. Mivel a ViewPager is virtualizál (azaz a ListViewhoz hasonlóan csak a látható vagy szomszédos viewkat tartja életben), elég kusza helyzetek alakulhatnak ki.
Hogy ezt hogyan kerüld el, van pár lehetőség.
Az első a klasszikus jávás Listener minta. Az activityben definiálsz egy Listener interfészt, amit a fragment megvalósít, valamint egy kis ceremóniát, hogy fel lehessen rá iratkozni. A fragment onAttach metódusában regisztrál, onDetachban pedig deregisztrál - ameddig össze van kötve, az activity tud neki jelezni. Mondjuk a konkrét activity osztályt is elfedném akkor már.
ExceptionChangeListener.java:
public interface ExceptionChangeListener {
void onExceptionsChanged();
}ExceptionSource.java:
public interface ExceptionSource {
boolean addExceptionChangeListener(ExceptionChangeListener listener);
boolean removeExceptionChangeListener(ExceptionChangeListener listener);
}MainActivity.java:
public class MainActivity extends AppCompatActivity implements ExceptionSource {
private final Set<ExceptionChangeListener> mListeners = new HashSet<ExceptionChangeListener>();
...
public boolean addExceptionChangeListener(ExceptionChangeListener listener) {
return mListeners.add(listener);
}
public boolean removeExceptionChangeListener(ExceptionChangeListener listener) {
return mListeners.remove(listener);
}
... amikor módosítottad a listát, hívd meg ezt ...
private void notifyListeners() {
for (ExceptionChangeListener listener : mListeners) {
listener.onExceptionsChanged();
}
}
}ExceptionsFragment.java:
public class ExceptionsFragment extends Fragment implements ExceptionChangeListener {
@Override
public void onAttach (Activity activity) {
super.onAttach(activity);
if (activity instanceof ExceptionSource) {
((ExceptionSource)activity).addExceptionChangeListener(this);
}
}
@Override
public void onDetach() {
if (getActivity() instanceof ExceptionSource) {
((ExceptionSource)getActivity()).removeExceptionChangeListener(this);
}
super.onDetach();
}
@Override
public void onExceptionsChanged() {
adapter.notifyDataSetChanged();
}
}Huh, ez elég hosszú lett. A másik kettőbe inkább nem megyek bele így nyilvánosan kód szinten.
A második az lenne, hogy a fragmented onAttach/onDetach időben egy BroadcastReceivert indít el, az activity pedig Intenteket dobál, ha változás van. Ez lehet közvetlenül a sendBroadcast metódussal, vagy LocalBroadcastManagerrel. Lazább csatolás, de elég sok ceremónia.
A harmadik pedig egy event bus bevezetése (pl. Otto), ahol a logika ugyanaz mint a másodikban, csak kevesebb extra kód (eltekintve a lib dependenciától). Én így 2015-ben egyébként ezt az utat javaslom.
-
Karma
félisten
válasz
#39560925
#3214
üzenetére
Azért sípol, mert nem használod ki a ListView újrahasznosító mechanizmusát, hanem folyamatosan új Viewkat fújatsz fel. Feltételezem, a warning buborék két findViewById hívást takar.
A tökéletes megoldásnak két lépése van, ebből az első a kritikus.
1) Használd a convertView paramétert! Ha nem null, akkor az egy olyan cella, ami kicsúszott a képből és így nincs rá szükség. Ebben az esetben az új cella létrehozása teljesen felesleges, ezt a viewt kellene bekonfigurálnod az új adatokhoz, megspórolva a példányosítást és a GC-zést.
View rowView = convertView != null
? convertView
: LayoutInflater.from(parent.getContext()).inflate(R.layout.exc_row_layout, parent, false);2) A ViewHolder minta ehhez képest már apróság, a findViewById hívásokat lehet megspórolni vele. Egy olyan custom classról van szó, aminek tagváltozóiba elteszed a TextViewk referenciáit (tehát gyártott viewnként egyszer kell keresni), a holdert pedig beállítod Tagként a cellán. Ha a convertView nem null, akkor elkéred a tagből a holdert, és azonnal írhatod az új adatokat.
@Override
public View getView(int position, View convertView, ViewGroup parent) {
RowViewHolder viewHolder;
if (convertView == null) {
convertView = ... inflate ...;
viewHolder = new RowViewHolder(convertView);
convertView.setTag(viewHolder);
} else {
viewHolder = (RowViewHolder)convertView.getTag();
}
... values tömb ...
viewHolder.bindRow(values[position]);
return convertView;
}
... valahol lejjebb ...
private static class RowViewHolder {
private TextView nameView;
private TextView descView;
public RowViewHolder(View rowView) {
nameView = rowView.findViewById(...);
descView = rowView.findViewById(...);
}
public void bindRow(Exception model) {
nameView.setText(model.getName());
descView.setText(model.getDescription());
}
} -
válasz
#39560925
#3203
üzenetére
Mármint az egész koncepciót nem értem. Ez valami vicces program lenne, vagy mi?
Milyen további funkciók lehetnek? Ha már vicces hibaüzenetek, az alábbi funkciókra biztos lehet valamit kitalálni:
- elemlámpa- geofencing
- wifi keresés
- mobil jel elvesztése
- touch műveletek (too many fingers ontouchscreenkeyboard error megvan?)
- adott program futása (túl sokáig, vagy túl sokszor)mod: Ja most látoma geofencing volt az eredetiben is...
Új hozzászólás Aktív témák
Hirdetés
- Gran Turismo
- Xbox Series X|S
- Luck Dragon: Asszociációs játék. :)
- Eredeti játékok OFF topik
- Debrecen és környéke adok-veszek-beszélgetek
- Azonnali fotós kérdések órája
- A fociról könnyedén, egy baráti társaságban
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Filmgyűjtés
- Otthoni hálózat és internet megosztás
- További aktív témák...
- Fehér Gamer Gép - GIGABYTE B860, Ultra 7 265KF, 16GB DDR4, RX 9060 XT 16GB, DDR5, 500GB SSD, 650W
- Gigabyte AERO X16 1WH 16" QHD+ IPS Ryzen AI 7 350 RTX 5070 32GB 512GB NVMe IR kam gar
- Samsung Xcover 7 gyári független bontatlan
- Apple MacBook Air 13" M4 (2025) 16GB / 256GB ezüst
- GIGABYTE RX 6900 XT 16GB GDDR6 GAMING OC - Eladó!
- Asus Rog Ally Z1 Extreme 6 hó garancia, számlával!
- Apple iPhone 15 / 256GB / Kártyafüggetlen / 12Hó Garancia / Akku:88%
- AKCIÓ! AMD Ryzen 7 5700X3D 8 mag 16 szál processzor garanciával hibátlan működéssel
- GYÖNYÖRŰ iPhone 14 Pro 128GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS4022
- GYÖNYÖRŰ iPhone 14 Pro 128GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS4619, 100% Akksi
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest



Attól hogy van egy jó kalapácsod, nem lesz mindenből szög.



Megvezettem saját magam...

