sourcebitsllc / chocolatechip-ui

Mobile Web App Framework
www.chocolatechip-ui.com
MIT License
616 stars 88 forks source link

Stock Android uses iOSBusy function instead of androidBusy #13

Closed grrowl closed 10 years ago

grrowl commented 10 years ago

Because it matches the User-Agent string for Safari as well as Android.

$.isAndroid = true
$.isChrome = false
$.isSafari = true
$.isiOS = false

Same thing happens with Firefox on Android, with the same matched variables as above except that isSafari is false

sourcebits-robertbiggs commented 10 years ago

ChUI version number please?

sourcebits-robertbiggs commented 10 years ago

I'm looking at the busy control loading properly on my Android devices. So, could you explain exactly how you're handling the loading of your Android theme? There shouldn't be any iOS stuff in the Android theme. Regarding the Safari true situation. Yeah, I'm aware of the issue. Chrome tries to identify itself as Safari, i guess to make sure all the code targeting mobile Safari works on Chrome. So what I do is first test for Chrome, then load Android things, else if Safari, load iOS stuff. However, you're getting $.isChrome false on Android? Is that on mobile Chrome or the Android native browser and which version of Android are you on? Details, detials, details. It helps me figure out what's going on.

grrowl commented 10 years ago

My apologies, we're balls-to-the-bandsaw with a deadline at the moment so I was a little hasty filing this.

The device identifies as Mozilla/5.0 (Linux; U; Android 4.0.3; en-au; LG-E612 Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30, using the stock Android browser ("Internet"). We're seeing ChUI call iOSBusy and we have icons on the tab bar (which don't work, presumably because of lack imageMask support), which leads us to believe it's falling back to being an iOS device based on the incorrect "safari" in the UA.

Here's a screenshot: chui-android01.png

Running ChUI-3.0.6, with jQuery 2.0.3.

sourcebits-robertbiggs commented 10 years ago

What version of Andriod are you running on? This looks like Gingerbread. Android before 4.0 has problems with image mask, which is being used for both the busy control and the tabs.

I’ve just checked in a fix for more granular device testing that I hope will solve the problem with the busy control: 658b1b4b9e

Regarding your tabs, those are show by CSS, which has nothing to do with browser detection. If you have the correct stylesheet for Android loaded, the icons should not be visible. Can you very that you’re getting the correct stylesheet loaded on Android?

Your Android theme should have a definition like this:

.tabbar > .button > .icon { display: none; }

Otherwise you must somehow be loading the iOS theme.

On Nov 27, 2013, at 3:29 PM, Tom McKenzie notifications@github.com wrote:

My apologies, we're balls-to-the-bandsaw with a deadline at the moment so I was a little hasty filing this.

The device identifies as Mozilla/5.0 (Linux; U; Android 4.0.3; en-au; LG-E612 Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30, using the stock Android browser ("Internet"). We're seeing ChUI call iOSBusy and we have icons on the tab bar (which don't work, presumably because of lack imageMask support), which leads us to believe it's falling back to being an iOS device based on the incorrect "safari" in the UA.

Here's a screenshot:

Running ChUI-3.0.6, with jQuery 2.0.3.

— Reply to this email directly or view it on GitHub.

grrowl commented 10 years ago

