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.
Related
I'm writting simple music player. There is a fragment in the app, where user can search for tracks. I want to show last 5 (for example) user queries. SharedPreferences only allows to save unordered data. I'm not sure but using SQLite only for 5 strings sounds strange.
What is the best way to save user queries?
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.
I am working on application, my requirements is when i post data as parameters like ID, Value etc using rest webservice and than i get some data as a response like deviceID, VendorID, driverID.
MY application senerio is. when user first time install app he/she can see the screen that enter the above data like ID, Value etc and some response appears that response is basically user configuration like deviceID, VendorID, driverID and has to save. And and than automatically move to the next screen using intent.
Now when user close app and than again open he/she will automatically move to list screen if he/she is login other wise stay on login. NO configuration screen at the, because its setting first time save in app (deviceID, VendorID, driverID).
How to save that configuration data of user first, which one is the best way.
Please give me best solution like in tutorial form and also little bit explenation.
Thanks
It depends a lot on what the "some response" is and how much data do you want to store.
In Android Storage Options:
http://developer.android.com/guide/topics/data/data-storage.html
There's Shared Preferences:
http://developer.android.com/reference/android/content/SharedPreferences.html
http://www.vogella.com/tutorials/AndroidFileBasedPersistence/article.html
How to use SharedPreferences in Android to store, fetch and edit values
Maintaining a database seems to be an optimal way.
You can store, update or over-write the data according to your need. The Id's can be maintained in tables, and further info with each Id can be associated in rows, increasing attributes and relating it with keys.
http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html
http://www.vogella.com/tutorials/AndroidSQLite/article.html
http://www.androidhive.info/2011/11/android-sqlite-database-tutorial/
I am new to android and am trying to develop some basic SMS application. Now, I have two fields one for phone number and other for message, I would like to store these fields in a file and when a user hits the load button I want it to pop back in the respected fields.
I tried using
fos.write (msg.getBytes());(fos = fileoutputstream),
but it does not seem to work.
Now, I have two fields one for phone number and other for message, I would like to store these fields in a file and when a user hits the load button I want it to pop back in the respected fields.
You should use shared preferences for that.
It sounds like it would be worthwhile for you to store it in a datastore-- http://developer.android.com/guide/topics/data/data-storage.html for more info.
It might also be helpful to walk through the Notepad tutorial:
http://developer.android.com/resources/tutorials/notepad/index.html
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.