Develop Reference

MvvmCross naming conventions for views

Where can i find a detailed list of the naming conventions of MvvmCross?
I came across this Stack-Overflow Thread but the wiki seems to be disabled.
Also, the official documentation isn't in-depth enough.
I recognized some strange behavior, for example, if I add a new layout without any view / viewmodel class, the app will crash at startup. So does it if i do not start a view models name with "view_".
It took a few hours to find out that the MvvmCross seems to do some magic stuff with layouts at the startup depending on their names, even if they aren't used in code or don't have any view models.

Refer to official mvvm cross documentation:
https://www.mvvmcross.com/documentation/getting-started/mvvmcross-overview
One important thing to note, is that by default Views are associated
with ViewModels using a naming convention. But using generic is the
preferred way. On iOS for example, this is what a View class
declaration would look like:
public class MyView : MvxViewController
What other conventions do you have in mind? I found a copy of the missing wiki here https://github.com/rafaelsteil/MvvmCross-Wiki/blob/master/Customising-using-App-and-Setup.md

Android's module with hidden classes

I'm creating a new module in android studio, and I want some of the classes to be hidden to outside of the module, I mean, that the classes could just be used internally in the module, but not externally. Is it possible? How could I achieve that?
Thanks in advance!

EDIT: I doubt it's possible to have module-visibility, but the closest you can use is package-visibility, for which you do the following:
Don't make the classes you intend to hide 'public'. Keep the default visibility, which is only seen within classes of the same package. Other public classes within this same package can act as your external interface to your module.
class PrivateToPackageInModule {
}
public class InterfaceOfModule {
private PrivateToPackageInModule ptpim;
}

For anyone that happens to stumble upon this post, there is now a keyword called internal which offers exactly the functionality that OP was looking for.
Documentation link

Would it be a bad idea to extend Context? Android

Context: "This is an abstract class whose implementation is provided by the Android system"
I was thinking of deriving it to include some handy methods, but I'm not sure what to make of the above line. Any thoughts?

The problem is that things like Activity are indirect subclasses--they won't see your additional functionality.
If your use is isolated and that's okay, then it doesn't matter--just something to be aware of, which sounds like it'd reduce the effectiveness of extending at that level, considering how much stuff extends it.

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 activity naming

I'm running into more and more naming clashes between Android activities and other classes. I was wondering if you could tell me how you avoid these. Sadly, my particular naming problems are not covered in the related questions on SO.
First example
I have an activity that displays a level of the game. However, the data required for that level (background artwork, entities etc.) is stored in a separate class. Naturally, I would call the latter class Level. However, I would call the activity Level as well, because it displays levels.
Second example
I have an activity that plays back a cut scene. It basically displays several images in a row. The information which image is shown for how long is stored in a separate class. As in the previous case, I would naturally call both classes CutScene.
How would you solve these naming issues? Name the activities LevelActivity and CutSceneActivity? Name the representation classes LevelModel and CutSceneModel? Something else?

I solve those problems by either prefixing or postfixing classes with their "type", like you suggested at the end of your question :
LevelActivity, GameActivity, MainActivity, ...
CommentsListAdapter, ...
CheckNewCommentsService, ...
and so on.
But I generally do an execption for the model classes, which are the objects that contain that data : I would still name my Level model class Level, and not LevelModel, to indicate I'm manipulating, and working with, a Level.
Another solution (longer to type ^^) might be to use fully-qualified names (see here) when referencing your classes :
com.something.yourapp.activity.Level
com.something.yourapp.model.Level
With this, you always know which class is really used.

In general the best way to name android application components is to add its "component type" as suffix.
Example :-
LevelActivity (LevelActivity extends Activity)
InboxUpdateService (InboxUpdateService extends Service)
ContactsContentProvider (ContactsContentProvide extends ContentProvider)
SMSBroadcastReceiver (SMSBroadcastReceiver extends BroadcastReceiver)
By naming using above method there will be minimal chances of losing track when you're working on big code flow with lots of similar names in your application.
So, name your Activities with suffix "Activity".
And name the Class which provides Data to your LevelActivity as Level.
In Contradiction to second part of Pascal MARTIN's answer, you can also use LevelActivity and LevelInfo together. Because they offer clear difference as quoted below:
Distinguish names in such a way that the reader knows what the
differences offer
- Robert. C. Martin, author of Clean Code
But the suffix are often redundant on cognitive basis. Using only the word Level clearly emphasises that class Level offers information about Level.
So, use Level for class that provides data about Level.
NOTE : If you're using suffixes, choose one word per concept.
For Example: If you're using the suffix Info to identify classes that offer information then only Info should be used (not Data or Model) throughout your application to avoid confusions.