I am implementing a pure Holo Soundcloud app and I would like to avoid having to authenticate the users as soon as they open the app the first time.
This kind of connection wall puts off a lot of users that simply close the app and never open it again.
Since I need an authenticated user to interact with the Soundcloud API, can I create a 'dummy' account used by all my users until they authenticate ?
This account would be able to consult the list of hot songs and use the player, but unable to share sounds, like a track or do anything else that suppose a real user account (and be presented with the connection screen instead).
Is it something possible with the Soundcloud API or will I encounter a limit (for example on the number of people that can use the account at the same time) ?
You don't need to be authenticated to access much of the API. Only the actions you'd expect, actually: things like getting the current user, their current tracks, editing, favoriting, uploading etc. Getting hot tracks, playing tracks, finding all the tracks and playlists of a user, etc, don't need any authentication.
Related
I have an app that has in-app purchases where users can purchase set of videos and there are ten of these sets. Now, before they do this they have to sign up for this app using their personal e-mail (not necessarily their phone's primary e-mail).
Since they have to log in this app, I was planning that they get the right to open the app and the set of videos they purchased from whatever device they use.
Problem:
After thinking about this and since this app is only directed towards local audience, I am afraid that users will pass their accounts to each other and my customer number will decrease.
Solution I thought about:
I will put a message when the users buy the set of videos that says: "These videos will only be viewed from the device you download it on". Which means I will use certain flags to ensure that an account will download them once. So that if someone is to share an account s/he won't be able to download because they where already downloaded.
Question:
If I do like this then if the user uninstalls this app, s/he will lose all the videos they purchased. Thus, if they install it again, they will have to buy the set of videos again. I am not sure if professional apps let the users have what they purchased back if they reinstalled the app or not.
So, is there a way that I can still use the solution that I thought about and still have my users regain what they bought before they uninstalled the app? Or do you have a completely different suggestion that can solve my problem.
Account sharing is a big topic. Daily business for Netflix and Amazon.
I'm not a big fan of your solution because of all the restrictions. I would suggest following approach:
User signs up in your App
You create a unique ID on the device (GUID - https://developer.android.com/training/articles/user-data-ids)
You store this data on the database plus the GUID on the device
You can now verify that the user has valid access.
I would suggest adding another field like max_guids=2. So that if the user looses the device he can still access his data (yes, this also means 1 single device sharing is possible, therefore you can detect irregularity with login sessions and ban the user).
Sounds better?
Im developing an android application for the first time (no prior experience whit coding....). Mainly the app is going to be used at work as a tool for service technicians. The app is almost ready for field testing, but there is one thing i need the app to do before that. I need the app to force the user to log in every time its opened. This is because some of the info on the app is confidential, and only people that currently works for the company is allowed to have this info. Whit firebase i can then block the users that leave the company, or users that are not verified. Currently the users sign in whit google and they stay signed in until they clear the app data or delete it.
I have looked far and wide for the answer to this, but i have only come across different use of timers.
If anyone has a better solution to this "safety" issue, im open to anything.
If you are using Google Sign-In for authentication, there is no out of the box support for forcing your user to authenticate with Google every time they use your app.
This makes sense, because the user is still authed with Google on your phone. A login system only authenticates the user; it doesn't inherently protect data stored on the device. As long as Google has a valid access token, the user won't have to type a username and password again (and simply clicking "login with Google" again doesn't really provide extra protection here).
If your primary concern is blocking access to users who have left the company, you should be covered if you are using Google Apps for your company. If you disable the user's account, their access tokens should become invalid. Google Apps admins can also manually revoke access to specific apps for specific users.
If you don't use Google Apps (e.g. your users are using #gmail.com accounts or accounts from a domain outside fo your control), you might want to consider implementing a list of users allowed to access the application, and verify the current user has access by checking that list via an API call on launch.
If the goal is really protecting the confidential information in the application, you might want to take an approach similar to Android Pay in which you require your user to set and enter a PIN number to access the application. As an added benefit, you can then use that PIN to encrypt any confidential data you are storing locally.
I will suggest you take a look into shared preferences and every time when the user is back into the app you send them to the login activity.
I have downloaded sdk of oovvoo from here https://github.com/oovoodev/Android-SDK-Sample and integrated video calling successfully.I register app on oovvoo's website and get app-id and token for this.
The problem is I am not getting oovvoo sign up page, so not able to chose user for video call. In this situation all the users adding in the conference. I need a way to implement manage user and user selection for video calling. I have seen- call.http://support.oovoo.com/link/portal/3908/4244/Article/1291/Quick-Start-Guide-for-Android but there is no implementation guidance for developers. Do we need to handle users on our end by the user-id or oovvoo providing this feature on its any sample.
i tried "oovoosdk-android-2.0.0.67" also but still have same issue.
Can any one please tell me how to register multiple test user on oovvoo for video call for a single application.
Please help.
I got the reply from oovvoo support team. For Now they don't have user management section in provided SDK. They send this- "ooVoo SDK doesn't provide today user identity management.
we are going to release in one month chat and signaling functionality and where you will be able to provide user ID and the user will join a call."
This past week I've inundated myself with links and led myself in too many circles to count, so I thought I'd pose the question here. I have an Android app that displays webviews pointing to urls which the user must be signed in with their Google account to see (the backend is built in Google App Engine). Since the end user is likely to be signed into their Google account on their Android anyway, I'd like the sign-in process to be automatic. Currently, on the first webview the user opens up they are presented with the Google sign-in form and a really ugly subsequent page asking "would you like to allow example.appspot.com to use your Google account?"
That process is dreadful for user experience. I've seen precious few resources here and there concerning auto-login, but I'm frankly lost in the sea of almost-what-I-want-but-not-quite to be able to discern the direction I ought to be going.
I read through Nick's tutorial on authenticating an app with App Engine, but just having the token doesn't get me the uniquely-assigned user ID associated with every Google account on the backend. On top of that, prior experience has taught me the hard way that an app's webview session is incongruous with the app's HTTPClient session. So even if I could log in with Nick's method it wouldn't help me sign into the webviews.
Then I came across this tutorial, which actually seems really promising, but so far I haven't been able to adapt his code to work with my own.
I also found this SO link which suggests that all I need to do is pass the auth token (which I could presumably obtain via Nick's method) into every webview I load as a cookie.
And that's about it. They are all rather different approaches, so I'm wondering if any of them are actually what I want. Or, if somewhere out there a reasonably simple approach actually exists. I'd really appreciate it if someone knows of a straightforward answer on this one. Thank you!
For security reasons WebViews do not have access to the phone's cache, cookie store etc, it is instead recommended you use the new Chrome Custom Tabs which can auto log in your users.
Concerning the "would you like to allow example.appspot.com to use your Google account?" screen; this is the standard OAuth process and requires that the User sign in and allow your app to access their account information.
In your 'example.appspot.com' App Engine app, if you are using an API that requires user information, like the Google Calendar API, it is required that you specifically request the User for their approval to access this information.
Once you have their approval, you can then save the access and refresh tokens to make future API calls on their behalf without the need for repeated user consent. You can see how the entire Oauth flow works in the OAuth 2.0 Playground.
Even if you automatically logged your user in, they will still see the approval page requesting for your app to have access to their information. To develop a hack to forcefully approve the access to a User's information on their behalf is a major security violation.
You can take a look at the new Firebase Authentication flow to easily manage your user's Oauth experience in your App Engine application.
I like to implement Refer a Friend functionality in my mobile application (Android and iPhone).
User "A" will refer my mobile contacts via SMS (Referred user "B"). And if "B" install my referred application or the referred content, "A" will earn some reward points.
This is my scenario. Suggest me.
Thanks in advance.
I used Google Analytics Campaign to implement this scenario.
Another way to do this is to generate unique links for all your users, that they can then send out to their contacts.
Let's say User A shares a link with User B. When User B clicks on the link to get your app, rather than immediately redirecting to the App Store, you can make a call to your backend, with the goal being to create a digital fingerprint. Your backend can record the digital fingerprint then do a 301, 304 or 307 redirect to the App Store.
To create the digital fingerprint, your backend can then make a browser-based digital fingerprint including:
1. IP address
2. OS
3. OS version
(These can be grabbed from the request headers).
--
Later when the user opens your app, you should send up the same 3 things, IP, OS and OS version. If they match and are close time-wise, you know that they came from this click from User A's link! Then you can give User A a reward and thank him for getting User B to download the app. This is what we do at Branch Metrics, where I work. We also leverage a browser cookie that works across apps, so that we don't need to rely on fingerprinting except for the very first time we see a user in any of our apps.
You should also think about preventing fraud. You should prevent User A from referring himself, you should prevent User A from referring User B over and over, etc. This is something we work on everyday as well. Definitely spend time on fraud prevention unless you really don't care about giving out duplicate rewards to the same user. Please leave a comment if you'd like more info.