I am using a Phonegap app to house a browser shell for a fully responsive website and I tweaked the Inappbrowser on IOS to only show the back/forward buttons but they are ridiculously tiny when I view the app on an actual iPhone. I'm talking like 8px by 4px tiny.
I searched through the CVDInAppBrowser.m file but couldn't find any settings for the actual size of the back/forward buttons.
I'm also having a tough time locating a solution via Google.
Any ideas on how this can achieved?
EDIT - Altering the toolbar height in the CVDInAppBrowser.m made the background container behind the buttons larger which makes the buttons stand out more but they are still so freakin tiny.
Related
I am currently developing a hybrid app in iOS that loads a website and has some other features (contacts, sharing, notifications...) using cordova plugins. I do have access to the content of the site that is being displayed by the iframe.
The normal way this is done is to load the website in an iframe. I have already done this in android and it works very well. In iOS however:
Safari messes up the size of the frame. I fixed this by setting the min-width css style to 100% for the frame.
Scrolling on the iframe is always set to "no" even if you specify "yes. I "fixed" this (so I thought) by using the only solution I could find which is to wrap the iframe in a div and scroll the div. This made the header (position:fixed) scroll with the page when it should be fixed to the top of the page and broke other things on the page that rely on scroll position to trigger an action. I also tried modifying the body of the content to contain css styles mentioned here but this didn't work either. I was back to square one.
I have spent a total of a week researching how to fix this with no avail. Recently I have discovered that loading my website in iOS's UIWebView or WKWebView works well to display the site exactly how I would expect.
That brings me to two possible solutions (and my question):
Maybe I missed something with the css style on the content of the site. I read that it is possible to get scrolling to work this way but I am sceptical because safari does not allow scrolling on an iframe.
(The likely solution but the one I cannot figure out) Make my cordova app use a one of iOS's webviews. This is what I am having problems with. I cannot figure out how to do this. Is a webview an iframe? How do I use one of these webviews in my app? What does the index.html (cordova specific file) look like when I use a webview instead of an iframe (because currently this is where my iframe is).
I solved this. Since I have access to the contents of the page, I added:
position:absolute
top: 0
right:0
bottom:0
left: 0
overflow-y: auto
overflow-x: hidden
-webkit-overflow-scrolling: touch
To the scrolling body of the page. This fixed my problem
This is not a question about JQM panels scrolling independently of the page, though that is an issue I've had trouble with and almost overcome, this is about making the panel scroll smoothly and ignore the device browser's edge event (or whatever the correct term is, I'll explain below).
Basically, I'm trying to replicate the menu on Google's mobile site, which naturally isn't using JQM like us common folk. I've got it pretty close, but the scrolling animation is very rigid. I need it be momentum-based rather than fixed to your finger.
Also, when you reach the top or bottom of the menu, it's considered the extremes of the document so the browser moves the whole document up or down to indicate the edge of the page. Instead, the page should never move while the panel is open and the menu should take on this behaviour within the panel.
Since I've set the panel height to 100%, this forces the address bar on iOS Safari to come down when the menu is open. This seems to be exactly what happens on Google, but if there's a way around this I'd love to hear it.
Finally, one downside of the way I've emulated independent scrolling is to just set the content wrap as fixed when the panel is open. However, this means the page always scrolls to the top when the panel opens. Any alternatives for this would be appreciated. I suppose I could just set the page top as scrollTop or something.
To summarise:
Panel menu needs to scroll smoothly (momentum rather than direct touch)
Elastic edge on menu rather than window
iOS Safari address bar interfering with height
Page fixed at top when panel open
If any of my descriptions don't make sense, just visit google.com on your phone and check out their menu.
ScrollFix seems to have solved all my issues.
I would like to add vertical scroll in Phonegap app. The app is able to move left and right.. but not up and down.. Need some guidance on how to do it.. Thanks..
depending on how your app is set up there are a few options out there.
1) If you don't need a fixed header ( very rare but does happen ) you can use a normal css approach, phonegap is just a webview wrapped as a native app, so most things in a browser will work here.
2) if you need a fixed header and footer I suggest iScroll.
iOS 5 gave us -webkit-overflow-scrolling: touch, which works in mobile safari, BUT since a webview is mobile safari's little brother you aren't given all of the awesomeness that regular safari has.
all containers, which are higher than 100% viewport con carry the CSS: overflow: auto or overflow: scroll.
important is, that the container (i think a div) is set to height: 100%.
this is a idea for solving with CSS.
PLEASE NOTE: This is not a "use two fingers to scroll" problem. Whether it is one finger, or two, or three, or the whole hand, for some reason our iframe does not scroll on an iPad. :)
Here is the scenario:
In our web application, which is built using EXT-GWT, we have a few windows that open as (maximized) pop-ups and present some forms to the users. These forms, which are most of the times external, are rendered in an iFrame and some of the forms have their content collapsed at the initial load - the user can choose to expand any section of the form, fill it in and submit. Now everything works fine except the scrolling in iPad. After the iframe's content is loaded and collapsed (collapsing is done using JS on the client side, basically, the content loads as expanded by default and then is collapsed by JS) iPad just fails to provide scolling to the iframe. Even after the content of the iframe is expanded the iframe does not get any scrolling.
As of now, we have solved this problem by increasing the height (using JavaScript) of the EXT-GWT window to the size of the expanded iframe body content. This makes the whole window scrollable, instead of just the iframe within the window. While it works, the window becomes way to big, so I was wondering if there is any better way for us to provide scrolling to the iframe.
Thanks for the help,
Nitin
For iOS devices you need set overflow: auto; or the scrolling won't work. For my web apps I used fancybox to display iframes modally and once I change the overflow setting in the css file the two finger scroll worked perfectly on the iPad.
After trying (almost) everything, I have come to the conclusion that increasing the GWT window height to the iframe.body.height is the only solution for getting the window/iframe to scroll on iPad. Hopefully, this will help someone in future.
I´m pretty new to GWT, but for me it worked like this:
The parent-div of the iframe has a class in my case, x-component.
I made an entry to my css file like this:
.x-component{-webkit-overflow-scrolling: touch; overflow:auto;}
It works as well if I set these entries not to the class, but to the div-element itself.
Hope that helps
As we all know, iPad do not support the <frame> element, but both Gmail and Ymail could do something similar by creating a 2pane style , and the navi pane (left one) could scroll (in ipad style). May I ask if anyone do have the idea how it created?
Thank you very much.
I don't actually know for sure how they've done it (I can't seem to reach mobile gmail in a desktop browser, and I can't find a view-source feature on my iPad) but I suspect that it's not as complicated as it looks.
Keep in mind that in a regular browser, when there is too much content we get a scrollbar. That's not how the iPad renders long pages. On the iPad, if there is too much content we never get a scrollbar, scrolling is achieved by sliding the content up and down. So what we should imagine is that this is two panes with scrollbars, because that's how it would show up in a normal browser.
From there, it's a much simpler problem. It's probably just two divs floated in a standard two-column layout, each with their overflow set to scroll. Something super-basic, like:
<div>
{the nav list of emails goes here}
</div>
<div>
{the currently-open email goes here}
</div>
<style>
div {
float: left;
width: 50%;
overflow-y: scroll;
}
</style>
There's probably something fancy in there to make each div consume 100% of the available height (it's probably not as simple as height: 100%) but already if either div contains enough content, we'll get individual vertical scrollbars which the iPad will hide, giving us that neat sliding-scroll gesture instead.
I've tested a few of my own apps which were build back in time with Frames. They all worked "normally" are you sure you didnt use the wrong Doctype for your HTML?
Individual block elements with overflow-y:scroll are only scrollable with two fingers on the iPad. That's just the way it is.
So how does Gmail do it differently? Manually, with JavaScript, reacting to various touch events.
Your best bet at the moment is to use iScroll. This used to be a bit un-smooth (compared to Gmail and others' implementations), but the latest version is really good. Try their demo.
It works on iPad/iPhone, Android, and you can even use it in a normal browser using your mouse. It has the nice elastic effect when you reach the top/bottom of a scrollable area, and it has the iOS-style scroll indicator thing that appears on the right during a scroll. It's almost as smooth as scrolling on a native app.
By the way, if you want to examine an iPad-specific website's source, the easiest way is using Safari (I've tried this on 5.0.3 for Mac, but probably works on other platforms too). Turn on the Develop menu (Safari>Preferences>Advanced), then you can set your User Agent to iPad.
You can do the same thing in Firefox, posing as an iPad, but I often find the websites look completely broken. I think this is because many iPad/Android-specific websites rely on Webkit features that aren't present in Gecko. In fact, Apple's iPad guide site, which also uses a two-pane scrolling technique, simply rejects you if you're not (a) sending an iOS User Agent string and (b) using Webkit. And Chrome doesn't have an easy way to change your User Agent string. So Safari is the easiest way to examine these kind of sites.