I want to show "Welcome Back" popup after auto-signIn process as stated in the following documentation(FAQ part) :
https://developers.google.com/games/services/branding-guidelines
I have tried some methods like reconnecting etc. but it couldn't work. How can I show Welcome popup without signing out the user and showing account selection popup again?
What you are asking does not appear to be possible. According to the documentation at Google Developer
public GamesClient.Builder setShowConnectingPopup (boolean showConnectingPopup)
Sets whether a "connecting" popup should be displayed automatically at the start of the sign-in flow. By default this is enabled.
Note that this call will use the default gravity for the "connecting" popup, which will display the popup at the center of the screen. If you prefer that the popup appear in a different section of the screen, you can use setShowConnectingPopup(boolean, int), and provide a Gravity value.
Parameters
showConnectingPopup Whether or not to show a "connecting" popup at the beginning of the sign-in flow. Default behavior is for this to be true.
Returns
This Builder.
In watching the log output during a reconnect, I can find no discernible difference if performing it after backing out and immediately reconnecting (without logging out the user). Only if the user if forcibly disconnected.
Yet, looking at the flow, and this documentation, and the branding guidelines, the behavior Should be to show the "Welcome" popup as long as the setShowConnectingPopup is set to true.
It would be nice if Bruno (hint hint) or any other Google Play Services could weigh-in on this, as it would appear we are violating the branding guidelines if we DON'T have the "Welcome" on each sign in (even though this is a new requirement as worded by Google, along with some of the other branding stuff)
As far as I can tell my original answer StackOverflow link is still the only way to do this "Every" time, but if a user has multiple accounts, then yes the account selection will popup.
(my tests are on multiple devices, running from 4.1.32 and before.)
Related
A quick search of Apple's Human Interface Guidelines and Developer Library yields an unequivocal guideline:
Users, and not apps, place menu bar extras in the menu bar.
Anecdotal data backs that up: submitting an app where - upon quit of a dock process/main view, the extra is left running - yields a tidy rejection.
Now - I'm a User experience designer (UXD) who typically plays, I mean, works in the mobile and web space. So please pardon my lack of Obj C chops, thanks.
I understand well the guideline and behavior/pattern: apps like Skitch, Wunderlist, Evernote, et al however very clearly leave the extra (often termed HelperApp) running in the menu bar on quit of main app. They all, do offer explicit user toggle of this w/i preferences.
There's no additional Human Interface Guidelines w/ specifics around handling this requirement for user control. Must this be included in onboarding? Dialog at 1st quit? Again: I can speak to best behavior UX wise, but my (very senior) dev wants the mandate - how are others not getting rejected?
Focus: what means of user control is/are mandated to avoid rejection?
Known/given: include in preferences
Other: ???
After hours of searching online and Apple Dev guidelines, I humbly bring this question here. There simply isn't time to play a carnival game of requirements: guess, get rejected, repeat. Thanks in advance.
Do you have a button somewhere in your user interface that adds the menu extra to the menu bar? Or does your app just do it automatically without the user telling it to do so?
I think that's the distinction, your app must only add an extra when instructed to do so. Also if the primary purpose of your app is to create a menu extra (eg, I have one that puts a calendar in the menu bar) then just launching the app is an implicit instruction, so it can be added automatically.
Ultimately, this rule really is vague and can't be clarified. What it comes down to, is that there should not be many menu extras in a user's menu bar unless the user explicitly chooses to have them. So unless your app really needs a menu extra, you must disable it by default.
If you think the reviewer should have allowed your app through then reply to the rejection explaining your position. I've had an app change to approved once after doing that.
If they still reject your app, then you can appeal the app rejection.
Alternatively, just disable the menu extra by default and have a button somewhere to add it to the menu bar.
Also, all of this assumes you are using NSStatusItem and not the "real" menu extra system — which is a private API. Only NSStatusItem menu extras can be placed in the app store as far as I know.
I am implementing a simple webview application with only one url. I have over ridden back button function for webview navigation (which is working fine). Now my app has only one screen with webview and user visits the links inside main url and navigates using back button.
I want to know that, What is Microsoft Certification Policy as my application has only one screen so should it Close when user press back button anytime? Or Microsoft allows implementing of webview with over ridden back button functionality.
If question is still unclear Kindly tell me. I'll explain more but I need to know answer to this question.
Thanks.
You shoulld be fine, I have submitted applications which works like that myself which passed certification.
As long as the application quits when pressing the back button when there is no more "history" for the webbrowser control it shouldn't be a problem because the user still get the experience of moving "backward" in his use and can finally quit the app.
Regarding WebBrowser control and content of the app please consider this requirement:
"Your app and metadata must have distinct, substantial and legitimate content and purpose. Your app must provide functionality other than launching a webpage."
So, the application's sole functionality must not be only to launch a website.
This is not releated to back button but very important thing that need to be considered!
Best regard
I'm currently developing a custom dialog to be displayed via an Authorization Plugin, based upon the Apple example code of "NameAndPassword", which subclasses the SFAuthorizationPluginView (https://developer.apple.com/library/mac/#samplecode/NameAndPassword/Introduction/Intro.html)
From what I understand, this should allow me to provide different types of authorization / authentication, such as, for example, developing facial recognition for authentication. The problem I have is that when my dialog is launched by the authorization services, it is embedded in a parent dialog and there is additional text automatically added that states: -
"Type the name and password of the user in the "(null)" group to allow this".
After many hours searching the web, I have discovered that I can remove the "(null)" group section with an undocumented environment flag of "suggested-user" (https://devforums.apple.com/thread/180052?tstart=0)
...but text still remains prompting for a password.
In testing, I can launch other available plugin dialogs by calling from my mechanism of the rules in /etc/authorization and these dialogs do not appear to be attached to the parent dialog.
Does anyone know what I need to do to prevent the default text being displayed, or even better, how to have my dialog launched, independently from the parent dialog? Is this even possible with inheriting from SFAuthorizationPluginView?
Thanks.
I am developing an app that allows the user to make certain changes to tiles on the Windows 8 start screen. When a change has been made within the app, the user will be shown a "View my changes" button. Clicking the button should bring the user back to the start screen.
I have looked into different ways of closing/suspending the app programmatically (and thus taking the user to the start screen), but I have not found a way to achieve this using WinJS. Throwing an exception closes the app, but this seems like a very dirty workaround. Any suggestions?
I'm assuming you are creating secondary tiles and want to show the users what they look like? #mydogisbox is right in that this kind of functionality has probably been deliberatly excluded.
I'd recommend to just do an in-app 'view changes' of whatever changes to secondary tiles the user might have made. In general, I'd argue that this would be a better user experience because you will keep the user engaged within your application and not be essentially kicking them out of the experience.
We've been having trouble with inconsistent display of the like button comment field on our external sites (i.e. some people see it pop up after clicking the like button, and some people don't). We searched around and made sure that the app id referenced when loading the HTML5 version of the like button code matched the website domain in the app settings (per this thread), and finally determined that the "problem" is the user's security settings: if they have enabled "secure browsing" in their security settings, then they won't see the comment field pop up unless the page is also hosted securely. (only other place I could find this discussed is on this site)
Has anyone figured out a workaround for this? It appears that the iframe version doesn't have this problem (though it does make the user click a link to see the comment field), but it requires 400px of minimum width which busts our layouts. We want to always make the comment field appears after the user clicks the like button, but it isn't feasible for us to host every page on the site securely. Any suggestions?