Depends on what you want to do.
We've looked at this product as well as a few others and all have their pros and cons.
Also keep in mind that we did speak with people that had originally used some of these solutions initially and had to revert back to native for many different reasons.
From what I've seen with these tools, if you want just something basic and you are alright with the pitfalls of basically having the lowest common denominator on a given platform than go for it. But if you want something that is and feels really indigenous to the market you'll be in I'd shy away.
Also keep in mind that with these tools you are at the mercy of them either wanting to build out functionality or have people willing to pay for the build out of that functionality. The cost to pay for the build out has reared its ugly head quite a bit.
I liken it a lot with using a WYSIWYG tool for a website - it's nice to abstract it all out for the user and you can do limited stuff to really make things seem neat in those tools, but if you want to go beyond that you really need to investigate the route of spending the money for native development.
Excellent summary.
Maybe in that regard it's closer to comparing it to flashjester or northcode which gave SWF files some native app capabilities when run as exe and dmg installed apps, back in the day.
I think for what I am attempting, phonegap is more than adequate. (https rest services, displaying a data table on response)
Is it loading full capability of phonegap into the app despite the app maybe using a subset? Is it enough that users consider it bloat? (as in, why the fuck is this app 20 megs?!).
There is also sencha touch I think for this sort of thing......I don't really know the difference I just thought I'd add options to the thread for archival purposes.
Along those lines I was considering jquery mobile for the ui framework to run inside phonegap:
I think Phonegap has some use cases. Certainly getting prototypes out very quickly without needing to know Obj-C is a big one.
For serious, paid, professional iPhone apps, I'm not sure it's all that great.
every app i've seen that isn't native has some seriously slow response times. both in retrieving data and displaying it. i might use it with a prototype i had to do in a day or two, but not for anything i wanted deployed to support.
Android users will notice the bloat - while their reviews tend to be "nicer", they are usually on top of what you set as far as permissions in your manifest as well as the app size (which makes move to SD card something you'll want in that world).
In all reality, if you want to just do something utilizing JS / HTML / CSS etc, it's extremely easy to build that out yourself and not be reliant on phonegap. Working with webviews is pretty simplistic in your iOS and Android world (don't know much about WP7).
If you knew how easy it was to do work utilizing JS / HTML / CSS in those environments you'd kind of realize that you're throwing any sort of money away on their tools.
I wonder what causes the slow response time.
I have heard the same things about the mobile flex app thing too.
Originally posted by persist
I wonder what causes the slow response time.
I have heard the same things about the mobile flex app thing too.
It basically works by running html/css/js in a browser which is obviously crazy slow compared to compiled C programs.
I've tinkered around with PhoneGap a bit. Fun, and quite easy to implement (as others have said, without having to know Obj-C).
I'm definitely more in the dabbler camp, and found it surprising how quickly I was able to hook in to device-specific functionality (GPS, camera, etc).
One pretty great resource I found was Jonathan Stark's Building iPhone Apps with HTML, CSS, and JavaScript. It's a combo of jQTouch and PhoneGap, but helped me learn the basics and build out an initial sample app pretty quickly.
The responsiveness all depends on how you actually implement.
For example, on the android side you could easily pass the entire object / response / whatever into the web view from your bridge that you build. The biggest issue with this is two fold:
one is that it is inherently slower to do this. Tests I did with a recent set of functionality had the web view looping on all elements in a fairly large object in about 400-500ms. When I moved the looping code into the bridge and updating the web view accordingly the looping went down to around 10ms. And this was really just looping and no other functionality to just build a baseline of what the actual processing time was with no further action.
The other is memory leak issues. In the test I was talking about before I went a step further and started building out the actual screen entirely in the web view to take the object from the bridge and build the screen. I'd watch the memory heaps in DDMS and they would grow quite fast. When I reversed the code to where most of the work was in the bridge and it would just update the web view as needed the heaps stabilized. Another interesting thing I noticed is that the heaps would grow so fast that it would eventually crash the emulator. I couldn't quite get it to crash a physical device, but you could notice it was slowing it down. I didn't get to testing on an older device with less power (most testing I did was on an Atrix).
Phonegap was literally just acquired by Adobe btw.
Interestingly, part of that deal is to put phonegap in apache license.
I've started to reply to this about 15 times now - but I'm not sure I can give any feedback that's not going to sound completely biased.
As an objective-c developer, the idea of replacing an entire app with a webview makes me cringe; this is one of the most common things that makes me go "eww" when I come across it in the app store. That being said, integrating web views into an app is pretty awesome, and with a bit (read: lots) of care it can even be a great user experience.
I was actually bummed to read that phonegap is literally a web view, I was under the impression that it was a middleware solution that provided a native end product. Something along the lines of what Appcelerator's solution does. http://www.appcelerator.com/products/native-iphone-android-development/
I also recall a coworker showing me some kind of javascript-y solution that resulted in native code. I was pretty impressed with the result, but can't remember how he built it out.
poliguin is right about the easy of setting up a webview, at least I can speak to the ease of it in cocoa. The whole phone gap solution interacts with the native side of thing by leveraging a custom URL protocol that is then used in your links; a technique that's common in any tightly coupled web view integration.
I'm curious, is the goal cross platform compatibility, or speed of delivery? Outside of "to prove that I can", I sometimes wonder if it's not better to spend time just learning the ultra basics of getting a native solution up and running.
Originally posted by Jetskier79
I'm curious, is the goal cross platform compatibility, or speed of delivery? Outside of "to prove that I can", I sometimes wonder if it's not better to spend time just learning the ultra basics of getting a native solution up and running.
Bingo, that's the biggest one of my biggest rubs.
I've been spending the last couple weeks with a POC for moving to a write once run everywhere solution. We utilized it for blackberry and now they are trying to convince us that we should use it for all platforms rather than native work (iOS, Android, WP7, BB, and mobile web).
Cost aside (and for their licensing costs for us I could just about triple the team size I have right now and get functionality flying out the door) there are a lot of pit falls I'm finding. I've spent the last two days with the Android version they generated and with only half the functionality of the application working I've found 27 defects in Android that I would not allow it to go to production with. And this is just supposed to be the "out of the box" generated application where at least the core functionality should work - such as logging in, being able to pull a list of data associated with the user and display it, just core functionality that should work without any tweaking. If I were to look at design defects the number would grow to about 50 that I would not allow it to go to production with and have about another 20 that really should be fixed.
And that's just the Android version of the application. I still have to do this testing on WP7 and possibly iOS to see if there are any other major ticket items that are an issue on that platform. So I just scratch my head and wonder where is this promise of "write once, run everywhere"? And don't tell me that I need to dumb things down, I'd rather just not deploy the application with those sorts of constraints.
Originally posted by Portnoy
One pretty great resource I found was Jonathan Stark's Building iPhone Apps with HTML, CSS, and JavaScript. It's a combo of jQTouch and PhoneGap, but helped me learn the basics and build out an initial sample app pretty quickly.
Seconded - great starter book.
You're all being so helpful. Thank you. There are currently no goals, only platform assessment.