The whole theme is iOS at the moment (it's a web app which will later be packaged on the app stores). The tabbar is being generated by $.UIPopup, so I suspect that's falling for the same fake UA as UIBusy and that's affecting the generated html.

The device is an LG Optimus L5, very mid-level android phone but in fact does run Android 4.0.3 (we figured this is a good low-to-mid-range device to test on).

You're right, it doesn't support image-mask. We rewrote the busy indicator to use the SVG as a background image instead now, but we do lose small amounts of functionality (like changing the background color to style it). We don't intend for tabs to be visible on this device anyway so otherwise it's not an issue.

sourcebits-robertbiggs commented 10 years ago

OK, so using the iOS theme on Android is not going to work. You just need to change it to the Android theme and then the tab bar and busy control will be appropriate for Android. That means, with tab bars, they will be at the top of the app, as per Google’s direction, and without icons. There’s just one spot where you change the them, in the link tag in the document header. Change: <link rel="stylesheet" href="../chui/chui.ios-3.0.6.css”> To: <link rel="stylesheet" href="../chui/chui.android-3.0.6.css”>

By the way, you can load your app in the desktop Chrome browser as well to see what it will look like on an Android device. You really need to be using the Android theme on the device because it is quite different from the iOS theme.

On Dec 1, 2013, at 7:27 PM, Tom McKenzie notifications@github.com wrote:

The whole theme is iOS at the moment (it's a web app which will later be packaged on the app stores). The tabbar is being generated by $.UIPopup, so I suspect that's falling for the same fake UA as UIBusy and that's affecting the generated html.

The device is an LG Optimus L5, very mid-level android phone but in fact does run Android 4.0.3 (we figured this is a good low-to-mid-range device to test on).

You're right, it doesn't support image-mask. We rewrote the busy indicator to use the SVG as a background image instead now, but we do lose small amounts of functionality (like changing the background color to style it). We don't intend for tabs to be visible on this device anyway so otherwise it's not an issue.

— Reply to this email directly or view it on GitHub.

grrowl commented 10 years ago

Yup will do — thanks for the direction. For the web app we want to simply have the iOS theme, and we'll switch to android for the app version. BTW I found great value in importing your LESS files into our workflow directly and overriding the variables, thanks for putting in the effort to make that available.

sourcebits-robertbiggs commented 10 years ago

If you’re doing a Web app, there’s no reason you can’t serve the iOS version to Safari and iOS devices, the Android theme to Chrome and Android devices, and the Windows theme to IE 10/11 and Windows Phone 8.

if you try out this link on different devices and browsers, you’ll see that the theme is appropriate for the target. I strongly suggest you not force one theme on all users. That’s what jQuery Mobile does. That is not what ChocolateChip-UI is about. I’m not sure what Web stack you’re using, but it is trivial to examine the headers and make a decision on the server to send the user the correct theme. That way the user has a tailored experience for the platform. Please read the documentation for theme switching: http://chocolatechip-ui.com/documentation#/platformsupport

On Dec 1, 2013, at 7:35 PM, Tom McKenzie notifications@github.com wrote:

Yup will do — thanks for the direction. For the web app we want to simply have the iOS theme, and we'll switch to android for the app version. BTW I found great value in importing your LESS files into our workflow directly and overriding the variables, thanks for putting in the effort to make that available.

— Reply to this email directly or view it on GitHub.

grrowl commented 10 years ago

I don't disagree, and that's definitely the reason I didn't go with something like jQuery mobile. Alas, some decision makers have decided a uniform UI for the web app is the best move (plus, the designs came in well after implementing the core features), so that's our direction at the moment. Apart from the imageMask it's been pretty smooth sailing.

sourcebits-robertbiggs commented 10 years ago

Well, then for the busy control, use and animated gif. You’ll have to change the reference for that in chui-ios.css. Same thing for the tabs.

Just look for .busy in the css. Then change all the references from -webkit-mask-image to background-image and change the -webkit-mask-image: url(…) to background-image: url(your animated gif path here);

Similarly, for the tabs, look for: .tabbar > .button.more > .icon

and redefine all there references to -webkit-mask-image to background-image equivalents. Use a png with transparency for your icons and you should be fine on all modern browsers. On Dec 1, 2013, at 7:50 PM, Tom McKenzie notifications@github.com wrote:

I don't disagree, and that's definitely the reason I didn't go with something like jQuery mobile. Alas, some decision makers have decided a uniform UI for the web app is the best move (plus, the designs came in well after implementing the core features), so that's our direction at the moment. Apart from the imageMask it's been pretty smooth sailing.

— Reply to this email directly or view it on GitHub.

rbiggs commented 10 years ago

Tom,

You can handle some of the differences between iOS and Android in the same document by including some document specific styles based on UA. 

.isAndroid .tabbar .icon {    display: none; } .isiOS .tabbar .icon { background-image: ...... etc. }

If i can help you solve a problem, let me know what your pain point is.

Cheers

On Sunday, December 1, 2013 8:51 PM, sourcebits-robertbiggs notifications@github.com wrote:

Closed #13. — Reply to this email directly or view it on GitHub.

grrowl commented 10 years ago

That's what I've gone with, also with the .isAndroidNativeBrowser (which I accidentally stumbled upon, given that the android native browser has no debugging capabilities...)

Thanks for your help, we shipped today! Good luck with the project.