サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ノーベル賞
blog.danlew.net
Have you ever gotten into a heated debate on a pull request, only to find out that the person critiquing your code didn’t really care that much whether their feedback made it into the PR? Or have you been upset when your strenuous objections to some design are going ignored by others? In these cases, there’s a brilliant tool that a coworker (Justin Holmes) came up with that I’ve found to be very u
One of the best changes I’ve made at work recently is to stop nitpicking in code reviews. Nitpicking isn’t about code that is wrong but suboptimal. It’s pointing out a variable name that could use a more appropriate word, a conditional that could be formatted more cleanly, or some minor simplifying of logic. Nits don't result in significantly better code, nor do they educate the developer; they ar
Hello. This is Dan Lew. You may or may not know me as the author of RxLifecycle. Here’s why I’ve started pulling back from using my creation. Origins When Trello first started using RxJava, we were dismayed with how easy it was to leak memory when using it. Seemingly any Subscription you setup would leak unless you explicitly cleared it. As such, we were constantly juggling Subscriptions and unsub
I want to explain why I prefer Kotlin over Java. In short, the many myriad Kotlin features enable more concise and understandable code than Java without sacrificing performance or safety. Kotlin compiles to bytecode, so it can perform just as well as Java. It's got the same compile-time checks as Java (and more, such as built-in nullability checks). And most importantly, Kotlin's language features
Sharing code between unit tests and instrumentation tests on Android Edit (August 16, 2022): This method is outdated and no longer works on the latest versions of Android Studio. See my new guide for an up-to-date solution on this problem. Suppose you've got an Android application with a bunch of tests. Some of them are unit tests (located in src/test). The rest are instrumentation tests (located
I've grown fond of RxJava's defer() as a tool for ensuring Observable code runs when subscribed (rather than when created). I've written about defer() before but I'd like to go into more detail here. Suppose you've got this data class: public class SomeType { private String value; public void setValue(String value) { this.value = value; } public Observable<String> valueObservable() { return Observ
Thoughts on life, the universe and the mystery of it all; but actually mostly just code. Software development (or, you know, life in general) is all about juggling priorities. For this post, I’m thinking specifically about code design priorities. You only have a limited amount of time to implement a feature, so you have to pick and choose which aspects of it to spend time
RxJava makes error handling a snap. Just use onError, right? That's fine and dandy if you're the subscriber, but what about exceptions that occur inside your operators? How do you ensure that an Exception in, say, flatMap() gets passed along to onError? And what if you don't want the exception to terminate the sequence? Unchecked Exceptions For the most part, unchecked exceptions are automatically
repeatWhen and retryWhen are fairly baffling at first glance. For starters, they are serious contenders for "most confusing marble diagrams": They're useful operators: they allow you to conditionally resubscribe to Observables that have terminated. I recently studied how they worked and I want to try to explain them (since it took me a while to grasp). Repeat vs. Retry First of all, what is the di
Check out these two EditTexts. One is on an API 21 device, the other on an API 22 device. See the difference? It's even more pronounced with "show layout bounds" enabled: The height and vertical alignment of the EditTexts are different! This was caused by a change in the background of EditText between v21 and v22 (diff). This change can cause sadness if your EditText is vertically aligned with oth
A number of people have asked me recently, "What the hell happened to RxAndroid?" The fact of the matter is, RxAndroid was getting to be a bit of a mess and thus has been majorly refactored. You can read more about it here, but essentially: I am proposing a from-scratch, modularization of the library into re-usable and composeable modules. That has been accomplished, but if you upgrade now you're
Suppose I have some Data that I query from the network. I could simply hit the network each time I need the data, but caching the data on disk and in memory would be much more efficient. More specifically, I want a setup that: Occasionally performs queries from the network for fresh data. Retrieves data as quickly as possible otherwise (by caching network results). I'd like to present an implement
One nice aspect of RxJava is that you can see how data is transformed through a series of operators: Observable.from(someSource) .map(data -> manipulate(data)) .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .subscribe(data -> doSomething(data)); What if you have a set of operators that you want to reuse for multiple streams? For example, I frequently use subscribeOn() and
RxJava is the new hotness amongst Android developers these days. The only problem is that it can be difficult to approach initially. Functional Reactive Programming is hard when you come from an imperative world, but once you understand it, it's so awesome! I'm here to try to give you a flavor of RxJava. The goal of this three four-part series is to get your foot in the door. I'm not going to try
In parts 1, 2, and 3 I covered how RxJava works (in a general sense). But as an Android developer, how do you make it work for you? Here is some practical information for Android developers. RxAndroid RxAndroid is an extension to RxJava built just for Android. It includes special bindings that will make your life easier. First, there's AndroidSchedulers which provides schedulers ready-made for And
このページを最初にブックマークしてみませんか？
『Dan Lew Codes』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
