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."
eh (Score:2, Insightful)
I'd personally call them migraines.
If you're gonna do it, do it right (Score:5, Insightful)
If you're gonna do cross platform app development, at least make the effort to follow the platform's UI guidelines. As an Android user, nothing irks me more than having an app with the iOS icons and navigation buttons simply copied over. I'm sure the same is true for users of other platforms.
Re: (Score:2, Insightful)
And nothing irks me more than users of any system expecting everything to work exactly to same with all the bells and whistles attached. F-ME for being a web developer that's had to deal with the nightmare that was (and sometimes still IS) IE 6 and the fucking "it doesn't work on my iPhone."
Sometimes, for production time purposes, and the rampant demands (re: bitching) of users, we have to take fucked up shortcuts to make things get done.
Re: (Score:2, Insightful)
Please spare us your software entirely in future then.
Re: (Score:2)
This post getting +5 insightful perfectly encapsulates what's wrong with many software developers.
Re: (Score:3)
No, it encapsulates what's wrong with project management in this industry. Failure to manage customer expectations and setting insane production deadlines isn't the developer's fault, it's the fault of the management layer that *should* be between the client and the developer.
Of course, in an ideal world, there would be someone there. There frequently isn't, or there's someone so ineffective there that it's *worse* than nobody being there. In those cases, the developer should be looking for a better job.
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.
Re: (Score:2)
well then... sounds like a problem for tool-makers (jquery mobile auto adapting, perhaps?) then app-makers...
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: (Score:2)
Is the back button there pr app in iOS, or OS provided like in Android (either hardware, or optionally, as one move to 4.x, software)?
If it is OS provided in both, i am not sure i see the problem. Unless one worry about putting a in app ui element confusingly close to a OS element.
Re: (Score:2)
I believe it's manually coded but all I have to base this on is that many apps implement the back button in different ways, and some don't have it at all. Not sure if it's part of a standard API.
Re: (Score:3)
On the other hand, when peole talk about not being able to write portable code, that's generally only true with some particular portions.
For the most part, the sorts of interactions available on touchscreen devices are similar. If your code accomodates that in a sensible fashion, the details of the particular language or smartphone API particulars should only constitute a limited portion of your app which is truly distinct from OS to OS.
If this isn't the case, you are mak
Re:If you're gonna do it, do it right (Score:5, Insightful)
There's no way of writing code that is portable between iOS and Android
There are several ways. If you want something using exactly the same codebase, companies like Adobe will sell you development platforms that wrap the native APIs and give you something that doesn't quite look or feel native on either. A better approach is to use GNUstep-base to provide an implementation of the Foundation framework on Android and then rewrite your UI for each platform but share the model code.
We've been through this before with desktop apps. If you want a good cross-platform application, make sure that your code uses a very clean MVC separation and rewrite the UI part for each platform. Otherwise you end up with something that, at best, only behaves well on one platform, and at worst feels wrong on all of them.
Re: (Score:2)
A better approach is to use GNUstep-base to provide an implementation of the Foundation framework on Android and then rewrite your UI for each platform but share the model code.
Why would you need GNUstep to share model code? Just write it in C++.
Re: (Score:2)
Android devices typically have a dedicated back button on their phones.
All android devices have a back button, software or hardware.
Re: (Score:2)
Absolutely not, the problem is that the tools, just like cross-platform desktop UI tools can't handle this.
A layout that makes sense on one platform might be complete bollocks on another; a gesture that's entirely sane on one platform might make no sense at all on another; a widget on one platform might support more modes than a widget on another.
The solution is to stop using cross platform UI tools, code the back end dirty work of your application once, and then write several UI layers to interface onto it
Re: (Score:2)
Re: (Score:3)
Too many youngsters who've never encountered "portability" concepts before? Are we going to get yet another push for a one-world-os just so people don't have to think so much?
Re: (Score:2)
No, we're not. I think we should have a push for developers actually heeding the design guidelines of the platform they're developing for. No more of this iOS back button in Android apps bullshit.
Re: (Score:3)
No, it will not kill them, but it may mean it takes an unacceptable amount of time to do, and cost way to much.
Re: (Score:2)
If you've got the time to make the app, you've got the time to do it right.
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:If you're gonna do it, do it right (Score:4, Insightful)
No, that's exactly how bad cross platform apps work. Good ones code the back end once, and have a different UI module for each platform interfacing onto it.
Re: (Score:2)
Cross platform apps (see Adobe) have a consistant UI, no matter what they run on. Some exception may be taken to make it align with the underlying OS's visual theme system, but that's usually limited to the "titlebar" piece of the application and not the menus.
Ah, yes, the "Write Once, Suck Everywhere" approach.
One app to make, multiple to purchase (Score:5, Insightful)
The one thing that irks me a bit about this whole situation is them complaining that they just can't write the code once and have it work across the different platforms, yet I'm still required to buy the same software separately on each platform. In my mind, you justify the cost to make it work for that platform by selling it on the specific platform. My opinion would probably be different though if I was able to buy the app once and not have to pay on each separate platform.
Re: (Score:2)
You have a point if the app is a commercial product developed by a company with several employees, UI designers, and the resources to maintain different source trees. However, for individual developers being locked into platforms (and platform-specific languages as in iOS) is more than just a minor nuisance -- don't forget that for many applications most of the development time nowadays is spent on GUI and packaging instead of the actual functionality.
Consider it that way: If it were possible to do real cro
Advice (Score:5, Interesting)
Keep it simple, Stupid
I'm developing an app which can be run cross-platform and/or mobile. Turned out to be a giant nightmare when looking at user experience on a tablet or smartphone. So .. I bailed on anything whizzy and went back to finding the basic html and javascript to get things done -- look and work consistently on multiple platforms and also be visible in sunlight (something a lot of apps fail miserably at.)
Re: (Score:2)
Here's the thing: Is your thing a website, that I access through the browser, or is it an app I purchase (or just download) in the platform's market? If it's the first, then ok. If it's the second, then that will just suck ass.
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: (Score:3)
PhoneGap still imposes the security model that other applications support. For instance, you can inform users that it collects GPS data and Address book or forgo support for that plug-in entirely. They support this both with manually building it via the Android tool chain as well as through PhoneGap Build service. Reason being is that the API for PhoneGap is just communicating with native code underneath to access things like GPS and address book, requiring the permissions model all other Android apps use.
Re: (Score:2)
Android: This is a potential problem with pretty much any Android application, regardless of how it's built.
iOS: Any app caught trying to update itself without going through the approval process will be pulled, again regardless of how it's built.
There is nothing substantially different about the security model of a PhoneGap application than that which can be imposed upon a traditional app. I say this as a developer who has spent some time with PhoneGap producing applications for both platforms.
Re: (Score:2)
Not as much as you indicate. Updates distributed through the Android Market still have to be signed by the appropriate developer key. It's easier to hijack a website than it is to hijack a code-signing key. (Also, updates which change permissions are presented to the user, and I've seen more than once that an app's marketplace rating has taken a nosedive when users objected to a new permission being r
Re: (Score:2)
Actually, without hacking Phonegap, at least on iOS, the first time you access geolocaiton, it pops up the standard 'APP_X would like to use your location' message - we had to rework our Phonegap app to do that properly, instead of having a trainwreck of a URL in that notification.
Android had a better model for security, frankly, in how you build an app - as part of the configuration, you can indicate with a fair degree of granularity what rights you want your app to have, and our upcoming app will only ha
Re: (Score:2)
The fact is, for web shops tasked with doing a "mobile app" because it's the next f**king Web 2.0 buzzword-compliant "we're serious - we have an app and everything", being able to do a shovelware mobile app without having to learn 2 new languages is great. Our customers go away happy, we don't have to spend the time becoming experts in yet more arcane single-use dev frameworks, and we can go on to the next project.
Great for everyone, but the users. The majority of apps that use these frameworks are very lazily done, and will typically make the app match the iPhone look and feel, and then push that crap out to everyone else. Nothing tells me quicker that an Android app is going to be absolute shit than seeing a title bar with a Back button in it, lifted from iOS.
Re: (Score:2)
My experience has been you are far better off to split the difference using MonoTouch and Mono for Android to do a common backend and then using native UI. Phonegap is an interesting idea, but it tries to map a little too directly to be able to optimize well and it sacrifices too much UI control.
Re:Advice (Score:5, Interesting)
So you're coding in the most inefficient way for each device to run your app then?
I feel for you. Your problem has been experienced by many who don't wish to rewrite that Objective-C app in Java, don't want to maintain two packages on different platforms without common bugs, and don't want to re-design your app so that on iOS it has a back button in the top left while on Android it obeys the hardware back key.
However before you continue I suggest you look at the ratings of apps on each market that are written in the way you're suggesting. Inconsistent with the native UI of the platform makes the app look .... cheap. An app that runs in HTML / JS is inherently incredibly slow compared to a native app which further upsets the user experience.
If you want to write a 5star app you'll likely need to abandon any hope of cross platform compatibility and simply code from the ground up for each platform.
Re: (Score:2)
Re: (Score:2)
There's no fundamental reason why an app written in HTML/JS can't have native look and feel or work "incredibly slow". Most apps don't do heavy CPU-bound computations, so JS perf is not really a problem. And UI fidelity is only as good as you make it - problem is, most people using HTML for UI just don't bother to actually make it look good.
Even so, GMail app is actually pretty good and "native looking" for being HTML, and that's just one example.
Re: (Score:2)
Except that, as the article said, users drastically prefer native apps to web apps. If your idea of a mobile ui is to make a site and use that in a hidden browser, you are setting up a path for user disappointment. That said, implementing and managing a couple of different object view front ends on top of a solid object modeled back end is not a big deal. Are there some frustrations, sure, but I haven't really found it to be a significant issue. The bigger issue is that in general, a lot of the current
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.
HTML5 & Weever Apps (Score:3, Interesting)
In the meantime, cross-platform, easy-to-develop HTML5 app frameworks are showing astonishing growth. In the least week alone we've seen three new Javascript + HTML5 frameworks released. And while it take consumers some time for consumers to get wise to the AOL-like 'we are the only (mobile) web' branding that Apple has established - the marketing advantages of one app that works across all touch phone and tablets and is actually affordable is pretty undeniable today - especially as web-app technology continues to mature.
At Weever Apps (disclaimer, I'm the lead designer) that's the goal: disrupt the expensive, case by case, walled garden model and produce useful apps that actually meet the end-goals of most organizations. We started as a couple of not-for-profit oriented programmers that just couldn't stand how bad the current mobile/web/app situation was out there - our clients couldn't afford a proper mobile experience for their constituents, and that pissed us all off...
Today, we've grown. We've hooked into amazing, established open-source web technologies like Wordpress, Joomla! and Drupal, created an open API and new RSS spec (RSS3 for semantic/web relationships, find it on github) and basically proven that web innovation can outpace mega-companies - we know this, because we're doing it and winning over former native-app clients. And are *web* apps are still affordable, useful and *accessible* to the at least 3/4 of companies that haven't 'gone mobile' today because of a combination of cost, utility and just sheer confusion with all the per-platform options out there.
Check out "Why I make web apps" by our lead programmer Rob Porter:
http://webweaving.tumblr.com/post/15651092883/why-do-i-make-web-apps
Or just get a free app at http://weeverapps.com if you're interested. We're new and still adding lots of features - but I can confidently say that we're proving that there are better ways than the status quo to add value to the web and mobile - and we're not the only ones doing it. :)
The Horror: Competition (Score:2)
Not that bad (Score:2, Interesting)
Check out LiveCode Runtime Revolution and you'll quickly dismiss this complaint, it has support for almost all desktops, tablets and mobile phone platforms. Write it once and it compiles for the platform in native code.
We use the hell out of it for the reason discussed above, not to mention that it allows you to build attractive cross platform products.
Re: (Score:2)
Re: (Score:3)
Apple can reject your app for any reason they seem fit, whether right or wrong. We have written a handful of apps that are on the market with RunRev, three were approved without issue and two were rejected.
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: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.
Re: (Score:2)
Slightly off-topic, but an interesting point:
Windows Phone 7 does actually allow C++ in apps. You have to wrap the API using COM, but that's not hard - an hour of work at worst, once you have the development environment set up - and after that the managed part just uses the ComBridge API (P/Invoke is not supported) to load your COM library and can call into it trivially.
The catch: ComBridge is not publically documented, and unless you get an exemption from MS your app will be rejected if it uses it. There a
Re: (Score:2)
For Windows Phone, it's a bit more difficult since the core may need rewriting in C#.
There is a trick you can use for that - this basically entails writing the core logic in a subset of C++, such that it can be compiled both with C++/CLR in /clr:safe mode (giving you verifiable assemblies that'll work on WP7), and with any C++ compiler to native code on all other platforms. You need platform-specific macros for classes and structs, and template adapters for object references, arrays and strings to make that work. And this won't let you compile pretty much any pre-written C++ code (so you ca
Thank You (Score:5, Insightful)
As an iOS developer, I heartily thank you for continuing to use cross platform development solutions that leave such a wide gap for someone to come along and write a better native app.
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: (Score:2)
it is entirely possible to have good software that is cross platform
BULL*cough*SHIT!
Re: (Score:2)
Well that's cute. Show me how it's impossible?
I think expecting a rational, well explained response from you is asking too much.
Re: (Score:3)
It is impossible to prove that something is impossible, but I'd you're right, it should be easy for you to find examples of cross platform mobile apps that are as good as natively developed ones.
Re: (Score:2)
If it's possible I haven't seen it. Got any reasonably common examples?
A non-trivial app(lication) is worth customizing the UI for each platform - it's not that difficult compared to the value of the app. Microsoft does it for Office, Adobe does it for all their applications. If your app is so trivial that it's not worth redoing the UI... well, it's probably crappy anyway.
CODE can certainly be cross platform, and very good. Entire applications can be cross platform and decent, but they're never as good
Re: (Score:3)
You can get away with it if you build a custom UI with a solid cross-platform language/API geared for UI work (Qt stands out as an example on desktops - not sure how good it is in the mobile realm), or you can get away with good results if you write your own UI from scratch.
OTOH, trying to write for one platform's little UI esoterics (even if you're trying to avoid them), then trying to graft all that onto another platform? Yeah, that'd end up leaving a gap 10 miles wide in most cases.
Like you said - it's p
Of course it's possible to have GOOD software (Score:2)
Ah look. It's the Apple Zealot who refuses to acknowledge that it is entirely possible to have good software that is cross platform.
Look, it's the Apple Hater who knows squat about mobile programming.
In fact I would say for enterprise development, where there's basically no competition and the bar for standards is low, that makes a lot of sense and you can have a good app.
However in the general market given a cross-platform tool and ANY native toolset (Android or iOS) I can always build an application that
For Enterprise, yes (Score:2)
I was just trying to keep my original method sort and pithy and trap the Apple Haters into a response (success! Not you of course).
You are right though that for enterprise use cross-platform tools can work - although I think enterprise developers should be looking at what the internal target market is using and build to that - i.e. sales forces are in fact just using iPads pretty much and it really makes sense to build a better tailored application that takes full advantage of the iPad.
Re: (Score:2)
Did you watch the video? Did you understand the functionality shown there? Would you say it'd survive just because of 'lack of competition'? Do you think the best under100 U$ app sold in the app store is more complex than the ERP shown there wroking on Android and updatign a remote DB in realtime?
I used to be an enterprise developer, for over a decade - working on all kinds of similar very heavily data-driven systems, many with lots of complex forms as well.
YES I understood what was going on in that video.
I don't care about BEAUTY (Score:3)
Not everything is about beauty
I don't care a whit about beauty. What I care about is USABILITY. That app (like so many other enterprise apps have worked with) was built by a bunch of people who didn't have to use the damn thing day to day. I didn't say anything about the widgets or color or anything. I just said it was not a very usable application and that could be improved.
I, like so many other enterprise developers, had to work with what people were trying to design but also listen to the complaints
So? (Score:5, Informative)
Success requires effort. Nothing new here.
Re: (Score:2)
... and standards do not define success only consistency!
Re: (Score:2)
And success is often dependant on consistency. People favour apps that are predictable, familiar and easy to use.
Re: (Score:2)
I hear you. But it would be preferable if we could spend our effort on something more constructive than dealing with idiosyncrasies of different platforms. This could be a solved problem if the different platforms weren't more interested in vendor lock-in than advancing the state of the art.
If I can only see the back of the dude in front of me, it is because I'm standing on the shoulder of a midget.
yeah, and...? (Score:4, Insightful)
Follow proper MVC development and save time (Score:5, Insightful)
The only thing that was really required was writing the UI, which was targeted for Android.
Re: (Score:2)
Only the UI? Your app on iOS was coded in Objective-C, or so I presume. You can abstract data and business layers, but still, it's written in Objective-C.
Now how did you use that code on Android, which requires you write your app in Java?
I can think of some solutions, such as compiling your Objective-C to object files, then use JNI to call the methods, but I wonder if you took this or another route.
Re: (Score:2)
"Only the UI? Your app on iOS was coded in Objective-C, or so I presume. You can abstract data and business layers, but still, it's written in Objective-C."
You are not required to use Objective-C for everything on iOS, only the GUI interaction (Cocoa). You can develop libraries in C or C++ and reuse these from Objective-C using Objective-C++ [stackoverflow.com].
Re: (Score:2)
Re: (Score:2)
Duhhhhhh.... (Score:2)
And you know what else irks me? (Score:4)
All these people speaking different languages. I mean, like, the French have a different word for everything! It means I have to have hire somebody who speaks some stupid language if I want to sell my software to them. Why can't we just have one language--English, obviously, since that's what I know? It would make my life a whole lot easier and I wouldn't have to spend money translating my software and adjusting dialog boxes for those damn foreigners!
And don't even get me started on Unicode!
In case you're missing it, the above is sarcasm. But it leads into an interesting point. How many times have you heard someone complain about having to deal with someone on the other end of a support line for whom English is not their native language? About having to dive through some weird accent in order to understand what they're saying? It makes customers not want to call their support line, right?
Similar thing here. I want an application that speaks the language that the OS developers have defined and that I have learned by using countless other apps. While, ultimately, it's about what your app does, if I have to choose between an app that has a native interface and one that does not, I will choose the native interface. Just like if I have choice between speaking to Ken in Minnesota or Pruthvij in Delhi, I'd probably choose Ken (at least until I discover that Ken doesn't know his ass from his elbow).
Want a write-once run anywhere app? Make it a web app. I use plenty of those on my iPhone.
Whatever (Score:2)
And? (Score:2)
Cross-platform desktop development is no picnic either. I once had to write a simple computer hardware check script - figure out what's in the machine, check against a list of programs, then spit out some XML. Came out to ~200 lines of Perl code for the Mac version, and ~150 lines of C for the Windows one. Not a single line of code was the same. Did I complain?
Well, yeah, I did complain, but more about how retarded Microsoft's APIs are than about having to rewrite stuff.
I'm also working on a video game in m
Re: (Score:2)
Now that C support in Android is getting better and better, it is completely possible to write the bulk of your program in cross platform C/C++, and only have to add in the UI hooks for the individual platforms. Of course this leaves out WP7, but really, with a c
Re: (Score:2)
Never mind things like ALT+number is tab change in Linux Firefox, but CTRL+number is what is needed in Windows...
Mobile? (Score:5, Insightful)
This should have been: The Headaches of Cross-Platform Development. It's not just a mobile thing. Today, if you're developing any kind of client-facing software then it's not just Android vs. iOS vs. WinPhone vs. BlackBerry. It's also PC vs. Mac vs. Linux. with IE vs. Chrome vs. Firefox vs. Opera. And of course, all of these on different devices with difference capabilities, most notably different screen sizes and input methods, and deployment options. So much wasted time and effort.
We were on the right path with webapps for a while, but then suddenly native apps became all the rage. The worst "feature" by far of native apps is they have to be installed - the deployment issue is practically gone with webapps, but contained apps let you charge people for installation, so we went back to that.
I pray HTML5 manages to become a capable and dominant platform for the sake of both users and developers.
Re:Mobile? (Score:5, Insightful)
Webapps are like cross platform apps, but on top of that they're crammed into a medium that was never meant for them, so instead of being just non-ideal they truly suck.
The only people who like web apps are the ones who don't have to use them (managers) and people who liked the idea of being able to get their e-mail anywhere, before everyone started carrying smartphones with... a native e-mail app.
Re: (Score:3)
ahhh yes do I reply or do I mod... Damit!
I pray HTML5 manages to become a capable and dominant platform for the sake of both users and developers.
You may pray but your prayers wont be answered. Well they might, but I seriously doubt it. The problem with whole web thing is that it is stateless. It is really as simple as that. There are tons of kludges to try an imitate a statefull connection but they are all hap hazard and only barely effective. The other problem are actual data aware components. Sadly even html5 does not address this. There should be a control type that accepts a mask like almost every
Re: (Score:2)
You know, I'm not ready to go public, but I've made a solution for html that does present an actual stateful app feel while keeping all the best of css, etc. And just what you outlined. It is possible. Out soon...
Re: (Score:3)
Until wireless carriers stop nickle and diming for data, apps are going to be the way of the foreseeable future.
Install all you want on wifi, it keeps data tx/rx needs smaller while on the go.
Re: (Score:2)
"This should have been: The Headaches of Cross-Platform Development. It's not just a mobile thing. Today, if you're developing any kind of client-facing software then it's not just Android vs. iOS vs. WinPhone vs. BlackBerry."
True, but for desktops, cross-platform development is considerably easier, and is, in many ways a solved problem. I.e. Qt [nokia.com]. However, for Android and iOS development, you have to deal with different programming languages for the UI.
For Windows Phone 7, this is even worse. On both iOS and
Xamarin Monotouch and Monodroid. (Score:2, Interesting)
This seems to work pretty well across platforms. Fast native compilation to binary same as C++ (NO JIT) via LLVM on both Android and iOS. Full access to the native API's. A pretty nice generational partially copying gc. XNA and OpenGL across all platforms. Full source debugging and profiling on all devices and simulators.
Only problem is that full binary compilation breaks some standard libs that depend on using the JIT, some occasional bugs, and I'd personally prefer to see the device API wrapping full
Re: (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
Re: (Score:2)
Monotouch and Monodroid are in no way interchangeable, beyond C#(or whatever Mono language they can use).
Oh please (Score:3)
No, you want a nightmare? Imagine you had to write one app that compiled and worked on an Android, iPhone, windows phone, and blackberry. Then you're dealing with the headaches of a web developer.
fail = not designing correctly to start with (Score:2)
cross-platform development is not hard.
the issue is when a developer focuses on one platform; utilizes special functionality and then says "oh.. i need to support that platform to". this is purely a design problem; not an industry problem. if you know, you need to support multiple platforms - one key word.. ABSTRACTION. separate platform code from business logic. that way; when you need to add a new platform, you have a small layer of abstraction to implement appropriately.. games are easier, as UI isn't an
Re: (Score:2)
There's absolutely no technical challenge in doing crossplatform development for mobile, relatively speaking, so abstraction won't help. As said in the summary, the problem is the user expectations are different, and no amount of technical solutions will help.
You said it yourself: "its a design problem". Thats just the thing: 99.999% of the challenge is the design. Coding is the trivial part that anyone can do.
Cross-Platform 'Native' Development can work (Score:2)
I'm not particularly interested in native development, maybe I should be, but I've looked at a number of technologies, initially Flex with deploy via Air, then Phonegap [phonegap.com] and finally settling on Appcelerator. [appcelerator.com]
Particularly for slower Android phones, Phonegap HTML5 apps really suck with many reviews having the classic "really like the app, but it was just too slow to be use-able". This is a killer and this issue will go away in the first world, but will never go away in the developing markets, just look at Aaka [wikipedia.org]
Die JS, Die! (Score:2)
Web apps will never become the best platform as long as they are built on javascript.
What a piece of shit language. I have used it and I truly hate it.
I'm not the only programmer who feels this way either. Google is trying a few things to reduce or even eliminate programmer usage of JS. Have a look at their Dart language or their Native Client initiative.
If a web browser could be properly sandboxed (like native apps are right now) and the webview widget could run native code instead of JS in the sandbox, th
This looks like a job for a car analogy! (Score:2)
So.. We need a way to design one car that works everywhere and follows the guidelines of the country, state, region while still feels natural.
1) Since the car will be driven in both American and European areas, the steering wheel must work whether you drive on the left or the right side of the road, and automatically know whether to display miles or kilometers.
2) Not every road is the same size, so we need to compensate for when you go down long, narrow roads, or if the road is wide so you can see more, wha
Re:lol, cry more, noob (Score:5, Interesting)
well.. not strictly true. IIRC iOS and android are both converging on (or already have) a view-based hierarchy... the way god intended. Personally i hate the signal-and-slots or win32 methods versus the DOM/events methodology - even if HTML's take on it is a little sprained... however, when i look at iOS, i see the DOM/event pattern, just without the xml (for the programmer, anyway, it's right there in the NIB..)
Re: (Score:2)
Personally i hate the signal-and-slots or win32 methods versus the DOM/events methodology
What, exactly, is the difference between signals & slots and DOM events, except for the fact that the latter require the listener to be an object implementing a specific interface, while the former can directly hook up any method with compatible signature? (i.e. less boilerplate)
It sounds vaguely like you were trying to compare signals/slots versus MVC, though of course they are largely orthogonal (in signals/slots framework, controller is what provides the slots).
And I have no idea what "Win32 methods"
Re: (Score:3, Insightful)
Who said it was hard?
What it is, is a royal pain in the ass. So where is your unified API that wraps all of the Android, Kindle, iOS, and Windows devices allowing a body to write once and deploy everywhere, having said app look and act like a native app?
Oh, that's right. I should have figured: up your ass. Right there beside your head.
Re:The past repeating itself? (Score:4, Insightful)
I wonder what it will take to "unite" them
Nothing. They dont want to be united. The "app" ecosystem is a competitive advantage for the OS. If all the apps are available for all the platforms, its no longer an advantage. Where do you think the "There's an app for that" slogan came from?
Re: (Score:2)
Or, perhaps right now there is a young Finnish college student writing a new OS even as I type...
I had high hopes in some Finnish guys, but then they sold out to MS.
However, there is still hope with Qt, as it runs on both Android and iOS. I don't know how well it runs, or how integrated it looks, but it's possible.
Android: http://sourceforge.net/p/necessitas/home/necessitas/ [sourceforge.net]
iOS: http://qt.gitorious.org/+qt-iphone/qt/qt-iphone-clone [gitorious.org]
Re: (Score:2)
How do you mean an other Microsoft ? It could just be Microsoft.
Re: (Score:2)
I thought flash was about to die for the mobile.
This is is why i used phonegap for my app. Then a previous comment suggests that phonegap is a liability. arggggh
Re: (Score:2)
Re: (Score:2)
Ofcourse not, just look at Apple for example. Apple marketshare would decline. They have expensive devices than Android. But more apps.