Luke1robb
macrumors 6502a
Uhhh as said above this is not how Push Notifications Services would work, essentially adding Push for apps would drain the battery no less than Push for mail, so if you use that already, your battery will not be affected.
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.
Guess Apple forgot about PUSH!
- Thread starter slapppy
- Start date
- Sort by reaction score
Uhhh as said above this is not how Push Notifications Services would work, essentially adding Push for apps would drain the battery no less than Push for mail, so if you use that already, your battery will not be affected.
Luke1robb
macrumors 6502a
It's coming at Macworld, no doubt. With no SJ there and this being the last one, their either coming out with something crazy to be like SJ doesn't have to present it to make it big or they'll bring PUSH out as SJ isn't really in charge of that stuff, maybe that's why he won't be there.
cellocello
macrumors 68000
dissdnt
macrumors 65816
SMS is push from AT&T. Your phone isn't constantly asking AT&T for txt msg's.
Same goes for voice mail.
And i'm sure Apple is using that same method to send push email as well, in the future, for other apps. Meaning they can push data to any specific phone they want on the network.
My two cents.
Same goes for voice mail.
And i'm sure Apple is using that same method to send push email as well, in the future, for other apps. Meaning they can push data to any specific phone they want on the network.
My two cents.
dccorona
macrumors 68020
dccorona
macrumors 68020
see thats the probem
text IS data
so by charging us for a data plan,
and then charging us to send a text message,
they essentially charge us twice for the same tiny amount of outgoing data
kdarling
Contributor
No. Please read my posts above in this thread.
A text (SMS) is a phone call. Phone calls are charged by time (with a minimum of one minute), usually starting at about ten cents a minute if you have a plan, going down as you buy more time. Texts are priced in a similar manner. Basically, you're paying for a very short call.
Email or web is a data connection. It's NOT a phone call. You only use air time when you're sending/receiving. So data is charged by amount... the number of bytes you use.
Eso
macrumors 68020
I don't care what you call it, ANYTHING that gets transmitted between your phone and the cell tower are just 1's and 0's, seems to me any difference it just arbitrary.
newyorksole
macrumors 603
Duhh, you actually thought Apple would come out with Push in September? I knew darn well it would get pushed back, not this much though.
Call it what you want: push, open sessions with extended time-outs, or whatever. I receive emails in sub-5 seconds every time they are sent, and my calendar/contact info is updated within minutes, if not less. I also do not have problems with my battery life. It consistently lasts 4:45 to 5:30 with a solid amount of surfing, heavy email usage, bluetooth always on, and a decent amount of phone calls...all on 3G.
I certainly understand the frustration behind push not working with other applications. But with Mobile Me, I can definitely say that it works great for me.
I certainly understand the frustration behind push not working with other applications. But with Mobile Me, I can definitely say that it works great for me.
That's because it looks like you haven't gone to either engineering school or law school. Different ways of sending ones and zeros have very different costs (depending on channel bandwidth, protocol overhead, etc.). Standards prevent you from sending them just any old way (you won't get FCC certification if you do that). Same with interoperability. And different purposes for those ones and zeros, as well as the exact way they are sent and used, are covered by different patents, which also have very different costs and legal restrictions. RIM paid nearly half-a-billion dollars to learn that the hard way. How much spare change do you have in your pocket to cover that kind of lawsuit?
.
Uh... no.
Push e-mail isn't really push e-mail. Push e-mail on the iPhone is accomplished in one of two ways:
1) Yahoo's "push". From what I've been able to tell from poking around, your phone gives Yahoo it's IP and an inbound UDP port. When Yahoo gets a new e-mail for you, it sends a notification packet to the IP/port your provided. Your phone then creates an IMAP connection to Yahoo's servers and retrieves the messages. (Lord knows why they didn't just use IMAP IDLE...)
2) Exchange ActiveSync "push". This actually sits atop HTTP(S). I can't explain it any better than Microsoft's simple explanation (taken from this FAQ:
Compare and contrast both of those to SMS, which works on a completely different principle...
Well... if push is implemented in the same way that ActiveSync Direct Push is, then yes, it _will_ cause additional battery drain.
If, on the other hand, Apple does something like use SMS for OOB triggers, then it probably won't affect battery all that much.
kdarling
Contributor
Right, SMS is a "free" push as far as battery goes, since the phone is watching for incoming rings already.
The original Exchange OTA sync a few years ago _did_ use SMS as the trigger, instead of the long-timeout Fetch that everyone (including IMAP Idle) uses today.
But it had two things against it. First and foremost, SMS costs money. A few years ago, that was a real killer. Second, SMS isn't super robust. Again, a few years ago it was not uncommon for them to get lost. However, with today's unlimited plans and better message centers, it could be time to revisit the technique.
The beauty of SMS is that it can be originated from a server that simply knows your phone number. The other "push" has to originate from the phone so the server knows the IP path to respond over.
Not to be a pedant, but IMAP IDLE doesn't use a long timeout -- it periodically sends/receives data to prevent the connection from timing out. This is in contrast to ActiveSync Direct Push, which *does* use a long timeout.
Yahoo's push strategy is actually very clever, and would work if 1) UDP over GPRS/EDGE/3G wasn't such a losing proposition and 2) the iPhone only told Yahoo its GPRS/EDGE/3G IP, rather than its WiFi one. Unfortunately, UDP over GSM data is a very lossy proposition, and many hotspots don't allow/correctly route inbound UDP.
Masquerade
macrumors 6502a
Interessenting where i can find more about this??
wikipedia has a short article about push.
johnnyjibbs
macrumors 68030
I heard that the iPhone 'push' is a real push service. When there is a new email on the server for you, Apple sends a specially formatted (i.e. secret) text message to your phone, which the iPhone interprets not as a message to display, but as a cue to check the mail server because there is something new.
Text messages do not use the data connection and existed long before WAP and the data protocols on mobile phones. They are pushed over the phone connection just like a phone call is. You do not get charged data for these, which is why they are charged separately.
The push notification system sounds complicated. The above system is easy enough, but how do you factor that into all the developers? What about security? Who handles the server notifications? This would have to be server-side because your app wouldn't be running at the time you get notifications pushed.
Text messages do not use the data connection and existed long before WAP and the data protocols on mobile phones. They are pushed over the phone connection just like a phone call is. You do not get charged data for these, which is why they are charged separately.
The push notification system sounds complicated. The above system is easy enough, but how do you factor that into all the developers? What about security? Who handles the server notifications? This would have to be server-side because your app wouldn't be running at the time you get notifications pushed.
I think you've touched on something that's been bothering me about all this Push Notification nonsense. This is going to cost money. Lots of money. It's going to work one of two ways for developers. Either they have to have their own servers set up (and with all the iPhones out there we're talking about a lot of servers) or they'll have to rent server space/time from apple. This won't be cheap either!
So what is the incentive for developers of free apps (Palringo and most of the other IM clients are free) to support this service? They'll be spending a great deal of money without making any?
And how is this better than just letting me run my IM app in the background for the six or so hours a day I want to use it? Whether it'll use any more of my battery than just using push email there are plenty of people out there who aren't using push now who's batteries are going to take the hit. What are Apple's problems with background apps? Do they believe that they're not up to writing the memory management code needed? I don't believe that, everyone else can do it and Apple have the added experience of writing computer OS's. Are they worried about security? They should just take a leaf out of Symbian's book and require developer signing. There has NEVER been a virus that could affect Symbian OS. They want you to know when there's app updates available? Just have a service which polls the app store every three hours or so checking for updates?
This just seems like a completely pointless exercise to me all together.
i agree, push would be great for some applications (mail etc), but when it's implemented to rectify another flaw in the design altogether, namely developers not being able to write programs that run in backround, it's an ad-hoc solution that creates more problems than it solves.
apple should really just address the problems there might be in the way of allowing background applications directly, not trying to "innovate" around it. all the other mobile os's are able to run applications in the background, and jailbroken iphones are able to run background applications, it's extremely rare that verified iphone programmers aren't allowed.
.
kdarling
Contributor
It's okay to be pedantic. 🙂 Keeps everybody straight. Thanks!
True, I was simplifying, but the implementation ends up acting almost the same, because they have to keep the connection open, for similar reasons (server or network timeouts). The intent was to explain that most "pushes" actually require a data exchange (or poll) more than the name implies.
Here's a short list of good articles:
Understanding Direct Push (MS article)
Direct Push Guide
IMAP Idle
RFC 2177 - IMAP IDLE
And here's that white paper I was looking for before, when talking about Blackberry bandwidth savings over other email / etc implementations:
Push Email Efficiency - RIM vs MS (pdf)
I read an example somewhere lately which to me highlights how stupid a system this is.
The author was talking about writing a very simple app which would alert the user at certain times of day when they were meant to take various medication. In essance a simple thing to do, the app sits in the background checking the system time every minute or so, and when the appropriate time comes it pops up the message. Ordinarily you could code that in about half am hour but with the iPhone, as it won't allow the program to run in the background, the developer will have to write a much more complex program, and either spend a lot of money to set up a server and server side app to do the time checking part. How does this make any sense?