Develop Reference

Kotlin - var property vs object copy [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
My team has an argument today about var property and object copy. We have an adapter for a RecyclerView. The adapter takes a list of ItemModel, which has a few properties. When any item is clicked, we need to change a property's value of the clicked item.
Some people say we should make the property a var. So, we can assign the new value to it.
Some others say we should make the property val, and use ItemModel.copy and pass the new value to the copy. But to do this, we need to call List.map to create a new list as List is not mutable. This means, to change one property value of one item, we need to loop through the whole list, create a new list with all the items and the new copy of the item that is changed.
In my experiences, the former method looks right to me and the later one does too much unnecessary things and makes bad impact upon performance and resources. But, they were arguing about property mutability and etc. and claimed the later one is a more modern way of programming.
Can anyone with good understanding of android and the functional programming explain for me if the later one really is considered a better way?

It being your recyclerview´s list it should be a mutablelist if the recyclerview should mutate the lists item count effectively (create or delete). val and var on the list does not really matter (in witch case you use val) as you don´t need to reassign the list when you create, update or delete the items. Every single of those operations will not reassign the list object. It´s still the same list, just with different items in it. val and var matters when you want to change value x of item number 3 in the list. Then it (the variable x) has to be var for you to be able to change it, but the list does not.
You use val to indicated that the value will never be changed. It´s for maintainability so weird bugs don´t happen. Like you have another object referencing that list we talked about before. If the list was a var it would be possible to create a new list on the variable and now your two objects no longer point to the same list. Instead one of them still points to the old list. You may not expect that and your program will break. Hence wherever feasible you should be using val. Wherever necessary you should be using var and not complicate your life trying to preserve val unless you have a good reason like this value cannot be changed as it´s referenced all over the place. That's when you use object copy. But not as a default best practice for everything.
That´s just my opinion about it.
On a side note marking a class as a data class will generate the copy method for you. So you can copy that object without even requiring to implement copy. Witch is pretty great!

Setting the property as var is very tempting, however it can lead to errors that could not be even that easy to reproduce. When you are passing around the reference to an object and there are a couple of places where its content is used and could be changed, you might lost control of the actual application state. The code might become unpredictable.
Immutability is the core of the functional programming. It's purpose is to eliminate such vulnerabilities and help programmers write pieces of code that every time execute as expected, because it eliminates the risk of side effects occurrences.
However, as you and your team noticed, the functional approach sometimes may require additional work and resources. But is it worth it? Well, I don't know how large that list should have been to significantly influence the performance by mapping it. And even if currently your objects aren't shared anywhere, you can't be sure that in the future somebody won't change that. So having in mind that the functional approach is less error-prone, I'd say it is worth it.

The second method is contrary to the Basic Design of Kotlin.
With Kotlin you don't Need to write as much lines of Code as in Java, for example the get and set functions which are included in a class. Why do you want to make your Code longer and more complicated in a Language that was designed to shorten the lines of Code?
Another Point is, longer codes can get hard to read and maintain.
The last Point is, that a copy of a class Needs more ressources and time to create and Access than a Var, for me there is no reason why this should be considered as good Approach.

Rename variables to make the XML ids cleaner

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 building a dynamic form in Android using RecyclerView and I need to save the state of the form

First of all I'm not native english speaker so I'm sorry if there is any grammar or spilling mistakes but I'm really trying to do my best here.
OK, I'm developing an application in android system for e-commerce, the user can add any product to sell, but as you know there are many filters questions.
For example if the user want to sell a car he has to select the model and the company of the car, but if he want to sell a mobile then the questions changed to select the storage for example and the model and the company questions will be deleted, so the questions here are dynamic.
I already developed the form using RecyclerView and its look great.
figure1
figure2
figure3
The problem that when I used
notifydatasetchanged
The form data get mixed!
I solved this problem using
notifyItemRangeRemoved and notifyItemRangeInserted
So it's working great, but I still confused why this is happened?
The second problem that is the dynamic form is a fragment called "DynamicFormBuilderFragment" and sometimes I have to replace it with another fragment like "Google Maps fragment" for example the problem that when I call back the "DynamicFormBuilderFragment" all my data is Lost and the form get duplicated!
Like this
figure4
I want to put some codes but really I don't know what to put because they all are too long and complex, but for start I think this problem because I made the RecyclerView.Adapter not static, I will try for now to made it static and see what happens, but I still need your help please.
Thanks for reading and I wish to you a great day and happy coding.
Update
this is my java files and classes
AddAds.class extends ActionBarActivity
DynamicFormBuilderFragment.class extends Fragment // is contain RecyclerView + Adapter + LoadToAdapter + questions classes and it's where dynamic form get build.
GoogleMaps.class extends Fragment

SLOVED!
I Replaced the RecyclerView with the ListView and it's working great now so thanks #greenapps.
I think it's a bug so I will reported to Google.

How to perform Redo Undo operation in EditText

I want to know is there any method or any link or tutorial to perform redo undo operation in Android edittext. If any one knows than please let me know.

Quick note on the Antti-Brax/Divers(Kidinov) solution. It works great, except if you try to use it with a TextView post-API 23, you'll run into problems, because guess-what, Google actually added a hidden UndoManager (android.content.UndoManager) and didn't document it or make it obvious it was there. But if you have a hard/bluetooth keyboard in Marshmallow or Nougat and hit ^Z or SHIFT-^Z, you'll get undo/redo.
The problem comes if you're already using Antti-Brax's class with an EditText, and you also hook it to ^Z and shift-^Z, you'll run into problems with anyone using a hard keyboard. Namely the ^Z will trigger BOTH the native and Antti-Brax's undo, leading to two undos simultaneously, which isn't good. And after a few of them, you'll probably get a Spannable out of bounds crash.
A possible solution I found is to subclass the TextView/TextEdit/whatever and intercept the undo/redo calls from the TextView so they don't run as follows:
#Override
public boolean onTextContextMenuItem(int id) {
int ID_UNDO, ID_REDO;
try {
ID_UNDO = android.R.id.undo;
ID_REDO = android.R.id.redo;
} catch (Resources.NotFoundException e) {
ID_UNDO = 16908338; // 0x1020032
ID_REDO = 16908339; // 0x1020033
}
return !((id == ID_UNDO) || (id == ID_REDO)) && super.onTextContextMenuItem(id);
}
Those magic id numbers were found here, and are used only as a backup if the android.R.id.undo values aren't found. (it also might be reasonable to assume that if the values aren't there the feature isn't there, but anyway...)
This is not the best solution because both undo trackers are still there and both are running in the background. But at least you won't trigger both of them simultaneously with ^Z. It's the best I could think to do until this gets officially documented and the getUndoManager() methods of TextView is no longer hidden...
Why they made a feature you can't turn off (or even know if it was there or not) "live" in released Android I can't say.
I just opened an issue on Android's issue tracker if anyone wants to follow this.

There is an implementation of undo/redo for Android EditText in
http://credentiality-android-scripting.googlecode.com/hg/android/ScriptingLayerForAndroid/src/com/googlecode/android_scripting/activity/ScriptEditor.java
The code works but does not handle configuration changes properly. I am working on a fix and will post here when it is complete.
My Google search was :-
android edittext onTextChanged undo

I know this is an old question, but as there is no accepted answer, and this is an issue I've tackled myself from many angles, I'd like to add my solution in case it helps anyone. My answer is probably most relevant to large (1,000words+) volumes of text editing apps that require this feature.
The simplest way to resolve this problem is to make periodic copies of all text on screen, save it to an array and call setText() every time the Undo method is called. This makes for a reliable system, but it isn't ideal for large (i.e. 1,000words+) text editing apps. This is because it:
Is wasteful. It could be that only one word changes in a two thousand word document, so that's one thousand, nine hundred and ninety nine words needlessly committed to memory.
Can lead to performance issues, as some low-tier hardware struggles with rendering large amounts of text. On some of my test devices, this method can lead to freezes of a few seconds whenever Undo is called.
The solution I currently use is comparatively complex, but I've published the results in a library here.
Essentially, this library saves a copy of text as soon as a user begins typing, and then another copy of text once they've stopped typing for a set amount of time (in my case, two seconds). The two text strings are then compared, and the altered section of text returned, the indexes where the alterations occured, and details on whether or not the change was an addition of new text, a deletion, or a replacement of old text with new text.
The net result is that only the necessary text is saved, and when Undo is called, there is only a local delete(), replace() or insert() call, which makes for much faster operations on large text fields.

Here is the undo/redo implementation that was linked to from Gary Phillips' answer extracted into a reusable and universal undo/redo plugin for any widget that descends from a TextView. I added some code for persisting the undo history.
http://code.google.com/p/android/issues/detail?id=6458#c123
Hope this helps.

To preserve EditText Styling with regards to undo:
You can create an ArrayList<EditText> or ArrayList<String> (String containing html text) to store your last 10 (for example) actions. So ArrayList [0] would contain html text from your first action and ArrayList [9] would contain html text from your very last action. Each time the user taps "undo" in your app, you would apply ArrayList [size()-1] to your EditText and then remove ArrayList [size()-1] from your Array.

Android Patterns: A Spinner where every item launches a different Activity

I'm trying to build a complex form where almost all of the elements are optional. It starts with just a single field and an "add element" button. When you click add, the form shows a Spinner of the types of elements you can add to the form (location, photo, detailed note, timestamp other than "now", etc). When you select an item, it will launch an Activity, and each item has a different associated Activity.
In addition, each choice will have several bits of data, which it would be nice to store "with" the Activity somehow:
An icon and the displayed name in the Spinner
A key for storing the data in the db (as well as passing to a webservice)
A layout for how to display the result on the original form (i.e. a thumbnail for the photo, the lat/lon for the location, etc)
I was considering a set of classes that all extend an abstract FormElement class, and would have static elements for each of the above extra pieces of data. (An additional bump for this solution is how much of a pain Resources are in a static context.)
How can I make this as clean and maintainable as possible? I'd really not enjoy editing five different files to add a new type of element to this form. (Mostly because I can guarantee I'll miss one and spend hours chasing down unbugs.)

