This is a general design question and I'm just trying to wrap my head around the best way to go about it.
Let's say I have a local database. I have a use case to retrieve some information from that database and build a model out of it. This model has things like a minimum, a maximum, and user selected values. I then give this model to my view model, which in turn puts it in a live data object and tells me a fragment to update the UI.
My fragment, then takes this live data object and builds a form with the values, including min and max values, and user entered values. The user then has the ability to change multiple fields (through pickers, date picker), before they click on a save button to save the entire form.
I'm wondering what is the best way to go about updating the data as the user is filling in the form. Originally I thought that as each field is entered, I should be updating my live data object, so that if the screen were to be destroyed or rotated, my UI would be rebuilt off my updated live data object.
However, I've been told that instead I should just keep the values in variables until the user clicks the save button. Then I should update the live data object as well as store that data in the database. In this case, I guess I'd use SaveInstanceState to retain the values that the user had entered.
I know there probably isn't a definite answer, but I'm looking for what is the best practice for a pattern like this. Let me know if you need more information. I've seen lots of MVVM examples with LiveData when data changes in the backend, but not many when there is user input to work with.
Any suggestion will be appreciated. Thanks.
Store the user selection as a databound field in ViewModel class created from a ViewModelProvider using the Activity context. ViewModel instances retrieved this way persist even if the Activity is recreated from an orientation change.
Related
I am new to this site so I am sorry if there are any inaccuracies in this question. I am trying to create a login system using a local database. Previously I did some research on how to make a login system but still have no luck. I am using something like intent.putExtras() (sorry, not sure what the correct word for that is) to store user's details such as username, date of birth etc, so the following activity can receive the data from the previous activity. However, I just figured out that SharedPreferences is used by many people to implement a login system and I am planning on using it as I have an impression that it is more reliable (correct me if I am wrong). However, I have been implementing a login system using intent.putExtras() and never seen anyone implementing a login system that way. To make sure my current way of implementation is reliable, my question is, can I use intent.putExtras() instead of using SharedPreferences?
intent.putExtras(//something) only stores data in Bundle temporarily. You need to store the user info (or if user has logged in) somewhere, to be accessed next time you open the application.
intent.putExtras() are intended to be used, for example, when you want to pass data from one Activity to another.
Locally, sqlite and shared preferences are your only options.
My question is, can I use "intent.putExtras(//something)" instead of using SharedPreferences?
With what you want to achieve, no you can't.
After you edited your question:
If you only want to pass data then you can do so with intent.putExtras(), if you want to store data locally, then you will have to use sqlite or shared preferences.
Working with Firebase for the first time and looking for advice of setting up the right structure for my project which is basically an "offers/coupon" type starter project.
The scenario is this:
I have a node containing a list of all offers available to users
This list of offers is displayed to users after successful Firebase authentication
When a user redeems an offer, I want to be able to count/record that activity in their child node under user and hide that offer so that they cannot see it again once used.
My question is what would be the best way to do this given that offers may be added, may expire, or may change at some point in the future. So, in effect, the user should receive the list of most updated offers, minus the ones he/she have used in the past.
a) would it be more effective to have a master list of offers, and then run a cloud/server function to clone this list for each new user an track that way
Firebase Structure 1
or
b) Keep a master list of offers in one node, then track user specific offer usage
Firebase Structure 2
Appreciate your guidance
The second solution is better because you'll save bandwith. This practice is called denormalization and is a common practice when it comes to Firebase. The first solution is not good becase every time you want to display the users you donwload unnecessary data. If you want to read more details about how you can structure a Firebase database in a efficient way, please read this post, Structuring your Firebase Data correctly for a Complex App. Also, you can take a look a this tutorial, Denormalization is normal with the Firebase Database, for a better understanding.
Second solution is much good. Because in first one we are having redundancy of data in our database. And second one obviously removing that cause.
But instead of using true or false because it is only showing you, "it's available or not", so you can use a string type parameter as "expired", "going to expire" and "updated" or whatever sooo. So it. Will be able to trace all you information related to offer for particular user. I think this is your requirement also.
Happy coding.
So an assignment requires me to only use 2 screens, both for displaying data upon login (which, for now, is done within the app).
I've currently been logging in and grabbing the data in the main startup activity, but would it be better to accomplish this in an Application class? I only need it to login once, and grab data which is a list of planes, from that 'user'. I also need that list of planes for 2 other activities to display data from, so I need a way to access it from everywhere. I've read that putting such objects in an Application class is more trouble than its worth and would just like to know pros/cons or alternate suggestions for this task.
By the current method (login being done in the main activity's onCreate), the login occurs multiple times, which is not ideal.
I am not at liberty to post the code as it is part of an assignment, and there are strict rules about 'helping your peers' should someone come across this, thanks!
I think you can store data in session management in android
after that you use any where in your app if you want that code
ask me i will give you
http://www.androidhive.info/2012/08/android-session-management-using-shared-preferences/?
I have an activity which is a form, there are some radio inputs in this form, each one have dependent activity, for example, there is a button named favorite sports, when the user clicks it, he will open a new activity to see the radio inputs as (football, basketball...), - actually I am not the father of this dummy idea, but the client made it- so I want save to results of all user inputs, I am asking if using sharedPreferences is a good idea, or if there is an alternative way to reach what I need?
You should only use SharedPreferences to store small bits of data related to user configuration/basic user input. It can only store basic data types, so if you have more complex bits of information, you should probably switch to another mechanism.
Also, you should not store large amounts of data in SharedPreferences; it's not made for that. Instead, use an SQLite database for a more robust solution.
I am designing a simple expenses app which keeps track of expenses I do per month. The expenses have a name, amount as well as a category. One can add/delete categories at will. I am storing the categories and expenses in a database.
Right now, the way I am exposing the add categories functionality is by keeping an editText and a button called "Add category" on the "Add Expenses" activity.
So, for a user scenario like when the user does not input anything about the expenses, but just adds the category, I want it to be saved in the database.
The category save can be done immediately in the database by using a AsyncTask to call the database helper to insert a value into the table.
In the mean-time I am confused as to should I put a progressDialog so as to tell the user that I am saving something or let him populate information in the other fields.
What exactly is the UI-pattern or commonly followed strategies while saving partial information of the record into the database. Also, should I just navigate to a different activity, if adding the category into the database produces an error?
Also, a side question, should I put the "Add categories" button in a different Activity than the Add Expenses one?
From http://developer.android.com/guide/practices/design/responsiveness.html:
Potentially long running operations such as... database operations... should be done in a child thread (or in the case of databases operations, via an asynchronous request). However, this does not mean that your main thread should block while waiting for the child thread to complete...
As the original situation of this post was described, a progress dialog is probably not necessary. Perhaps there could be some small visual marker on screen next to the record being saved, indicating it's save state (which might be one of "new", "saving", "saved", "problem/error"). In the case of an error while saving, if it's probably important to the user that the record be saved, then I'd definitely make it very obvious to the user that there was a problem, and provide them with steps to remedy the situation.
Also, note that during at least one recent Google I/O 2011 session (for which videos are available at http://www.youtube.com/googledevelopers), the Android user interface engineers, including the guy that authored the official Twitter app, recommended that blocking UI, such as with progress dialogs, be limited, as their overuse can make for a suboptimal user experience, making the app feel unresponsive and slow to use.