|[thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Kerri Shotts||4/2/12 10:41 PM|
First off, I just wanted to say what a fantastic community this is, and what a great thing PhoneGap is. That said, I wanted to share some of my thoughts about developing an app for iOS using PG vs. going the native route. Keep in mind that this isn't a knock on PhoneGap -- it's more a knock on mobile webkit development than anything, but I did want to get this out there in case anyone else is feeling similarly.
The projects to which I am referring are below:
PhoneGap Version: https://github.com/photokandyStudios/GreekInterlinearBible
Native Version: https://github.com/photokandyStudios/gbible [Yes, the organization in the folder structure is horrible. Load it up in XCode for a legitimately organized view...]
So I decided to tinker natively and to see what I could come up with. Surprisingly, after a few rough starts (especially when trying to wrap my head around storyboards), I realized that this was /so much easier/ than trying to shoehorn my html, js, and css into a native look & feel. After all, you get native look & feel for /free/ natively (obviously), but I've suddenly realized how important that is. I went through lots of tweaking on my UI (and its all important, and will have future uses, so I'm not abandoning the /concept/) to get it close, but there are just some things that I don't think one can ever /totally/ duplicate. [Okay, yes, you probably can. But it would be a ridiculous amount of work, and likely not nearly as performant.]
Now, I could probably have done something very similar by creating plugins that would do some native controls in phonegap -- and I did consider that. I considered creating tableviews and other controls that could live atop the webview, and then suddenly decided that if I was going to have to go to all that work, I may as well do the whole thing natively. Tableviews naturally fit my data model, and at that point, a very large portion of the code would be handled natively /anyway/.
I could also have gone the route of Nimbus/Appcelerator/etc. But in each there was something missing that I would need, and the more I drilled down into them, it quickly became apparent that if I was going to have to live in Apple's world, I may as well live in objective C/UIKit/etc. as well, rather than always going through someone else's wrapper around it.
And so here we are: I've got a project that (so far) is going quite well natively, and while there isn't feature parity yet (far from it!), I'm already feeling like I've made more progress than I did getting from 98% to 99% on the webapp. Why? Here's a few reasons:
Does native development have its issues? Yes - lots:
And even with all those quirks, I'm still happier with what I've got natively than with what I got with html, js, and css. Oh it looked nice enough. It functioned /almost/ natively. But look too close and you could spot the glitches -- like switches that you couldn't slide, or small differences in how shadows rendered, and scrolling -- don't get me started on scrolling! And then the performance issues that occur for no good reason on a simple list where in you could spend five seconds just /waiting/ for something /simple/ to happen. And there was no JS code running during that time -- it was pure webkit.
Anyway, enough of a ramble. I'm not abandoning phonegap -- no, I think it has a lot of potential. Nor am I abandoning the concept of a native-feeling web-based UI -- just that I was overloading webkit in this particular app. I fully plan on using the things I've learned in building mobile sites that act like apps, and I also plan on working on some phonegap plugins, especially now that I'm getting a much firmer grasp on Objective C and the Apple Way. But this is one app where I think native is the better choice, and so far, I'm feeling much better having gone native. Oh well, live and learn, right? C'est la vie!
So, I just wanted to share that and show a comparison between the two paradigms, including some code. Now, questions, comments, etc? I'm sure someone has something to say about all this. ;-)
|Re: PhoneGap vs. Native: Some Thoughts on Going Native||Giacomo Balli||4/3/12 1:05 AM|
there is no "one" tool to make something.
You always need to assess what is the best technology depending on
what needs to be accomplished.
I would never say I'm abandoning something just because it was not
ideal for one project.
In addition, every tool is at most as good as the person using.Perhaps
there could have been something to improve your code...
Just my to cents...
> - I'm not having to continually come up with a workaround for some silly
> webkit bug, glitch, or quirk. Believe me, this was quickly becoming the> - I'm not having to generate the native UI elements /and/ make them feel
> native. They just /are/.
> - Objective C and UIKit and Foundation, etc., are actually quite easy.
> You can get a lot accomplished with a few lines of code. [Nothing against> - I can really, truly /debug/ on this now! That was perhaps the second
> most frustrating part (aside from webkit getting in the way): no true> - Drop-dead easy gesture recognition. In comparison, the equivalent code
> to recognize a swipe gesture in JS is nuts.> - Lighter memory footprint. Of course, this just happens mainly by not
> having to load a webview, a javscript engine, etc.> - XCode gets twitchy about what it decides to compile and deploy.
> Sometimes it picks up a newly added file and does the right thing, and> - XCode likes to crash. Even on my loaded iMac that has lots of memory
> and space. Needless to say, saving frequently is a really good idea.> - UIKit does some very funny things. I mean why in the world is the
> background color of a table cell decided at one point, when the /content/> - /Customization/ of the native elements isn't as straight-forward as I
> would like. Apparently Apple's made great strides here, since before iOS 5> - Table View rendering takes a lot of thought to get right, and I won't
> even say I'm 100% there /yet/. Mainly because if you do much of /anything/> - The view hierarchy is both amazing and a bit nuts. I've programmed for
> Windows and Windows CE before, and goodness knows, it's nothing like that.> - Interface Builder/Storyboarding is too much magic for my tastes.
> /Especially/ storyboarding. It's great for getting a prototype UI down, but> - And plenty more...
|Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Sam||4/3/12 9:30 AM|
Thanks for sharing your experience ! Yes I agree with you, you can loose a lot of time if you want to emulate the native feeling and UI components. But, IMHO, if you want to support several plateforms, phonegap is the way to go. In addition, you can easily have your own UI design with CSS. You don't have to have a native look to sucess.
|Re: [PhoneGap] [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Phil Mitchell||4/3/12 1:07 PM|
On Mon, Apr 2, 2012 at 10:41 PM, Kerri Shotts <kerri...@gmail.com> wrote:
Thanks a lot for the insights. I'm curious to know where you were starting from when learning Obj-C? What languages did you already know and how long until you became productive in Obj-C?
Learn Bird Songs, Support Conservation: http://www.larkwire.comBikewise: http://www.bikewise.org
|Re: [PhoneGap] [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Kerri Shotts||4/3/12 1:59 PM|
Probably the biggest thing that helped me wrap my mind around Objective C was something I read somewhere, and I wish I could remember where... but it boiled down to saying that Objective C is a marriage between C and Smalltalk. I've had enough experience with smalltalk (back in my college days) so that helped cement the underpinnings of ObjC's idea of objects, which is both similar and disimilar to a good portion of the languages I'd previously worked with. In reality the only difficulty in picking up the /language/ of Objective C was getting used to bracket notation when sending messages to objects instead of dot notation (which is reserved only for property accessors). Given that I might write "object.doThis()" in JS, the same would be written "[object doThis]" in ObjC. The next biggest thing was in getting over how parameters were handled. While it is great for readability, it does tend to get verbose. In away, ObjC's methods are more akin to methods with named parameters that are required than they are to regular parameter passing (where it is done by position). For example, in JS I might write a function declaration as "function doThis (a, b, c)", in ObjC, I'd do "doThis: (type) a withB: (type) b withC: (type) c". Not that you can't do the other in ObjC, just that it's the preferred convention.
Of course, being a C-based language means that all the C notation is there too: you declare a string as "NSString *", and you pass variables by reference using "&" [when appropriate]. You also have to deal with primitives not being boxed automatically, so an "int" isn't always something you can use without converting it to an NSNumber. Or vice versa. Further, given C's proclivity towards type casting, you also see this quite often in Obj-C. Consider that all objects are of type "id", you often will see something along the lines of this: "(MyViewController *)[subviews objectAtIndex:1]" whereby I'm taking an object from the subviews array (which contains any object, but typed to ID), and then I'm typecasting it to the type I need.
Becoming productive in the /language/ was pretty quick. It really is a matter of understanding the grammer and syntax, and then getting used to the differences. What took longer, I think, was the concept of how the libraries worked to build the user interface. I've written programs for both Windows and Windows Mobile (when it was CE), and so I had a pretty firm grasp of how Windows constructed its UI. Apple does things entirely differently when it comes to iOS, and I had to unlearn my personal concepts of how UIs really did work. Getting used to the view hierarchy really was the hardest thing for me to do, and I won't vouch that I'm there 100% yet.
This wasn't helped by going the "Apple Way" and jumping into storyboards immediately, either. I think they are great for mocking up a UI quickly, and even including a good deal of interaction. For simple apps, it could probably work quite well. But to me, there was too much magic going on. The same tended to apply to Interface Builder when desigining forms and such visually. Yes, great, visual design for a visual user interface, but I don't know... I've always preferred my UIs in code. Perhaps because of the flexibility, the lack of magic, and/or this is the way I'd always done things. ;-) So once I dropped going with StoryBoards and Interface Builder, I was a lot happier and much more productive. I bought various books and looked at lots of sites (http://www.raywenderlich.com/ is a good one), and then got busy coding. After a couple misfires, the code that started to come out started making sense and actually working!
Consider this: the little objective C I /did/ know came from peering inside Phonegap and its plugins. Put that around January/February of this year. Now, by early March, with less than a month of intensive coding, I've got just over 5k lines of ObjC. Granted, to compare line count with performance, proficiency, efficiency, etc., is a fallacy, but it does indicate that there's plenty of stuff going on inside. Is the code excellent? No. Are there better ways of doing things? No doubt. Does it /work/? Yes. Is it working better than the non-native method? So far, /yes/. I don't want to think about how much of my non-native code was working around a webkit glitch, or was a tweak to get a little closer to native look & feel (lots), whereas here, the code is all doing app-specific work: loading data, displaying it, taking it from the user, etc.
That I'm probably a couple weeks away from feature parity doesn't necessarily indicate the effectiveness of ObjC as a language, or UIKit as a framework: a lot of this stuff I'd already developed for the non-native app. If anything, I could consider that non-native app a good mockup. The majority of the concepts can be used directly, and it's really just a rewriting of code. Along the way some changes were made, obviously, as would occur in any rewrite, but the concepts were already in place. Without those concepts in place, I'm unsure how long it would have taken to get here.
Okay, that's a long-winded answer, so the TL;DR of it is this: languages previously known: C#, C, PHP, VB, PL/SQL, BASIC, PASCAL, dabs of SmallTalk. Time from start to productivity: <3mo. [This is really closer to ~1.5mo, TBH, if you don't count my first failed attempt at storyboards. But it was part of the learning process...]
And just to drag this out a little longer, I don't mean to say that PG and/or non-native development never has its place. Just that it wasn't working out for me with this particular app. Had it been a different app, things probably would have gone differently. What is the right tools for this app (native Obj C) may not be the right tools next time.
Hope that made some sense!
|Re: PhoneGap vs. Native: Some Thoughts on Going Native||Kerri Shotts||4/3/12 2:23 PM|
Of course, nor am I trying to indicate that one tool fits all. It doesn't. Never will. That's why I use a /lot/ of languages ranging from C to PHP to PL/SQL. I use what I think will work best for the situation. Obviously that doesn't always work out, as I initially believed (and my initial tests seemed to indicate) that html/js/css would do the job for this app.
And actually, I think they would be a perfectly fine tool. It wasn't so much the language, it was the platform - that is, mobile webkit that got in the way one too many times. I perhaps should have retitled the post to Mobile Webkit vs. Native development, since this isn't PhoneGap's fault. It just provides the interface from webkit to some other native device features.
My frustration largely stemmed from having to debug what felt like a webkit issue vs. debugging my own code. First off, debugging is a pain in the rear anyway, and it is worse when there is no proper debugger for the platform. You can only go so far by developing in Chrome or Safari, and then using the iOS Simulator + Safari. After that, issues become issues /on the device/, and while Weinre is great, it's not a fully-fledged debugger yet. Oh, for the day it is, because then one of my primary complaints goes away. But until then, my point stands. And when the issues show up only /on device/, you're left with being unable to debug in a proper environment. Oft times I was reduced to console.log(). People, this is the way we used to debug 20, 30, 40 years ago.
If we discount debugging, the next big frustration was webkit. I /love/ it. Don't get me wrong. I use Chrome on my desktop (webkit). I use Mobile Safari on my iPad and iPhone (webkit). I /convert/ people to Chrome whenever I have a chance. I /love/ it as a browser, and as a platform. But when it translates to a touch environment on a mobile device, mobile safari has a long way to go. Let's see a few of my issues:
I could go on and on, but seriously, it quickly became a feeling of debugging webkit vs. debugging my app. Honestly, I'm not doing anything in my code, my stylesheets, or my html, that is that hard. Regular Safari handles it just fine, and that's perhaps the only hope that mobile webkit will improve in future versions of iOS. But when I'm feeling like I'm debugging the very platform I'm running on vs. debugging my own code, productivity goes down the drain, and I'm forced to consider other options.
It is true that the tools can only be as good as the person using them. This adage holds true in all walks of life. That said, I'm a pretty good programmer. I've been doing it for 20+ years. I've worked most of my adult life in programming positions creating successful applications for the companies I've worked at. Am I the /best/ programmer? No, by all means, no. Do I write hacks sometimes? Yes. Most programmers do at some point. Show me something /in production/ for a few years that hasn't become hacky over time. There's always an incredibly horrible exception to the rule, something most college courses and language purists like to ignore. Would I love to write pure, beautiful code all the time? Sure, but you may as well toss productivity down the drain, 'cause it just ain't happenin' in real life. Something always comes along to throw it out the window.
Could different code have alleviated my issues with performance? Maybe. Actually the majority of performance was quite good. In fact, the one place that should have been slow as molasses /wasn't/ (canvas). The final straw became a ridiculous 5s delay (sometimes - like I said, this was inconsistent at best) between selecting a /list element/ in a simple unordered list (and I do mean /simple/) and the display of the next list in the hierarchy. There was nothing in my code there causing such a delay. Of course I couldn't reproduce it in a full debugger either, since there is no full debugging on the device. So /maybe/ there was code somewhere getting run taking up all the time. There is simply no way to know at the moment. But something was getting in the way, it was inconsistent at best, and the feeling was: oh no, not /another/ webkit problem to work around. When that was the feeling, I decided it best to start over in an environment where, at least, I could debug properly if any performance issues came up. In fact, they did. (They /always/ do.) But this time I could use the debugging tools at my disposal and pinpoint the problem precisely. Oh, if only I could have done that non-natively.
|Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Kerri Shotts||4/3/12 2:29 PM|
Yes, for cross platform support, nothing comes close. But at the same time, I do feel it important to closely emulate the platform you're running on -- that is, if you're on iOS, use iOS conventions. If you're on Android, use Android conventions. Anything less is disconcerting for the user. (Though, perhaps, only iOS users will thumb their nose at it? ;-) )
I'll agree that you don't have to have a native look & feel to be successful either. Games are a great example of that. But my app really did need to look and feel native -- the content here was the more important thing -- the UI should just /blend in/, be /immediately understandable/ by the end-user, which meant it needed to act the way a typical Apple app reacted. And that means emulating native look & feel. I do think I got really close - about as close as possible without going insane and trying to be pixel-perfect. Ultimately it was less the UI that got me, and I think, more webkit's issues with handling it that did. With no proper support for debugging on-device where the problems occurred, it was impossible to fully figure out where the problems actually were. It was starting to feel like a webkit issue, simply due to this fact: the replacement I wrote to be /faster/ was -- and wasn't. Super fast on the iPad. Dead-slow on the iPhone. What's up with that? The two devices had comparable power (iphone 4 vs ipad 1). Why was webkit acting so differently on the two devices? I don't know... and may never know, though my brain does want to figure it out... just after I finish the native version that doesn't have to worry about it.
|Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Devgeeks||4/3/12 5:15 PM|
I think Android users would thumb their nose at a UI that looked like a ported iPhone UI.
I would if I was one of them :)
|Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Alper Çuğun||4/17/12 10:52 AM|
On Tuesday, 3 April 2012 07:41:17 UTC+2, Kerri Shotts wrote:
I hade the same on my current project but I had it after 5% in. It may not be Phonegap that was the issue, but I had half second freezes on event handlers for buttons in mobile safari and that was having only created a handful of very basic screens. I did a bunch of micro-benchmarks to see where the issues was, but being so fresh into the project, I thought I might as well switch to native development instead of wasting time polishing it and it slowing down on me in other places.
|Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||DanN||4/17/12 11:23 AM|
For now, I will continue developing my project using PhoneGap. If I switch my mind I will surely share my experience :)
|Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Dave Sims||4/17/12 7:47 PM|
Kerri, I could have posted this nearly word-for-word. Just finished porting my company's Android app from PG to native. I second your remarks that this is not an issue with PhoneGap. It's WebKit and rendering and choppiness and the heaviness of all the JS libraries, JQMobile, Sencha, even just JQuery or Zepto, the overall feel and performance of the UI just isn't there, doesn't feel like a premium app.
So I'm just chiming in to say I'm glad to see someone back up my experience, against all the noise of so many saying how HTML5 is the future and it doesn't make sense to write two native codebases, etc. I agree HTML5 is the future, it's just not the present, at least not for apps where UI/UX directly affects things like purchases and the bottom line (like ours really, really does). I do use WebViews with Zepto for targeted places where it makes sense, like detail views and other specific areas where I can re-use some of the mobile site's styling. Just not as the main structure of the app.
Again, no knock on PG, it's a fantastic framework, and I've recommended it recently. There's a lot of domains and contexts where it's a great solution.
|Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Dave Sims||4/17/12 7:48 PM|
Completely agree here. I've finally pared it down to nothing but Zepto unless I really really need something else. Even just getting away from core JQuery makes a big difference.
|Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||solartoys||6/15/12 11:09 AM|
I have 4 android apps running and want to move them to itunes. I purchased a mini with osx 10.6.8 and xcode 4.0.2 My 4 apps are simple display apps for trivia, mlb winners, nfl winners, and nba winners. They are display only...no user input..they display fine in xcode but crash when trying to look at build settings. I have ofps.oreilly's phonegap instructions but they are not for cordoba. What do I need to do to get phonegap running on the mini to this very simple task? thank you...bob
|Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Joe||6/15/12 11:54 AM|
I'm with Dave Sims on the not using one of the mobile frameworks, especially on iOS. I'll concede I use jQuery, not Zepto, though. If you're concerned about page transitions being shaky or flickering or something like that, just use translate3d to do all your moving things around and the GPU will kick in and everything gets nice and silky smooth. Can't wait til I can do that on Android, but 2.2 and 2.3 are still like 90% of the market.
The worst part for me is dev environment, especially Eclipse. Is there a better one around for Android?
On Monday, April 2, 2012 10:41:17 PM UTC-7, Kerri Shotts wrote:
|Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native||Joe||6/15/12 11:55 AM|
Did you try using ontouchstart instead of onclick?