Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

iPhone SDK Limitations: Multitasking, Java, Emulators

Relax.

It seems like some on this thread have forgotten that the iPhone is still fundamentally a cell phone. That's it's first and most important function. It's not a mini Mac Pro that somehow squishes into your pocket. That means it has some limitations? Compared to what; Windows Mobile? Jeesh.:rolleyes:
 
Eraserhead said:
It is the lack of memory, and that flash isn't really suitable as swap space due to the limited read/write cycles.
Click to expand...

There's is that, but even if the read/write cycles were not an issue in practice, you would still have a limited flash resource whose size isn't really big enough to accommodate an appropriately sized swap file/partition (16GB is a lot, but goes quickly with media storage). So practically speaking, we're limited to the physical RAM of the phone.

FTR, Windows (or any OS for that matter) flash-based devices would have the same technical restriction as well.
 
Anyone having problems with the Aspen Simulator "rotate left / right" menu option for landscape presentation?
Anyone having trouble getting audio to play in the Aspen sim?
 
bristolian said:
I haven't seen anyone commenting much about whether the iPhone will be able to support external devices, such as a GPS unit, a games controller or an external keyboard even. Any thoughts?
Click to expand...

as these would be most conviniently handled by processes running in the background, probly not. apple has explicitly stated that 3rd party apps won't be able to access connector port so that kind of external devices won't be supported.
 
IMO, the restriction makes sense. However, I anticipate that it may be relaxed after the initial developer frenzy. If not, then it will certainly happen in the beefier v.2 devices.

Although a convergence device, this is still more of a mobile phone than anything else. That functionality should trump all others.
 
sjo said:
yeah, that's why apple doesn't make any laptops with flash drives, oh, wait, http://www.apple.com/macbookair/ ...
Click to expand...

Yup. Not to mention any and all PDA's.
And the iPhone has a processor and memory that can run with most of them.
I don't understand why people have to invent hardware limitations as the reason for these limitations, when the hardware doesn't have those limitations on other platforms.
If nothing else, that is certainly a red alert to apologism (this of course to the bloke you responded to).
 
cnorth3 said:
It seems like some on this thread have forgotten that the iPhone is still fundamentally a cell phone. That's it's first and most important function. It's not a mini Mac Pro that somehow squishes into your pocket. That means it has some limitations? Compared to what; Windows Mobile? Jeesh.:rolleyes:
Click to expand...

Funny you should mention that. It has the same processor speed etc. What's the problem comparing it to an OS like that? Ah, I see, it's an Apple-product, so it's above comparison …
 
Universal Remote?

This nifty little device replaced my old cell phone and my aging iPod. Now I would like to see it replace all of my remote controls sitting there on my coffee table.

I see the potential of the iPhone/Touch in becoming the best universal remote. Even better than some existing remotes costing twice the price of an iPhone/Touch. Maybe with a dongle attached to the iPhone or Touch that would emit an InfraRed signal, or just for the iPhone with a bluetooth accessory placed near the components that are to be controlled.:confused:
 
When you get right down to it, the "restrictions" are to maintain an interface paradigm, not to overtly restrict a functionality. So if your app does tasks that actually interfere with the smooth operation of "main tasks" it is lilely they would be restricted under the license restrictions.

If on the other hand your app does background tasks central to the function of the tool and does not appreciably impact user interaction (snappiness), then I suspect Apple will allow it on a case by case basis. The language allows them to refuse by default pending proof of that trade off.

We already know Apple alows considerable latitude to important app developers and despite the obvious and stated limitations of java and virtual machines to the iPhone's ultimate success, I also suspect the publishers will aswage Apple's concerns sufficient to make their environments available to their narrow markets where presence is mandatory.

It is a judgement call. Publishers who knowingly violate the default conditions would do well to both minimize it and justify those examples that persist. Maybe even NOTIFY (nag) the user that usage will impact the overall interface experience.

Rocketman
 
Common

Most mobile phone OSes have the concept of suspended states. PalmOS does exactly this - when you switch out of an app, it saves its state and quits.

Other mobile OSes like Windows Mobile and Symbian try to allow processes to stay running in the background. This causes several problems:

- Complexity:It's not clear to the user when an app quits and when it just goes to the background - WM and Symbian have task managers which is way too complex for a tiny little screen on a mobile.

