I had a little trouble finding updated information about WebViews, and as a back-end developer, I would like to understand how they work and differ from the actual WebKit browser engine?
For practical purposes, I'm interested in the experience that happens by default for users when they scan a QR code using their native camera. I would like this to navigate to my website. The user would sign in, and I want to give them a cookie or session id to provide them with authentication.
As I understand, when a user scans a code with their camera, clicking on a link, the link is opened in a WebView, rather than their preferred browser. If the user closes the WebView after they sign in, such as by navigating back into their camera's functionality, the stored cookies will be lost.
Would appreciate references to the specific behavior and technical details of the webpage and storage information from browser pages opened from cameras on both iOS and Android.
Related
Can anyone explain in real life example what is the difference between
App Links - https://developer.android.com/training/app-links/deep-linking.html
Deep links - https://developer.android.com/training/app-links/index.html
App Indexing - https://developer.android.com/studio/write/app-link-indexing.html
in Android?
Have read too many posts and documentations, but still cannot get the exact gist.
I understand that App links works with Android 6.0 and Deep Links with 4.2. but in performance, they are doing the similar task.
App Indexing allows Google to crawl your app content (as it would on a website).
Deep Links vs Android App Links:
App Links are just deep links that have been verified for a website, AND allows opening URLs in the associated app directly without asking the user to select the app (via the disambiguation dialog). With App Links, your app designates itself as the default handler of a given type of link (though the user can override it from device system settings)
A nice overview of the differences is at https://developer.android.com/training/app-links/verify-site-associations?authuser=0
Also see comparison table below, lifted from the above link at the time of writing
If you have an app or are developing an app, app indexation and deep
linking are things you definitely need to be paying attention to.
Basically, Google wants to treat your app like a website. It wants to
crawl it and index it so that search results can return specific pages
from an app in mobile searches. That ability to return specific pages
within an app? That’s deep linking.
What is Deep Linking?
Deep linking, in a general sense, involves linking to specific content
within a website or app, rather than to the homepage. Here we’re
talking in particular about getting specific elements of an app to
show up in search results on a mobile device, allowing users to open
an app directly from a search results page. Note: Users will only see
this prompt if they have the particular app installed.
Photo:
What Is App Indexing?
App indexing is the result of getting your app in Google’s index to
enable deep linking. By allowing Google to index pages within your
app, features (or promotions) within the app can begin showing up in
users’ mobile searches, driving visits (and hopefully conversions) to
the app.
What is an App Linking with the example of Facebook
When someone shares content from within an app that has Facebook App
Links applied, anyone clicking on that link will be able to access
that content through the app. This can be done using an app
alternative to existing web content, or app-only content, and works
either from ‘web to app’ or ‘app to app’. The feature works with
Android, iOS and Windows phones
Photo:
I would like the ability to share content/page URL to a mobile's native application from a webpage. At the moment very few mobile users appear to be signed into Facebook/Twitter through the website URL, but rather through the native application. This obviously creates a problem that I can't find a real solution for.
Facebook
<a href="twitter://>Twitter</a>
http://jsfiddle.net/yyqj7u6L/
Both these links open the native app on Facebook & Twitter (if installed), but don't appear to have the functionality to post a status/share content without manually typing in.
I have checked the documentation here
http://wiki.akosma.com/IPhone_URL_Schemes#Facebook
With no luck.
My other thought about this problem is to target the share ability built into most mobile browsers, for example on Chrome I have the option to share via Facebook and so on. Although very little seems to be available about launching this feature from within a web page? I guess there is some security issues with this.
I did have a good look on here to find similar solutions but nothing quite hit the spot, related directly to sharing to native app from web page.
The code below should work for Twitter.
Share to Twitter
Is there a way to prevent my site from being opened inside a UIWebView of any iOS or Android app, such as formatting the URL in a special way? These are apps that I do not own, so the call is coming from my page, not from the app.
Preferably, when an app tries to open the page on my site from within the UIWebView, it would automatically open up the page in the Safari or native browser app instead of inside the users application.
Otherwise, it looks like I would have to run some javascript to determine if the page is opened inside of a UIWebView and then just restrict access.
No. A browser is just an app. There is no specific distinction between a browser app using a webview and another app. That link for javascript browser detection will be pretty much useless for this scenario. Apps can set their user agents to whatever they want, including a user agent identical to what the native browser app uses. Essentially anything that you try to use to detect the default browser can be mimicked by another app.
You could change the user agent in your own app to something specific that you could then detect with javascript.
You can also call javascript functions in the webview from your iOS code so you could potentially wait to display things until that call comes from your app.
While these things can be easily mimicked, and wouldnt block a scraper that ignores javascript, it's unlikely someone will go through all the trouble. If you want further protection, you'll have to introduce some form of authentication.
I have a number of Drupal 7 websites (http://drupal.org) that have a mobile theme with JQuery mobile (http://jquerymobile.com/) for users browsing with smart phones or tablets. Although this provides a great mobile experience I would like to create an app for the Android and Iphone that uses a few built in features for content creation (mainly just the camera on node creation). I have eclipse and the android emulators all installed and have an installation of Phonegap working for Android testing. Here is where I need some advice on the best approach to my particular problem.
Basically each app can be almost entirely just a webview (easy), but I do need 2 features which should add enough uniqueness to make it able to get approved in the MAC app store.
Ability to add nodes using a REST service (along with phonegap) have access to the use phone’s camera to populate an image field.
A start or front-page has a fast login, and allows instant access to add content (all assets stored locally on phone, so even if the phone is offline, this page will still come up).
Ability to go from the regular mobile site (webview) back to the local node creation page (with access to the camera) or frontage.
Ability to pass something to the webview so I can hide content creation links that access the web version of node creation forms (which would not have the camera for example).
Here is where I’m confused. I don’t want to recreate the entire site and retrieve all the data using services (lots of tutorials and stuff I’ve seen are doing this including DrupalGap - http://drupal.org/project/drupalgap). That seems like a ton of redundant work that will require lots of continuous updates when the site is upgraded and changed with no real gain other than speed (For this it’s ok that it won’t be as fast).
For my mobile apps, when a user wants to view their profile, look at various pages etc, that should all happen in a webview, I only need services and the typical approach to mobile development for the front page, authentication and node creation. The rest should happen in a webview. So what is the best way to switch between adding nodes and authentication using a service and just going to a regular webview? Should I try embedding a webview in a page and having a small menu on the top that doesn’t’ change which links to the add content and login?
How do I setup the session for both the webview content and the service? Or how I can I force authentication through REST and then pass that on to the webview?
You don’t have to answer each one of those directly, I would just like some tips to get me started in the right direction. So far I’m thinking I create a “frontpage” for the app with all it’s assets stored locally on the phone, which has a login which authenticates through a web service (REST). After you login it shows the link to add nodes and a link to view the webview. The big question is how I use the same session for both and how to navigate between the 2 well?
I accomplished the goals stated above, by have the login use a REST service via jquery mobile in a regular html page (like this tutorial http://tylerfrankenstein.com/code/android-app-with-drupal-7-services-phonegap-and-jquery-mobile) this is also where the create content links can be placed. When you want the user to be able to open the "regular" mobile website and already be logged in, use the childbrowser phonegap plugin (https://build.phonegap.com/docs/plugins). Users can close the childbrowser and go back to the main dashboard by clicking the X, or you can create a listener that responds to them vising a specific URL (like the homepage).
The new Google Play Developer Program Policies state that it is no longer allowed to publish web browsers that are based on WebView:
Do not post an app where the primary functionality is to:
Provide a webview of a website not owned or administered by you
(unless you have permission from the website owner/administrator to do
so)
I was thinking of developing a WebView-based web browser but now I see that this is no longer allowed.
Frankly, I find it insane to ask every website in existence for permission to display its content via a WebView based browser.
What are my options? Is there an alternative web kit that is as powerful as WebView?
It doesn't say you're not allowed to make a browser.
It says, that you're not allowed to make an app which merely is a WebView showing a website you do not own, and don't have permission from the owners to make.
That is, I am not allowed to make a GMail app, which merely is a WebView showing the GMail mobile website.
One reason could be, that such an app provides nothing that a bookmark wouldn't. Another reason could be, that such an app may seem to the end user to be affiliated with the website it's embedding. If the app then added adverts, crashed or provided some kind of negative user experience, this could reflect poorly on the website being embedded.
You totally missed the point, if you are making app that displays some site that you don't own then some users of that site will use your app instead of simple browsing to get information from that site.
Let's say that site has 3 pages
-> 2. -> 3.
If you are showing page #3 from your app then users will not see ads from page 1. and 2. Which means that you are stealing that site's money.
And that's why you need permission from site owner.