Our Action has worked as expected for years on iPhone, but something changed and now access is blocked for our customers.
How to reproduce the issue: Simply go to Assistant on iPhone and say "Hey Google, talk to the mobile concierge" (our Action). Instead of launching the Action, Assistant says "I need permission before I can use your personal info for anything. To change your settings, just open the Google Home app on your phone. Once that's done, ask me again!".
My question: Can Google confirm that this is a bug and not expected behavior? (Specifically, that a user must have 'Personal Results' turned on in order to access an Action on iPhone.)
I truly hope this is not expected behavior, but even if it is there are 2 issues:
instructions that are provided to users when Personal Results are turned off are wrong. Pointing users to the Google Home app is incorrect. Many iPhone users won't even have the Google Home app installed. But if you do have it installed, launching it and then following Assistant's directions does not lead to being able to open the Action. The correct instructions are to stay in the Google Assistant app, click on your profile pic, go to Devices, and then select your iphone. There, you can turn Personal Results on/off.
The additional problem is that upon testing, I already had Personal Results turned ON. In order to get access to our Action, I had to turn it off, and then turn it back on again. So this pretty clearly seems like a bug.
As an aside, we don't collect any personal information as part of our Action so I am unclear why Google implemented a change involving the Personal Results option as it relates to the ability to launch Actions like ours. All it has done is made it so that our customers can't use it from a huge percentage of phones out there (iPhones), and phones are the only device we are targeting for use with this Action.
Related
I have a device which I want to control with Google Home.
Device also can be controlled via mobile app.
It will be a commercial device so many users have different devices and, of course, I can recognise them in my mobile app.
I read documentation about Action and Home Graph, but it is still not clear how I can integrate my device/app with google home in the same way as, for example, Hue is integrated.
I could not find where I can "register" my device/app with google so it will be shown in supported devices.
What I want to achieve is the following:
User gets device, installs the app, connects it device to the app. <- this already works.
Then user goes to google home integrations, selects my platform and he is ready to go.
Maybe someone can push me to the right direction where to start?
The smart home documentation provides the content to help you get started, along with several codelabs to learn about the webhook fomat.
When you are developing your action, through the Actions Console, you will be able to see your service in the full service list as "[test] Your project name". Once your integration is ready, you submit it to be published in the full list of services.
This is the first time I upload an app to apple app store. After weeks for reviewing, finally, I get my app listed on apple app store. But the problem is, now seems like my app app-store page is only viewable from iTunes. When I try to open it in a browser, it will shows "Connecting to the iTunes Store...". Why is it my app can't be the view from the browser? Why did another app can? How to fix it?
Short answer: It seems, you cannot fully predict the behavior of an app store link for a certain user. You being redirected doesn't mean other people will be redirected right away as well. Your app's country/language availability, users' app store region and language settings, the specificity of the app store link (which has optional components and alternative styles), and the browser cache all seem to have a say.
Added details: After experimenting with this a lot, it seems to me that the behavior of the link (or rather the response from the Apple server to requesting it) depends on the language/country version being requested, my own current country/language defined in iTunes/my app store account, plus some caching issues. So, whether a preview page is shown in the browser, or iTunes is attempted to be opened right away depends on several factors and doesn't always have the same result (for different users). In fact, two consecutive attempts to open the same URL can have different redirect behavior.
I noticed that a full app store link like https://itunes.apple.com/us/app/keynote/id361285480 more likely leads to the preview web page, if the app is available in the language/country referenced ("us" in the example) and there is no prior request cached in which I clicked through to the app in iTunes. If the app isn't available in the referenced location, or any other information is missing in the link for the Apple server to identify a particular language version on the preview website, or there is cached data that makes Apple confident enough to redirect you to iTunes directly (or it's Friday 13th and the moon is right behind the sun by pure chance...) then you may see a redirect instead.
For posting app store links in the likes of Facebook, Apple's app linker seems to produce URLs with the nicest preview snippets (and not: "Connecting to the iTunes store"), when putting in the right country. So, these generated URLs seem to be most complete/specific.
If your app is intended for a specific region, AppStore connect will still give you a URL with .../us/... in it. Changing it to the respective local region seems to fix the problem for me.
For an example,
given URL: https://apps.apple.com/us/app/yourcompany/id123456
If the app is for Norway region, change the URL to: https://apps.apple.com/no/app/yourcompany/id123456
Is is possible to dynamically figure out the position of an app's icon on the home screen of an iphone/ipad?
Sorry I don't have enough credit to comment yet so I'm posting here.
To my knowledge no you cannot natively or easily do this. I know of no open source or other libraries. The reason being that your app exists in its own world, it is not in touch per say with the rest of the device. It can get permissions to read and write data but it doesn't know of itself.
Does that make sense?
When you open a website it cannot know which tab it is in the browser. Instead it knows how it was accessed and what device (physically) is using it. It knows the user-agent, the time, the browser, etc because that is information sent to it in the request. In turn the phone on launch gives data to the app in how to handle it but not for example how many other apps are running, or where it is on the screen. It's not normally considered relevant to run time. In addition it's a security feature in preventing an app from deleting or altering other apps, as well as itself. If you have an iPhone you will notice that SIRI cannot turn off google maps navigation or any other non-apple specific app. Only apps natively comparable and private party ones (ex apples) are accessible because Apple did that intentionally. They all know of their own existence and each others. However non-native in the sense of apps that do not come preinstalled and manufactured by the company creating the device are less trustworthy, in addition there are no guarantees about how they will be run by the device, where they will be, or what other apps will be there.
It is true that an app can request for another app it may be comparable with but it is up the user to handle that information.
May I ask for curiosities sake why you are trying to do this? Are there any other workarounds?
However in terms of it being physically possible, yes. I doubt that apple allows independent developers to do this however. But an example of this occurring may be gridlock where a user can move their apps around differently on the screen. The app in this case has the ability to access app position. But I believe in this case app position is about the UI and not about nested files. apps cannot to my knowledge modify information outside of their own file. Imagine if you had an app that could edit other games scores.
It is not possible to dynamically find out the position of an app's icon on the Home Screen (even for jailbreak apps). Apple wants you to respect the user's privacy settings.
Extra Info - There is popular JavaScript library that adds a promo bubble to the bottom of your mobile web application, inviting users to bookmark the app to their device's home screen.
I created a router that connects to facebook to get some info before a user may access the internet.
First they connect, get the Captive Portal Page and then continue to a facebook login. Since the upgrade to iOS7 it fails to load the facebook login page. On my mac with the Captive Portal Assistant it has no problems and even on the phone itself while using the iOS version of safari there are no problems.
What is going wrong here? Is facebook filtering request from the iOS7 Captive Portal Assistant or is Apple doing some sneaky stuff here?
It seems the problem is widespread and only related to facebook.
Update: I worked with the beta's and they worked fine a few weeks ago. Now with the same beta version it doesn't anymore. So another point for the facebook explaination.
Regards, Cas
This problem was fixed by Apple since IOS 8. But as all iPhone 4 users can't upgrade to IOS 8 this problem is still one.
The IOS 7 devices check for the following domains:
www.appleiphonecell.com
captive.apple.com
captive.apple.com
www.apple.com
www.itools.info
www.ibook.info
www.airport.us
www.thinkdifferent.us
Whitelisting this domains stops the login mask to be appearing as the IOS device thinks, that the internet is working as expected. This way you have control on the things which happens, as the IOS device does not interrupts anything, if you use a normal browser for login.
If you don't whitelist the domains, the following thing happens. I debugged it on routers with several IOS devices and they all did mostly the same:
If you connect to a wifi, the IOS device tries to connect to one of the domains, which are listed above. If it can contact one of the domains, it tries another one. If it can't, it starts the redirect, which is controlled by the router. Sometimes it query one or more domains, before it thinks, that the internet is working.
After the check, the login screen redirects to your router and then to the login screen of your captive portal. This behavior stayed the same as it was on IOS 6 or before.
Now you start an oauth login to a 3rd party provider like Facebook, Google or Twitter. And now the difference appears. You can check it on a router, if you run it in debug mode. As the IOS device goes to an other domain for oauth login (like www.facebook.com) the iPhone thinks, that something changed and starts to query one of the apple domains, which are listed above. The user sees only a white screen and in the background the IOS device tries to contact one of the domains repeatedly. For the user this seems to be an error, as the screen stays white or takes very long to show the login on the 3rd party provider. Sometimes it stops loading and nothing happens forever.
To avoid this behavior, you must whitelist the above listed domains. This is a not a common behavior for IOS users, but this way, your browser have the control of the login session and the IOS device don't interrupt it as it does with the login screen.
Some shallow parts of information is reported on the following sites:
https://supportforums.cisco.com/docs/DOC-36523
http://www.cadincweb.com/why-your-apple-ios-7-device-wont-connect-to-the-wifi-network
https://discussions.apple.com/thread/5355766
I couldn't find a detailed description of the problem and found the one above myself by debugging all parts with some routers and IOS devices like iPhones and iPads.
I've just tested various router settings and noticed that iOS 7 is NOT trying to contact above mentioned sites/URLs when router's DOMAIN field is blank.
My guess is that blank domain points to a consumer-type network set up and Apple is not expecting a Captive Portal at such network. If you have access to administer your router see if you can clear out the DOMAIN field (and restart/retest).
I found my solution to my problem. (a while ago, but I found this post again)
First I found out, iOS makes 3 calls, first to check, second to get the page that needs to be displayed, third to check again after the pageload. Then I discovered, for every POST or GET action made by the page, regarding of the source page was refreshed, iOS checks for an active internet connection. Since the facebook api makes a lot of calls, the browser starts stalling(possible in combination with QoS on my router) and freezes the page.
My Solution:
Since I am in control of the DNS records of the Router I use, I redirected all domains towards my own server.
First I saved the check request, this to later identify the user when he comes back for the 3th request.
When the second request comes I just display an info window that every thing is right, and the user has to click the "Done" button.
The page is loaded, so iOS checks again, but i recognize the user so I display the OK-code Apple also displays. The "Done" button us show, and the user has "internet", according to iOS..
On the page that I display, I instruct the user to open the webbrowser. When he does, he opens a page and my portal with the right page is shown(I can detect this based on the Browser Agent). Then my facebook api start doing its job, and of we go :-)
Let me know if someone needs some more info on how to detect or maybe even a code sample if necessary.
Extra Information
To capture a user on your own server, redirect every request to your processing page using for example .htaccess. The request is made to a domain with a subfile e.g:
http://captive.apple.com/getrT09Nx7G/YNrnUOulnDj/3cfrq3M40iR.html
To keep multiple users apart, use the unique url the device tries to contact when checking for internet, in this case: /getYT09Nx7G/YN1nUOulnDj/3cfMq3M40iR.html
My company has an app (iOS and Android), to which the following scenarios applies. I'm trying to help point my engineers and product team in the right direction.
When one of our users clicks on a content link from one of our emails, or Tweets or Facebook posts, and they're on their mobile device, we prompt the user with a link to download our app. This is similar to what many apps do, including LinkedIn (see i.stack.imgur.com/glSgJ.png).
I imagine this is mildly effective of driving awareness and downloads of a native app, for new users who came in from social media and various web sources. However, it is not helpful at all for a user like me who already has the app!
1) clicking "No Thanks" keeps me on the mobile web (when I want to be in the native app), and
2) clicking "Download the App" takes me to iTunes App Store page for an app I already own.
SUPER ANNOYING. As a result, I have to manually open the app, and search for the content in question. I'm guessing most users don't do this. More importantly, depending on the UI/UX of the app, I may never get there!
Again, I know we are handling mobile web visits in the same way many other companies (including LinkedIn) do, but it seems we are leaving a lot of potential native app use on the table. I want our engineers to build that elusive 3rd option, "Open In App".
Spotify and Rdio have solved this very nicely. Here are deep content links (in the case of these companies, to a specific song) for the two apps respectively:
http://open.spotify.com/track/2SldBUTJSK6xz43i8DZ5r2
http://rd.io/x/QF3NK0JKWmk
If you have a moment, first grab the free version of Rdio or Spotify apps. Then, if you open those links above from an iOS device, you will see how nice the experience is, for existing native app users: Rdio has a nice "Tap to open in Rdio" link (http://i.stack.imgur.com/B7PuE.png), and Spotify's link is even more clear, "I have Spotify" (http://i.stack.imgur.com/Q3IV6.png). Both apps also include a link to download the app, for new app users. More importantly, both apps cookie the user: future visits to links (whether from email, Twitter, Facebook, etc) on mobile web automatically open the app, instead of prompting you to choose each time. SUPER CONVENIENT.
Questions:
1) How do they accomplish this? I'm initially only concerned about iOS (on which I tested this), but this same situation should apply to Android.
2) Why aren't more apps doing this? It doesn't seem like rocket science, so am I missing a key reason why this might be a bad idea? Half of my problem is convincing the use case.
3) Why don't I see discussions about this technique? I've searched a ton for an iOS solution. I come up with a lot of discussion about URL registrations (mainly app-to-app), but no one actually referring to the type of scenario I describe (mobile web prompt to open native app).
It seems that with minimal engineering, app developers could dramatically increase native app use, converting from mobile web. :)
Android supports deep linking. Please refer to
http://developer.android.com/training/app-indexing/deep-linking.html
Tapstream's deferred deep links can send users to specific views within apps (iOS only), even when the app isn't yet installed on their device.