Dobre praktyki - Lekcja 1

1. Testuj małe elementy - im mniej, tym lepiej, nawet jeśli to tylko zmiana koloru - upewnij się, że się zmienił tam gdzie powinien.
2. Testuj małe elementy - nawet jeśli nie powodują widocznej zmiany wyglądu lub zachowania - sprawdzaj, czy nic nie popsuły.
3. Czytaj materiały branżowe regularnie - warto się uczyć od innych.
4. Porządnie planuj - najpierw zgrubnie, później coraz dokładniej, im mniejsze zadania tym łatwiej je wykonać nawet przy zmęczeniu.
5. Usuwaj logi, których nie potrzebujesz.
6. Upewnij się, że element, którego używasz !=null

Jak dodać menu do aplikacji?

1. Nadaj nazwy swoim opcjom - np. wprowadź je jako wartości w strings.xml
2. Utwórz katalog zasobów dla menu:
1. Kliknij prawy przyciskiem na katalog res
2. Wybierz New Resource Directory
3. Zmień Recource Type z value na menu
3.  Dodaj w katalogu plik menu.xml:
1. Kliknij prawy przyciskiem na katalog menu
2. Wybierz New -> Menu Resource File
4. Wprowadź ustawienia opcji menu, np.:

   <?xml version="1.0" encoding="utf-8"?>

   <menu xmlns:android="http://schemas.android.com/apk/res/android" 

    xmlns:app="http://schemas.android.com/apk/res-auto"> 

         <item android:id="@+id/menu_day1" 

               android:orderInCategory="1"         

               app:showAsAction="never" 

               android:title="@string/menu_d1" />

   </menu> 

5. Zaimplementuj w aktywności, która udostępnia menu funkcje onCreateOptionsMenu i onOptionsItemSelected, np.:
   

   @Overridepublic boolean onCreateOptionsMenu(Menu menu) {
       getMenuInflater().inflate(R.menu.menu, menu);    return true;}
   
   @Overridepublic boolean onOptionsItemSelected(MenuItem item) {
       return selectItem(item);}
   
   public boolean selectItem(MenuItem item) {
       switch (item.getItemId()) {
           case R.id.menu_day1:
               return true;        case R.id.menu_day2:
               return true;        case R.id.menu_day3:
               return true;        case R.id.menu_day4:
               return true;        case R.id.menu_day5:
               return true;        default:
               return super.onOptionsItemSelected(item);    }
   }

Dlaczego moja aplikacja nie ma tej ładnej ikonki?

Znowu się na to złapałam.
Wygrywam apkę na wirtualkę a tam androidek zamiast mojej ikonki.
Sprawdzam manifest - OK.
Sprawdzam grafikę - OK.
Co się dzieje?
Jest nie w tym katalogu - znowy bezmyślnie dodałam ją do katalogu anydpi. A z tego katalogu poprawnie obsługiwane są grafiki wektorowe a nie rastowe...
Po przełożeniu mojego .png do innego katalogu wszystko zadziałało.

Dlaczego "R" jest czerwone?

Coś jest nie tak z moimi zasobami.
Po raz kolejny mam nadzieję, że to kompilator ma jakiś problem - przecież dopiero go włączyłam, pewnie coś się źle załadowało. W dodatku znowu chce zrobić jakiś update. Pewnie to to.

NIE!

Zrobiłam "niewielką" modyfikację w zasobach, dodałam tylko jedną linijkę w stylach, kompilator jej nie podkreślił, uznałam, że wszystko jest OK. A jednak nie było.

Od dziś:

Jeśli zasoby nie budują się poprawnie, upewnij się, że wprowadzone zmiany są poprawne.

Drobiazgi SQL

Ten post będzie edytowany

Jak połączyć kilka warunków w wyszukiwaniu z bazy danych?

SELECT column1, column2, column3 FROM tableName WHERE condition1 AND condition2;

Ciąg dalszy nastąpi...

LockMe - java.lang.RuntimeException: Unable to instantiate receiver dmm.lockme.Lock$LockReceiver: java.lang.InstantiationException: java.lang.Class has no zero argument constructor

Taki mi się właśnie FATAL EXCEPTION trafił. A długo się zastanawiałam czemu mi się apka wywala zanim się jeszcze porządnie włączy, jak tylko dam jej prawa administratora, a później działa sobie normalnie i spokojnie. To przecież nie może być mój błąd, skoro później tak ładnie działa.

