I got a new lens recently, the FUJINON XF90mmF2 R LM WR, for Fujifilm X-mount cameras. It has been quite an experience working with it as the focal range is not something I’ve used before. So far I find it to be really great for making portraits and somewhat-macro pictures (as it’s not a real macro lens, but it can sort of do the job from about two feet away).
I might write a longer review later on, or at least post some example pictures. But in the meanwhile, here’s an unboxing video I made:
The Repository pattern is one of the concepts frequently used and mentioned within Android Architecture Components. As English is not my first language, I’m drawing a blank in my head whenever I read or hear the term “repository” itself. I have some abstract idea about what it is, mostly from the concept of Github repositories: it seems to be a central place for something.
In my experience, not understanding an English term is a common barrier to having a better intuition of a programming concept. I would read about something new and would have a hard time connecting a term that drew a blank in my mind, to the larger understanding of the concept. So today I figured I’ll geek out a little bit and see what the “repository” word really means.
According to Merriam-Webster, the word means:
: a place, room, or container where something is deposited or stored
This definition matches my understanding of a Git repository: it’s a place where the code is stored.
What about when the term is used in Android Architecture Components? From this Codelab:
A repository class abstracts access to multiple data sources. The repository is not part of the Architecture Components libraries, but is a suggested best practice for code separation and architecture. A Repository class provides a clean API for data access to the rest of the application.
and
A Repository manages queries and allows you to use multiple backends. In the most common example, the Repository implements the logic for deciding whether to fetch data from a network or use results cached in a local database.
Uh, what? That sounds like a lot of things it’s doing other than just being a storage.
The Codelab also provides this graphic:
I found a clearer explanation from an article about the Repository pattern:
[The repository] will persist your objects sans the need of having to know how those objects would be actually persisted in the underlying database, i.e., without having to be bothered about how the data persistence happens underneath. The knowledge of this persistence, i.e., the persistence logic, is encapsulated inside the Repository.
In essence, the Repository design pattern facilitates de-coupling of the business logic and the data access layers in your application with the former not having to have any knowledge on how data persistence would actually take place.
In using the Repository design pattern, you can hide the details of how the data is eventually stored or retrieved to and from the data store. This data store can be a database, an xml file, etc. You can apply this design pattern to even hide how data that is exposed by a web service or an ORM is accessed. Martin Fowler states: “Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.”
So from the above, it sounds like the Repository pattern is more of a way to allow access to various data sources, without the accessor having to know about how the data sources are created. It’s not just a dumb place to store things, instead it’s a smart storage that allows someone to add or remove things as needed.
That mental model still makes sense for a Git repository as well: I add and remove code to my repository without really knowing how Github stores it: is it in a database? If yes, what database? I don’t need to know.
From now on I figure I’d imagine the Repository pattern as a sort of librarian who I can talk to to help me find a book: I mention a title and they’d go ahead and fetch it for me. From my perspective it’s not important where the book is stored within the library (shelves? Fridge? Vault?), as long as I can borrow and return it properly. After all, a library is indeed a repository of books, yeah?
🇮🇩
Artikel kali ini diterjemahkan dari artikel asli dalam bahasa Inggris, “Dagger 2 for Dummies in Kotlin (with 20 lines of code)” oleh Elye, link di bawah:
🇬🇧
Below is my Indonesian translation from the original article “Dagger 2 for Dummies in Kotlin (with 20 lines of code)” by Elye, link below:
Saya seorang dummy, dan belajar Dagger 2 membikin otak saya melar!! Semua tutorial yang saya baca membahas terlalu banyak hal, seperti Dependency Injection, Provider, Component, Module, Scope… membuat otak meledak!
Selain itu, kebanyakan tutorial memakai Java. Kotlin adalah pilihan yang lebih baik saat ini. Saya perlu berbulan-bulan untuk memahami Dagger 2 di Kotlin. Jadi saya berjanji pada diri sendiri bahwa nanti begitu saya paham, saya harus membuat tutorial yang super sederhana, sesimpel ABC, untuk orang-orang seperti saya yang mungkin membutuhkan.
Karena alasan itu, saya membuat aplikasi Android paling sederhana yang memakai Dagger 2… Hanya 2 halaman, kurang dari 20 baris 😎 . (tolong jangan membuat yang lebih simpel lagi, biarkan saya memegang satu rekor dunia 😝).
Banyak tutorial menampilkan kode berhalaman-halaman, dan tautan hubungan antar classes. Otak saya capek, karena stack saya dangkal 😝
(Untuk para ahli, saya minta maaf untuk cara saya yang tidak umum untuk memperkenalkan Dagger 2, karena ini benar-benar untuk dummies, dan hanya meminta pengetahuan yang minim bagi pembacanya)
Oke, saya akui, saya lumayan punya pengetahuan pemrograman. Saya tahu soal Function, Class, Member Variables. Saya tahu cara membuat aplikasi Hello World dengan satu MainActivity (hey! … Anda bisa membuat aplikasi itu tanpa mengetik satu baris kode… Cukup memakai template Empty Activity di Android Studio 😁)
Untuk membuatnya lebih keren, saya bisa mengubah aplikasi Hello World tadi menjadi aplikasi Hello Dagger 2. Silahkan lihat kode di bawah (bagian yang ditebalkan adalah kode yang saya tambahkan kepada template yang sudah ada).
class MainActivity : AppCompatActivity() {
val info = Info()
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
text_view.text = info.text
}
}
class Info {
val text = "Hello Dagger 2"
}
Maaf kalau saya membuat hal sederhana jadi lebih rumit dengan menggunakan class untuk menyimpan teks. Dan saya membuat member variable bernama infountuk menyimpannya. Nanti dia akan berperan penting untuk menjelaskan penggunaan Dagger 2.
Saya harap semua cukup simpel sejauh ini.
Dalam aplikasi beneran, biasanya saya tidak hanya punya satu member variable info. Bisa jadi akan ada banyak lainnya. Atau barangkali saya ingin membagi info dalam banyak activities.
Untuk mempermudah, alih-alih membuat info di dalam class MainActivity, saya ingin membuat info (dan semua member variables lain) dibuat di tempat lain, lalu dikirim masuk. Hey, kamu tahu? Ada istilah untuk hal tersebut… Dependencies Injection 😉.
Kedengaran sederhana… mungkin saya bisa membuat seperti ini?
class MainActivity(val info:Info) : AppCompatActivity()
Ups! Maaf, Android tidak mengizinkan saya menambah argumen kepada constructor Activity. Kalau saya mau, ada jalan yang lebih susah. Cek di Stack Overflow. Tapi meskipun saya mau pakai jalan susah tersebut, dia masih tetap mustahil dilakukan, karena kita melakukannya di Activity pertama di dalam aplikasi. Siapa yang akan mengirim parameternya?
Kalau Anda punya lebih banyak pengalaman di Android development, mungkin sekarang Anda sudah berpikir untuk menggunakan Application untuk membantu Anda… Tepat sekali, Anda benar! … Tetapi saya yang sedang bercerita di sini. Saya sedang bercerita soal Dagger 2, jadi mari kembali ke topik…
Dengan adanya kebutuhan seperti kita bahas sebelumnya, beberapa orang mulai membayangkan, betapa enaknya kalau kita bisa secara ajaib membuat semua dependencies agar bisa di-inject (dalam kasus saya, dependency yang saya punya adalah info). Untuk Android, beberapa orang tersebut akhirnya membuat Dagger, yang dibuat oleh para ahli dari Square. Google menyukai karya mereka, dan membuat versi keduanya, Dagger 2.
Dagger 2 menjadi sangat populer… sampai suatu hari seorang dummy ingin belajar tentangnya… lalu memutuskan membuat blog post… Okay, cukup ngobrol sejarahnya…
Dengan adanya Dagger 2, kita sekarang bisa membuat info muncul secara ajaib. Mungkin akan lebih ajaib lagi kalau kita bisa menghapus baris val info = Info(), tapi hal ini TERLALU ajaib. Sudah di luar kemampuan Dagger 2, mungkin butuh David Copperfield.
Yang lebih realistis, kita masih harus memberitahu MainActivity untuk memiliki member variable bernama info, tetapi dia TIDAK PERLU membuat/menginisialisasinya (hal ini biarkan terjadi secara ajaib).
Dengan Kotlin, karena kita ingin info sebagai non-nullable item, maka info harus diinisialisasi dengan sesuatu. Tetapi karena kita tidak tahu dia mau diisi apa, dan kita menunggu kerja dari Dagger 2, maka kita perlu memberitahu Kotlin agar lebih santai dan tidak kuatir soal inisialisasi, dengan cara menambah modifier bernama lateinit.
Jadi singkatnya, cukup tambahkan lateinit var info: Info untuk mengganti kode kita sebelumnya.
class MainActivity : AppCompatActivity() {
lateinit var info: Info override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
text_view.text = info.text}
}
class Info {
val text = "Hello Dagger 2"
}
Hey, jangan di-compile dulu kode di atas, nanti akan CRASH 💥!!! Penyebabnya karena info belum diinisialisasi.
Maaf karena belum ada keajaiban di sini. Jangan marah ke saya… Saya janji kita nanti tidak perlu inisialisasi di MainActivity, cukup Dagger 2 yang melakukannya.
Sekarang, menuju dunia Dagger 2…
Sebelum terlalu jauh, kita lakukan hal-hal membosankan dulu. Semua yang kita perlu pakai di luar hal-hal Android paling dasar, kita perlu tambahkan libraries-nya ke project kita. Dagger 2 juga begitu. Cukup ikuti langkah berikut.
Di file build.gradle aplikasi Anda (pilih untuk app, bukan project), tambahkan baris yang ditebalkan berikut:
apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'
apply plugin: 'kotlin-kapt'
dan
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
// ... other dependencies ...
implementation 'com.google.dagger:dagger:2.13'
kapt 'com.google.dagger:dagger-compiler:2.13'
}
Lalu lakukan sync di project Anda. Sekarang Anda bisa pakai Dagger 2.
Sekarang kita kembali ke kode. Saya kenalkan Anda pada yang namanya @Component. Dia adalah satu cara untuk memberitahu Dagger 2, “Hey! Saya ingin satu kotak ajaib yang bisa melakukan keajaiban membuat member variable saya.”
Saya mendeklarasikan kotak ajaib tadi seperti ini, sebagai interface:
@Component
interface MagicBox
Saya menyebutnya
MagicBoxagar berbeda dengan tutorial lain, agar Anda tahu kalau dia bisa dikasih nama apa saja. Tutorial lain akan memberinya nama<Something>Component. Dalam proyek bersama-sama dengan orang lain, saya sarankan memakai nama seperti itu, jadi orang lain bisa paham kode anda.
Saya juga perlu memberi tahu kotak ajaib tadi, bahwa dia dibuat untuk melakukan keajaiban pada MainActivity. Untuk melakukan itu, saya membuat function bernama poke , yang menerima MainActivity sebagai parameter di dalam MagicBox
@Component
interface MagicBox {
fun poke(app: MainActivity)
}
Catat bahwa saya memakai nama
poke(suntik) agar berbeda dengan tutorial lain, jadi Anda tahu dia bisa diberi nama apa saja. Hampir semua tutorial yang saya baca, memakai namainject. Sekali lagi saya sarankan memakai nama itu untuk proyek bersama, agar mudah dipahami.
Untuk membuat semuanya lebih jelas, bayangkan bahwa MagicBox bisa dipakai untuk menyuntik MainActivity, seperti di diagram di bawah, agar bisa memasukkan info ke dalam MainActivity. Kita cuma perlu memasukkan info ke dalam MagicBox, dan dia langsung bekerja! …Akan saya tunjukkan bagaimana info dimasukkan, sebentar lagi…
Mari kita bayangkan sebentar. Terutama jika saat ini Anda bertanya-tanya, untuk apa membuat MagicBox kalau kita bisa membuat info langsung di dalam MainActivity?
Sekarang bayangkan kita punya banyak members variable selain info, dan kita juga punya banyak activities dan classes yang membutuhkan mereka. Jadi diagramnya jadi seperti di bawah, dan MagicBox bisa mengisi semuanya sekaligus, tanpa satupun activities atau classes harus repot-repot membuat members variable-nya sendiri.
👏👏👏 MagicBox mengurus semuanya untuk kita!! Baik sekali dia…
Oke, sekarang kembali ke kenyataan. Kita hanya butuh satu info di satu MainActivity, karena kita sedang membuat aplikasi Dagger 2 paling simpel di dunia.
Oke, sekarang kita masukkan info ke @Component…
Sekarang bisa jadi Anda berpikir, kalau kita harus secara manual memasukkan info ke @Component, terus apa spesialnya? Bukannya kita bisa membuat class untuk membuat yang seperti itu? Di mana ajaibnya?!!
Tunggu… keajaiban Dagger 2 segera muncul… sekarang!
Keajaibannya adalah, saya tidak perlu memasukkan info ke MagicBox. Saya cukup tambahkan keyword spesial (disebut juga annotation) ke dalam class Info, dan Dagger 2 langsung tahu ke mana dia harus mengambil Info.
Perkenalkan… @Inject!!
Ubah dulu class Info tadi dari
class Info {
val text = "Hello Dagger 2"
}
menjadi
class Info @Inject constructor() {
val text = "Hello Dagger 2"
}
Maaf kalau Anda harus mengetik lebih banyak dari @Inject, karena sebelumnya kita tidak membikin constructor. Karena @Inject harus ditambahkan di constructor, maka kita perlu menampilkan contructor di Kotlin memakai function constructor() di atas.
Setelah annotation @Inject ditambahkan, Dagger 2 sekarang sudah tahu caranya mengambil class Info lewat MagicBox. Gampang sekali caranya, sekarang Anda bisa tambahkan @Inject ke class manapun yang sudah ada, dan class object langsung terkonek dengan MagicBox secara ajaib saat dibuat.
Jika Anda penasaran bagaimana caranya… Itulah keajaiban Dagger 2. Tidak usah pusing-pusing memikirkannya, karena kita cuma dummies 😝.
Semua belum selesai. Kita sudah mendefinisikan MagicBox, dan menyambungkan Info ke MagicBox. Kita sudah punya function poke untuk menyuntik MainActivity.
Tapi sejauh ini, kita belum menyuntiknya!
Sebelum kita bisa melakukan itu, kita harus membangun MagicBoxnya dulu…
Tapi MagicBox adalah sebuah interface. Siapa yang harus membuat implementasinya?
Jangan takut!!! Inilah keajaiban Dagger 2 berikutnya. Karena kita sudah memberinya nama MagicBox, kita cukup menjadikan Dagger 2 sebagai penguasa dari MagicBox, dengan cara memanggil Static Class yang secara ajaib sudah dibuatkan, bernama DaggerMagicBox.
Kelas ini akan memberi anda sebuah Builder untuk membangun MagicBox. Cukup panggil seperti berikut:
DaggerMagicBox.create()
Jangan kuatir kalau Android Studio protes karena dia tidak mengenali DaggerMagicBox, karena sampai pada titik itu dia memang belum diciptakan. Cukup percayakan pada Lord Dagger 2, dan dia akan membereskan semua. Compile/Run... dan seperti dijanjikan, DaggerMagicBox diciptakan saat proses kompilasi.
Oke, menyuntik MainActivity bisa dilakukan seperti berikut (intinya: buat MagicBox, panggil function poke. Masukkan MainActivity sebagai parameter memakai this):
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
DaggerMagicBox.create().poke(this)
text_view.text = info.text
}
Idealnya, sampai di sini aplikasi langsung jalan.
Compile… run… CRASH 💥 !!! Android Studio protes lagi, info belum diinisialisasi!!!
Tolong, tolong jangan tembak saya… saya tidak bohong soal keajaiban Dagger 2. Ijinkan saya tambahkan satu step lagi…
dalam MainActivity, kita sudah definisikan info seperti ini
lateinit var info: Info
Dagger 2 tidak ingin membajak member variable manapun dengan membuat tanpa ijin saya. Ini sebenarnya bagus, karena kadang bisa jadi saya ingin bikin info saya sendiri.
Jadi untuk memberitahu Dagger 2, member variable mana yang perlu dia ciptakan, kita pakai kata kunci @Inject di depan namanya:
@Inject lateinit var info: Info
SELESAI!!! Sudah cukup. Compile, semua jalan!!!
Dengan kode tadi, selesai sudah dalam satu file (kurang dari 20 baris, dan hanya 4 baris Dagger 2):
class MainActivity : AppCompatActivity() {
@Inject lateinit var info: Info
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
DaggerMagicBox.create().poke(this)
text_view.text = info.text
}
}
class Info @Inject constructor() {
val text = "Hello Dagger 2"
}
@Component
interface MagicBox {
fun poke(app: MainActivity)
}
Anda bisa ambil contoh project-nya di
https://github.com/elye/demo_android_simplest_dagger2
Oh tentu tidak. Ini hanya ujung dari gunung es Dagger 2. Tapi untuk seorang dummy seperti saya, mencerna hal sederhana begini adalah awal yang bagus, dan otak saya bisa istirahat sejenak.
Saya tahu kalau saya hanya membagi hal paling dasar (dan saya dengar sebagian orang memprotes, karena saya tidak adil kepada Dagger 2. Maaf… saya akan tambahkan lagi detailnya kalau pembaca tertarik), dan saya memang sengaja tidak membahas hal-hal penting seperti @Module, @Singleton, @Scope, dan lainnya. Mereka tidak dibahas supaya saya bisa membuat semuanya lebih mudah dipahami para newbies. Tapi mereka memang penting untuk membuat Dagger 2 semakin berguna.
Kalau Anda tertarik, Anda bisa belajar lebih lanjut di sini.
Atau, Anda juga bisa mencari tutorial lain, karena saya merasa tutorial saya sudah memberi Anda pemahaman dasar bagaimana hal-hal di Dagger 2 saling menyambung. Anda bisa jadi sudah siap untuk membaca tutorial lain yang lebih padat.
In other words, you are unlikely to know up front whether an optimisation will be of any real benefit. Just write the code the simplest way. If, eventually after profiling you discover a bottleneck optimise that.
from Optimize Later
(Also related: Premature Optimization)
I am currently designing an app that will make heavy use of the WordPress.com REST API. During the process I was a bit worried that the app will need to make multiple API requests at once and becomes too slow. But it seems like it’s no use worrying about now. We’ll have to see how the actual app runs, and work on optimizing it if it’s ever needed.
It can feel like each day a new JavaScript framework is introduced, and the fast-paced development becomes difficult to keep up with. I came across a comment on Hacker News that explains the reasoning, the why of a particular framework. I reproduced the comment below and added some links to help make research easier:
While it might look like the frontend is going around in circles, there are major & minor differences between the technologies, and they have each introduced novel (to JS at least) things… Off the top of my head (this timeline might not be right but it’s how I went through it at least):
Backbone got you away from jquery spaghetti, helped you actually manage your data & models. Often paired with Marionette to handle views (if you squint this is the precursor to components) and bring some order in that part of the app.
Angular bundles backbone’s data handling (services), Marionette’s orderly view separation (views, directives), but they made a fatal mistake in the apply/digest cycle and maybe encouraging a bit too much complexity. Angular is everything bundled together, with consistent usage/documentation/semantics, a familiar programming pattern (MVC), and a large corporate sponsor in Google it caught on like wildfire.
Knockout sees Angular’s MVC, laments it’s complexity and focuses on MVVM — simple binding of a model and a relatively simple reactive-where-necessary controller
React comes along and suggests an even simpler world where the only first class citizen is components and everything else comes separate (this isn’t necessarily new, there is an article out there comparing it to COM subsystems for windows). React is almost always used with react-router and some flux-pattern supporting data management lib — these are also departures from how angular, backbone and knockout structured in-application communication (backbone was pure event bus, angular had the usual MVC methods, knockout was just callbacks — if you have a handle to an observable when you change it things reload).
Vue sees the complexity that React grew to (case in point:
shouldComponentUpdate) and devises a much simpler subset along with a new way to handle reactivity — using the `data` method of a Vue component. Vue made a lot of decisions that helped it stay simple and small yet very productive and this is in large part thanks to React existing before hand.Svelte comes on the scene and realizes that truly optimal rendering could be achieved by just compiling away the excess and eschewing the virtual DOM all together in most cases. No need to track all the structure if you compile the code with the updates necessary. Don’t quote me on this but I think a whole host of things influenced this project — smarter compilers, better type systems, the ideas around zero cost abstractions & doing more work at build time.
Ember (formerly SproutCore) is actually an anomaly because it tries it’s best to be both angular like (so large, and usable by large teams) and keeping up with the tech as it evolves (see: Glimmer, Octane). Ember also has some innovations, like Glimmer’s VM-based approach — turns out you can just ship binary data representing how to draw your components to the browser and skip a bunch of JS parsing, if you bring your own virtual machine that is optimized to draw the components.
hardwaresofton on Hacker News
