I got really confused of all the W3C specifications and implementations of different browsers.
I have a list questions:
I found this page from W3C's website: http://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html
And I found this page from apple's website: http://developer.apple.com/library/safari/#documentation/UserExperience/Reference/TouchEventClassReference/TouchEvent/TouchEvent.html#//apple_ref/doc/uid/TP40009358
They are talking basically the same thing.
So my question is : did apple published all the multi-touch apis first then W3C followed apple to make all the specifications? or did W3C published the specifications first then apple followed the specifications to make a new version of Safari?
2.Is the Touch Events Specification a part of HTML5 specification?
3.If I write a web page that uses multi-touch to interact with users, can the users be able to use this web page in IPad, Android devices and Windows Phone 7(Mango)?
Or do I have to write different code for each different platform?
Thanks
The Touch Events Specification is based on events cloned from Apple Safari's implementation, although it adds significantly to it. It is not technically part of HTML5. The other platforms have also copied Safari's touch events. It should be possible to write code to the original Apple Safari reference documentation and have it work on iPad and Android. I don't know about Windows Phone 7 (Mango).
Related
I have a medium size project on React+Nodejs and I need to choose best suitable technology for the mobile part. I am considering React Native or Web Progressive Apps for that. I want to ask you guys what is your experience so far about performance of "native-like" React Native versus WPA based apps.
I need to put into consideration:
1. Making it as easy as possible to make a transfer from ReactJS code into mobile.
2. Hardware support on mobile devices. Such as Barcode reading and NFC.
3. Push notifications.
4. Function well on both Android and iOS.
Biggest question is whether WPA technology has already become mature enough to trust it or not.
I had to make the same decision couple of months back and we chose PWA (not the answer for everyone yet).
Here is why we chose PWA,
1) Performance - Web can now perform 60fps - The magic number needs for native like smooth transitions.
2) Cost - Its fast and easy to build a product for both as a mobile app and web using PWA with no learning curve for existing web developers.
3) Proven - Starting from Twitter lite to Flipkart, there are so many success stories on PWA. No doubt its reliable. With iOS support coming couple of months back, now all major browsers support it.
PWA limitations and workarrounds,
1) Hardware - PWAs are limited to what web can do today. So there are hardwares like bar-code scanner we don't have any scope of support anytime soon and there are some hardware which very limited support and some hardware like Bluetooth with average support(in terms of % of browser versions supporting today) We had to build a small Android Native application to interact with these hardware and pass on the info to PWA suing web sockets. Say, when a barcode is scanned, this native Android service will listen for and receive it and pass on to our PWA. Same thing goes to NFC.
2) Packing and deploying - There is no official way to generate an APK and distribute in corporate environment. We were able to extract the APK after adding the PWA app to home screen using some file explorer and use that to distribute though. Havent tried on iOS. Hope for latest versions for any mobile OS, we can use cordova(not pure PWA but we get most of the benefits like Service Worker) to package and distribute as well.
I have few SSRS reports (with charts, gauges etc) deployed to the server and they all work fine but not so well when viewed as well worked upon on cell phones/tablets.
The users find difficult to choose the report parameters, selecting from drop downs and also presentation of data through charts, gauges etc.
I am thinking to modify the SSRS report for cell phones but not sure how to progress. I have searched and started reading some blogs but thought of asking suggestions of experts here who may already dealt this.
I have sample RDL files (deployed to the report server) that I can post here but they are any other typical SSRS Reports with various parameters, charts, gauges etc.
Many thanks.
Please share your thoughts.
Looking for an solution for the same problem, I have found this answer. I have applied it ant it worked!
My context is:
I'm using the ReportViewer Webform component:
Microsoft.ReportViewer.WebForms, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91
It tested in Androind Asus Zenphone 2. Using the default browser and Chrome.
It worked at desktop chrome too.
The code change:
Replace:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
with the following tag:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Are the reports being delivered using Report Manager, SharePoint or a ReportViewer control in a web page?
You're using SQL Server 2008 R2, so the only supported browsers are Internet Explorer, Firefox and Safari and although it doesn't explicitly state it this almost certainly refers to the desktop versions of these browsers so there's no guarantee that mobile versions will work the same way.
So the SSRS technology you are using is not designed with modern day mobile devices in mind. That said you can still try to make this work: You need to ensure the users are using either Firefox (on Android) or Safari (on iOS). Note that Chrome (or related browsers) are not supported at all. You need to consider how the report security is going to work (e.g. only Basic authentication is supported with Safari).
In terms of layout and report components, you'll have to do some trial and error testing to see what works - and remember it may not work on all devices. You might want to consider providing links to render the reports as PDF files, which have much better support on most devices. There is a great blog post by Adam Aspin on some layout techniques for reports on mobile devices here: https://www.simple-talk.com/sql/reporting-services/mobile-bi-with-sql-server-reporting-services/
Generally though, if you're trying to design a solution for mobile devices you really want to consider an upgrade to a more recent version of SQL Server which has support for more browsers (including Chrome) and security options.
What is the best way to test my website across various mobile browsers AND various versions of each of those browsers.
Additional Info:
Most of the online cross browser testing support wide range of desktop browser testing, and quite a range of mobile devices. But they don't seem to offer various versions of mobile browsers on those devices.
This similar question is quite old and it is surprising that in spite of the proliferation of mobile devices and focus on responsive designs, testing services for mobile is not catching up.
Major mobile browsers I would like to target : various mobile versions of Safari, Chrome, Firefox, Opera, Dolphin, UC Web etc
Just wanted to note this and this good alternative to online testing services for desktop browsers. Maybe something similar exists for mobile browsers too?
I'll suggest that both Opera's "device mode" is a really good for a first crack. But nothing beats actual device testing. I have found the odd case where Chrome's iPhone mode renders something different than what the actual phone does, but I would say it is about 90%. And the fact that it is so much easier to tweak code, and refresh using Chrome on the desktop rather than tweak, and refresh on phone, that I tolerate the 10% difference as long as I can. Then I just verify on an actual device after I am done with Chome's device mode.
I have not used Opera's device mode, but have heard it is good too.
There is a tool called as https://www.browserling.com/ which can be used for Desktop and Mobile testing(Android)
I don't think there is one way of doing cross browser testing across various mobile browsers and versions. It all boils down to what you want to do?
It is impossible to cover ALL browser combinations and versions. So my suggestion based on experience would be-
If you have too many combinations in mind, use a combinatorial tool (pairwise testing) from here - http://www.pairwise.org/tools.asp and reduce the number of permutations to get the best coverage.
Then go to Android and Apple website to see what the most commonly used phones and versions in the US, Europe and Asia region are based on where your customers are located. They have all these stats publicly available on their website
If you have google analytics see what browsers, versions and phones your users most commonly use to access your website
Now, you will have a list of devices and browser versions which is more focused.
Check what budget you have to invest in cross browser testing. Based on that I would recommend buying at least a couple of phones and tablets based on the usage statistics you got in the first 3 steps. Then, you can choose from a number of cross browser testing tools/services like
BrowserStack
Amazon Devices Farm
Saucelabs
Now atleast you have a more scientific way of doing cross browser testing :-)
I have a client who wants me to optimize their mobile website for the Kindle Fire. I've done development on iPhone, iPad, and Android, but not for Android tablets and not specifically for the Kindle Fire either.
I wanted to know, as a mobile web developer, are there any special considerations I should make or any red flags I should be aware of for doing web development on this platform?
After doing some research, it looks like it's using Android 2.3, running an Opera mini-like browser called Amazon Silk, and using a networking protocol called SPDY. A found an article that suggests I should be designing for a 1280 × 752 space.
I found one article on Quora that says "Silk tracks user behaviors in aggregate, and will attempt to predict likely next pages (similar to what some browsers do to preload links - just in a more targeted manner). It then delivers that content to the device ahead of time." That raised a little bit of a red flag for me because I do implement some server side (php) tracking and logging on some of my webpages. I don't want to be recording logs on pages that aren't being requested by a real person.
Other than that, I don't really see anything else to be concerned about. Thoughts?
The Amazon Silk backend does employ certain optimizations to reduce latency. But, as a general rule, you don't need to factor the Silk backend into your web development considerations. There are no gotchas to worry about.
With regard to the UA string: You can find the latest and greatest info on the Silk user agent at the Silk Developer Guide: http://docs.aws.amazon.com/silk/latest/developerguide/user-agent.html.
The Challenge
I would like to create a simple website for:
iPhone 3 and 4
iPad
Android 2.2
– BBerry OS 7 and Playbook Browser
Symbian
Desktop Webbrowser
The Problem
Whats the "best-practice" for detect, optimize and deliver the Webapp for each device/screensitze? I know this is about HTML5, CSS3 Mediaqueries and JS. HTML5 Boilerplate is a good point to start.
But:
Should I detect Browser/Devices via backend/front? What are good
libraries?
How Do I detect different screensizes? What are good libraries?
etc.
Use Phone Gap as your starting point.
Depending on your use case, there may be other libraries you may want to pile on top of it, but basically Phone Gap is what you should start with.
My suggestion would be to use Sencha Touch. Its a very mature mobile app frame work with a very active community. They support any mobile that uses the webkit based browser which is everything on your list(Im not sure about the symbian browser).
Sencha 2 which will be released by the end of october will have its own native packaging library, so the use of phonegap wont be required. But it work well with phone gap if preferred.
Mobl is new language for the mobile web. just a look on it.
Adobe's Edge is the most refined HTML5 creator that also supports Android, iOS and Playbook (IMHO forget about Symbian, that's Nokia's half dead platform). BB7 uses webkit like most other desktop and mobile browsers.
Note that coincidentally Phonegap (that I see in other answers here) is part of Adobe now.
You can give a try to Titanium's new web SDK too.
And then look at this SO question which is very similar to yours and has lots of useful links in it.