Develop Reference

Is there a way to trace who invoked onNext() on a Subject, in RxJava(2)?

I am developing an Android app (It doesn't matter though) using RxJava2, and in some singleton there are some PublishProcessors.
And there are a lot of .onNext() calls on these PublishProcessors all over the project.
Now in order to debug, I need to know, on every .onNext() called, which line in my project invoked this .onNext().
Is there a way in RxJava(2) that I can achieve this?

I think you can use Frames tab in Debug menu.
For example, in this case, MainActivity line 18 trigger onNext

Ah, thanks to #PhanVanLinh, I found a solution that worked for me.
(Actually it has pretty much nothing to do with RxJava...)
You just need to print the stacktrace using Thread.currentThread.stackTrace and print it to your own string inside doOnNext(), but remember to do it before .observeOn() so that the thread won't switch, it must stay at the original thread that called .onNext(), otherwise you won't get meaningful information.
Then you will know which line that called .onNext().

what should callerContext param be for Fresco's prefetchToBitmapCache?

In order to implement image pre-fetching, we get the ImagePipeline and call prefetchToBitmapCache on it. however, both the API Javadoc (http://frescolib.org/javadoc/reference/com/facebook/imagepipeline/core/ImagePipeline.html#prefetchToBitmapCache(com.facebook.imagepipeline.request.ImageRequest, java.lang.Object) and the plain doc (http://frescolib.org/docs/using-image-pipeline.html#) are incorrect. specifically , they leave out the description and example for what the second method parameter is. I am talking about the Object callerContext . which since its an object isn't an android Context. I'm guessing that because the type is an object, not a Context. Could the documentation be updated and/or someone explain what the caller context is supposed to be?
Thank you!

So I posted this question a while back on the fresco github (https://github.com/facebook/fresco/issues/609) and I was told the documentation would be updated. I'm posting my results here since it is likely others might look here. I still haven't seen any updates to frescolib.org or anywhere else. I decided to figure it out myself. Basically, if you're using SimpleDraweeView and its respective ImageRequest (which the prefetch call needs) , then you would notice that setting the uri on the view creates a DraweeController with a null callerContext. I figured that might be what is needed here. Sure enough, I made the call to prefetchToBitmapCache(draweeController, null) and its prefetched! I know that because I waited for a bit and turned off the data. also this call was only active on a select imageview. the other did not load. I can't be sure this is the right way to do it, ntil they come out with the right documentation. but like i said it works.

How do I navigate through and understand the documentation in Android?

I got one piece of code to study and I was puzzled for a long time because I tried to make my own version of it and it broke then I tried commenting the original code step by step to see when it failed and it gave me a null pointer in a getView method after I commented the declaration of one variable it used. I wasn't seeing this method being called anywhere and searched a lot for an answer until I found this:
When is the getView() method of ListView called?
It esentially says that getView getts called whenever an item is passed to the adapter through the setAdapter method.
I look all over the View docs, Adapter docs, Inflater, etc and couldn't find any piece of information to tell me that this happened, not even the setAdapter method itself says anything about this behavior. Is this just a documentation error or is there some general guideline I'm not following correctly?

I think you are going in the Right direction, if you are breaking into the code and hitting road blocks. The best resource to Study API's for Android is android developer site itself
http://developer.android.com/reference/android/widget/Adapter.html
PLus the [android] tagged questions on StackOverflow.

Android. ACRA. Is putCustomData thread safe

I can't seem to find the answer to this question I'm having:
Is the method from the ACRA library ...
ACRA.getErrorReporter().putCustomData(Name, Content);
... thread safe?
I'd like to call it from two different threads and I'm not sure if i should or not.
I've searched through the documentation but I wasn't able to find anything related to this unfortunately, or maybe I'm just a bad Googleler :)

If you're not sure, buy some insurance:
ErrorReporter er = ACRA.getErrorReporter();
synchronized( er ) {
er.putCustomData( ..., .... );
}

So I think I've figure it out.
Looking through the code I've noticed that the putCustomData method is in fact a call to a HashMap's method, more precisely put.
Upon further search I've found that the method put is not synchronized.
So the answer is no, calling putCustomData from two different threads can create problems for you.
For a solution to the problem: see 323go's idea below. In my case, I already had a singleton class which I used, so I just placed a synchronized method in that class in which I called the putCustomData method.
Note: If I am wrong, someone please let me know, but this is what I was able to find out.

Android Spinner - System view VS User view

I have been creating Spinner controls (Combo boxes/Drop downs) in one of my apps, and was surprised to find out how difficult it was to achieve all of the following features:
User facing Strings are externalized, taking advantage of strings.xml internationalisation (I18N) feature of Android.
Spinner selections operate using a System view, which facilitates not having to work with or map Strings to meaningful values (yuck).
User view to System view mapping should be easy, automated and minimal (i.e not hand rolled for every component).
Others have attempted solutions to this, but universally as far as I could see they suffer from one or many of the following problems:
UI code is creeping into their enum class which doesn’t belong there (messy), nearly all existing solutions suffered from this.
Hardcoded User facing Strings in their enum classes. Because these are not externalized you cannot do I18N using the stock Android features.
Authors typically make the Fragment or Activity an OnItemSelectedListener which perpetuates a common problem of inheritance for convenience, where composition is more appropriate.
I have developed my own solution which does this: http://www.androidanalyse.com/android-spinner-externalize-user-strings-mapped-to-system-enum/
My question is, have I missed something? This seems like something that should not have been this hard (which makes me feel like I'm possibly reinventing the wheel).
Below is some example code showing my solution in-use (which is available Apache 2 license from the link above).
String none = getString(R.string.none);
String light = getString(R.string.light);
String medium = getString(R.string.medium);
String strong = getString(R.string.strong);
SpinnerUtil.createNewSpinner(view, R.id.wind, Arrays.asList(none, light, medium, strong), WindLevel.values(),
new SpinnerItemSelectedListener<WindLevel>() {
public void onItemSelected(Spinner item, WindLevel value) {
// Take whatever action you wish to here.
}});

I would just use ArrayAdapter<WindLevel>. Yes, you created a custom typed listener, but the regular event listener gets the position and can call getItem() on the ArrayAdapter<WindLevel> to get a WindLevel properly typed.
IMHO, the vast majority of Spinner widgets will be populated with material read in from a database, the Internet, or some other dynamic data source, rather than populated by some sort of enum with display values coming from static strings that can be internationalized ahead of time.
This is not to say that your code is useless: if you find it useful, then it was worth writing. And I am sure that there are apps out there that contain your targeted pattern (i.e., a Spinner backed by an enum or equivalent where the display values are known in advance and can be internationalized) who might find your solution useful as well. Every developer who writes enough code cooks up these sorts of helper classes and the like that help map an OS or framework model into something that better fits the developer's own mental model. So long as you are not perceiving any performance issues, it's all good.
Also, note that OnItemSelectedListener is an interface; implementing that interface on an existing class is not inheritance.

I believe the reason nobody answered you is :
What problem are you trying to solve ? Spinners existed prior to your well designed attempt.
Why reinvent them in exactly the same way they exist in Android ?
http://developer.android.com/guide/topics/ui/controls/spinner.html
It is a beautiful wheel indeed you designed, but still, it is just a wheel :)
UPDATE :
I think I begin to understand what you did. This is interesting. I'm not sure why you did not go to the pattern implemented by the ListPreference with its entries and entryvalues.
In fact, I'm not sure I understand why the Android team did not go that route either.
In any case, it is worth proposing your idea to the Android framework. It is after all open source.