The Headaches of Cross-Platform Mobile Development 197
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."
Re:If you're gonna do it, do it right (Score:5, Informative)
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.
So? (Score:5, Informative)
Success requires effort. Nothing new here.
Re:If you're gonna do it, do it right (Score:0, Informative)
the tools are available, lazy programmers don't use them.
Re:Not that bad (Score:4, Informative)
They changed that policy in late 2010. http://daringfireball.net/2010/09/app_store_guidelines [daringfireball.net]
Re:If you're gonna do it, do it right (Score:5, Informative)
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.
Re:Thank You (Score:4, Informative)
A huge portion of our applications now are enterprise class crm solutions, so easy portability to multiple platforms is something we offer as a courtesy. There is always an officer or VP that must be that special snowflake that requires Apple support, even though the other ten thousand people use Linux or Windows.
We have Amazon EC2 services and simply need front ends for access, manipulation, reporting, etc. We have little to no need to have really amazing, shiny and pretty interfaces. Between ICS and iOS 5.x we have almost identical user interfaces with nice transitions and pleasant looking graphics. The thing that matters is speed of access to S3 buckets and read/write access to EC2 clustered databases. The nice thing is we can compile to Linux, Windows, almost all mobile platforms and have almost identical user interfaces. Instead of spending copious amounts of time on one platform, we create portable interfaces that are nice, fast and compile on just about anything, even the magical over hyped/marketed products. :)
Cheers
Re:Not that bad (Score:4, Informative)
It's not a rejection criterion anymore. Apps can be coded in any language (including Flash), with the exception that no external code may be downloaded. C++ was always accepted, but JavaScript, Flash, C# are all acceptable.
The general method is to stick all your core logic in a C++ module and then interface to that the UI code. Then cross platform porting involves rewriting the small UI core. Obj-C can call C++ objects trivially (native function call). For Android, it's done through JNI, but supported via the NDK. For Windows Phone, it's a bit more difficult since the core may need rewriting in C#.
iOS encourages MVC development, and doing it properly means it can be trivially ported.
My experience differs from yours. (Score:5, Informative)
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
Re:Advice (Score:5, Informative)
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.
Re:If you're gonna do it, do it right (Score:4, Informative)
Hopefully, the UI is implemented in the OS in both cases anyway, and all I have to do is call an API to get/put information to the user.
Re:Xamarin Monotouch and Monodroid. (Score:2, Informative)
(posting AC since I moderated a couple earlier posts)
Indeed, using MonoTouch [xamarin.com] and MonoDroid [xamarin.com] sound attractive. Even if it isn't perfect or you don't get full API coverage, at least (most of) your core app functionality could have a single codebase for most platforms (from mobile to desktop and web), and then just code the UI/platform specifics.
MS would be wise in helping the Mono project grow, increase the level of API support on more platforms (ie, at least to the level of the Compact Framework), so they can outgrow Windows, and embrace and extend most mobile platforms nearly overnight. They would still benefit from controlling the main framework on Windows, but would provide a viable interoperability path with other platforms (for better user experience).