I'm working on an android cooking app (using java) and the homepage has a recycler view populated with recipes which users can like (similar to FaceBook posts). The like button is a checkbox, what is the best way to save the state of the like checkbox for every recipe, so when the user signs out of the app and sign in again they will not like the same recipe more than one time.
Is using SharedPreference a good idea in this situation?
**im using MySql as a database and firebase is not used.
You could definitely do it using SharedPreferences - but I believe this is more ideally designed for 'preferences' of an application rather than 'application' behaviour state.
You might want to have a look at : https://developer.android.com/topic/libraries/architecture/saving-states?authuser=1
Here you will see some options of how to serialize and persist UI states to memory. I have not actually used something like this before - in the past only using SharedPreferences.
You could of course also create your own storage method, or solution but why bother when ones already exist.
Since you are already using a MySQL database, your application is already grabbing the rows from the DB to show them, so why not add another column called 'checked' which is a boolean type. Then when you get your recipes you get the 'checked' variable, and if it is true, then set your UI state of the checkbox to checked, otherwise false :)
The benefit of this approach is that if your app became 'hybrid' and you wanted a website for it too - the data on the database becomes centralised, meaning your persisted user state is the same on mobile as it is web experience, which is a nice benefit!
Related
My app contains about 8 activities having different Listview's. As the data shown in each activity is constant (cannot be changed by user), what method should I use to save the listview items ?
Should I make a arraylist, sqlite db, or other method.
As the list may be long I want a easy structured method to add data on my PC then shown it on my app.
*Adding data is updating my app with latest list
If you want to add data later on and have it updated on all user phones, you should make an API with a database behind it, where you can send an HTTP request to retrieve data for each list separately.
This way, you can change list content however you want and it will be the same on all devices and you don't have to store it on the phone (maybe only cache it to reduce load on the API). The only bad side is that you need a server and a domain.
May I suggest some simple backends: Flask(Python) or NodeJS (Javascript).
When I make an app, I always wonder when is the best moment to load data from a remote database.
If the app ask for a login screen, then:
Is it better to launch every data from remote DB at his time, and then use them in the app? This way, the app is much faster after the login screen (no more queries needed to retrive some data)
Is it better to load data only when we need to use them (for example, display some data from DB into the app). This way, the login is much faster, but the app can be slower than the first case.
What do you guys think?
It depends on the scenario, but I would go with option 2: First, the user is granted the access and you retrieve the data from your backend when needed.
Imagine a very simple scenario where the user logs in to see a list of products he can work with (add and remove). The solution would consist of 2 screens:
A login screen to manage user access
product list screen to work with products
For me, in a good design each screen has its own resposibility, and each screen should query only the data that it is going to manage.
The login screen responsibility would be only to perform the login and then navigate to the product screen.
The product screen responsibility would be retrieve the products, show them and store them when the user has ended the editings.
If your login screen queries the product data to pass it to the product screen, you are coupling the login screen and the product data.
Anyway, if you have a set of static data that can be used by several screens (for example product categories), you can query them the first time you need them and store them in a cache for further accesses.
Another scenario could be if there can be conectivity problems. In this case the best solution could be to download a set of data that the user can work with, edit them and them upload them to the backend (taking into account the possible concurrency issues).
If you want to logIn your user you have to call the remote DB to authenticate the user. I do not see where you are able to do this without the remote db.
Otherwise you are correct that you should only query the DB if you want to show the data you get.
In my java application, I have a dropdown box which needs to be populated with values from a table games.
There is a separate functionality to add a game. (i:e. an insert in the table games)
The values of the dropdown wont be changing unless someone adds something in the database.
To develop the functionality to populate the dropdown box,
One way is to -
Hit the table everytime a page load happens and fetch the data to populate the dropdown.
Is this an effective way? Can someone suggest me a better alternative design?
You could use a cache... everytime a game is added you simply update your cache.
Implementing a cache is simple.
If inserting data and retrieving it for the dropdown are performed in the same java application, then we might implement a kind of cache for the list of values.
So, we need a structure to store last list of games fetched from database, for example List<Game>, and a flag that is essentially an indicator for the event "someone added row to database".
Each time the page with dropdown is requested, we first check the indicator - if it is true, then we need to reload the list from database and set it back to false, if it is false - we can return the cached list.
Each time user adds entry to database, we set this indicator to true.
Also please be advised of possible concurrency problems when implementing that kind of cache.
I'm making a game of Tetris on android as a project for school and right now im using shared preferences in order to save the current state of the game so that it can be resumed on a later time , i've come to realize that when you store over 100 or so preferences the sharedprefernces object starts working in a strange way , i can save everything but when i try to call the editor to clear (e.clear + e.commit) it wont remove the preferences.
i would appreciate any help regarding this issue
thanks
SharedPreferences are good and lightweight mechanism how to persist data.
But i think for game it's not a win at all. SharedPreferences are usually used for persisting non-structured data for example if you have some application that requires login and when User is logged in successfully you can save this state to SharedPreferences and in next Activities just check it whether User is logged in or not. But in the game you have (i guess for sure) structured data-structures (for instance players and their properties (values) like reached score, loses, wins etc.).
So i suggest you to think about another mechanism for data persisting. Specifically try to think about a possibility to use classic object serializing or and usage of SQLiteDatabase which provide more complex solution how to persist structured data.
A main advantage is that you can persist (serialize) whole objects and then simply deserialize them (and not persist them as specific "chunks" in SharedPreferences). Regarding to SQLite, it provides almost same solution as classic serializing but objects are represented as tables in database.
If you need to remove specific values use this:
SharedPreferences.Editor.remove() followed by commit()
To remove them all SharedPreferences.Editor.clear() followed by a commit()
(references here https://stackoverflow.com/a/3687333/1584654).
However If the values remain limitated, for Shared Preferences should not be an issue.
The notifications I received from Facebook are all like the following:
{"object":"user","entry":[{"uid":"100002366898088","id":"100002366898088","time":1314270539,"changed_fields":["feed"]}]}
I am wondering what does the "id" used for? Shouldn't it be the changed feed's id? Why it always same with the uid?
It is simply stating that the users feed has changed. Sure its redundant in this instance but in other updates you subscribe to it could change.
In certain situations, you can get different IDs in your updates:
I have been using the Realtime Updates API to listen for changes on a Fan Page. To do this, you add your app to the Fan Page and then listen for the object 'user' and field 'feed'.
You get notified about updates to the feed on the Fan Page (in which case you get the id of the Fan Page), but also get notified about updates to your App Owner's feed (in which case you get the Id of the User than owns the app). So you would need to distinguish in this situation, and I guess there may be other similar situations.