- Reliabilty: Symbian forums are full of complaints about low memory causing crashes and slowness. Open more than a few apps and they grind to a halt. The low memory available on a mobile phone forces the user to manually quit applications anyway.

- Performance: why waste system memory on a background application on a device with such a tiny screen? Are you really going to split the screen and have your web browser and email open at the same time or something?

From the sound of it, Apple have taken the sensible decision here. By only having one application running at once (with certain exceptions) they get a more reliable, simpler and faster solution. Saving the state of most applications will take writing out a few dozen bytes to storage, and the OS on the iPhone seems to be pretty quick at launching processes, so the whole thing should be transparent to the user.
 
Relax, its coming

I think the two main limitations (background tasks and data syncing) will be resolved soon. For background tasks, Apple just needs time to figure out exactly how to appropriately sandbox this to prevent it from hurting the performance of other apps and battery life.

The data syncing will surely be based on Sync Services--they probably just need more time to get this polished for external release.

My guess is that, Rather than unrestricted background tasks, apps will probably be allowed to register for either push or pull notifications.
- push notifications will have to follow a strict protocol. The OS will implement receiving these notifications, so no app specific code is run.
- pull notifications will be probably be a little app specific "plug-in" process that can poll in whatever way it wants. But the OS will probably only let it run for x seconds before killing it, and let it run at most once every 15 min (according to the user's preference).
Both notification methods will only be able to set a number (which is displayed in a red circle over the icon of the appropriate app) and/or activate the notification chime/vibration. And possibly accept a small amount of data.

There are obviously many legitimate and phone-friendly uses for app-specific message notifications. A good way of providing this service to third-party apps definitely enhances the platform. So its just a matter of time before Apple has an approved solution.
 
winterspan said:
The SDK is free I believe. The $99 would be to join the Apple Developer program and obtain a digital certificate to be able to distribute Apps through the iTunes store.

I'm not experienced in Objective-C, but I have heard its much less of a nightmare than C++ and actually more elegant to use than C. Nevertheless, if you haven't done ANY type of programming before, I'd recommend you start easy and choose a simpler language.

PHP is nice and easy, but mostly limited to web applications.
Java is more advanced and much more versatile with a huge dev community, but it has its drawbacks.
I don't have alot of experience in Python, but it seems to be a major favorite among many, and very intuitive and developer friendly. Ruby is much the same, although like PHP, it's much less popular for anything other than web applications.
C# and VB.net are also very nice to use, but because they use a "virtual machine" like Java, they are mostly limited to Microsoft systems.

If you are ambitious to get moving on the iPhone SDK ASAP and are a quick learner, then you should just dive head first into Objective-C.

I would post some links for getting started, but honestly this is such a popular topic on the web that you won't have any trouble finding resources and information.
Click to expand...

Thanks for the info. I downloaded the SDK and am going through it :) Apple has posted a bunch of videos about basics and getting started too. This is going to be fun. Right now I am going through the simulator and videos to try and find new features in 2.0 hehe :) Do they have Chinese in the current firmware? It is in the simulator!
 
quantumbits said:
Although a convergence device, this is still more of a mobile phone than anything else. That functionality should trump all others.
Click to expand...

Let's not forget the iPod Touch. The Apps should run on both devices, though some will limit functionality on the touch.
 
sjo said:
yeah, windows 2.0 was such an awesome os, no-one ever wanted to have a program in the background eating all the resources...

seriously speaking, modern operating system such as os x would not allocate any cpu cycles to a process idling in the background. it should also be able to manage the memory in such a way that a process in the background would not affect the processes on the foreground.

in other words, considering that iphone is touted having the most advanced operating system of all the smart phones, this is really bizard and makes one wonder what exactly they had to do to make the mini-osx feasible.

or is this apples' way of ensuring dominance over the small software vendors. say someone introduces a killer program, but it lacks some features due inability to run in the background. then it's easy for apple to make similar program, although slightly better, having the ability to run in the background.

speaking of restriction, i've understood that there is no access to file system, making word processors etc impossible to implement. this and the no 3rd party apps during phone calls would be a serious blow to enterprise usage, when users need to make notes to word processor or spreadsheet or check things while on the phone.
Click to expand...