A jednak.
Problem wynikał z tego, że wydawało mi się, że ta aplikacja jest bardzo, bardzo prosta, na 3 linijki max. Wydawało mi się, że ja chcę tylko blokować ekran, to przecież nic ważnego, nic wielkiego, nic skomplikowanego. Dlatego z różnych przykładów brałam tylko to, co było niezbędne do uruchomienia aplikacji, nie kopiowałam wszystkiego bezmyślnie.

Aplikacja wymagała implementacji klasy, która miała rozszerzać DeviceAdminReceiver. To po to, żeby aplikacja mogła uzyskać uprawnienia administratora. Nie wiedziałam wtedy, że do manifestu nie można dodwać klas, które nie są statyczne i dlatego pojawił się ten wyjątek. Moja klasa nie miała robić nic szczególnego, dlatego mogłam spokojnie zadeklarować ją następująco:

public static class LockReceiver extends DeviceAdminReceiver{
    }

LockMe - java.lang.RuntimeException: Unable to create service dmm.lockme.FloatingWidgetService: android.view.WindowManager$BadTokenException: Unable to add window android.view.ViewRootImpl$W@9a6db9d -- permission denied for window type 2002

Mój kolejny wyjątek.
Wystąpił przy okazji przygotowywania widgetu, który umożliwiałby mi blokowanie ekranu przy otwartej dowolnej aplikacji.
Znalazłam informację, że można zrobić taki element, który działałby na zasadzie alarmu. Niestety, żeby tak było użytkownik musiał wyrazić zgodę na takie działanie aplikacji.
No i zaczęły mi się robić pętle w pętlach, okazało się, że warunek nie został spełniony a ja tu chcę alarm wyświetlać (podobnie jak w sytuacji z adminem) i tak to się pojawił wyjątek.

Wniosek: następnym razem, gdy aplikacja będzie potrzebowała specjalnych uprawnień do wykonania działania muszę się upewnić, że je ma. Nie wystarczy założyć, że gdzieś wyżej w kodzie, wcześniej, poprosiliśmy o nie - zawsze przed użyciem funkcji, która potrzebuje specjalnych uprawnień sprawdź czy je ma.

LockMe - java.lang.SecurityException: No active admin owned by uid 10088 for policy #3

To miało być takie proste. Przeczytałam ze (mam nadzieję) zrozumieniem co mam zrobić, dopasowałam ustawienia do swoich potrzeb, skompilowałam i... FATAL EXCEPTION

A raczej tak mi się wydawało.

Kluczowe okazało się sprawdzenie, czy aplikacja te uprawenienia ma i wywołanie funkcji blokowania TYLKO wtedy jeśli je ma - wszystko w jednej pętli if () oraz else() - wydawało mi się, że wystarczy samo sprawdzenie czy uprawnienia są (i oczywiście nadanie ich w przypadku braku) wystarczy a funkcję blokowania mogę dodać poza pętlą. Otórz nie mogę.

LockMe - początki

Mój stary telefon ma wiele problemów - pęknięta szybka, często niestykające połączenie USB, niedziałający przycisk Power. Nauczyłam się już go uruchamiać bez tego przycisku poprzez tryb serwisowy, ale bez niego nie mogę też zablokować ekranu (a czasami nie mogę czekać aż minie timeout).
Postanowiłam więc napisać sobie apkę, która będzie wywoływać blokowanie ekranu.
Myślałam, że to będzie banalne - ot kilka linijek i tyle. Zaczęłam szukać odpowiednich komend - już samo to było trudniejsze niż myślałam - na hasło "lock screen" wyskoczyło wiele podpowiedzi, z któych żadna nie miała nic wspólnego z tym, czego szukałam. W końcu jednak znalazłam:
https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#lockNow()
I znów pomyślałam - no proszę - kilka linijek i będzie gotowe - już widziałam oczyma wyobrażni kilka wersji gotowej apki. A tu nie - okazało się, że to początek przygody z uprawnieniami administratorskimi :)
Znalazłam nawet to:
https://developer.android.com/guide/topics/admin/device-admin.html
O - pomyślałam - gotowy wzór, teraz to już prawie koniec.
I potem pojawiły się FATAL EXCEPTION...