Write your app in HTML5, upload it and get back app-store ready apps(build.phonegap.com)
build.phonegap.com
Write your app in HTML5, upload it and get back app-store ready apps
https://build.phonegap.com/
96 comments
> But, are there any successful apps made with PhoneGap?
Define successful. Because, let's be honest, if I need an application for my company that will be used internally, does it matter if you haven't heard about it? Don't get caught look at this from just one point of view.
Define successful. Because, let's be honest, if I need an application for my company that will be used internally, does it matter if you haven't heard about it? Don't get caught look at this from just one point of view.
The new LinkedIn and OkCupid apps are primarily HTML5 based. Not quite the same, but every new release of the Facebook app seems to have more of its existing views replaced by HTML5 counterparts.
I'm fairly certain that the Facebook iPhone app does not UIWebViews to render anything. Their fast-scrolling tableviews are painstakingly crafted from scratch, natively, and (I believe) still use Joe Hewitt's framework for complex view rendering. I know some guys on the Facebook iPhone app team and they're die-hard Cocoa developers, I can't see them ever saying "screw it" and using a UIWebView with HTML.
Some, but not all, table views were replaced with web views a few months ago. News Feed is one example that is now HTML.
I'm not always proven totally wrong on HN...
...but when I am it's by Joe Hewitt. TGIF!
...but when I am it's by Joe Hewitt. TGIF!
Hm. How do you handle progressive loading? Do you even bother, or do you just load up the entire news feed and let the WebKit struggle with keeping images in-ram/in-cache etc?
Netflix uses an interesting WebKit-based approach for progressive loading.
Basically, they reuse cells like UITableView does.
http://cdn-0.nflximg.com/us/presentations/htmltvui/oscon-201...
Basically, they reuse cells like UITableView does.
http://cdn-0.nflximg.com/us/presentations/htmltvui/oscon-201...
Thank you, good sir!
I just watched this video (http://gigaom.com/2011/09/27/facebook-mobilize-2011/) where Facebook's head of mobile product talks (a tiny bit) about using HTML5 in their mobile products instead of all native development to keep pace with launches on the Facebook desktop site.
Check out the video at ~16 minute mark.
Check out the video at ~16 minute mark.
As if by magic, this story was just published: http://www.readwriteweb.com/archives/how_facebook_mobile_wil...
Are writers scouring our discussions looking for topics for their readers?
It took m a few seconds to realize what is wrong with "HTML5 fist of rage" logo in the article. The fist has 6 fingers. To be fair the original HTML5 logo isn't that much better...
6 fingered fist is the original logo. (More precisely, it's the best we had to use until the release of the w3c one you're referring to.)
not magic, TechCrunch and other blogs have been talking about Project Spartan for months. The screen shots were leaked yesterday, which is news worthy...unlike our comments.
Go to your profile and swipe left on a wall post and observe the "Remove" button and its animation. Now go to the bottom of your wall, and tap on the "See more posts..." cell. Notice that the activity indicator is an animated GIF. Open the app frequently and you'll see certain elements in the UI automatically changing without downloading an update. Or check out m.facebook.com and play around with the news feed that is identical to the one in the iPhone app.
Granted, there are other approaches you can take to get this behavior, but I'm not sure why you would. My impression is that they're using HTML5 in these areas.
Granted, there are other approaches you can take to get this behavior, but I'm not sure why you would. My impression is that they're using HTML5 in these areas.
I stand corrected! I got confirmation from both Joe Hewitt and JazzyChad that they are indeed webviews used in many places now instead of native tableviews. Disregard everything I said :)
Hmm, they're not using the native UITableView animation for editing, but that doesn't mean it's HTML. It's just clunky animation, mostly because each cell is doing a lot of drawing translation due to it all being three20. Also, the "see more posts" cell at the bottom is a TTTableMoreButtonCell (https://github.com/facebook/three20/blob/master/src/Three20U...) I believe.
I know that Facebook is very pro-HTML5 but I don't think there are any views in the native iPhone app that are not native UIKit or based on three20. I'll ask around, would be nice to now if there's any shared code at all on their end.
I know that Facebook is very pro-HTML5 but I don't think there are any views in the native iPhone app that are not native UIKit or based on three20. I'll ask around, would be nice to now if there's any shared code at all on their end.
It is easy to get fast scrolling pseudo-UITableViews using UIWebViews, as long as 1) the tables aren't /that/ long, 2) you change the grid size to something larger than default (to avoid checker-boarding), and 3) you decrease the deceleration constant to match those of normal tables. (Note: I know this from experience with a very widely deployed application: Cydia.)
And I uninstalled the OKC app within a week of them making the switch. Changing it to every action being roundtrip-based made it unusably slow. A total misstep, if you ask me.
Apple's "App Store" app on iOS uses HTML...
Haha - Indeed. It didn't load the style sheets for me once. Not a pretty sight.
Our app (Zite for iPad) is 90% HTML5+js and (I think) is reasonably successful.
Is it made in phonegap though? ie. The only native control on your app is a web browser window?
The FT app is based on html5. Initially, they had an app, but transitioned quickly to html5. Takes a wee bit longer to load, but barely notice that anymore. The experience otherwise is pretty much the same. And for what its worth, it's the best news app on my ipad.
This has always been my feeling. It hasn't made me any friends though.
Phonegap is a great feel good piece of technology, that browser enthusiasts can point to and say, "See this is what you can do with the web".
Phonegap is a great feel good piece of technology, that browser enthusiasts can point to and say, "See this is what you can do with the web".
Just wait till Spine Mobile is released on the 4th of October at FOWA:
http://cl.ly/Aa4V http://cl.ly/Aa7P
http://cl.ly/Aa4V http://cl.ly/Aa7P
Looks great maccman. Here's a little more context if you're not sure what he means by "Spine Mobile".
http://bit.ly/q7Wrkr
http://bit.ly/q7Wrkr
Mobile browsers are getting better and better, and apple's iOS happens to have the best. I think the app store distribution mechanism is the main reason you don't see many html apps. It's the big entry point, there's a huge network effect and its cool to say "we have an app for that". Maybe facebook's project Spartan will spark the inevitable switch to html. I mean, check out twitter or kindle on the ipad... what are they lacking in?
https://build.phonegap.com/docs/ios-builds
"Since PhoneGap Build uses Apple's standard development process to build applications, you will need to sign up for their developer program to build iOS applications on PhoneGap Build. You will also need a Mac to configure your certificate and provisioning profile."
:(
"Since PhoneGap Build uses Apple's standard development process to build applications, you will need to sign up for their developer program to build iOS applications on PhoneGap Build. You will also need a Mac to configure your certificate and provisioning profile."
:(
Check out AppMobi[1], it may be what you need - at least, from my brief glance at it, it looks like it: build iOS and android apps using HTML+JS, no need for a Mac or the iOS developer kit. The core tools are free too, but they charge for services such as compiling your program for iOS and such. They also have something called DirectCanvas which is basically HTML5 canvas without the rest of the browser cruft, for higher performance canvas apps (eg, games - they have built in support for the Impact JS game engine, for example).
[1] http://www.appmobi.com/
[1] http://www.appmobi.com/
It's "just" a code generation tool
I'm writing really a very large app for the company I work for. We're using PhoneGap with HTML and JavaScript and have many plugins.
What we are not having problems with is the fact that we only really have a single thread to do everything. All I can say is that I'm glad it wasn't my idea to build it this way.
What we are not having problems with is the fact that we only really have a single thread to do everything. All I can say is that I'm glad it wasn't my idea to build it this way.
This is a surprisingly often ignored limitation of the browsers. You need threads to achieve decent performance given any significant complexity, and mobile CPUs are going multi-core.
Yep - Buttons are bad enough, but things like sliders are just the worst things imaginable!!
I thought it might be worth looking into web workers, but everything seems to interact with the DOM so that's not much help either.
I thought it might be worth looking into web workers, but everything seems to interact with the DOM so that's not much help either.
Speaking as someone writing a fairly major HTML5 iOS app using Jo and PhoneGap: this looks like a very helpful way to take the make-work out of the case where you have an app that uses no native functionality, and is not in any way optimized for best appearance.
That's not a knock - a lot of people have that use case, and spend a lot of time on their own systems for deploying to multiple platforms. Consider internal apps, for example, that don't have to be massively visually slick and polished.
But ... given the very large differences between even similar platforms, and even between versions of platforms, you're not going to be getting much from this if you are building ultra-slick apps in which you really do need consider, say, how hardware acceleration or browser quirks fit into the picture.
That's not a knock - a lot of people have that use case, and spend a lot of time on their own systems for deploying to multiple platforms. Consider internal apps, for example, that don't have to be massively visually slick and polished.
But ... given the very large differences between even similar platforms, and even between versions of platforms, you're not going to be getting much from this if you are building ultra-slick apps in which you really do need consider, say, how hardware acceleration or browser quirks fit into the picture.
Nice, and I use PhoneGap for Android, but you lose all the niceties like access to hardware buttons (which means you convert limited screen space to menus) and keyboard and intents and whatnot.
I had to write some plugins to get my game working on Android (and there are still compatibility problems around opening intents), so PhoneGap apps definitely lose something in the usability department.
And of course animations are not successful in this environment.
Ads are a pain too, if that's important to you, with the Google Admob/Adwords migration happening and the mobile web vs app ambiguity.
PhoneGap seems helpful as a part of the app's main UI, but native chrome is still important to completing an app's functionality and usability. I don't see how Build solves that use case.
Still, it's a niche.
I had to write some plugins to get my game working on Android (and there are still compatibility problems around opening intents), so PhoneGap apps definitely lose something in the usability department.
And of course animations are not successful in this environment.
Ads are a pain too, if that's important to you, with the Google Admob/Adwords migration happening and the mobile web vs app ambiguity.
PhoneGap seems helpful as a part of the app's main UI, but native chrome is still important to completing an app's functionality and usability. I don't see how Build solves that use case.
Still, it's a niche.
The menu button, back button, and search button all work with Phonegap. What version are you using?
http://docs.phonegap.com/phonegap_events_events.md.html
http://docs.phonegap.com/phonegap_events_events.md.html
Wasn't there a time when apple rejected phonegap apps? (they did reject one of mine for sure).
Yes. Policy changed in 2009.
https://code.google.com/p/phonegap/downloads/list
https://code.google.com/p/phonegap/downloads/list
Great service - I've used it to build a modest application or two for Android and iOS. One caveat: Phonegap plugins that include native components (for example, the Facebook plugin) can't be included in apps built with Phonegap Build (yet).
What plugins have you been using? Last time I look at pg, the plugins I found were alpha quality or just abandoned. I'd love to hear what's current. Thanks.
At the moment, just the Facebook plugin for Facebook Connect authentication.
[deleted]
I started looking at PhoneGap but wasn't happy with Jquery Mobile for the UI. I am now trying out Titanium which offers a similar promise of ease for web/Javascript developers but with more native UI elements. So far so good but developing in Aptana/Eclipse-based Titanium Studio is a drag.
The more "consumer" your app the more likely it needs to be mobile. But I think there is probably a large class of apps where PhoneGap/Titanium make sense. Definitely in the internal business category where the audience is finite and the look-and-feel is secondary to the functionality and cost/ease of development and maintenance.
The more "consumer" your app the more likely it needs to be mobile. But I think there is probably a large class of apps where PhoneGap/Titanium make sense. Definitely in the internal business category where the audience is finite and the look-and-feel is secondary to the functionality and cost/ease of development and maintenance.
This site is awesome. To try it out, I made a quick one page app, uploaded it, made signing keys, and got it to the Android Marketplace, all inside of a few hours. My first mobile app ever.
This is my favorite example of an expertly-made PhoneGap app: http://www.youtube.com/watch?v=0pCtD4GuAqE
So smooth.
So smooth.
Nice. Anyone know how they achieved the transition effect? It's not a simple CSS3 transform. The bottom of the page seems to move first, then the top of the page is dragged over.
It could be an artifact of the scanning used in the video capture. The image has moved between the time the top pixels and bottom pixels were recorded. I believe this is known as aliasing.
Maybe I'm missing something but given you write the app in HTML/JS it must be difficult to unit test your wrappers for the phonegap functions, as I assume you can't simply pull up your dev site from the phone's browser. I'm thinking particularly about things like the contacts or network status functions.
[deleted]
Phone Gap paired with sencha would make one seriously native-feeling iPhone application. And all HTML5? Beautiful.
Beta code pretty please?
Funny I just released an application using this method yesterday. Too bad the Apple sales reporting site is down. I wanted to see how well HTML5 Apps sell.
http://defyent.com/#astro-dating
http://defyent.com/#astro-dating
Is there like a demo app with code I can look at? Thanks.
Very curious to see how they implement this tool.
I would think there would have to be some type of "compiler hints" for particular app device builds.
I would think there would have to be some type of "compiler hints" for particular app device builds.
QUESTION: Is there a good tutorial about creating PhoneGap apps integrated to Rails apps?
this looks cool!
Upload your website, download a native app.
What is wrong with this picture? If you can build your app as a web app and don't require hardware access then I'd think twice whether a native app is required.
What is wrong with this picture? If you can build your app as a web app and don't require hardware access then I'd think twice whether a native app is required.
It's about being found in the app stores. That's where people look for stuff on their phones, that's where you need to come up if you have something you want on someone's phone.
Of course there is a lot of down-side to this, but it is what it is. I wish the App Stores, particularly the Android Market, would create a much more elaborate system of categories allowing people to narrow their browsing down to exactly what they want, then it wouldn't matter so much if there was a lot of useless crap in the app stores, because we would never see it.
Of course there is a lot of down-side to this, but it is what it is. I wish the App Stores, particularly the Android Market, would create a much more elaborate system of categories allowing people to narrow their browsing down to exactly what they want, then it wouldn't matter so much if there was a lot of useless crap in the app stores, because we would never see it.
This brings up an interesting point: is there anecdata regarding appstore presence being a gateway/entry-point for a website? That is, first the app, then the website?
HTML+CSS+JS certainly implies a website, but it doesnt have to be.
We built a prototype mobile game in two weeks using PhoneGap and we were able to deploy to Android effortlessly. The visibility of the app store gave us (zero marketing, free app) brought in 2k downloads in two days.
That kind of free distribution is hard to replicate on the open web.
We built a prototype mobile game in two weeks using PhoneGap and we were able to deploy to Android effortlessly. The visibility of the app store gave us (zero marketing, free app) brought in 2k downloads in two days.
That kind of free distribution is hard to replicate on the open web.
There are plenty of good reasons to write apps this way, not the least of which being access to the app store. (Unless you've figured out a way to charge $1.99 for access to a mobile web site, in which case, God bless.)
There used to be an HTML app store. I can't find it now, as I don't remember the name, but that existed.
It's also pretty easy to just implement a registration fee, especially now with Stripe out in the wild.
If you're really looking to limit access though, you could probably use something like gumroad to get it off the ground.
It's also pretty easy to just implement a registration fee, especially now with Stripe out in the wild.
If you're really looking to limit access though, you could probably use something like gumroad to get it off the ground.
That's what I've been saying for years, until I was dragged into the Apple store by a friend and, to kill time, tried my web app on an iPad. It worked pretty well. An intrigued 10-year-old or so girl across the aisle asked, "What app is that?" "It's not an app but a site and you can see it at [redacted].com." She was turned off by the time I said "site" and tuned me out.
After that incident, I resolved to take my web app to the various app stores and am working on that with PhoneGap now.
After that incident, I resolved to take my web app to the various app stores and am working on that with PhoneGap now.
PhoneGap gives you access to much of the phone's hardware in a cross-platform compatible way:
http://docs.phonegap.com/
http://docs.phonegap.com/
Required? No. But there are benefits to being available on said platforms such as free distribution and eye balls.
But there are also drawbacks, more specifically with Apple, if you have to spend a lot of time in the black hole review process.
But there are also drawbacks, more specifically with Apple, if you have to spend a lot of time in the black hole review process.
Well, one advantage of the app store is that you can charge for your app.
"Native app" could be a critical bit for marketing or payment processing.
I may be ignorant, but to write a complex app, don't you need HTML5 AND a mobile javascript framework like JQuery Mobile and Sencha? Or does HTML5 handle that too? If it does require a Javascript framework, that's when the quality deteoriates... I think imitating the look and feel of native apps is easy. Making the performance smooth on the other hand is hard.
I'd say they're both hard. As an interface designer who works on iOS apps, it always pains me to see a web technology mobile app that's trying to look like it was built with UIKit but it's ever-so-slightly off. Some pixels are broken, text looks wrong, padding is off. I know why it's alluring, but I'd much prefer to see them craft their own interface style without aping Apple's UIKit look and feel.
If someone is trying really hard to emulate a native app's interface but without native technologies, I think they're already doing it wrong. Focus on the UX, not taking a different framework's exact visual style and copying it pixel for pixel.
If someone is trying really hard to emulate a native app's interface but without native technologies, I think they're already doing it wrong. Focus on the UX, not taking a different framework's exact visual style and copying it pixel for pixel.
HTML5 is JavaScript. Without JavaScript, HTML5 is just a few semantic HTML tags (like header and section) and a few extra form input attributes (like required and placeholder).
As far as JavaScript frameworks go, you could use Sencha or jQuery Mobile or one of the other few dozen frameworks out there --- or you could roll your own.
I've been doing mobile web development for about a year now. I've done both PhoneGap and over-the-air mobile web/native apps (with embedded webviews that load HTML/CSS/JS from the web when requested). Both types of apps accepted by Apple and in the Appstore as well as in the Android Market. I would recommend rolling your own and not trying to imitate the look of native apps. One of the strengths of using HTML5 is that you can create a custom look and feel that doesn't look like every other app out there.
Since you mentioned Sencha and jQuery Mobile, here's what I think having used both:
Using Sencha is nothing at all like using HTML5. You don't even write HTML or CSS. You write JavaScript that uses Sencha's classes/methods. The look and feel very much tries to mimic native and they do a pretty good job at it...except that most widgets look like they were ripped from an iPhone, which is disorienting for users on Android. That said, you get good performance and a boatload of widgets/ui controls out of the box. The price for this is a large, multi-hundred kb framework and a commercial license.
jQuery Mobile doesn't really try to look native and it really doesn't "feel" native either. jQuery has it's own ui controls that more or less look identical on iPhone or Android. With jQuery Mobile, you do write HTML and have a more transparent view of that as well as of the CSS. But, you have to write HTML the "jQuery Mobile way" to utilize the UI built into the framework. You don't get as many widgets and ui-controls as you do in Sencha and overall, the look and feel is not of the same caliber either. But, it's smaller than Sencha, has your standard MIT license and is more easily modified.
Neither is perfect and both have pluses and minuses. If you know some HTML, CSS and JavaScript, you will absolutely get better performance and and a smoother look and feel by rolling your own light JavaScript for your app that does just what it needs to do.
If you'd like to see an example app I built using PhoneGap and handrolled HTML/JavaScript/CSS, you can download Easy Baby from the Android Market. It's free. You'll find a link to it on my website: http://newbabysleep.com
As far as JavaScript frameworks go, you could use Sencha or jQuery Mobile or one of the other few dozen frameworks out there --- or you could roll your own.
I've been doing mobile web development for about a year now. I've done both PhoneGap and over-the-air mobile web/native apps (with embedded webviews that load HTML/CSS/JS from the web when requested). Both types of apps accepted by Apple and in the Appstore as well as in the Android Market. I would recommend rolling your own and not trying to imitate the look of native apps. One of the strengths of using HTML5 is that you can create a custom look and feel that doesn't look like every other app out there.
Since you mentioned Sencha and jQuery Mobile, here's what I think having used both:
Using Sencha is nothing at all like using HTML5. You don't even write HTML or CSS. You write JavaScript that uses Sencha's classes/methods. The look and feel very much tries to mimic native and they do a pretty good job at it...except that most widgets look like they were ripped from an iPhone, which is disorienting for users on Android. That said, you get good performance and a boatload of widgets/ui controls out of the box. The price for this is a large, multi-hundred kb framework and a commercial license.
jQuery Mobile doesn't really try to look native and it really doesn't "feel" native either. jQuery has it's own ui controls that more or less look identical on iPhone or Android. With jQuery Mobile, you do write HTML and have a more transparent view of that as well as of the CSS. But, you have to write HTML the "jQuery Mobile way" to utilize the UI built into the framework. You don't get as many widgets and ui-controls as you do in Sencha and overall, the look and feel is not of the same caliber either. But, it's smaller than Sencha, has your standard MIT license and is more easily modified.
Neither is perfect and both have pluses and minuses. If you know some HTML, CSS and JavaScript, you will absolutely get better performance and and a smoother look and feel by rolling your own light JavaScript for your app that does just what it needs to do.
If you'd like to see an example app I built using PhoneGap and handrolled HTML/JavaScript/CSS, you can download Easy Baby from the Android Market. It's free. You'll find a link to it on my website: http://newbabysleep.com
I can't see why anybody would actually use jQuery Mobile and Sencha for web app development. I've tried them last week and they were impressive on a desktop browser. On a mobile device, not so much. Both jQuery Mobile and Sencha feel slow, very slow. The animations are choppy. Response times on clicks are way too long. Everything flickers like mad. Focus borders are drawn at all the wrong places. I can actually feel that it's a web app trying too hard to be a native app. On my Android phone it's even slower than on my iPad 1.
I'm not blaming jQuery Mobile or Sencha. I think mobile browsers are just not ready for delivering a smooth UI experience that's up to par with native apps.
I'm not blaming jQuery Mobile or Sencha. I think mobile browsers are just not ready for delivering a smooth UI experience that's up to par with native apps.
Somehow we ended up with very different experiences. I played with Sencha Mobile Kitchen Sink demo on the iPhone 4 and it was quite impressive. http://www.sencha.com/products/touch/demos/
Yes, it lags ever so slightly, but faster CPU in iPhone 5 should take care of that. My only other complain is that they messed up calculating tap areas for tabbar/toolbar items - Sencha has tap area equal to the visual size of the button, whereas UIKit assigns entire section of the toolbar (44 pixels tall in portrait), which makes a lot of difference in tap detection. But I don't see why they can't fix it, and then it would be pretty good...
To be clear, I am still staying away from UIWebView in favor of UIKit, but I am getting increasingly interested in this.
Yes, it lags ever so slightly, but faster CPU in iPhone 5 should take care of that. My only other complain is that they messed up calculating tap areas for tabbar/toolbar items - Sencha has tap area equal to the visual size of the button, whereas UIKit assigns entire section of the toolbar (44 pixels tall in portrait), which makes a lot of difference in tap detection. But I don't see why they can't fix it, and then it would be pretty good...
To be clear, I am still staying away from UIWebView in favor of UIKit, but I am getting increasingly interested in this.
Yes, it lags ever so slightly, but faster CPU in iPhone 5 should take care of that.
This is always the reply of web developers -- even on the desktop! "Yes, it's slow now, but it'll be faster with new hardware!".
Meanwhile, the native applications use that additional processor power to do more stuff, and the webapps fall further behind again.
This is always the reply of web developers -- even on the desktop! "Yes, it's slow now, but it'll be faster with new hardware!".
Meanwhile, the native applications use that additional processor power to do more stuff, and the webapps fall further behind again.
So? Desktop HTML/JS was too slow for a while, all the way until the point when it became fast enough to handle maps, email, finance etc. Remember MapPoint? It used o be a desktop map application. No one uses it anymore.
I have to wonder who is the downvoting person, who beleives the above post does not contribute to the discussion? Would you rather this not be posted at all? Because if you keep with the downvotes that's what's going to happen - no links to Sencha demo, no keen observations about tap areas, no personal opinion from experienced i-thing developer.
I also wonder where are the people who would appreciate this sort of contribution. They gotta be somewhere...
I also wonder where are the people who would appreciate this sort of contribution. They gotta be somewhere...
Mobile web development requires a different way of thinking about code. Every line counts. More lines equals a larger code graph in browser memory and starts to affect your app's performance.
Mobile web frameworks get you an immediate boost in developer productivity, but down the road, those gains are given back as you try to achieve reasonable performance, which to some extent is a fools errand because you just have so much library code bogging down the browser/webview.
Other parts of a mobile web app, like CSS3 transitions, will perform as well as the browser/phone lets them. Using CSS3 for transitions and animations is definitely "the right way", but as of now, these are pretty clunky on most phones.
Mobile web frameworks get you an immediate boost in developer productivity, but down the road, those gains are given back as you try to achieve reasonable performance, which to some extent is a fools errand because you just have so much library code bogging down the browser/webview.
Other parts of a mobile web app, like CSS3 transitions, will perform as well as the browser/phone lets them. Using CSS3 for transitions and animations is definitely "the right way", but as of now, these are pretty clunky on most phones.
I agree somewhat, and would add that I wish jQuery Mobile would focus more on being a solid compatible framework for mobile 'websites' than in emulating the features/transitions of a native app.
Agreed. When i first heard about jQuery mobile i was hoping they would take the familiar jQuery syntax and add things like touch events and optimize it for mobile. However, you really can't make your own custom jQ mobile site without getting the 'app' thing. Also, you need to include the normal jQ library, which is a pretty big download and includes lots of cross-browser code for fixing old IE bugs.
Right now i guess either rolling your own framework or looking into alternatives like Zepto.js makes more sense.
Right now i guess either rolling your own framework or looking into alternatives like Zepto.js makes more sense.
I've been using phonegap and jQM since pre-alpha, and I've found it to be a near-native experience on the iphone and impressively responsive on android and palm. I think the alpha version had some flickering, and it is a bit slower on android, but if there is "mad flickering" something likely wasn't done right.
> The price for this is a large, multi-hundred kb framework and a commercial license.
Sencha Touch is free now (not sure when that happened). And the multi-hundred kb framework isn't much of an issue since it's bundled up in the native download and always local to the device.
Sencha Touch is free now (not sure when that happened). And the multi-hundred kb framework isn't much of an issue since it's bundled up in the native download and always local to the device.
The overall size of the code graph in browser memory matters. It's not just about the size you're delivering over-the-air. That said, I have apps in both the Apple Appstore and Android Market that have embedded webviews that pull down the mobile web app portions from the air. This allows 100% freedom in changing/fixing things. In these cases, yes, size matters.
How much effort needed to convert my single html with few javascript files to be app-store eligible. I think there is more to just using the phonegap
http://www.mockuptiger.com/a/123wireframe.php
cool web app. i think the difficult part of converting it for mobile would be the screen size necessary to work effectively and possibly getting the touch gestures to work properly for moving and resizing the controls.
Am I back to 2010? Or am I reading Reddit?
But, are there any successful apps made with PhoneGap? Writing apps in HTML5 is constantly hyped, but there isn't a single HTML app out of the dozens on my iPhone except Netflix. PhoneGap's app gallery doesn't have a single app I've heard of.
(The Netflix app isn't too pleasant, either, unfortunately.)