Slashdot Mirror
The Headaches of Cross-Platform Mobile Development
snydeq writes "Increased emphasis on distinctive smartphone UIs means even more headaches for cross-platform mobile developers, writes Fatal Exception's Neil McAllister, especially as users continue to favor native over Web-based apps on mobile devices. 'Google and Microsoft are both placing renewed emphasis on their platforms' user experience. That means not just increased competition among smartphone and tablet platforms, but also new challenges for mobile application developers. ... The more the leading smartphone platform UIs differ from one another, the more effort is required to write apps that function comparably across all of them. Dialog boxes, screen transitions, and gestures that are appropriate for one platform might be all wrong for another. Coding the same app for three or four different sets of user interface guidelines adds yet another layer of cost and complexity to cross-platform app development."
No, I want people writing apps for my platform to be following the platform's guidelines. It's not going to kill them, and it makes the experience better for everyone.
Success requires effort. Nothing new here.
Coder's Stone: The programming language quick ref for iPad
In theory maybe, but in practice the phone's UI is an open canvas for developers.
There's no way of writing code that is portable between iOS and Android. If for no other reason than the different programming languages, there's also capabilities and methods used on one system which are not appropriate for the other. I.e. iOS typically places a back arrow on the top left of the screen, Android devices typically have a dedicated back button on their phones.
The problem is we expect apps to perform consistently on our platform. This requires the design guidelines for the platform are followed.
Realistically given how you need to recode your app in a different language there's no reason a developer shouldn't simply adjust their app in the process to meet the design guidelines.
It's been my experience that you have a lot more control if it's a phonegap wrapped native app, than a browser app.
My experience differs from yours.
In my experience, phonegap provides JavaScript extension based access to information local to the phone without any controls on its use by a third party, by subclassing UIView and then going to a web page. This includes but is not limited to location information, any history files you have, your contacts, and anything else available to a sandboxed application.
If the software isn't intentionally malicious in the first place, the app developers tend to suck off all your information into their database with no malice, but with about as much thought to security as you would expect from someone who was unable to limit themselves to uploading only the information relevant to the running of the application. That is to say, very little.
Given the lax security already apparent, the sites that show up in the UIView are typically changed by malicious third parties in order to trigger redirection to a site that does then pull the information off for malicious reasons. Whether that's because the originating site's phonegap App web page was attacked through one of any number of security holes which the app developer already proved themselves incompetent to protect against through their use of phonegap in the first place, or it's done via DNS cache poisoning, links in forums in the applications, or a dozen other ways isn't important. What's important is that everything that phonegap exposes to JavaScript is now exposed to the malicious third party.
I understand the reasoning behind phonegap. It unfortunately doesn't apply in an unsafe world.
I hope that people who would perhaps want to use phonegap understand the security implications, and the fact that if you're caught using it, you get kicked off the Apple App store for exposing those APIs to third parties whose URLs happen to get displayed in the UIView on your web site, for whatever reason.
-- Terry
HTML5 supports offline caching of files as well as the SQLlite datastore, so you can provide a fully offline experience for users and even sync back with the server when a connection is available.