I'm working on a mobile webapplication which consists of multiple pages (with different urls)
/index.html
/products/1.html
/products/2.html
{...}
Now if the user is on one on the subpages and selects "put on homescreen", I'd like to put the startpage (i.e. /index.html) on the homescreen, so he goes to the home page when clicking on the icon instead of some subpage.
Is there any way to tell the mobile OS (iOS and Android in my case) which URL to choose for putting on the homescreen?
Unfortunately iOS chooses the current URL and does not provide a meta tag option to set this. As for Android I don't know whether there is a possibility to do this but I don't believe there is one. It makes sense for security reasons.
But maybe there is a workaround for this. I thought about the following (untested, just brainstorming):
Create a session for the user and measure last interaction time. If the last interaction happened e.g. 10 minutes ago, redirect the user to the starting page. So if your user doesn't use the App for a while and calls it via the homescreen, he will be redirected to the first page.
Another method would be to use anchors for all the navigation and a script that disallows to directly browse to anchors without previous user interaction. So even if your user is at /index.html#products/2 he has to start at index.html
Related
I'm building a somewhat basic app (only testing on Android for now) with multiple lists, one of which is an Inbox list. I can share text from other apps to my app, and it works well.
However, I would like the app to handle the intent without launching the full app UI. For example, if I share a URL from the browser to my app, I would like it to be handled in the background, save the URL to Firestore, and show a toast to the user indicating that it was successful.
Ideally, I would like to put two entries in the share menu, one to add to the Inbox and show a toast as described above, and a second entry that gives the user a modal dialog that floats above the sharing-from app, which allows the user to choose a different list to save to.
I think I'll have to make a (for example) ShareActivity.java, and add it to AndroidManifest.xml, but I have no idea where to go after that, or even if that's the right approach.
I was wondering if there is a best practice in Android about WebView/Browsers. I want to open an url in my app to show a web page but I do not have anything to retrieve from that page so I do not need to show it in a webview inside my app. Should I show that page in a browser or in a webview ?
If you should open an URL in WebView or Browser that totally depends upon your requirements. Still I am adding some points that you can consider:
Browser:
If you have some data like Privacy Policy of your organization, that just for user information. You do not require any inputs from user.
WebView:
If you want to,
Customize content of URL
Get some input from User
Send some information to Server
Thank You!
Quick Answer:
From your context, it looks going the Browser way is good enough.
Details:
When you don't have user inputs to process and it is not part of the user-flow in your app, go about showing it in the Browser. It's easier that way, because you don't have to manage anything explicitly.
When you have something to process or that this window is some part of your in-app flow, you should go the WebView way. It gives you the power to manage things and you really need to code of situations like user pressing "back button", and the like. I mean, you're the owner of the life-cycle management of the WebView and see how it seamlessly fits in your user flow while (s)he is at it.
I'm trying to create an app using MIT's App Inventor. I'd need to get a history of the pages a user visits using a WebViewer block or, at least, count the number of pages visited. Note that I want to include the pages opened by links internal to the WebViewer.
I've been trying, but it looks like there is no possibility to detect any clicked link within the WebViewer. Maybe there is some way to detect and count URL changes?
Is there any way to achieve this? Thank you.
You will have to use a clock component and a list.
Inside the clock.timer event check, if the current url is already stored in the list. If yes: do nothing else store the current url in the list
I have an android app, which lets people share content from other apps to it. When it receives the shared data, it looks for the URL in the shared text and fetches the page and does processing on the data fetched. This is designed with specific purpose and not a generic for all apps.
It works fine, except that people have to click the share icon and then choose our app name. With accessibility we can reduce this work for the users. We are able to get the text displayed in the app.
Is it possible to get the content which we would get if we were to click the share button.
Or
Is it possible to trigger the share button and choose our app without disturbing the user in anyway
You could try that if it's only for 1 specific app. See question How to click button in settings using AccessibilityService? which clicks a button. This will not scale if you want to do this for more apps. You could however parse the text that is on the screen and look for http links and process them in a background service and then show a floating button like Link Bubble Browser
You can simply trigger the share activity of your app when you detect the text from the other app; but the question is how will you know when user is done typing the text?!
One way is you can place a system-wide floating button similar to Facebook Messenger and after user clicks it, the text can be shared. This will reduce number of clicks user has to do.
So,
1) Yes, its possible to get text content via AccessibilityService.
2) No, you cannot automate this action.
I am using an href tel: to successfully create a clickable link for mobile phones such as Android. However, if the number is engaged/busy (unreachable) there seems to be no fall=back option to redial or reload the page.
Is it possible to refresh or redial the page if this happens from within the OS?
That functionality would clearly lie outside the control of a website or web app, since it will have transferred control of the call over to the phone application by that point.
So no, you're not going to be able to get a "callback" or the like from the phone application to the webpage indicating failure. Indeed, that might be a privacy concern anyway.
As far as refreshing or redialing, the closest you might get is to put a "refresh page" hook on the action of clicking a href tel: link with javascript, which is a relatively trivial procedure that is well documented elsewhere.