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

iOS textcell setText deprecated... what do i use to set the text now then?

C

Chirone

macrumors 6502
Original poster
Mar 2, 2009
279
0
NZ
So i upgraded to xcode 3.1.4 and when i compiled it told me that i can't set the text of a UITableCell
it didn't tell me what to use instead so i went to the documents and it told me to use textLabel or detailTextLabel
so i check those out and WOOPS they are read only

so... how are you meant to set the text of a table cell now..?

Code: 
cell.textLabel.text
... so stupid of me
 
Just note that although the text property is deprecated, usage only produces a warning not an error, so it's still usable. Eventually it will disappear but you can safely use it for now, especially if you still need to support OS 2.x & 3.x users.
 
Chirone said:
So i upgraded to xcode 3.1.4 and when i compiled it told me that i can't set the text of a UITableCell
it didn't tell me what to use instead so i went to the documents and it told me to use textLabel or detailTextLabel
so i check those out and WOOPS they are read only
Click to expand...
They're UILabels so you set the text the same way you would with any other UILabel.
 
here's an example...


firstLabel = [[UILabel alloc] initWithWhatever...];
firstLabel.text = [NSString stringWithFormat:etc...
firstLabel.font = [UIFont boldSystemFontOfSize:11.0];
 
If the rest of your application is taking advantage of some features that are specific to the 3.0 OS, then go ahead and use the new scheme.

Otherwise, keep using the old scheme. I've seen estimates that a quarter of all iPhone OS devices are still running 2.x (mostly from iPod touch users who have to pay to upgrade) and you still want them to buy your application.
 
thanks guys, i actually figured it out after 3 minutes of the initial post (and edited the first post to say i did... although that wasn't really clear:rolleyes:)

BruinEcon you bring up a classic point about writing apps
we still have to produce for the lowest common demoninator if we want to sell anything....

kind of annoying but that's how the world works, right?
 
I think it depends. I sell both a Mac app and iPhone apps. One program, BeerAlchemy, runs on both platforms. On the mac I support everything from Tiger onwards as I feel that many homebrewers might be using an older mac in the brewery that they can't update (although it would certainly make my life a bit easier if I dropped Tiger support). On the iPhone though I only support 3.x - why? Well the app costs $14.99 on the iPhone ($29.99 on the Mac) and I figured that anyone willing to drop 15 bucks on an app is likely to have updated to 3.0 even if they have an iPod Touch and have to pay for the update.
 
Apple has made it a real pain to support OSes older than 3.0. The SL version of the tools doesn't support these OS versions in the Sim. There never was a supported method for running an app that supported 3.0 and 2.x on the Sim because they wouldn't compile without errors. There is no good way to reset the OS on an iPhone to an older version. And on and on.

It doesn't make much sense to start a new app today and to support the old OSes. If your app was started on the old OS it's still difficult to maintain that support in your app if you move to support the new OS.

I've refrained from updating to SL mostly because of this. I'm in a period of transition with the app and until Apple approves it, which is a running saga of over six weeks so far, I can't move to the new tools.
 
Thanks. I was thinking more along the lines of the "traditional" syntax, which I thought I'd tried but obviously didn't expand correctly:

[[cell textLabel] setText:mad:"whatever"]

The dot notation is arbitrarily and incompletely implemented, so I tend not to use it.
 
MobiusStrip said:
It doesn't work on methods, for one thing.
Click to expand...

Nonsense. What do you think textLabel and setText: are?

If you mean "It doesn't work with arbitrary methods", then the answer is "Duh, it's not intended for that."

If you thought dot notation is for arbitrary methods, you're mistaken. The dot notation is intended for use with properties. Both textLabel and text are documented as properties. That means dot notation works with them.
 
chown33 said:
If you mean "It doesn't work with arbitrary methods", then the answer is "Duh, it's not intended for that."

If you thought dot notation is for arbitrary methods, you're mistaken. The dot notation is intended for use with properties. Both textLabel and text are documented as properties. That means dot notation works with them.
Click to expand...

So anything is excused by saying "Oh, it's not intended for that"? No. You've basically just repeated my point. This implementation is half-assed. Either fully implement the dot notation for access to an object's members (both methods and public properties) or don't. The bracket notation was ridiculous from the outset, and this effort to eliminate it looked good at first but it turns out to simply add variety to the mess.
 
MobiusStrip said:
Either fully implement the dot notation for access to an object's members (both methods and public properties) or don't. The bracket notation was ridiculous from the outset, and this effort to eliminate it looked good at first but it turns out to simply add variety to the mess.
Click to expand...

Do you have a workable proposal for method invocation using dot notation? IMHO the bracket notation is the only way to achieve the flexibility of named parameters (since delimiters of some form are needed).
 
Good question, whose importance depends on whether you think named parameters provide enough benefit to outweigh the lengthy syntax.

So no, I don't have a suggested solution; but I don't really care about named parameters.

Now, if only ANSI would get off its ass and make #import a standard...
 
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