Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Sprint CEO Says iPhone Extends Ability to Offer Unlimited Data
- Thread starter MacRumors
- Start date
- Sort by reaction score
Programatically you aren't accomplishing the same thing and the push notification system has some serious downsides (namely its lack of reliability).
Push notifications cannot do everything that a simple daemon running in the background can. They may use less data, but that's simply because they're doing less.
Again, you have not shown that Android is a "data hog". A program performing the task it is designed to do does not make it a "data hog". If you want to compare fairly, the Push Notification system in Android does not use more data than it does in iOS.
Even Apple realises that Push Notifications don't work for everything - hence the VOIP API in iOS 4.0+.
Last edited:
Better wifi reception on the iPhone, that's an interesting tidbit....
And it's also interesting how that sort of thing ends up influencing the availability of unlimited data plans.
And it's also interesting how that sort of thing ends up influencing the availability of unlimited data plans.
I get between .5Mbps and 1.2Mbps. I also get service everywhere and never get dropped calls. I'm a happy Sprint customer despite all the noise on this board, haha.
CDMA data rates blow so hard. All the cheeky bastards over in Europe and Austrailia are posting screenshots of speed tests with like 10+mbps with averages around 5~ and anything under 1 is crazy...If I could have 1mbps consistently I'd be content! Regardless I don't really rely on 3G as much and most of my 3G usage is text based browsing and occasional Facebook (through the app). I find that allot of the time I get a notification on my iPhone I usually have my MacBook Pro with me so I can just hop on that..
Slow this, slow that, slow slow slow. Waaaah.
I will tell you this. I did speed tests next to a Verizon [Android] device on my Sprint 4S and blew them away under ping, download and upload.
In fact, Sprints network has improved a LOT over the last week and a half. Here:
![]()
All this bashing is old news to me. That's like saying Mac has no Games nowadays.
I will tell you this. I did speed tests next to a Verizon [Android] device on my Sprint 4S and blew them away under ping, download and upload.
In fact, Sprints network has improved a LOT over the last week and a half. Here:
All this bashing is old news to me. That's like saying Mac has no Games nowadays.
I see no evidence anywhere that APNS/Cloud-to-Device is less reliable than a background daemon. I see plenty of reasons why APNS/Cloud-to-Device is a better solution than background daemons for everybody. Perhaps you can explain in technical detail why you might think so?
They're using less data, because they're eliminating overhead to accomplish the same task. If you don't understand that, you've missed a very important detail and should not be writing networking code.
A program performing the task it is designed to do, is a "data hog" when it uses more data than necessary to perform the task. Are you saying a badly implemented background task using the network is not a "data hog" because it was designed to perform badly?
The majority of applications would have no negative effect for the user and no loss of features using APNS/Cloud-to-Device.
Indeed push notifications can't do everything. But the majority of applications, using push notifications over background daemons gets you better battery life, higher reliability, and better data efficiency for no loss in features.
For every Android application which implemented a background daemon and did not switch to Cloud-to-Device in Android 2.2, they're simply wasting battery life, providing a worse experience to their user, burning more data, and in some cases, requiring themselves to have even more server costs. It's not just being a "data hog" but crippling battery life as well.
It's called Cloud-to-Device. It was introduced in Android 2.2. And I never said it was less efficient than APNS. In fact, I was saying that it basically is a copy of APNS and that people should use it. It sounds like you didn't understand what I said earlier.
Using Cloud-to-Device is good. Using background tasks to poorly implement a feature that Cloud-to-Device can do for you is bad. Too bad because so many developers wrote their code for Android 1.6-2.1, most apps don't use Cloud-to-Device. Hence those apps are almost certainly dragging the Android user down.
Doesn't help that it took so long to get phones on 2.2+. (As a Android dev, you can choose to ignore fragmentation, to do more work, or to have less potential customers. You can only pick one.)
By the way, it's not a VOIP API in iOS4, it's a plist tag that says "I'm a VOIP app doing VOIP things, and request that I be allowed to run as a background process."
Simply because the notion of a basic IM app requiring everything to be routed through multiple central servers on iOS, when every other platform can do it peer to peer is incredibly redundant.
A message on, say Windows Live Messenger has to go from
Sender's Device > Recipient's Device on a computer.
Sender's Device > Intermediary Server (e.g. run by Beejive IM) > Apple Push Notification System (APN) > Recipient's Device on iOS.
That is only the notification part!
That leaves a lot of room for notifications to get lost - just look at the reviews of Apps like Facebook or Windows Live Messenger to see that Push Notifications are unreliable.
If the user chooses to open their IM client, that client must then authenticate with the intermediary server and download the message itself.
That's duplication - one form of inefficiency.
Of course I understand that they are using less data, but they aren't doing the same thing.
A peer to peer IM network simply doesn't fit in with Push Notifications.
We aren't talking about badly implemented Apps here. Of course a badly implemented App isn't a good thing - but that's so obvious it shouldn't even be mentioned. There are plenty of Apps on iOS that implement push notifications badly.
Not allowing developers to do things that their customers demand just because some developers might use it badly was the reason Steve Jobs wanted everyone to use Web Apps on the iPhone. Look how wrong he was on that.
iOS does not allow a VOIP app to just "run as a background process". It must do that in a very specific way by interacting with certain API calls - hence why I said "VOIP API".
There are strict restrictions on what a VOIP app can actually do (i.e. it can only run code for a maximum of 30 seconds no more frequently than every 10 minutes).
Outside of that, the OS will monitor the VOIP app's connections for any incoming activity (i.e. a VOIP call) and wake the App to deal with it.
Dan Hesse is simply acknowledging that iPhone users don't really stress American phone carrier data networks because the iPhone swtiches to wifi more efficietly than most smartphones. Whether this is true or not, it sounds like an admission that tiered pricing of data is really intended to enrich phone companies rather than be the result of over- use of data networks by most of us. Take a look at your past monthly bills, and you will notice that you did not use AT&T or Verizon's data networks nearly as much as the claimed when justifying tiered pricing.
1) On the iOS App Store, reading the first 5 pages of reviews of Facebook reveals no reviews complaining about push notifications. But tons of reviews complaining about the UI.
Reading the first 5 pages of reviews of Windows Live Messenger reveals a few complaints about how the app marks messages sent via push notifications. This isn't a push notification problem, it's a problem with how the app decided to show it.
I see nothing about reliability or lost push notifications.
2) The whole point of APNS/Cloud-to-Device is to reduce the amount of data sent to the phone, increase battery life, and increase deployment reliability. Yeah, you'll send the data to another server. So? Sending the data to a central server when the involved servers are all plugged into high speed internet connections and power grids is a great tradeoff considering the benefits of the system.
Are you seriously trying to tell us that you think BOTH Apple AND Google are telling us to do it wrong?
Are you seriously trying to tell us that hitting a user with crappy battery life and a bigger data bill is the right thing to do? What you're suggesting is the "right way" is an pretty much the defining example of a badly implemented network-notified app.
Daveoc64 I am just going to point out that you seem to have a poor understanding of how push notifications work and is done.
On any major IM client it is going to go sender>server> user heck they have more moved to a push system so to speak since your IM client is not going to be checking constantly for some update. That is a huge waste of resources no matter how you cut it.
The only difference with phones is they can not be logged into multiple push locations at a single time and really need a single central location. (Apple, Google, MS RIM ect). I am willing to bet Apple, Google and MS all use a very similar system for their push updates which to the app end they upload to a "web page" that is just for the that one phone and those changes are pushed to the phone. It is really a pretty cool system on how it works. Hard to explain but it is a very effience system. The push is general notification type
(toast, badge ect) and a little info. Anything larger it points the phone to the correct location to download it. Really a very effective little system.