Background processes run locally on the iPhone, and do not require connectivity to determine when a notification is to be displayed. Recall that there can be more app types than IM. For example, the calendar app provides reminders. Don't you think a third party task list app could benefit from reminder notifications?
I wonder, is there a way to add to add calendar events from your own app, complete with reminders? Either that or a local push service is enabled sometime in the future
Th SDK rules forbid VoIP outside of WiFi, but I see no reason why they can't use the new services set up by Apple to push incoming calls to you while connected via WiFi. Or if the IP address hack still works, and you'll be hanging around, say, an office building all day, you could.
It'd surely require quite a change though for VoIP providers who would have to initiate calls through Apple's server instead of using SIP/STUN directly. I really can't see it happening as the service would then be dependent on the performance of Apple's server, not the VoIP provider.
It'd surely require quite a change though for VoIP providers who would have to initiate calls through Apple's server instead of using SIP/STUN directly. I really can't see it happening as the service would then be dependent on the performance of Apple's server, not the VoIP provider.
It would require a change on their part, but not a big one. One possible solution, have the native iPhone VoIP app inform Apple's push service to monitor for the incoming signal, then tell the VoIP server to send a simple notification ping and caller ID of incoming call to Apple's push server, which would then get pushed to your device as a simple text message. If you see/hear/feel the notifcation and initiate the App before it goes to voicemail (longer ring time can also be initiated) then it connects and pushes the call through.
I think Skype could do this with ease. Of course, VoIP is time sensitive so this is not a full proof plan, but the best I can think of under the rules of the SDK.
Internet radio is like the car going to a place, by definition it needs energy, opening the sunroof (getting a notification about a forgotten SMS) doesn't really need energy in the same manner (at least not energy I have to pay for).
I don't know if that made any sense, if not, I think you should just let it go :-)
You are using your battery to open the sun roof. When you start your car and its burning gas. Your alternator has to replenish the energy you used to open the sunroof.
Have you ever used a Jailbroken phone? I ask because it REALLY sounds like you are speaking from ignorance. I run a ton of apps on mine and have NEVER had a problem beyond the occasional crash in Safari, and that happens jailbroken or not.
I have a friend who has used jail broken apps and has had many problems. There are reports across the internet of problems with jailbroken apps. So its not an entirely safe environment.
Quote:
Beyond that, the entire concept of protecting the lowest common denominator is unfair to anyone that is willing to take that risk. Apple isn't letting you do what you want with your phone, and that is absurd and insulting. What are you going to suggest next, that they start checking and signing applications in OS X because a few luddites don't know how to use their computers? Give me a break.
What is the better platform? One in which you are assured all of the 3rd party apps work without negative impact on the device, or one where you are never completely sure.
And if a 3rd party app negatively affects the phone who is the general user going to blame. The 3rd party app or the phone?
How will the push notification service solve the need for an app to periodically send information back to a 3rd party server? For example, the Loopt app will need the iPhone to continuously report its location, even when the Loopt app is not running.
Since Jobs made such a big deal of "tracking" iPhones with the GPS chip, I assume some sort of solution will exist. My guess is that users will opt-in to which companies/services should have access to iPhone location data (Apple, Loopt, etc.). If Apple is allowed to have access, then it will store periodic GPS pings from the iPhone on its servers. Apps that have been authorized by the user will be able to query the location data directly from Apple's servers.
I really think it is a nice feature. Imagine the possibilities. I really hope that Apple create some kind of theft recovery/protection system using feature. For example, someone can write an app so that if you iPhone get lost or stolen you can have it send you the location. Maybe the application can be some how hidden and can only be removed from the iPhone owners iTunes. I know I've read about an application for jailbroken iPhones that do the same thing using the web but that was using cell towers. The other thing I hope for is that Apple give MobileMe users the ability to remote wipe.
Quote:
Originally Posted by samab
The first thing developers should ask is whether Apple is going to charge them money for traffic going thru their servers.
The other thing I hope for is that Apple give MobileMe users the ability to remote wipe.
I'm surprised this wasn't announced. Even if it would be the only be available for .Mac/MobileMe customers, it would be a cheap feature to add while adding incredible value via security to two products.
............ On top of that, your entire second argument is a logical fallacy. What technically illiterate people do you know that go about installing applications on their phones?
I think this is one of the reasons Apple is doing it this way.
The App Store makes it trivially easy to find, purchase and install apps on your iPhone. The process is much like buying and transferring music to your iPod.
Given that, it really would be quite easy for an unsophisticated user to download a bunch of apps that could drain the battery in the background, were it allowed.
I hope Apple are very careful about who they open this up to. Those little popup windows could easily be used for spam. Also in the absence of this mechanism, third party devs could just send you an email telling you you need to open one of your programs.
Just seems that they're making things unnecessarily complex for developers and well-informed users. In reference to AjayToo's message, why even go through Apple's servers at all (thereby adding more bandwidth requirements)? I can easily picture an app that would be periodically checking the GPS and taking some action accordingly, either locally (when reaching a predetermined location) or reporting via a TCP socket to a different server. I understand Apple's concern about battery life and background apps, but I see other, and not mutually-exclusive solutions. An application could "register" to be awaken in the background every x seconds to do whatever it needs to do. A well-behaved app in this mode would take as little processor time as possible, and register for the next activation with the minimum time required to accomplish the task (for example, a birthday reminder app doesn't need to check every second what day it is: it could be scheduled to test once a day, and that would suffice). Any thoughts on that?
Just seems that they're making things unnecessarily complex for developers and well-informed users. In reference to AjayToo's message, why even go through Apple's servers at all (thereby adding more bandwidth requirements)? I can easily picture an app that would be periodically checking the GPS and taking some action accordingly, either locally (when reaching a predetermined location) or reporting via a TCP socket to a different server. I understand Apple's concern about battery life and background apps, but I see other, and not mutually-exclusive solutions. An application could "register" to be awaken in the background every x seconds to do whatever it needs to do. A well-behaved app in this mode would take as little processor time as possible, and register for the next activation with the minimum time required to accomplish the task (for example, a birthday reminder app doesn't need to check every second what day it is: it could be scheduled to test once a day, and that would suffice). Any thoughts on that?
It's not complex at all for the user. The app still fucntions as if it's still running without constantly using the system resources.As for developers, it's something new for them but the end result is that their apps get used more than ones that aren't informing the user immediately.
As for the "x seconds" solution it would be impossible to create an app that would work. The only solution here is to have a user-controlled interface to alter the time between server checks, but this wouldn't be the same at all times and would require the user to use an inelegant soltuion.
For example, let's take an IM client for example. If I'm in a conversation and waiting for a reply I can use the other aspects of my phone while I wait for a response. When it comes in, I know immediately and can go to the message. Your solution requires the phone making the outgoing connection to the server. The lower the time the more power is used (there is no way I could be waiting for an IM all night with the device checking every 1 minute if it wasn't plugged in. IF I choose a 30 minute check the phone will last all night but I may have to wait over 29 minutes to know that the response has come in. No matter where you put the time frame you are either losing power or losing instantaneous mesages.
Now think about having a dozen apps checking periodically for messages. None of that is good for the user. And subsequently it hurts developers if you aren't buying as many apps.
I was thinking more along the lines of app-specified timer, depending on the application. Birthday checker would be a once-a-day thing, whereas other apps would need different periodicity. One thing we were seriously considering was turning the iPhone into a posh personal GPS, which reports every number of minutes to a server so the user can be tracked. The app would also check if the phone leaves a certain "geofence". It seems to me a waste of bandwith to have the server request that the unit reports, when this could be just as easily be initiated at the iPhone itself. And even worse for the birthday app, since there is really no reason for any outside communication. Finally, remember this is not meant to exclude the other model: use it where it fits, and use push when that makes more sense...
Have we heard anything on how these alerts will need to be sent from our servers? Will I need a Mac server in order to "play nice" with Apple's servers?
Comments
Background processes run locally on the iPhone, and do not require connectivity to determine when a notification is to be displayed. Recall that there can be more app types than IM. For example, the calendar app provides reminders. Don't you think a third party task list app could benefit from reminder notifications?
I wonder, is there a way to add to add calendar events from your own app, complete with reminders? Either that or a local push service is enabled sometime in the future
Th SDK rules forbid VoIP outside of WiFi, but I see no reason why they can't use the new services set up by Apple to push incoming calls to you while connected via WiFi. Or if the IP address hack still works, and you'll be hanging around, say, an office building all day, you could.
It'd surely require quite a change though for VoIP providers who would have to initiate calls through Apple's server instead of using SIP/STUN directly. I really can't see it happening as the service would then be dependent on the performance of Apple's server, not the VoIP provider.
It'd surely require quite a change though for VoIP providers who would have to initiate calls through Apple's server instead of using SIP/STUN directly. I really can't see it happening as the service would then be dependent on the performance of Apple's server, not the VoIP provider.
It would require a change on their part, but not a big one. One possible solution, have the native iPhone VoIP app inform Apple's push service to monitor for the incoming signal, then tell the VoIP server to send a simple notification ping and caller ID of incoming call to Apple's push server, which would then get pushed to your device as a simple text message. If you see/hear/feel the notifcation and initiate the App before it goes to voicemail (longer ring time can also be initiated) then it connects and pushes the call through.
I think Skype could do this with ease. Of course, VoIP is time sensitive so this is not a full proof plan, but the best I can think of under the rules of the SDK.
Internet radio is like the car going to a place, by definition it needs energy, opening the sunroof (getting a notification about a forgotten SMS) doesn't really need energy in the same manner (at least not energy I have to pay for).
I don't know if that made any sense, if not, I think you should just let it go :-)
You are using your battery to open the sun roof. When you start your car and its burning gas. Your alternator has to replenish the energy you used to open the sunroof.
Nothing is free.
Have you ever used a Jailbroken phone? I ask because it REALLY sounds like you are speaking from ignorance. I run a ton of apps on mine and have NEVER had a problem beyond the occasional crash in Safari, and that happens jailbroken or not.
I have a friend who has used jail broken apps and has had many problems. There are reports across the internet of problems with jailbroken apps. So its not an entirely safe environment.
Beyond that, the entire concept of protecting the lowest common denominator is unfair to anyone that is willing to take that risk. Apple isn't letting you do what you want with your phone, and that is absurd and insulting. What are you going to suggest next, that they start checking and signing applications in OS X because a few luddites don't know how to use their computers? Give me a break.
What is the better platform? One in which you are assured all of the 3rd party apps work without negative impact on the device, or one where you are never completely sure.
And if a 3rd party app negatively affects the phone who is the general user going to blame. The 3rd party app or the phone?
Since Jobs made such a big deal of "tracking" iPhones with the GPS chip, I assume some sort of solution will exist. My guess is that users will opt-in to which companies/services should have access to iPhone location data (Apple, Loopt, etc.). If Apple is allowed to have access, then it will store periodic GPS pings from the iPhone on its servers. Apps that have been authorized by the user will be able to query the location data directly from Apple's servers.
Thoughts?
-Ajay
http://mobileopportunity.blogspot.co...ouncement.html
The first thing developers should ask is whether Apple is going to charge them money for traffic going thru their servers.
http://mobileopportunity.blogspot.co...ouncement.html
I believe SJ said it is free for all developers.
The other thing I hope for is that Apple give MobileMe users the ability to remote wipe.
I'm surprised this wasn't announced. Even if it would be the only be available for .Mac/MobileMe customers, it would be a cheap feature to add while adding incredible value via security to two products.
............ On top of that, your entire second argument is a logical fallacy. What technically illiterate people do you know that go about installing applications on their phones?
I think this is one of the reasons Apple is doing it this way.
The App Store makes it trivially easy to find, purchase and install apps on your iPhone. The process is much like buying and transferring music to your iPod.
Given that, it really would be quite easy for an unsophisticated user to download a bunch of apps that could drain the battery in the background, were it allowed.
Just seems that they're making things unnecessarily complex for developers and well-informed users. In reference to AjayToo's message, why even go through Apple's servers at all (thereby adding more bandwidth requirements)? I can easily picture an app that would be periodically checking the GPS and taking some action accordingly, either locally (when reaching a predetermined location) or reporting via a TCP socket to a different server. I understand Apple's concern about battery life and background apps, but I see other, and not mutually-exclusive solutions. An application could "register" to be awaken in the background every x seconds to do whatever it needs to do. A well-behaved app in this mode would take as little processor time as possible, and register for the next activation with the minimum time required to accomplish the task (for example, a birthday reminder app doesn't need to check every second what day it is: it could be scheduled to test once a day, and that would suffice). Any thoughts on that?
It's not complex at all for the user. The app still fucntions as if it's still running without constantly using the system resources.As for developers, it's something new for them but the end result is that their apps get used more than ones that aren't informing the user immediately.
As for the "x seconds" solution it would be impossible to create an app that would work. The only solution here is to have a user-controlled interface to alter the time between server checks, but this wouldn't be the same at all times and would require the user to use an inelegant soltuion.
For example, let's take an IM client for example. If I'm in a conversation and waiting for a reply I can use the other aspects of my phone while I wait for a response. When it comes in, I know immediately and can go to the message. Your solution requires the phone making the outgoing connection to the server. The lower the time the more power is used (there is no way I could be waiting for an IM all night with the device checking every 1 minute if it wasn't plugged in. IF I choose a 30 minute check the phone will last all night but I may have to wait over 29 minutes to know that the response has come in. No matter where you put the time frame you are either losing power or losing instantaneous mesages.
Now think about having a dozen apps checking periodically for messages. None of that is good for the user. And subsequently it hurts developers if you aren't buying as many apps.
Just trying to plan ahead.