[samrod]

"Microsoft paved the way for this path with its Windows CE operating system more than a decade ago"
Right. Apple didn't pave the way earlier with its original netbook running an OS designed for a PDA: the eMate 300 running Newton OS.
Be it a PDA or a netbook, Apple's been there, done that. PC tech columnists who know nothing about Apple before the iMac, or what all the rumor sites are talking about, are only capable of providing the layman's commentary and nothing more.

[bb1968]

Copy Paste
Copy Paste
Everyone's clamoring about copy and paste. I'd so much rather see a decent GPS app with turn by turn spoken directions.

[ipete6]

i hope you can pic and video messages with os 3.0

[ncrbrd]

How many of you grinching about copy-paste own an iPhone even though it doesn't support it? Right, that's what I thought. To be sure, there are technical challenges to putting a worthwhile copy-paste solution into the touch OS, but did anyone stop to think that a big reason it's not there already is that Apple just doesn't care? It's a virtual certainty that the vast majority of people who complain about this missing feature buy the iPhone anyway. It's obviously not a limiting omission if its absence isn't hurting sales, which it isn't, materially.

[gleepskip]

I wish Apple would release a device that only has two features: MMS and copy & paste. All of the other features of the iPhone are pretty worthless.

[LowededWookie]

My point being is that there is already a documented way that doesn't break any rule set out by Apple.

By using SQLLite any application could conceivably access that database to perform the copy paste.

Would Apple implement it? I guess not but the fact the ability is there is what I was getting at.

[swemoney]

I don't think the actual 'buttons' for copy and paste are the problem. You went ahead and jumped past the step where the text is highlighted. I'm assuming the holdup has always been how to actually highlight text without overlapping gestures. Using 2 fingers to 'pinch' the text you want to highlight would overlap with zooming.. just swiping would overlap scrolling.. So I'm sure the 'copy' button would appear when you finally have some text highlighted, you just have to get to that point first..

[robogobo]

@ncrbrd

Um, I think it's a given that the only people complaining about the iPhone's lack of copy/paste would be the ones who own one. Are you saying Apple only wants to sell and not have their customers like what they buy? They just want to take our money once and run? And you really think missing a basic feature isn't hurting sales at all?

and what the shit is a virtual certainty?

@everybody else Jailbreakers have been using Clippy for copy/paste for months now. It works. It's possible.

[paulm]

Oh, I am so very sure that nobody could ever think of that except you... "copyrighted", indeed....

[ryanchaight]

What about landscape mode for typing sms? Is there any talk or anybody else that thinks that would be nice?

[robogobo]

yes! and email.

[dicklacara]

LowededWookie said:

My point being is that there is already a documented way that doesn't break any rule set out by Apple.

By using SQLLite any application could conceivably access that database to perform the copy paste.

Would Apple implement it? I guess not but the fact the ability is there is what I was getting at.

>



That is simply not true. There is no supported API to use an SQLite database that can be read and written by any app.

You can google the web and find discussions on how to write to an SQLite db on the iPhone. You must first copy the DB from within your app bundle to your /Documents folder on the iPhone (or you can create a New SQLite db in your /Documents folder. Your /Documents folder is within your sandbox and is not accessible by any other app.

Here is some code from an Apple SQLite SDK example:

{quote}
- (void)applicationDidFinishLaunching:(UIApplication *)application {
// The application ships with a default database in its bundle. If anything in the application
// bundle is altered, the code sign will fail. We want the database to be editable by users,
// so we need to create a copy of it in the application's Documents directory.
[self createEditableCopyOfDatabaseIfNeeded];
// Call internal method to initialize database connection
[self initializeDatabase];
// Add the navigation controller's view to the window
[window addSubview:navigationController.view];
[window makeKeyAndVisible];
}
{quote}

This same example discusses the implications and overhead of using SQLite (see below).

Also, every app using SQLite takes additional (precious) memory to contain the optional SQLite frameworks.

There are plenty of standard API elements (UITextView, UIWebView, UIImageView, etc.) that could map a clipboard with no memory or performance penalty.

So, I will say it again, using SQLite to implement a clipboard would place too much overhead in every app just to access the clipboard.

Sure, you can use an 18-wheeler to drive to the supermarket... but it doesn't mean you should.

Dick






Memory Management
In iPhone OS, the amount of usable virtual memory is constrained by the device's physical memory. The system will send notifications to applications in cases where available memory runs low. These warnings are received by the application delegate with the expectation is that steps will be taken to reduce in-memory resources. The nature of these steps is left entirely to the developer. Taking no steps at all may in some cases result in the application being terminated.

This sample presents one strategy for handling these memory constraints. This pattern is most applicable to applications where memory consumption is dominated by application data that can be stored offline - applications in which memory consumption is dominated by user interface elements may not find this pattern as useful.

The strategy is oriented around a concept called "object hydration". Loosely defined, hydration refers to fetching stored attributes of an object from a database. In more detail, a bridge between a database and an object oriented programming language is implemented such that a table in the database maps to a class in the programming language, and each row in the table maps to an instance of the class.

In this application, at launch time the application delegate initializes the database connection and retrieves the title and primary key identifier for every object stored in the database. This is sufficient information to present to the user a list of the objects. When the user choses to view or edit additional detail for an object, the object is "hydrated" - the remaining attributes for the object are fetched into memory. The user can inspect object after object, and each will be fetched into memory on demand, slowly growing the memory footprint of the application.

At some point, the device memory threshold will be reached and it will issue the application a low memory warning. The application delegate will receive the warning and respond by "dehydrating" all of the objects. Dehydrating, as the name implies, is the reverse of hydration. All attributes of the object except the essential title and key are written back to the database (if there were changes) and removed from memory. This dramatically reduces the application memory footprint in response to the low memory warning.

In practice, this implementation may be overly coarse - massive writes to disk might result and cause an unacceptable user experience. A more sophisticated implementation might use the dehydration approach in conjunction with a least-recently-used table, flushing stale objects at regular time intervals. This implementation is left to the discretion of developers interested in using this pattern.

[casfian]

I wish iPhone 3.0 should have:
1. Video Call, Please Apple. You're still in the stone age, Apple?
Integrate with either iChat or by it's own.
2. Video Capture. Come on...it's basic and Apple still doesn't have this? WTF?
3. MMS...The world is having it.
4. 3.5G vs 3G...come on....Asia's laughing at you. No wander Japan luke warm on iPhone.
5. Cut & Paste...
6. SMS forwarding, please I need that.
7. Make iPhone better! Better than Storm, Better than Pre! Then you rock!

[eamgt]

Here's a feature developers have been wanting from the get-go:

How about finally implementing a
subscription mechanism? Some developers stay away because the
technology (aka: costs) of providing their service cannot support
unlimited usage for life, for a fixed one-time price - not an affordable
one, anyway.

If they could charge less up front, but continue generating revenue
over time from each user (to support the service) this would open the
floodgates for more complex and useful apps, while keeping them
affordable.

Advertising in the app is not a solution - the paltry, uncertain
returns don't justify the resources needed to create the app. It would
be much better if there was a mechanism so that users could continue to
pay for functionality they find useful.

Comments, anyone?