Develop Reference

what's the difference between #Mockk and mockk<*>()?

In this Q&A, it says there's no difference. And some people says annotation is better or using constructor(mockk<*>()) is better.
For me, if they are equivalent, less line of code(not using annotation) is better.
Many sample code shows #MockK is used for the values that pass to Class such as ViewModel/Activity or Fragment. On the other hand, mockk<*>() is used for the classes that have its behaviour or data class, etc
There must be some differences since one is annotation and the other is using constructor. And there must be some reasons why each of them are created, not only one of them.
If you know this, could you please answer it?

Why android made View a base class but not an interface?

Recently I was thinking about View hierarchy in android and I faced with question in my mind, why Android SDK have base class View, but not, for example, interface View and base class BaseView.
As I know similar situation we have, for example, for Collections in Java. We have interface List and abstract class AbstractList, which implements it. Thus, we can provide on the one side a common logic for all 'sub'-views and on the other side common interface for, for example, mocking it in testing or something like that.
But instead of that, we need to use in tests emulator to retrieve some context, that we will pass to constructor of our 'stub' view, or for example mock context somehow (using robolectric, or try to mock yourself).
Moreover, I think it would be better to have sub-interfaces for TextView, EditText, or something like that. So, for example, if you have to implement your own CustomView class, you would need to create an interface CustomView and it's implementor. Something like: class MyCustomView extends BaseView implements CustomView and if it is needed interface CustomView extends View. I think, besides it askes from your side to write more code, It could make development process more flexible. For example, as I said for tests or for providing recently popular MVP (in other words to provide more loose coupling for components).
I don't know, maybe I missed something, and this approach is bad in Android, so could you, please, explain me why it is bad, or maybe share your thoughts about how it could be, or maybe current approach is just more simple, or we need to restrict developer from creating custom implementations of View interface (for example there is have to be a context reference in view, or something like that), or it's not bad approach, but because of backward compatability we need to use old way?
I will glad to hear your advize or thoughts. Thank you.

Is it good practice to write Intent dispatching as static methods in the class to be launched?

I'm just starting Android development, so I'd like a little advice on code style. It seems nice to me to write Intent dispatchers in methods that are doing the dispatching, like
// in case it's not clear, names are meta-variables
public class MyService...
...
public static void sendMessage(Context ctx, MyArgClass myArg) {
Intent sendIntent = new Intent(ctx, MyService.class);
sendIntent.setAction("send message");
sendIntent.putExtra("my_arg", myArg);
ctx.startService(sendIntent);
}
}
then, any callees just run MyService.sendMessage(ctx, arg), instead of having the Intent creation code in their bodies.
It seems like a win: there's less stuff to remember when you want to e.g. sendMessage, and you don't have to synchronize names, like "send message" and "my_arg" across modules. However, I don't see it that often in Google's music app that they've open sourced, so I'm wondering if there are downsides, and I should stick to convention.

It is good practice. This pattern can be found in android developer guides (sample)

Please allow me to answer your question in a more general context, ie programming approach static vs singletin, since these are the alternatives I would consider.
I found that using static solutions for global access to methods, constants, etc.. seems to be a matter of taste.
One commonly used alternative is a singeton approach where you create only one instance of an obejct and use this to access your method. So also in your case you could use a sigleton instead - I have not looked at the Google code you referring to, but I wouldn't be surprised to see a singelton pattern instead.
You may find several discussions on that - but in general singletons allow you to reuse code and control object state much easier than static. The main difference is that singletons can implement interfaces, so you can pass them around.
However, in cases where I just need easy access to some utility methods I prefer static solutions - since they are easier and faster to implement and use IMHO.

This is like having a Utility method to take care of this.
In the example code for GCM from Android, they have done a similar thing.

How to reuse a single class within multiple projects, with minor modifications in functionality?

I have a common library where I've put classes that are used between multiple Android projects. However, now I encountered a situation where I have to make minor changes to the functionality of the class in one project. How should I organize the classes, keeping in mind easy readability of code and future extension possibilities?
Should I
Extend the class (MyClass) with modifications that are special to the subproject (MyClassSub extends MyClass)? What about if I have references to MyClass in the library classes, but in this special subproject MyClassSub should be called?
Have switch OR if clauses for each special part in the class file? And then pass some variable to the class?
Some other option?
This is probably a trivial question, but I am quite new to java and can't quite figure it out.

Definately 1.
Create a library (jar) containing the base class, and then use that jar in the projects that need its base functionality. Each project should provide the specialized class that extends the base.

If the new functionality is specific to the one project, I would avoid putting the functionality in the library. Go with a subclass or a replacement class. If later you find that this extended behavior is more widely usable, you can migrate it to the library (perhaps creating an entire new version of the library, much in the same way that the Java API evolves.)

Unfortunately the answer is "it depends."
Specifically, a class hierarchy should be designed such that the behavior of the base class holds for all subclasses of the class. One way to look at this is to say that the subclass may expand the behavior of the base class. The corollary is that a subclass should not restrict the behavior of the base class. So a Square IS NOT A Rectangle.
Also consider "favor composition over inheritance" unless the base class is specifically designed for inheritance, as a change to the base class might BREAK the subclass.
Have fun!

Android: How to best pass data to a view?

I have a view that displays all the levels of my game. These levels are read by the activity and then passed into the view. I could read them from the view, but it's not really its responsibility, and I'm a fan of separation of concerns.
Right now, I'm calling a setter for this:
((GameView) findViewById(R.id.game)).setLevels(loadLevels());
However, I don't like the fact that the view will be dysfunctional if I forget to call the setter. Is there a better way to pass the levels in?

It is also a bit a matter of preference. Theoretically it's perfectly fine to pass the levels as you're doing. Alternatively, if you need more than just set the levels, but provide further functionalities (i.e. also saving of levels) I normally use a separate class responsible for handling such things (i.e. a Repository, some "Manager" class etc...). This class is then passed into the View on the constructor preferably s.t. one is forced to provide it. Of course, in order to separate things, I use interfaces rather than specific implementations s.t. it may then look as follows:
public class MyView {
public MyView(ILevelLoader levelLoader){
this.levelLoader = levelLoader;
}
...
}
Often, this may not work, because the view is something instantiated by the framework directly rather than by the application. In such a situation you're forced to do it through an appropriate setter. It is some sort of MVC/MVP pattern.
Just for your interest, you might also want to take a look at IoC containers and dependency injection. Guice provided by Google is a nice framework I've already used on Android.

I hope I didn't miss the point, but here goes:
Generally you have either a function setting something (like the text for a textview), or an attribute you set in the xml.
Take a look over at this answer I got on a question: How to layout a 'grid' of images in the center of the screen
There are some things the custom view needs, but lets take an example: 'numColumns'.
you can set it using setNumColumns (that would be the equivalent of your loadLevels() ? )
you can ignore it, it'll revert to default.
you can set it as an attribute lik so: app:numColumns="3"
You can try to use the attribute or the default in the class to accomplish this.

Make your view an abstract class with an abstract method getLevels()? This way, when you instantiate the class if you forget to pass the levels in your code won't compile.
Whether or not this is better is a matter of taste I guess :)