sharedpreferences post added and some updated

Author: maciej-nowak

_drafts/2019-05-27-rxandroid.md

@@ -1,12 +1,12 @@
 ---
 layout: post
-title: "RxAndroid"
+title: "RxJava"
 date: 2019-05-27
 categories: ["Biblioteki"]
-image: libraries/rxandroid
-github: libraries/tree/master/rxandroid
+image: libraries/rxjava
+github: libraries/tree/master/rxjava
 description: "Biblioteki"
-version: RxAndroid 2.1, RxJava 2.2
+version: RxJava 2.2, RxAndroid 2.1
 keywords: "reaktywne, reactive, rxandroid, rxjava, reactivex, obserwator, obserwowany, observer, observable, schedulers, operator, disposable, subscribe, async, thread, java, android, programowanie, programming"
 ---
 
@@ -94,7 +94,7 @@ private List<String> prepareData() {
 {% endhighlight %}
 
 ## Harmonogramy
-Wprowadzone w module `RxAndroid` harmonogramy decydują o tym na jakim wątku obiekt obserwowany będzie wykonywał zadanie oraz na jakim wątku obiekt obserwatora będzie odbierał i przetwarzał wyemitowane dane. Najpopularniejszymi harmonogrami są: `AndroidSchedulers.mainThread` - odpowiada za główny wątek aplikacji, `Schedulers.io` - wykorzystywany w nie wymagających operacjach i `Schedulers.computation` - przeznaczony do przetwarzania intensywnych zadań. Wyróżnia się także `Schedulers.newThread`, `Schedulers.single`, `Schedulers.immediate`, `Schedulers.trampoline`, `Schedulers.from`, które różnią się synchronicznością, kolejnością, czasem rozpoczęcia i ilością przetwarzanych zadań. Przypisanie harmonogramu dokonywane jest na obiekcie obserwowanym za pomocą metod `subscribeOn` i `observeOn`.
+Harmonogramy decydują o tym na jakim wątku obiekt obserwowany będzie wykonywał zadanie oraz na jakim wątku obiekt obserwatora będzie odbierał i przetwarzał wyemitowane dane. Najpopularniejszymi harmonogrami są: `AndroidSchedulers.mainThread` - odpowiada za główny wątek aplikacji (wprowadzony w module `RxAndroid`), `Schedulers.io` - wykorzystywany w nie wymagających operacjach i `Schedulers.computation` - przeznaczony do przetwarzania intensywnych zadań. Wyróżnia się także `Schedulers.newThread`, `Schedulers.single`, `Schedulers.immediate`, `Schedulers.trampoline`, `Schedulers.from`, które różnią się synchronicznością, kolejnością, czasem rozpoczęcia i ilością przetwarzanych zadań. Przypisanie harmonogramu dokonywane jest na obiekcie obserwowanym za pomocą metod `subscribeOn` i `observeOn`.
 
 {% highlight java %}
 private void startWorkAndSubscribe() {

_drafts/2019-07-08-service.md

@@ -11,6 +11,7 @@ keywords: "service, thread, task, foreground, background, bound, start, bind, on
 
 ## Wstęp
 `Service` jest usługą dziąłającą w tle na głównym wątku aplikacji. Nie posiada interfejsu użytkownika i jest niezależny względem cyklu życia aktywności (`Activity`). Komponenty mogą związać się do serwisu w celu interakacji z nim. Wykorzystywany przede wszystkim do natychmiastowego wykonywania długich, powtarzalnych lub ciągłych zadań w tle implementowanych na wątku roboczym (np. pobieranie, przetwarzanie danych, odtwarzanie muzyki). Może zostać uruchomiony przez różne komponenty oraz przez inne aplikacje. Jest zdolny do kontynuowania pracy w tle nawet po wyjściu z aplikacji. Może rozpocząć działanie zarówno poprzez wystartowanie jak i podpięcie. Wyróżnia się trzy tryby działania serwisu: `background`, `foreground` i `bound`.
+
 ## Ograniczenia
 Ze względu na wykonywanie pracy całego serwisu na wątku głównym należy zaimplementować kosztowne zadania usługi w oparciu o wątki robocze lub jako alternatywę rozważyć wykorzystanie `IntentService`. W zależności od wybranego trybu działania serwisu trzeba uwzględnić także konieczność dostarczenia mechanizmu odpowiedzi zwrotnej do klienta oraz restrykcję systemu dla procesów działających w tle. Jeśli wykonywanie zadania ma sens tylko w ramach aktywnego danego ekranu czy też powiązane jest z cyklem życia komponentu należy zrezygnować z wykorzystania `Service` i użyć innych mechanizmów takich jak np. `AsyncTask` czy `HandlerThread`. 
 

_drafts/2019-07-15-intentservice.md

@@ -29,11 +29,11 @@ class CustomIntentService : IntentService("name") {
     //they are automatically invoked by IntentService
 }
 
-class MainActivity : AppCompatActivity() {
+class CustomActivity : AppCompatActivity() {
 
     override fun onCreate(savedInstanceState: Bundle?) {
         super.onCreate(savedInstanceState)
-        setContentView(R.layout.activity_main)
+        setContentView(R.layout.activity_custom)
         button.setOnClickListener { startIntentService() }
     }
 
@@ -70,13 +70,13 @@ class IntentServiceCommunication : IntentService("name") {
     }
 }
 
-class MainActivity : AppCompatActivity() {
+class CommunicationActivity : AppCompatActivity() {
 
     private val receiver = CustomBroadcastReceiver()
 
     override fun onCreate(savedInstanceState: Bundle?) {
         super.onCreate(savedInstanceState)
-        setContentView(R.layout.activity_main)
+        setContentView(R.layout.activity_communication)
         button.setOnClickListener { startIntentService() }
 
         registerReceiver(receiver, IntentFilter("FILTER_ACTION"))

_drafts/2019-07-22-workmanager.md

@@ -169,7 +169,7 @@ class FinalWorker(context: Context, params: WorkerParameters) : Worker(context,
 `JobScheduler` pozwala na planowanie zadań w tle gwarantując ich ukończenie w nieokreślonej przyszłości. Wykonanie zadania jest uzależnione od warunków stanu systemu. Może się zdarzyć, że rozpoczęcie pracy będzie natychmiastowe lub pozostanie w oczekiwaniu na korzystny stan systemu umożliwiający podjęcie działania zgodnie z wymaganiami wstępnymi. Optymalizuje użycie baterii i pamięci w stosunku do innych kosztownych rozwiązań realizacji pracy w tle takich jak np. `Service`, `AlarmManager` czy `BroadcastReceiver`. Usługa `JobScheduler` jest jednak dostępna od wersji systemu `Android L`. Alernatywnym rozwiązaniem może być wykorzystanie `FirebaseJobDispatcher` (działa także poniżej `Android L`). Obie usługi działają w oparciu o `JobService`, którego zadaniem jest obsługa zdarzeń rozpoczęcia i zatrzymania pracy. Warunki wstępne deklarowane są w obiektach `JobInfo` lub `Job`, a zaplanowanie zadania odbywa się przy pomocy metody `schedule`.
 
 {% highlight kotlin %}
-class JobScheduler : AppCompatActivity() {
+class JobSchedulerActivity : AppCompatActivity() {
 
     lateinit var jobScheduler: JobScheduler //works min for API 21
     lateinit var jobDispatcher: FirebaseJobDispatcher //alernative for lower API

_drafts/2019-08-05-sharedpreferences.md

@@ -0,0 +1,163 @@
+---
+layout: post
+title: "SharedPreferences"
+date: 2019-08-05
+categories: ["Przechowywanie"]
+image: store/sharedpreferences
+github: store/tree/master/sharedpreferences
+description: "Przechowywanie danych"
+keywords: "store, data, datastore, sharedpreferences, preferences, key, value, primitive, settings, get, put, editor, android, programowanie, programming"
+---
+
+## Charakterystyka
+`SharedPreferences` umożliwiają przechowywanie i zarządzanie prostymi danymi prymitywów tj.: wartości logiczne, liczby całkowite i zmiennoprzecinkowe oraz teksty w postaci pary `klucz - wartość`. Dane przechowywane są na urządzeniu w plików `xml` niezależnie od cyklu życia aplikacji. Istnieją tak długo dopóki nie zostaną usunięte przez kod programu lub wyczyszczone ręcznie przez użytkownika z danych aplikacji. Aplikacja może posiadać wiele instancji `SharedPreferences`, które najczęściej są prywatne lecz mogą być także publiczne dla innych aplikacji. 
+
+## Przeznaczenie
+Nazwa `SharedPreferences` może sugerować przeznaczenie do przechowywania informacji nt ustawień użytkownika, co jest po części prawdą. Jednakże wszystkie informacje, które można sprowadzić do postaci klucz - wartość nadają się do umieszczenia w `SharedPreferences`. Mogą więc to być ustawienia czy preferencje użytkownika, ale równie dobrze także inne dane stanu aplikacji (np. najlepszy wynik) czy dane autoryzacyjne. Pomimo, że wiele informacji może być technicznie zapisanych w `SharedPreferences` (np. konwersja do `String`) to nie wszystkie powinny się tam znaleźć. Umieszczając wartości należy kierować się zasadą prostych, pojedynczych informacji (nie kolekcji). W pozostałych przypadkach warto rozważyć alternatywy w postaci m.in. plików i bazy danych.
+
+## Implementacja
+Aby uzyskać referencję do wskazanego pliku `SharedPreferences` należy wywołać metodę `getSharedPreferences` lub `getPreferences`. Czytanie wartości odbywa się za pomocą metod get danego typu, natomiast zapisywanie wartości przebiega jako transakcja na obiekcie `SharedPreferences.Editor`.
+
+{% highlight kotlin %}
+class MainActivity : AppCompatActivity() {
+
+    override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+    }
+ 
+    fun getSharedPreferences(name : String) : SharedPreferences {
+        //must be called on Context
+        return getSharedPreferences(name, Context.MODE_PRIVATE) //pass public to allow access outside app
+    }
+
+    fun getSharedPreferencesForActivity() : SharedPreferences {
+        //SharedPreferences file only for this activity
+        return getPreferences(Context.MODE_PRIVATE) 
+    }
+
+    fun write(key : String, value : Int) {
+        val sharedPref = getSharedPreferences("pl.androidcode.app.FILE_KEY")
+        val editor = sharedPref.edit()
+		
+        //do some transactions
+        editor.putInt(key, value) //or use another method to put different types
+        editor.commit() //to save immediately or apply to save in background
+    }
+    
+    fun read(key : String) : Int {
+        val sharedPref = getSharedPreferences("pl.androidcode.app.FILE_KEY")
+        val default = 0
+        return sharedPref.getInt(key, default)
+    }
+}
+{% endhighlight %}
+
+## Preference
+W przypadku standardowych ustawień aplikacji edytowanych przez interfejs graficzny dobrym pomysłem mogłoby być wykorzystanie biblioteki `Preference`, która ułatwia pracę z `SharedPreferences` poprzez dostarczenie kontrolek widoku dla kluczy ustawień. W tym celu należy stworzyć Fragment rozszerzający `PreferenceFragmentCompat` i w metodzie `onCreatePreferences` przekazać plik `xml` z preferencjami. Wprowadzane zmiany dotyczą globalnych domyślnych ustawień możliwych do uzyskania przez wywołanie `getDefaultSharedPreferences`.
+
+{% highlight kotlin %}
+class SettingsActivity : AppCompatActivity() {
+
+    override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+        setContentView(R.layout.activity_settings)
+
+        //add Preference Fragment
+        supportFragmentManager
+            .beginTransaction()
+            .replace(R.id.container, SettingsFragment())
+            .commit()
+    }
+	
+    //read some pref when needed, use getDefaultSharedPreferences
+    fun readPref() : Boolean {
+        val sharedPref = getDefaultSharedPreferences(this)
+        return sharedPref.getBoolean("pref2", false)
+    }
+}
+
+class SettingsFragment : PreferenceFragmentCompat() {
+
+    override fun onCreatePreferences(savedInstanceState: Bundle?, rootKey: String?) {
+        setPreferencesFromResource(R.xml.preferences, rootKey)
+    }
+	
+    override fun onPreferenceTreeClick(preference: Preference?): Boolean {
+        return when (preference?.key) {
+            "pref2" -> {
+                //do something when pref has changed if needed
+                true
+            }
+            else -> {
+                super.onPreferenceTreeClick(preference)
+            }
+        }
+    }
+	
+    //implement more methods to react for interactions
+}
+{% endhighlight %}
+
+{% highlight kotlin %}
+<!-- PreferenceScreen must be parent -->
+<androidx.preference.PreferenceScreen
+    xmlns:app="http://schemas.android.com/apk/res-auto">
+
+    <Preference
+        app:key="pref1"
+        app:title="Some title"
+        app:summary="More details"/>
+
+    <SwitchPreferenceCompat
+        app:key="pref2"
+        app:title="Some message"
+        app:summary="More details"/>
+
+    <!-- use more preferences from Preference class and subclasses -->
+
+</androidx.preference.PreferenceScreen>
+{% endhighlight %}
+
+## DataStore
+Biblioteka `Preference` domyślnie zarząda danymi wykorzystując implementację `SharedPreferences`. Nierzadko jednak taka realizacja zapisu i odczytu danych może nie być wystarczająca ponieważ może np. zachodzić potrzeba dodatkowego zapisu danych w chmurze ze względu na synchronizację preferencji między urządzeniami. W takiej sytuacji z pomocą przychodzi `PreferenceDataStore` dostępny od wersji systemu `Android O`.
+
+{% highlight kotlin %}
+//use custom PreferenceDataStore inside onCretePreferences
+class DataStoreFragment : PreferenceFragmentCompat() {
+
+    override fun onCreatePreferences(savedInstanceState: Bundle?, rootKey: String?) {
+        setPreferencesFromResource(R.xml.preferences, rootKey)
+
+        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
+
+            //enable data store only for specific preference
+            val preference = findPreference("pref2")
+            preference.preferenceDataStore = DataStore()
+
+            //ore enable for entire hierarchy
+            preferenceManager.preferenceDataStore = DataStore()
+        }
+    }
+}
+
+//override only used operations
+@RequiresApi(Build.VERSION_CODES.O)
+class DataStore : PreferenceDataStore {
+    
+    //make sure to provide proper non blocking threading during extra work
+    
+    override fun getBoolean(key: String?, defValue: Boolean): Boolean {
+        //try to get pref from remote
+        //if failed or doesn't exists then try to get from local
+        return super.getBoolean(key, defValue)
+        //log operation
+    }
+
+    override fun putBoolean(key: String?, value: Boolean) {
+        //try to put pref to remote
+        //save also in local
+        super.putBoolean(key, value)
+        //log operation
+    }
+}
+{% endhighlight %}