Not just the performance. A lot of the UI behavior was just wrong. Scrolling in particular was a disaster. Maybe they were using PhoneGap badly, but still--in a native iOS app it's quite easy to get scrolling to work right, and apparently in PhoneGap it's not.
no idea why you would get downvoted for this, it is clearly just a well stated opinion without flame etc.
However, PhoneGap shouldn't be completely to blame for any one applications performance. If many PhoneGap applications performed poorly, then you could make the case. PhoneGap apps should perform as well as any web-based app on the same device. It is up to the developer to make efficient use of javascript animations, etc. in order to provide the best user experience.
Remember that PhoneGap really isn't anything more than a thin wrapper around a web app. Performance/usability is going to be heavily influenced by how you write that web app.
I'd be more interested to know what web framework O'Reilly used that was slow, rather than it being PhoneGap per se.
Have you personally used PhoneGap? It sounds like you don't quite understand how it works.
For an iOS PhoneGap project, inside the Xcode project there is a 'www' directory into which you stuff your HTML, JavaScript, and CSS files from your mobile web app. PhoneGap then creates a webview and loads your index.html in it.
PhoneGap by itself cannot be used to make any kind of an application. You also need a web app that works outside of PhoneGap (barring some PhoneGap-specific JavaScript APIs which you can optionally include to get access to device-specific information and features), and that web app presumably would either use one of the common frameworks or be written from scratch.
Hence my point that what's more interesting to know is what web app framework they used, since that'll have a bigger impact on performance and especially usability than just "it's PhoneGap".
4GB is a safe bet for best quality stream, but it depends on the encode. For iPad its scaled down. Assuming top encode rate is 1Mbps. 1Mbps * 7200 seconds = 7200 Mbit / 8 = 900 Mbytes
I always thought this was a pretty good visual representation of budget distribution. Note this reflects the 2010 budget, not the proposed 2011 budget.
It's not that good really. The site you linked to only displays the discretionary budget. The NYTimes infographic is much better, because it also includes all mandatory spending. Mandatory spending is over 50% of the entire federal budget, and includes pretty much all of the 'welfare state': social security, medicare, medicaid, unemployment and other income supplements, veterans' benefits, student loans, and on down the list.
Displaying only discretionary spending is a rather tendentious way of representing the federal budget, because it makes defense spending look like the largest expenditure. Such graphs are usually linked to by people decrying U.S. militarism or imperialism or the military industrial complex. This is not to say that the U.S. does or does not spend too much on the military, but simply to point out that the visual effect of cutting out over 50% of the budget biases people's perceptions and provides undue support for politicized arguments.
Well I think it's mainly a hardware limitation. I still get kicked out of apps from time to time due to low memory. This is probably due to errors on the programmers side. However if this happens with a single program running, you can imagine what would happen if other programs get memory hungry. It raises a lot of questions, what is acceptable amount of memory to use in the background? Which program does the OS terminate first? Save state when I'm told to go away?
I think Android has handled a lot of these questions very well. We'll see how Apple handles it in the future, but I don't see background processes being compatible with older models of the iPhone.
Loopt doesn't run in the background on the iPhone like you would think. It actually runs on servers at ATT pulling already available GPS data on your cellphone's location from the towers.
After lots of work, apparently--up to "six or seven" partner companies in the network infrastructure. All this engineering tinkering has resulted in an always-on Loopt iPhone app that runs in the background on the network rather than the phone. Presumably this has a knock-on effect on the precision with which one can be located (the background Loopt app isn't accessing the iPhone's GPS to find out where you are, and it's most-likely using cell-tower triangulation methods, much as Assisted-GPS units do to boost their location-sensing powers).
What is worse, bad commit messages or no commit messages at all? Having to diff through no commit message changes is the bane of my existence. Yes I have brought this up to my supervisors multiple times, sometimes they are the culprits.
