Reply from : https://github.com/google/physical-web/issues/595
For example, I am transmitting www.starbucks.com
http://www.starbucks.com as the URL.
My phone looks for physical web pages and say it detects www.starbucks.com
and shows it to me in my physical web present in my chrome.
As a user, this is how it will appear to me presently
» Now this does not convey much information to me.
» The text "Order while you wait" has been taken from the metadata
description of the page( as far as I know) and the title "Starbucks" *has
been taken from the *title tag.
Now, say if I can custom define these parameters, for example like this
Here, I custom defined the text of the same starbucks URL that my phone's
physical web scanned for.
This adds for relevancy to the URL. A user gets a clear message. Also, it
allows the stores to convey an effective contextual message.
This is possible when you use ReactJS and JSX?, because only you have one HTML file and always show the title default that is in this html, even if you change it with document.title = "other title" in the notification show the first and not the new title
The text shown in the Physical Web notification is strictly given by the target website and you can influence it only there.
The Chrome is actually not analyzing the target website. Its a Google server (Physical Web Service) that analysis it and this one provides information to Chrome. You seem to need changing the title instantly and often. So be careful about caching of already resolved webs on the server.
The website analysis does not execute any Javascript. It takes only what is written in HTML directly. So the trick with document.title wont work.
But there is a different way how to get the notifications. Look at the Google Nearby Notifications. In summary this works based on Eddystone-UID. You register your UID with the service and configure to redirect to target website. But in the configuration you can specify the title and description. Look at the mentioned page for the details.
Related
I hope this finds you in good shape.
I'm attempting to scrape data for my colleagues, and I've noticed that various websites can share the same URL. This has given me problems because I won't be able to scrape the data I require. Is there a solution to this.
Colgate's website in question is depicted below. The corporate vice-president tab and the leadership tab share the same URL. Can someone tell me how to scrape their names and roles or tell me how to find their individual URLs?
https://www.colgatepalmolive.com/en-us/who-we-are/our-leadership-team
You’re going to need more complex logic than just screen-scraping. The nature of object-oriented web scripting means that these links don’t work the way you think they do.
If you imagine a web page as static HTML, then each link is a discrete URL that the web server receives, interprets, and displays.
But most web pages aren’t static HTML anymore. When you click on the picture for Joe Smith you are not sending a message to the web server to retrieve and send another static HTML page that contains Joe’s bio. Rather your click is sending a message to the “Joe Smith Object” and telling it “please display the bio portion of your object.” The message never says “open the Joe Smith” bio, it simply says “open your bio. How does it know which one to open? The “display your bio” message only gets sent to whichever object the user clicked on. If Joe’s,object gets the message, the request Is for Joe’s bio. If Jane’s object received the message, the request is for Jane’s bio.
When should I have addresses with # and when should I have separate address for each page or part of a page.
For example
https://ca.news.yahoo.com/nick-hornby-boys-read-telling-101350029.html
I know sometimes we need to have #, for instance when we call a javascript method to show a lightbox(modal) but some websites are using it in their unique address of their pages.
For example icloud is using it to show its modal when you click on create one now link.
https://www.icloud.com/#
However, as I said some websites are using that as a method to have unique addresses for their pages.
For example following address that is showing a single page of icloud website.
https://www.icloud.com/#find
Is that correct to follow this practice of having # in our unique address of the website pages similar to what icloud website has?
I am not asking about icloud.com thats just an example. What I meant is that if you go to www.icloud.com/#find page you would see it is not a single page website because there is just a header, login page and a footer. So why they are using #find and not something like find.html? Is there any specific reason that I am missing?
URL fragments(#whatever) are a way to address sup-parts of a document. You should keep in mind that these are never sent to or seen by the server so you can't really use them serverside to differentiate between URLs. You can use them to make parts of a static page addressable or, with the right amount of JS contortions, use them as a foundation for addressable navigation within a single page app. Some JS frameworks rely on this fairly explicitly although with is starting to go out of style as most browsers now support the history api.
This has been driving me nuts all day:
I have an iOS app with a custom URL scheme defined, and am trying to share a link on FB which points to a page that has this scheme in its applink meta tags, so that tapping it should fire up my app.
Every little piece of it is working just fine. I can enter my URL scheme in safari on the phone and the browser launches my app. I have tested my webpage with the FB debug tool and there are no errors or warnings - it correctly identifies all the meta tags.
If I share the link using FB on the phone or on my laptop, all works fine.
HOWEVER, if I share the exact same link using FBSDKShareDialog, it does not work. It just opens the web page with the meta tags as if it was any regular web page.
Anyone has any idea why these two ways of sharing would be different? They look exactly the same otherwise.
If anyone else runs into this problem, here's the reply from FB:
When you share with mode automatic, the app does a fast app switch over to the FB app to show the native share dialog
The post is cached locally on the device, and it does not know about app links (since only Facebook server side knows about it)
When the user opens the FB, the user sees their cached story (with no app links behavior),
This doesn't manifest with the Web mode since the Facebook app needs
to pull from the server to get the post, in which case it has all the
app links info.
This is unlikely something that we'll fix. However, after a while, the
cache will expire, and Facebook app will re-pull the posts from the
servers, in which case the app link data will be available.
In order to test this, you can share the post on one device, and then
try clicking on the post from another device. The app links should
work at that point.
Which is kind of a lame response IMO - they parse the target page to build the preview, how hard would it be to remember the applink and use it?
There could be two possible issues:
Either the one told by #NJ, i.e. you are just trying to open the link in Facebook app, using the same device from which you posted the link.'
Solution - either open link in other device or cose and re-open your facebook app and do multiple refresh
Or You have some error in your meta tags. There is one important thing though, that Facebook never mentions, i.e. they cache the URL you provide.
So any one used the web link with meta tags the first time in Facebook, Whole meta tags will be cached, and you updated meta tags won't be parsed by facebook.
Solution
To get over with the issue, use below link
Facebook debug tool
Input your meta data included web page URL and
-click on show existing scrape information to find any error
Click on Fetch new scrape information for refreshing your URL on facebook. it will clear the cache for that URL in facebook server.
Can Chromecast be used to display a web site or web app? All the sample sender/receivers I've seen so far show how to play videos. The docs posted so far are minimal as best, just an API reference with little explanation what any of it does. I just want to send a URL of my choosing and have that page displayed on the TV. There's no user interaction required past that point. Assuming that's possible, does anyone have sample Chrome sender and receiver code for that?
I was able to modify the Github sample Project > googlecast/CastHelloText-chrome
to show a web page.
In the receiver.html file, I replaced the DIV with an IFRAME and styled it for 100% width and height.
Then in the displayText() function I changed innerHTML to src.
The only modification made to the sender chromehellotext.html was to replace YOUR_APPLICATION_ID with the app id created by registering the receiver.
Note that some sites like Google and Yahoo will not display inside an iframe. If you really needed to do that you could skip the iframe and just set window.location.href to the URL. That, of course, will overwrite your receiver code so the only way to change URLs would be to manually disconnect first and reload. I tried using window.open instead but that did not work.
One could imagine writing a Custom Receiver that has an iframe that wraps any website. Your sender would could then send webpages to your receiver, and the onLoad would set the the URL of the iframe. Don't have any code, but it's fairly simple to write.
There is a simple way to do that with the hellotext sample. You can send the html by typing that into the text field.
<iframe src="http://mywebpage.com" style="width:1280px;height:720px"></iframe>
To provide extra info from the current answer, as this post comes up near top on most searches.
Thing to search for is Digital Signage, this is the sort of industry word.
following GreenScreen Chromecast works okay. Greenscreen
host solution is Sign Simple - which looks to be same approach as Greenscreen without you needing to host the receiver web page.
Similar hosted solutions using Raspberry Pi can be found.
Of note: with GreenScreen and the CastHelloText, I could not get 1080p only 720p, some comments mention Video only in 1080p, but Images in 720p, which I take to mean html pages aswell.
Chromecast can indeed be used to display an arbitrary URL.
This can be done from plain old Chrome, using 'url-cast-receiver'. (Usable 'demo' page, GitHub project page.)
I've just encountered some weird behavior in Gmail that looks like some new kind of phishing attack. I got a couple shipment confirmations from Amazon today and there are these "Track Package" buttons (also I see "View Order" buttons on order confirmations) but when I click on them the page that gets opened is clearly not the correct shipper's web site.
Which looks fine but clicking on those buttons lead to bad pages. For example one of them goes to http://websro.correios.com.br. On the other it goes to USPS.com while the actual shipper (and correct link in the email body) goes to UPS.com.
I've looked at the source of the email and it all looks fine. There are no SCRIPT tags of any kind and no bogus links anywhere in the text (by which I also mean the HTML). The problem appears the same in Safari (6.1.1) and Chrome (31.0.1650.63). It looks normal in Mail (both Mountain Lion and iOS 5).
I couldn't figure out how such a button could get there and I found this feature for adding "registered" script actions to Gmail which is the only thing I can imagine would affect both Safari and Chrome.
When an order confirmation or parcel delivery email doesn't contain the necessary microdata to trigger the action, Gmail can still try to automatically extract the same information and show the button to the user as if the microdata was present.
Clearly this approach is less accurate than the one that relies on microdata, and it seems that in your case something went wrong with the automatic parsing.
No need to be worried about phishing though, as actions only show up for registered senders.