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
Related
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?
What is the difference between java.text.Normalizer and android.icu.text.Normalizer2?
I studied this page https://developer.android.com/guide/topics/resources/internationalization, but it doesn't contain required information.
Normalizer2 is an abstract class and is not supposed to be extended for general use.
The Normalizer2 class is not intended for public subclassing.
I did a quick search of AOSP and found mostly internal uses of Normalizer2.
I've been wanting to make the code cleaner, but I do not give it away. I mean...
To name the ids of the views in the XML I use Hungarian notation like this:
<WHAT> <WHERE> <DESCRIPTION> <SIZE>
For example: tvExampleSectionEmptyBig,tvExampleSectionEmptySmall
Previously, using Butter Knife, I did not get too much coding because to do the bindings, I did things like this:
#BindView (R.id.tvExampleSectionEmptyBig) TextView tvEmptyBig;
#BindView (R.id.tvExampleSectionEmptySmall) TextView tvEmptySmall;
The code was much clearer and more reusable since the Hungarian notation used to avoid the confrontation between ids with the same name in different activities, fragments, etc. it was not present in practice more than in XML.
What's going on?
Kotlin has synthetic, which makes your life easier since with putting the id of the view, the binding is done directly, but with such long ids the code is very dirty ... Besides, makes sense that all the views I use in an activity called ExampleSectionActivity, contain within its variable nameExampleSection?
What would I like?
Surely there are better solutions that, but initially, what I feel is to implement a way to rename variables by removing a given String. As I follow a convention in all the names of the ids, it would be something internally in this way:
val tvEmptyBig = tvExampleSectionEmptyBig
val tvEmptySmall = tvExampleSectionEmptySmall
But of course, I would like to do it in an automated way.
On the other hand, I already tried naming the ids without the and to be careful with the imports, but for the moment synthetic fails very occasionally in this respect and I had to rebuild constantly. Especially if I open another instance of Android Studio, which I usually do quite often for consulting other projects I have.
Any idea? :-)
In my opinion, the easies and the most clean thing you can do is this:
private val myTextView: TextView
get() = f_layoyt_text_view
This way you don't have to use ridiculous, at least in 2018, ButterKnife and even more inconvenient findViewById.
For a few weeks, I already take for granted, that with the latest stable updates of Android Studio, there is no problem with repeating names of ids in different activities or fragments. Therefore, it is no longer necessary to put long variable names. Only there is to pay a little bit of attention to the imports, everything works like a charm, more readable and reusable. :-)
I'm writing an Android application in Kotlin.
I also use the Anko view library to replace xml with programmatic view creations.
I'd like to write specs for my views (which are AnkoComponents).
Is there an accepted methodology for doing this?
I can't seem to find any information on specs + anko by googling or looking at the Anko docs.
Specifically, I'd like to test the createView(ui : AnkoContext<T>) method.
More specifically (and what I'm hoping will be answered by asking this question), is how do I mock out an AnkoContext<T> which I can pass to createView in my test?
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.