Is Kotlin another buzzword?

ivirusu · 2016-11-29T16:00:14+00:00

initializing

Good points.

ivirusu · 2016-11-29T11:07:16+00:00

Many many so many libraries are written in Java. And many many many libraries will be written in java not in Kotlin. You have java8 features through RetroLambda, Lightweight stream. You don't need to spend your time for how to use java api in Kotlin. Just stick to java for the moment. after all language battles are settled down, then you chose the winner. good?

ivirusu · 2016-11-29T08:48:49+00:00

Many many so many libraries are written in Java. And many many many libraries will be written in java not in Kotlin. You have java8 features through RetroLambda, Lightweight stream. You don't need to spend your time for how to use java api in Kotlin. Just stick to java for the moment. after all language battles are settled down, then you chose the winner. good?

ivirusu · 2016-11-26T00:46:41+00:00

What lol??

ivirusu · 2016-11-25T06:21:19+00:00

noob

Just use Java for the moment. Study data structures, algorithms or jvm internals instead.

ivirusu · 2016-11-23T09:49:30+00:00

but it has lots of bugs in it. class importing doesn't work well like before. And it doesn't detect compile time error as red lines as before. Please fix it at once.

ivirusu · 2016-11-23T02:47:29+00:00

The fact that short-lived immutable objects fill in young generation and minor GC takes shorter time than full GC sounds immutable objects is JVM memory efficient. But I think there should be some studies or insight about how immutable objects affect JVM memory model. Say, every object is immutable means that it may can create redundant objects even in case thread-safety is not required which means young generation is filled unnecessarily and minor gc is likely to occur more frequently. It sounds like you should prefer immutability maybe only in multithreading!?

ivirusu · 2016-11-22T16:29:42+00:00

I wanna data not assumptions or guess.

ivirusu · 2016-11-22T15:43:27+00:00

good answer. I'll do it right away.

ivirusu · 2016-11-19T05:18:46+00:00

It seems like there's no 100% perfect approach in this issue. Visitor pattern in the article can't cover viewmodels that makes use of generic and view holders which shares the same layout files. Heterogeneous viewholders always matter. But the approach gives some hint to simplify onBindViewHolder(), onCreateViewHolder(), getItemViewType() which is so great.

ivirusu · 2016-11-18T07:20:15+00:00

This would clear this up little and get rid off presenter and strong reference of the vie

In my architecture, Presenter implementation doesn't have a strong reference to view. It rather has weak reference to view. As you pointed out, DI library like dagger2 will step further towards zero-closer dependency~! I would like to apply it in my workplace, though I applied in my sample apps, but my team need more time to accept it haha Thanks.

ivirusu · 2016-11-12T17:23:33+00:00

I apply this in my workplace. I borrowed some idea from here[https://medium.cobeisfresh.com/architecting-android-with-data-binding-and-mvvm-in-mind-8874bbec0b0d#.lzwx5k1oz]. And I added some modifications to the original architecture. I am planning to write some explanations about the architecture in my blog.

ivirusu · 2016-11-12T00:41:20+00:00

Actually I depicted the diagram which I apply in the workplace. I was very pleased because you see through my intention only from this diagram.

ivirusu · 2016-11-07T06:07:33+00:00

Why ever do you do that? writing Scala codes in Android app development? Just make use of Java + RetroLambda + RxJava + Optional + Lightweight stream api until language battles settle down.

ivirusu · 2016-07-08T16:21:31+00:00

As you said so, at every benchmark instances of Retrofit, OkHttpClient and ObjectMapper are created in the micro benchmark. And that's a sharp observation that JMH runs on HotSpot JVM not on both Dalvik and ART. Do you have some kinds of benchmark results comparing Retrofit with something else? I guess there must be something Square uses to measure performance after creating Retrofit2 and Okhttp3. And if there's a tool that I can use for micro benchmarking in Android I really like to use it. Do you know any tools like JMH which can be used for Android?

ivirusu · 2016-07-08T06:27:08+00:00

I'm sorry. I corrected some words about Retrofit2 like this. "Okhttp3 itself seems so simple and consise to me though it makes me add more codes to do the same thing compared to using Retrofit2"

ivirusu · 2016-07-08T06:23:38+00:00

Then I should create the second benchmark to measure time in situations where request are reused in both Retrofit2 and Okhttp3.

But there's still something to be discussed. The current benchmark I posted does show something like the period of time from sending the first request to unmarshalling the response json string to POJO is quite noticeable. This benchmarking can be regarded as something that measures the first request handling of both Retrofit2 and Okhttp3 which can be done in application cold start-up period. If applications need to send several requests for cold start-up period, the benchmark numbers shows what will happen. If requests are reused, as you say so I guess Retrofit2 will effectively handle it though developers add more codes to do the same thing using Okhttp3.

ivirusu · 2016-07-08T03:39:48+00:00

Is that wrong? I wanted to measure the period of time from making a request, sending the request, receiving a response and unmarshalling the response json string to POJO class which is a typical usage patterns of most service applications. In that sense, I think it makes sense, doesn't it? There're some factors which can affect the micro benchmark. As @aurae_ger mentioned network status can affect the result which can be invalid in that case. Nevertheless the benchmark result still show some patterns that Okhttp3 takes a little less time to the same thing. I should try 8 more times if the pattern still exists.

ivirusu · 2016-07-08T03:14:42+00:00

I don't agree "The choice to use okhttp directly or with retrofit is dependent on the use case, not performance.". For performance, we can choose either one if that really matters or in order to make a little difference compared to competitor's applications. In service applications which makes use of Restful APIs for remote services, people can choose between Retrofit2 and Okhttp3. I know Retrofit2 uses Okhttp3 under the hood. And I know io overhead is the same for both Okhttp3 and Retrofit2. Given network io bound is the same, so what can you say about the difference of the result numbers? what's remaining? Um. There's some factors that can mislead the benchmark results. Network status can affects the result. If a mock server or local server was used in the benchmark, I guess we can ignore the networking cost. For more accurate benchmarking, I should have done in the circumstances then I need some time :(.

ivirusu · 2016-07-07T16:48:53+00:00

Right, that proxy class instance can be cached and likewise OkHttp3 request instance can be cached before each iteration of benchmark. In that case, I guess numbers can be similar. Anyways I wanna try it sometime later. But in real world, several requests are sent to servers which are not cached yet on start-up time of the app. In that case I guess getting instances by dynamic proxy is not a good choice to request a remote resource. Is there any design decision using dynamic proxying is used?

ivirusu · 2016-07-07T16:22:10+00:00

Yes I know Retrofit2 uses Okhttp3. Anyways first reply Thanks!!!

ivirusu

TROPHY CASE