Is this possible?
Think of the following scenario.
User A logs into device and fires up your app, doesn't like certain features, so turns them off.
Profile is switched to User B. They fire up the app and love all the features that user A didn't like, so they switch them all on.
Is there a way that the profile can be switched back to User A and all the features that user wanted are still switched off? (And on when user B uses the device)........?
The reason I ask is because I'm using local flags to determine if a user has unlocked (Google Play Games) achievements, so if the user reaches the goal, the flag is set like so:
if (!score100_AchievementUnlocked)
if (score>=100){
unlockAchievement(Score100);
score100_AchievementUnlocked=true; //Don't check this any more
}
I'm then saving score100_AchievementUnlocked in sharedPreferences so that we don't keep sending API requests to Google Play Games when we no longer need to.
However, if another user then comes along and plays the game, as things stand, they will never be able to unlock the achievement because the app will never check it (as score100_AchievementUnlocked will be true).
So I'm wondering if I can detect who is the active user on a device and have them use their own sharedPreferences.
You may want to make profile system into your application.
Just concatenate username and every preference to use them as the key for Sharedpreference system.
Then, let the user choose theirs favorite profile to retrieve theirs configuration for the application according to the chosen profile.
Please let me know if you get the idea, hope it help or if you need more information.
Sincerly yours.
Related
I am developing an app, which is soft dependent on what a user does in another app. E.g. my app may allocate a reward to to a user who shares our image on Instagram.
What can be the best way for my app to verify that the user has done this action. Let's say no API is available for me to verify existence of such a post on Instagram.
a) Does android allow one app to programmatically interact with another. To what extent this depends on what the other app allows, vs certain general features of the platform which are always true irrespective of other app's intention of preventing such interaction?
b) Secondly, if I go the brute force way (provided user permits), can I simulate user actions and launch the other app and interact with it on behalf of the user, much like using the Win32 API and simulating a mouse click or keyboard input?
c) Basically, I just want a screen shot of the user showing me the post has been shared. My simplest goal is to verify that the screenshot is indeed from the other app, and not a static image or a fake app looking like the original?
Any guidance or general advice would be greatly appreciated.
Thanks
Asif
I am working with several organizations. They have formed a coalition and have agreed to share apps they have created. The group is trying to implement a set of Android applications that will be used by first responders on shared devices during a high visibility event. The applications are all 3rd party, by various vendors, and since the group does not have time to implement an SSO solution, they are using an app called Keeper to allow the users to store their credentials in a database. This is not an ideal solution, but it’s a time crunch. The biggest issue that they are looking at right now is that, although they can set Keeper to log out of the Keeper app itself after a set amount of time, the applications that the user was logged into will all remain logged in unless the user manually logs out. This means that at shift change, unless the first user manually logs out of all of their apps, the second user will have access to all of their applications.
One of the ideas that they had was to create an external Android script that would allow the user to logout of all applications with a single click. But it seems like this would require access to session ID’s and other information from all of the 3rd party applications. If that were possible, it seems like it would be a scarily large security flaw.
Can anyone shine some light on this for me?
I need to write a application which has login functionality. It needs to have user name and password. Once a user logs in I need to switch to an activity that displays data from a REST API.
However I want to know the right way to implement this. I'm thinking that if I login and switch to the next activity, then the first login activity should no longer be reachable unless user logs out. Also I'm thinking that the data activity should not be exported and login might (?) be exported.
Can anyone suggest the right way to implement this ?
Your suggestion is one way to approach this, but it's a bit "brute force".
Is there a reason that users have to log in each time they use the app? Why don't you store the credentials, at least as an option (that is, provide a "Remember me" option?).
For example, the only way to use the Gmail app is to add your Google account credentials first. Once you've done that, you no longer have to provide your email and password when you look at mail. The Gmail app assumes that you've protected access to your phone.
Remember that, for a mobile device, entering text is tedious and error-prone. On the whole, it's best to do it once and store it securely.
I need to be able to prevent the user from using my app until I allow him. The idea is that the app should be available for download but the user should only see activation screen when he launches it.
Then he has to request an activation key through email and use that key to unlock the app.
Is there a way to achieve something like this in Play Store and is it allowed?
I also don't like this idea but its my client's wish..
Note to moderators: I posted a similar question for the Apple Store but I want to keep both threads separated so please don't consider this as spam.
Google Play does not have such a feature out of the box.
I can however, think of 3 ways you can get it work. I am speaking strictly for the Android platform though.
You can design you app in such a way that the first screen should ask the user to get an Activation Code / Enter an Activation Code.
After the above, you can either store the Activation Code in a Preference File and check the value for its validity and start the application only if it matches / is valid.
Store the Activation Code in a Database and again, check the value and its validity and start the app if it matches / is valid.
Provide a couple of features and integrate Google Play In-app Billing and let the user pay a one-time fee to activate and enable all functions in the app.
These are the things I can think of at the top of my mind. Hope this helps.
No, There's no way to achieve this. You will have to create a functionality within your application.What you can do is make the user enter an activation key, if the activation key is correct make the user go to the next screen else don't let the user.
Thats something you would have to implement in your app. If there is some payment involved in getting the registration key then the solution is clearly against the play store rules.
i use similar system on my application. When user open the app first time. I ask for promotion code if this promoition code is true (i check it from back end service) user can use app for 3 months free. After this period end, app ask user to buy subsciription. You can do it using a backend service with interact a database.
Hiho,
is there a solution to disable my App for one single user?
There is one Person, who buys my app every few days to use the app for calculations, and than deinstalls the app within the 15 Minuts window.
Over 10 times he did it and with the next update i want to create a method, that checks the user mail from market and if its these person, the App should close instantly.
Thanks for Help
Alex
Are you sure this is the same user (and not just a usage trend of one refund every few days)? A user should only be able to refund an app once. According to the App Refund article in Android Market Support:
You have 15 minutes from the time of download to return an application purchased through Android Market for a full refund. You may only return a given application once; if you subsequently purchase the same app again, you may not return it a second time.
EDIT: If it looks like it's the same user, please contact Android Market Support and let them know. Follow the relevant "Contact Us" link at the bottom, and include all relevant information: App name, user's email address, order ID's, etc. Abusing the refund policy like this shouldn't be possible. If it is, they need to know so that hole can be closed :)
you can get the accounts from accountmanager, as I know to do what you want, checking account is the only way I think. you will need GET_ACCOUNTS permission.
Instead of putting in hate code for this single user, I'd suggest you put in a little more effort and put in a more generic check.
Whenever a user signs up, check if the user has already used your application, and if he/she has not, save the user's account information on a backend. Else notify him saying that he/she has already checked the application out and if he/she has some feedback. Try to make the user 'guilty' here!
Building a backend system is pretty simple with a service like stackmob.com. Though for this, you'll need to acquire the GET_ACCOUNTS permission, and for a service like calculator, asking for this permission might seem fishy. So you need to make that call here!
If you do figure out how to identify your user rather than close right away you should do stuff that delays them for 15 minutes.
Make them fill out some forms first (Just for that user), stuff that takes time. Be really specific in the forms with password requirements like 10 chars including upper, lower number and punctuation, then force them to "Log in" using this password (which they won't remember and will have to start over...), but always make it look like each step is the "Last little bit" they will have to do before they can use the app...
Also use a lot of "Contacting server..." and "Calculating" and "Installing" that take time. If you really need to stretch it out, add a few "Retrying" after the connecting message has been there for a while.