A few tips...
Unit tests will prevent "unbugs" :)
When each Activity has obtained the information it needs from the user, call Activity#setResult() with an Intent that contains your per-type data. Intent supports all the Bundle methods, so you can set different types of data as needed.
To support #2, make sure you're using Activity#startActivityForResult(Intent,int) to launch it, and listen for the result in Activity#onActivityResult(int,Intent)
I would probably maintain the list of available "element" types for use with the SpinnerAdapter (e.g., ArrayList<Class<? extends AbstractFormElement>>, and invoke static methods like .getDisplayName(), .getActivityClass(), etc, in the Adapter's getView() method, in order to determine what to display and what Activity to launch.
In this way, your list would actually contain things like { MyPhotoElement.class, MyTextElement.class, MyDateElement.class, ...}).
As each element is added to the form, add it to an ArrayList<AbstractFormElement>, which will be used to back another Adapter for a ListView. That adapter will dispatch the inflation of a custom view layout, as well as the creation of a ViewHolder, based on what type of object it is -- that will require that each distinct AbstractFormElement will have its own "view type", according to the Adapter. See BaseAdapter#getItemViewType(int) and related getViewTypeCount().
It's worth noting that these will need distinct view types only if one cannot be converted to the other... For example, if you have two "Elements" that only need to display a string of text in the list, those can both share a "text-only" view type. Likewise, two elements that only display a photo, or can easily convert one to the other (e.g., an icon with a caption, vs a photo thumbnail with no caption), can share a single "image-plus-caption" view type.
With the above in mind, you actually would end up having to modify different files to add a new type (well, I guess technically you could have them all in one file, as inner classes, but there's really no good argument for doing that), but if you've done your interface API correctly, and follow good OO practices, and implement good unit tests, you'll considerably reduce the amount of effort required to find bugs -- simply because most of the things involved in adding a new type would actually force a compiler error if you do it incorrectly. Add to that the fact that a proper unit test suite will be able to programmatically add all possible types, and ensure that everything displays properly, and you should have a pretty streamlined process for easy extensibility :)
It sounds like a lot of work, and it might seem tedious and verbose at first... But the end result is actually much more maintainable, especially if your list of element types is going to be fairly extensive.