In the beginning, there was no prtense from Apple that the iPhone was a business device at all. None! Apple even made remarks to that effect.
But, despite the lack of most business aspects, software, security, database support, etc., the phone kept sneaking into businesses anyway.
So, starting with the 3G, and the ver. 2 OS, they began to make a push.
But if you, or anyone else, thinks that Apple is finished adding to this, you'd be wrong.
It's easy to forget that the established business phones took years to get where they are today, and that they were added to over time. It's simply impossible to add every requirement in a ver 1 software release.
Android has a long way to go as well.
As far as your having to register, well, gee, what a big deal to complain about!
Yes it is that simple if you plan ahead and they did not. Like you said, it was not meant to be a business phone. Actually, I really rather Apple not try to make it into a business phone because they are bad at it. Good at marketing but bad in business vision. I say the good and the bad as I see it. With that said, I like apple's strenghts (UI, uniformity etc) and hate their weakness ([their ego] failure to involve the dev ecosystem etc). They always wait till there is competition and not when the supporting community suggests/needs it. That's my bottom line.
Now if you think I'm complaining about signing up before reading what an sdk can do, then you have been an apple cheerleader for far too long. An sdk documentation helps someone to better make a decision if their app will be supported by the api's provided by the platform. Now, signing up and finding out that my app cannot be supported on the iphone because it needs a background process is sheer stupidity and wast of my time and an extra account someone else doesn't need. In my case, i compromised and degraded my app to fit the iphone eco apps but still stupid if you ask me.
Yes it is that simple if you plan ahead and they did not. Like you said, it was not meant to be a business phone. Actually, I really rather Apple not try to make it into a business phone because they are bad at it. Good at marketing but bad in business vision. I say the good and the bad as I see it. With that said, I like apple's strenghts (UI, uniformity etc) and hate their weakness ([their ego] failure to involve the dev ecosystem etc). They always wait till there is competition and not when the supporting community suggests/needs it. That's my bottom line.
Apple isn't "bad" at it. They're new to it. Apple hasn't been interested in larg businesses, and small one have different needs and concerns. Apple has been good there, while ignoring big business, because they weren't, and didn't want to be set up to deal with that.
This could be changing, because even big business is placing more Apple equipment in their environments than they have in a long time.
Apple hasn't been interested in helping them do that, which is why you think that they are bad at it. You cant be bad at something that you are avoiding doing at all. The most they've done is to make concessions on interoperability at the OS level, which has been getting better over time.
As for the ver 2 phone OS, it's much more business friendly than was ver 1. As a result, may commentators have said that for most businesses, thought not all, it is enough to get them in.
I've no doubt that as Apple has seem the light here, ver 3 will be friendlier yet. It's interesting that in the last big survey, the iPhone was given much higher ratings from business customers in every area that was given the Blackberry. That says something interesting. It says that even with a possibly "half finished" product, it beat out the otherwise most highly thought of product in the business category.
You have to think of that as well.
Quote:
Now if you think I'm complaining about signing up before reading what an sdk can do, then you have been an apple cheerleader for far too long. An sdk documentation helps someone to better make a decision if their app will be supported by the api's provided by the platform. Now, signing up and finding out that my app cannot be supported on the iphone because it needs a background process is sheer stupidity and wast of my time and an extra account someone else doesn't need. In my case, i compromised and degraded my app to fit the iphone eco apps but still stupid if you ask me.
Please don't call people cheerleaders, fanboys, etc. It gets in the way of intelligent conversation. I respect your views in this even if I don't agree with them, and I expect you to respect mine as well.
I understand what an SDK is for, and I understand what the documentation is for as well. I also understand that signing up for it is not a big deal.
What app did you write BEFORE you signed up for the SDK and received the information and software required for writing it?
If this was all a waste of your time, why did you bother to do it? I don't understand that.
If all you had was an idea for an app first, then you didn't have much.
Are you also planning to write this app for the Android? That's about as open as you can get right now.
Apple's Push concept is(was?) that Apple would be hosting the servers, everything would be going through that.
This means less work for the developers, and no worrying about having to buy, and maintain their own servers, or the expense of it, as Apple would be shouldering that load for everyone.
No, that was part of it. But as a developer you had to notify Apple's server of any notifications you want pushed, so they could collate them to send to the iPhone.
With this method you still need(ed?) your own server to act as a go-between from whatever service to Apple.
Seems like a pain to me, but a decent solution for bigger developer groups such as AIM, who already have their own servers.
And there's simply no reason to allow people to write their own background logic. What are they going to do? Monitor device states, log event data somewhere and notify the user.
Sure, there are reasons. Take for example a simple thing like a step counter (I use steptrack) that simply stops counting because you answer a call or do anything else.
Or maps. I want it to continue to track my position (and possibly movement) so there's to re-acquire time when I pull the GUI back up after say googling something or answering a call.
There aren't that many apps I want running in background but the ones that I do want would work a lot better if I could push them into the background.
No, that was part of it. But as a developer you had to notify Apple's server of any notifications you want pushed, so they could collate them to send to the iPhone.
With this method you still need(ed?) your own server to act as a go-between from whatever service to Apple.
Seems like a pain to me, but a decent solution for bigger developer groups such as AIM, who already have their own servers.
The point is that you aren't needing a server to service your customers directly, which is a much bigger pain.
The point is that you aren't needing a server to service your customers directly, which is a much bigger pain.
Well whether you are serving the customer straight to the device or through Apple's server, you still need to control a server to make a push notification app.
My point is it is harder for a dev to make a push app than to have the app (or a service part) run in the background to fetch data.
If I wrote a Flickr app that could watch someone's photostream and notify the user of any updates, I would have to write some server code to track any number of users watch lists and post back to Apple if one of them were updated. It's also worth noting that if my app took off, I'd have to scale quickly to maintain the push feature.
With a background process, I just write a component that checks for updates.
I'm not saying I prefer the background running of apps, certainly there's a huge elegance in Apple's push notification system from a system resource point of view. From a developer POV, it just makes things that much harder to achieve something relatively simple.
Well whether you are serving the customer straight to the device or through Apple's server, you still need to control a server to make a push notification app.
My point is it is harder for a dev to make a push app than to have the app (or a service part) run in the background to fetch data.
If I wrote a Flickr app that could watch someone's photostream and notify the user of any updates, I would have to write some server code to track any number of users watch lists and post back to Apple if one of them were updated. It's also worth noting that if my app took off, I'd have to scale quickly to maintain the push feature.
With a background process, I just write a component that checks for updates.
I'm not saying I prefer the background running of apps, certainly there's a huge elegance in Apple's push notification system from a system resource point of view. From a developer POV, it just makes things that much harder to achieve something relatively simple.
I haven't seen to many developers speak out against it. Most comments seem to be positive.
Apple isn't "bad" at it. They're new to it. Apple hasn't been interested in larg businesses, and small one have different needs and concerns. Apple has been good there, while ignoring big business, because they weren't, and didn't want to be set up to deal with that.
This could be changing, because even big business is placing more Apple equipment in their environments than they have in a long time.
Apple hasn't been interested in helping them do that, which is why you think that they are bad at it. You cant be bad at something that you are avoiding doing at all. The most they've done is to make concessions on interoperability at the OS level, which has been getting better over time.
As for the ver 2 phone OS, it's much more business friendly than was ver 1. As a result, may commentators have said that for most businesses, thought not all, it is enough to get them in.
I've no doubt that as Apple has seem the light here, ver 3 will be friendlier yet. It's interesting that in the last big survey, the iPhone was given much higher ratings from business customers in every area that was given the Blackberry. That says something interesting. It says that even with a possibly "half finished" product, it beat out the otherwise most highly thought of product in the business category.
You have to think of that as well.
Please don't call people cheerleaders, fanboys, etc. It gets in the way of intelligent conversation. I respect your views in this even if I don't agree with them, and I expect you to respect mine as well.
I understand what an SDK is for, and I understand what the documentation is for as well. I also understand that signing up for it is not a big deal.
What app did you write BEFORE you signed up for the SDK and received the information and software required for writing it?
If this was all a waste of your time, why did you bother to do it? I don't understand that.
If all you had was an idea for an app first, then you didn't have much.
Are you also planning to write this app for the Android? That's about as open as you can get right now.
If you do, then let us know about the process.
Melgross, my apologize for my language if I offended anyone. Again, my apologize. I developed my app for the android and currently porting it to the iphone. I guess you are right that signing up is a small task. I would have like to know the details of the sdk before sign up. I guess because the api of the iphone is a way a subset of that in the android sdk api, I had to find a work away. I could have made the choice to ignore the iphone but I like it and believe it can be better. I hope apple becomes more open with it's thought and future road map for the iphone so developers like me can join in. Again, my apologize for my earlier post if it offered anyone and specifically, Melgross
I hope apple becomes more open with it's thought and future road map for the iphone so developers like me can join in.
Just to give you some background on how open Apple is with future road maps.
Apple did not bring a prototype to show AT&T executives when they negotiated for AT&T to carry the phone. AT&T agreed to carry the iPhone without seeing the phone. AT&T executives did not see the iPhone until a couple of years later, days before Steve Jobs announced it at Mac World.
Apple employees are not allowed to share information with other Apple employees who are not directly working on the same project. Employees within Apple who are not working on the iPhone have no idea what is going on with the iPhone.
The likely hood of Apple sharing the future road map of the iPhone is not likely at all.
Sure, there are reasons. Take for example a simple thing like a step counter (I use steptrack) that simply stops counting because you answer a call or do anything else. Or maps. I want it to continue to track my position (and possibly movement) so there's to re-acquire time when I pull the GUI back up after say googling something or answering a call.
And my point is that if the step counter could get a consistent log of 'step' events (i'd imagine sharp accelerometer changes, or GPS data) and the map application a steady log GPS positions, from when they weren't running, there'd be no difference to the user whether those apps themselves ran in the background, or the push API just logged those events on their behalf.
And if the push API is the app running in the background, then other apps still have a reasonable expectation of what the device state will be when they're running and don't have to worry about remaining performant if apps X, Y & Z are running in the background.
Furthermore, X, Y & Z aren't duplicating the code of accessing the network/gps/accelerometer, occupying memory and writing data to flash, thereby draining the battery far faster than necessary.
Comments
Oops! I don't want to change the history of the post since it's been noticed already.
But I will apologize.
In the beginning, there was no prtense from Apple that the iPhone was a business device at all. None! Apple even made remarks to that effect.
But, despite the lack of most business aspects, software, security, database support, etc., the phone kept sneaking into businesses anyway.
So, starting with the 3G, and the ver. 2 OS, they began to make a push.
But if you, or anyone else, thinks that Apple is finished adding to this, you'd be wrong.
It's easy to forget that the established business phones took years to get where they are today, and that they were added to over time. It's simply impossible to add every requirement in a ver 1 software release.
Android has a long way to go as well.
As far as your having to register, well, gee, what a big deal to complain about!
Yes it is that simple if you plan ahead and they did not. Like you said, it was not meant to be a business phone. Actually, I really rather Apple not try to make it into a business phone because they are bad at it. Good at marketing but bad in business vision. I say the good and the bad as I see it. With that said, I like apple's strenghts (UI, uniformity etc) and hate their weakness ([their ego] failure to involve the dev ecosystem etc). They always wait till there is competition and not when the supporting community suggests/needs it. That's my bottom line.
Now if you think I'm complaining about signing up before reading what an sdk can do, then you have been an apple cheerleader for far too long. An sdk documentation helps someone to better make a decision if their app will be supported by the api's provided by the platform. Now, signing up and finding out that my app cannot be supported on the iphone because it needs a background process is sheer stupidity and wast of my time and an extra account someone else doesn't need. In my case, i compromised and degraded my app to fit the iphone eco apps but still stupid if you ask me.
Yes it is that simple if you plan ahead and they did not. Like you said, it was not meant to be a business phone. Actually, I really rather Apple not try to make it into a business phone because they are bad at it. Good at marketing but bad in business vision. I say the good and the bad as I see it. With that said, I like apple's strenghts (UI, uniformity etc) and hate their weakness ([their ego] failure to involve the dev ecosystem etc). They always wait till there is competition and not when the supporting community suggests/needs it. That's my bottom line.
Apple isn't "bad" at it. They're new to it. Apple hasn't been interested in larg businesses, and small one have different needs and concerns. Apple has been good there, while ignoring big business, because they weren't, and didn't want to be set up to deal with that.
This could be changing, because even big business is placing more Apple equipment in their environments than they have in a long time.
Apple hasn't been interested in helping them do that, which is why you think that they are bad at it. You cant be bad at something that you are avoiding doing at all. The most they've done is to make concessions on interoperability at the OS level, which has been getting better over time.
As for the ver 2 phone OS, it's much more business friendly than was ver 1. As a result, may commentators have said that for most businesses, thought not all, it is enough to get them in.
I've no doubt that as Apple has seem the light here, ver 3 will be friendlier yet. It's interesting that in the last big survey, the iPhone was given much higher ratings from business customers in every area that was given the Blackberry. That says something interesting. It says that even with a possibly "half finished" product, it beat out the otherwise most highly thought of product in the business category.
You have to think of that as well.
Now if you think I'm complaining about signing up before reading what an sdk can do, then you have been an apple cheerleader for far too long. An sdk documentation helps someone to better make a decision if their app will be supported by the api's provided by the platform. Now, signing up and finding out that my app cannot be supported on the iphone because it needs a background process is sheer stupidity and wast of my time and an extra account someone else doesn't need. In my case, i compromised and degraded my app to fit the iphone eco apps but still stupid if you ask me.
Please don't call people cheerleaders, fanboys, etc. It gets in the way of intelligent conversation. I respect your views in this even if I don't agree with them, and I expect you to respect mine as well.
I understand what an SDK is for, and I understand what the documentation is for as well. I also understand that signing up for it is not a big deal.
What app did you write BEFORE you signed up for the SDK and received the information and software required for writing it?
If this was all a waste of your time, why did you bother to do it? I don't understand that.
If all you had was an idea for an app first, then you didn't have much.
Are you also planning to write this app for the Android? That's about as open as you can get right now.
If you do, then let us know about the process.
Apple's Push concept is(was?) that Apple would be hosting the servers, everything would be going through that.
This means less work for the developers, and no worrying about having to buy, and maintain their own servers, or the expense of it, as Apple would be shouldering that load for everyone.
No, that was part of it. But as a developer you had to notify Apple's server of any notifications you want pushed, so they could collate them to send to the iPhone.
With this method you still need(ed?) your own server to act as a go-between from whatever service to Apple.
Seems like a pain to me, but a decent solution for bigger developer groups such as AIM, who already have their own servers.
And there's simply no reason to allow people to write their own background logic. What are they going to do? Monitor device states, log event data somewhere and notify the user.
Sure, there are reasons. Take for example a simple thing like a step counter (I use steptrack) that simply stops counting because you answer a call or do anything else.
Or maps. I want it to continue to track my position (and possibly movement) so there's to re-acquire time when I pull the GUI back up after say googling something or answering a call.
There aren't that many apps I want running in background but the ones that I do want would work a lot better if I could push them into the background.
No, that was part of it. But as a developer you had to notify Apple's server of any notifications you want pushed, so they could collate them to send to the iPhone.
With this method you still need(ed?) your own server to act as a go-between from whatever service to Apple.
Seems like a pain to me, but a decent solution for bigger developer groups such as AIM, who already have their own servers.
The point is that you aren't needing a server to service your customers directly, which is a much bigger pain.
The point is that you aren't needing a server to service your customers directly, which is a much bigger pain.
Well whether you are serving the customer straight to the device or through Apple's server, you still need to control a server to make a push notification app.
My point is it is harder for a dev to make a push app than to have the app (or a service part) run in the background to fetch data.
If I wrote a Flickr app that could watch someone's photostream and notify the user of any updates, I would have to write some server code to track any number of users watch lists and post back to Apple if one of them were updated. It's also worth noting that if my app took off, I'd have to scale quickly to maintain the push feature.
With a background process, I just write a component that checks for updates.
I'm not saying I prefer the background running of apps, certainly there's a huge elegance in Apple's push notification system from a system resource point of view. From a developer POV, it just makes things that much harder to achieve something relatively simple.
Well whether you are serving the customer straight to the device or through Apple's server, you still need to control a server to make a push notification app.
My point is it is harder for a dev to make a push app than to have the app (or a service part) run in the background to fetch data.
If I wrote a Flickr app that could watch someone's photostream and notify the user of any updates, I would have to write some server code to track any number of users watch lists and post back to Apple if one of them were updated. It's also worth noting that if my app took off, I'd have to scale quickly to maintain the push feature.
With a background process, I just write a component that checks for updates.
I'm not saying I prefer the background running of apps, certainly there's a huge elegance in Apple's push notification system from a system resource point of view. From a developer POV, it just makes things that much harder to achieve something relatively simple.
I haven't seen to many developers speak out against it. Most comments seem to be positive.
The Newton is still alive and kicking. Just not on Apple's agenda.
yup. there are still things that the newton does better than the iphone.
Apple isn't "bad" at it. They're new to it. Apple hasn't been interested in larg businesses, and small one have different needs and concerns. Apple has been good there, while ignoring big business, because they weren't, and didn't want to be set up to deal with that.
This could be changing, because even big business is placing more Apple equipment in their environments than they have in a long time.
Apple hasn't been interested in helping them do that, which is why you think that they are bad at it. You cant be bad at something that you are avoiding doing at all. The most they've done is to make concessions on interoperability at the OS level, which has been getting better over time.
As for the ver 2 phone OS, it's much more business friendly than was ver 1. As a result, may commentators have said that for most businesses, thought not all, it is enough to get them in.
I've no doubt that as Apple has seem the light here, ver 3 will be friendlier yet. It's interesting that in the last big survey, the iPhone was given much higher ratings from business customers in every area that was given the Blackberry. That says something interesting. It says that even with a possibly "half finished" product, it beat out the otherwise most highly thought of product in the business category.
You have to think of that as well.
Please don't call people cheerleaders, fanboys, etc. It gets in the way of intelligent conversation. I respect your views in this even if I don't agree with them, and I expect you to respect mine as well.
I understand what an SDK is for, and I understand what the documentation is for as well. I also understand that signing up for it is not a big deal.
What app did you write BEFORE you signed up for the SDK and received the information and software required for writing it?
If this was all a waste of your time, why did you bother to do it? I don't understand that.
If all you had was an idea for an app first, then you didn't have much.
Are you also planning to write this app for the Android? That's about as open as you can get right now.
If you do, then let us know about the process.
Melgross, my apologize for my language if I offended anyone. Again, my apologize. I developed my app for the android and currently porting it to the iphone. I guess you are right that signing up is a small task. I would have like to know the details of the sdk before sign up. I guess because the api of the iphone is a way a subset of that in the android sdk api, I had to find a work away. I could have made the choice to ignore the iphone but I like it and believe it can be better. I hope apple becomes more open with it's thought and future road map for the iphone so developers like me can join in. Again, my apologize for my earlier post if it offered anyone and specifically, Melgross
Because nothing a corporation says could ever be the truth? Or is it just Apple who you don't believe?
yeah you are right...
_______________________
http://blog.gethsemanefuneral.com
_______________________
http://gethsemanefuneral.com
I hope apple becomes more open with it's thought and future road map for the iphone so developers like me can join in.
Just to give you some background on how open Apple is with future road maps.
Apple did not bring a prototype to show AT&T executives when they negotiated for AT&T to carry the phone. AT&T agreed to carry the iPhone without seeing the phone. AT&T executives did not see the iPhone until a couple of years later, days before Steve Jobs announced it at Mac World.
Apple employees are not allowed to share information with other Apple employees who are not directly working on the same project. Employees within Apple who are not working on the iPhone have no idea what is going on with the iPhone.
The likely hood of Apple sharing the future road map of the iPhone is not likely at all.
Sure, there are reasons. Take for example a simple thing like a step counter (I use steptrack) that simply stops counting because you answer a call or do anything else. Or maps. I want it to continue to track my position (and possibly movement) so there's to re-acquire time when I pull the GUI back up after say googling something or answering a call.
And my point is that if the step counter could get a consistent log of 'step' events (i'd imagine sharp accelerometer changes, or GPS data) and the map application a steady log GPS positions, from when they weren't running, there'd be no difference to the user whether those apps themselves ran in the background, or the push API just logged those events on their behalf.
And if the push API is the app running in the background, then other apps still have a reasonable expectation of what the device state will be when they're running and don't have to worry about remaining performant if apps X, Y & Z are running in the background.
Furthermore, X, Y & Z aren't duplicating the code of accessing the network/gps/accelerometer, occupying memory and writing data to flash, thereby draining the battery far faster than necessary.