I have couple of different users on my app. There are certain keywords associated with these users based on their selections and I want to make them such that, user1's kselected keywords are not displayed for user 2 when he logs on the same device.
Here's the basic code :
Boolean firstuserlogin= Sharedpreferences.getinstance().firstlogin;
Boolean sameuserlogin = !Sharedpreferences.getinstance().differentuser;
Boolean differentuserlogin = Sharedpreferences.getinstance().differentuser;
if(firstuserlogin && differentuserlogin) {
//Please note: firsttime user is also considered a new/different user
m_keyword = Sharedpreferences.getinstance().getkeyword1();
}else if(sameuserlogin){
m_keyword = Sharedpreferences.getinstance().getkeyword1();
}else if(differentuser){
m_keyword = Sharedpreferences.getinstance().getkeyword2();
}else{
m_keyword = Sharedpreferences.getinstance().getkeyword1();
}
The issue is I am not able to get it to work as expected.Theoretically: Say a user 1 logs in ,he's considered first user and at the same time a new/different user, until he logs out.His keyword settings which he selects during his session are saved as expected. Now, Say he logs out and logs in again , he should be able to see his keyword settings and be considered as the "sameuser" since he logged in before, unless some other user with a different id logs in on the same device, in which case, it should show all new default keyword(which is lets say keyword2 in this case ) and should not show the previous users selections.Currently based on the above logic I implemented it seems to go haywire, sometimes it works, and sometimes it doesnt recognize the user as a different user, but same user AND VICE VERSA. is there a better and compact way I can restrict and implement this logic?
Thanks!
Well, if you insist on using shared preferences, you can use a unique key(email,username,userId anything) and merge it with the keyword and save to share preferences. You will need a special character to seperate the unique key and keyword (somekind of key-value pair)
for example if we use id as uniqkey and ## as token character. keywordA for the keyword you should save as "userid1##keywordA) and read it back from preferences. After you get it. You should split it via ##.
But for such operations shared preferences is not the best place, you should use a database since you have multiple users. Android supports sqlite database built in. You can see a tutorial here
Good luck
Related
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!
Just as a precurser to the question, I am moderately new to Java, so please bear with me.
I am right now attempting to create an account system, and it seems that automating the account ID process is more difficult than previously thought. I want to be able to have customized user IDs for each individual object reference, so it's easy to access, count how many users there are, edit values in the object, etc.
I basically want:
int accountsMade=1;
userAccount (A1) = new userAccount(other Input);
And then the next time a user registers an account, the object reference will be:
userAccount (A2) = new userAccount(Different input);
Is there any way to automate this system? It seems as if there is, but I can't figure it out.
What you'd want to do is create and keep reference to a HashMap object. These are key-value pairs, in which providing a key (in this case, the user ID provided by the user) allows you to get the value (in this case, the user account object) in a very quick and efficient fashion.
The actual signature of the HashMap you'd want to use would be Map.
Here's the current documentation on HashMap: http://docs.oracle.com/javase/7/docs/api/java/util/HashMap.html.
However, I think there's a pretty significant issue with the design you're building right now, and that's that you're constructing a new userAccount object each time you get input. The concept of an account suggests some sort of continuity - saved data, passwords, etc. Right? GMail doesn't make a new account for you every time you sign in.
So, you're going to need somewhere to keep that data, somehow. You could either use an external database, like SQL, or, if you're 100% sure that your use cases and userbase will never, ever, change, you could just hardcode account objects into your prototype and check user login attempts against the keys in the HashMap. Either way, I'm not sure it'll work for your purposes to be constructing a userAccount object upon user login.
What i want todo with Java and Javascript:
If a user try to register an Account, after he write the Login name and klick in the next field, there should be an immediately check, if the Login Name already exist.
My Question is now, what is the best performance way.
I know, how i can check the username in the database, that is no Problem.
But is it possible to cache the List of users in a Application wide variable ?
If yes, how or where should i create a such variable ? I use tomcat as server.
But no idea how i can do that.
Or is it just fine, todo a check on the DB Server.
I want something similar like the Registration from hotmail
Thanks
Two ways to do it (and not thinking very hard). First - before loading the page, on the server side retrieve all user names, put the in a list and put the list in the request. Now you have all your user in the page and can check if the entered name exists (must do it in javascript). The second method - after typing the name make an ajax call to the server and check in DB if exists. Hope this helps.
It's not a good idea to cache all login names. First because at every http session, you need to refresh the whole cache. Second because it's possible to have multiple http sessions (multiple user trying to create an account) and you need to refresh the whole cache to verify new registrations login names. Third it's not a good practice to store temporary the whole user names table in such a variables.. imagine you have 10000000 login names!
With a cache, if two users want to register at the same time, and enters the same user login, both user login pass the validation!
Just query your database with an ajax request or a servlet and make sure your login name column has an index!
I would like to get some advice on designing a count based access control. For example I want to restrict the number of users that a customer can create in my system based on their account. So by default a customer can create 2 users but if the upgrade their account they get to create 5 users and so on.
There are a few more features that I need to restrict on a similar basis.
The application follows a generic model so every feature exposed has a backing table and we have a class which handles the CRUD operation on that table. Also the application runs on multiple nodes and has a distributed cache.
The approach that I am taking to implement this is as follows
- I have a new table which captures the functionality to control and the allowed limit (stored per customer).
- I intercept the create method for all tables and check if the table in question needs to have access control applied. If so I fetch the count of created entities and compare against the limit to decide if I should allow the creation or not.
- I am using the database to handle synchronization in case of concurrent requests. So after the create method is called I update the table using the following where clause
where ( count_column + 1 ) = #countInMemory#
. i.e. the update will succeed only if the value stored in the DB + 1 = value in memory. This will ensure that even if two threads attempt a create at the same time, only one of them will be able to successfully update. The thread that successfully updates wins and the other one is rolled back. This way I do not need to synchronize any code in the application.
I would like to know if there is any other / better way of doing this. My application runs on Oracle and MySQL DB.
Thanks for the help.
When you roll back, do you retry (after fetching the new user count) or do you fail? I recommend the former, assuming that the new fetched user count would permit another user.
I've dealt with a similar system recently, and a few things to consider: do you want CustomerA to be able to transfer their users to CustomerB? (This assumes that customers are not independent, for example in our system CustomerA might be an IT manager and CustomerB might be an accounting manager working for the same company, and when one of CustomerA's employees moves to accounting he wants this to be reflected by CustomerB's account.) What happens to a customer's users when the customer is deleted? (In our case another customer/manager would need to adopt them, or else they would be deleted.) How are you storing the customer's user limit - in a separate table (e.g. a customer has type "Level2," and the customer-type table says that "Level2" customers can create 5 users), or in the customer's row (which is more error prone, but would also allow a per-customer override on their max user count), or a combination (a customer has a type column that says they can have 5 users, and an override column that says they can have an additional 3 users)?
But that's beside the point. Your DB synchronization is fine.
Is it a bad practice to expose DB internal IDs in URLs?
For example, suppose I have a users table with some IDs (primary key) for each row. Would exposing the URL myapp.com/accountInfo.html?userId=5, where 5 is an actual primary key, be considered a "bad thing" and why?
Also assume that we properly defend against SQL injections.
I am mostly interested in answers related to the Java web technology stack (hence the java tag), but general answers will also be very helpful.
Thanks.
That bases on the way you parse the URL. If you allow blind SQL injections that is bad. You have to only to validate the id from the user input.
Stackexchange also puts the id of the row into the URL as you can see in your address bar. The trick is to parse the part and get did of all possible SQL. The simples way is to check that the id is a number.
It isn't a bad thing to pass through in the URL, as it doesn't mean much to the end user - its only bad if you rely on that value in the running of your application. For example, you don't want the user to notice that userId=5 and change it to userID=10 to display the account of another person.
It would be much safer to store this information in a session on the server. For example, when the user logs in, their userID value is stored in the session on the server, and you use this value whenever you query the database. If you do it this way, there usually wouldn't be any need to pass through the userID in the URL, however it wouldn't hurt because it isn't used by your DB-querying code.
To use the database ID in URLs is good, because this ID should never change in an objects (db rows) life. Thus the URL is durable - the most important aspect of an URL. See also Cool URIs don't change.
Yes it is a bad thing. You are exposing implementation detail. How bad? That depends. It forces you to do unneeded checks of the user input. If other applications start depending on it, you are no longer free to change the database scheme.
PKs are meant for the system.
To the user, it may represent a different meaning:
For e.g.
Let's consider following links. Using primary-key,it displays an item under products productA, productB,productC;
(A)http://blahblahsite.com/browse/productA/111 (pkey)
(B)http://blahblahsite.com/browse/productB/112 (pkey)
(C)http://blahblahsite.com/browse/productC/113 (pkey)
User on link B may feel there are 112 items under ProductB, which is misleading.
Also it will cause problem while merging tables since PK will be auto-incremented.