Not sure if you've noticed, but the iPhone/touch are not permanently connected to a wall jack for unlimited, endless power. In addition, memory constraints are, for the moment, somewhat of a reality. To complain that an early gen hardware device and its os (less than a year old btw) should allow all of the freedoms of a desktop system are silly. I applaud Apple for taking this slowly. (Although the depth of the SDK sure accomplished an pre-emptive slapdown of the autowhine crowd.
 
Cool

I have an ipod touch, but i realized something for iphone users. There will no longer be a need to use AT&T's texting, because you can use AIM to text cellphones for free. Why pay for texting any more? The iphone just got even better. Can't wait for all these app's on my ipod touch!
 
stein0726 said:
I have an ipod touch, but i realized something for iphone users. There will no longer be a need to use AT&T's texting, because you can use AIM to text cellphones for free. Why pay for texting any more?
Click to expand...
because the iphone plan on att gives you 200 texts anyway. good way to get around it if you're a super-heavy text user, but I send/get maybe 5 messages a day.
 
Aihal said:
Most mobile phone OSes have the concept of suspended states. PalmOS does exactly this - when you switch out of an app, it saves its state and quits.

Other mobile OSes like Windows Mobile and Symbian try to allow processes to stay running in the background. This causes several problems:

- Complexity:It's not clear to the user when an app quits and when it just goes to the background - WM and Symbian have task managers which is way too complex for a tiny little screen on a mobile.

- Reliabilty: Symbian forums are full of complaints about low memory causing crashes and slowness. Open more than a few apps and they grind to a halt. The low memory available on a mobile phone forces the user to manually quit applications anyway.

- Performance: why waste system memory on a background application on a device with such a tiny screen? Are you really going to split the screen and have your web browser and email open at the same time or something?

From the sound of it, Apple have taken the sensible decision here. By only having one application running at once (with certain exceptions) they get a more reliable, simpler and faster solution. Saving the state of most applications will take writing out a few dozen bytes to storage, and the OS on the iPhone seems to be pretty quick at launching processes, so the whole thing should be transparent to the user.
Click to expand...

you have obviously never used the new nokia s60 devices, because if you had you would realize how uninformed you are.
 
Hattig said:
Oh well that puts paid to the idea that people can write small background processes to listen for network events. I think Apple needs to think some more about this...
Click to expand...

They most likely already have. Apple wants to control the sum total of all possible background processes so that they can more precisely account for the amount of actual RAM, the number of CPU cycles, and the micro-watt-hours of battery required, and can then much better guarantee that the rest of these resources will be available for phone use or for any foreground app, and still maintain a given amount of user responsiveness, no matter what the user has installed from the official app store.

Apple obviously thinks that the bulk of its target market value stability, responsiveness, and a tiny selected number of targeted apps (push email, chat, etc.), over allowing users to slow their device down to a crawl running arbitrary applications.

Palm attempted to solve some of these issues with their now defunct Cobalt OS. This OS had a tiny limited pool of memory and CPU cycles that the background processes of all user applications had to share. Not sure they ever figured out how to get a bunch of unrelated random apps to share properly.
 
ruinfx said:
you have obviously never used the new nokia s60 devices, because if you had you would realize how uninformed you are.
Click to expand...

I have mostly developed on UIQ, Palm, WM and Linux, the few S60 devices I've used were from the N70 era when they were pathetically slow and crash-prone.

From a quick google, the N95 still has similar problems, with forum posts recommending closing every application when you quit and an advice article over at AllAboutSymbian with multitasking advice, showing which apps use the most memory in the background.
 
firewood said:
Apple obviously thinks that the bulk of its target market value stability, responsiveness, and a tiny selected number of targeted apps (push email, chat, etc.), over allowing users to slow their device down to a crawl running arbitrary applications.
Click to expand...

Thank god I have Apple to save me from loading too many applications! I have no idea what I would do without Apple. I wish they would do the same for OSX because when I run a bunch of applications at one time things can get sluggish. I know the obvious answer is for me to close some apps, but I would much rather Apple tell me what I can and can't run.
 
Isn't Belkin trying to build an external GPS receiver? A youtube video shows a guy with a hacked phone that constructed already such device.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back