Re: Introducing ioscomponents.com
Hi Jason, Don't be too disappointed. This is exactly what The Lean Startup (a good read!) is all about and I am pretty sure quite a few of us have run into a situation like this ourselves. I was thinking about your remark on the radio buttons. I could be wrong, but I think it is the only control in your suite for which Foundation does not offer a widely known and used standard object. The closest thing is a UISegmentedControl, but that is still quite different from radio buttons, like Java has. So my guess is that you are getting a lot of feedback on it, because it is not regularly available and a custom control has to be created when a clients requests something like that. If that thought were true, than maybe focussing on controls that are currently absent in Foundation, but that could be useful might be a strategy to consider? A successful example would be the 'Facebook' panels, for which there is no out-of-the-box solution, but which are hugely popular. In short, my 5 cents would be to not focus on existing controls for which - to be honest - it will be very hard to come up with look and feel improvements AND for which coding practices are widely known, used and very accessible, but to focus on the white spots on the map instead.. Along the way, try to get feedback from your target audience as early as possible, maybe even at the drawing table, and let them help you find the best direction.. Best, Diederik Op Aug 28, 2013, om 12:04 AM heeft Jason Gibbs iosmaniac...@gmail.com het volgende geschreven: Allright - thanks everyone - I feel like going and hiding beneath a rock or something - We put months of blood and sweat into this thing and did not focus on the one thing that matters - polish and presentation. I am already going through the website and fixing the inconsistencies. However, as you guys said, we need a serious UX review of the whole thing. I am going to keep the website up as we do this, otherwise google will forget us. I hope to fix these mistakes and hopefully next time I ask for feedback, you guys wont be disappointed. Thanks again for your brutal, yet VERY constructive and HIGHLY appreciated feedback. This is just what we needed. On Tue, Aug 27, 2013 at 12:03 PM, David E Blanton aired...@tularosa.netwrote: On Aug 26, 2013, at 8:56 PM, Jason Gibbs iosmaniac...@gmail.com wrote: main DataGrid product … is ugly and reminds me of Windows MFC crap. -koko ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/diederik%40tenhorses.com This email sent to diede...@tenhorses.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Introducing ioscomponents.com
For reference, I’m not convinced that you needed them here, but instead, that you didn’t devote enough thought to how that UI should work on a touch screen. There’s no reason why your preferences couldn’t have used a column of UISwitches. Your export panel could have used a UISegmentedControl to select the export type, and a UIPicker to select the export format. That said, don’t get disheartened – a good, high quality data table is something that would be very useful on iOS – just try to polish it up more! Tom Davie On 27 Aug 2013, at 04:56, Jason Gibbs iosmaniac...@gmail.com wrote: Also one more thing - A few of you messaged me about this privately - I am quite surprised why everyone is looking at the checkbox/radio button exclusively - This is such a tiny part of the whole thing - we actually built it just because we needed it inside the our main DataGrid product (multi select filter has checkboxes) But we built everything as stand alone so they can be used indepentant of each other. our real product is the iOSDataGridView : http://www.ioscomponents.com/Home/IOSDataGrid Is our site not pushing that message very well? On Mon, Aug 26, 2013 at 10:42 PM, Jason Gibbs iosmaniac...@gmail.comwrote: All, thanks for your candid feedback - I realize we have some work to do, but I am glad to see the feedback. If there is anything else you think we can address, please free to bring it on - we can take it! The one thing I would like to add, we;re not a design company - we are a component vendor - all those components are meant to be skinnable and styleable. In fact we have a number of examples of themes and such. But you are right - we need a good iOS theme which is the default. On Mon, Aug 26, 2013 at 5:33 PM, Fritz Anderson fri...@manoverboard.orgwrote: [It happens I'm replying to Jonathan Hill, when my use of you refers to Jason Gibbs. A vagary of how I try to cut down quotes and recipient lists.] And to pile on, intercaps (camelCase) is a good idea in code (or underscores, I'm not picking a fight here), and common in cheesy trademarks (sorryApple), but when you address normal people, they aren't acceptable. Cheesier still if it isn't even a trademark. Nor are initial caps used in mid-sentence for words that are not proper names, including trademarks. It's a check box, not a CheckBox. Perhaps that's how you spell it in your API. Nobody cares how you spell it in your API, except when they're writing to your API. I'd like to see how this works out. Some very smart people have devoted a lot of thought to how mouse-and-keyboard UI would work on four-inch touch screens. — F On 26 Aug 2013, at 2:17 AM, Jonathan Hull jh...@gbis.com wrote: Good URL. The components don't really feel like they fit on iOS. Feels more like a XP UI than iOS. From your website, it seems like the components have lots of good features, but you should definitely hire a designer with iOS experience to help them feel at home on the platform... ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/iosmaniacdev%40gmail.com This email sent to iosmaniac...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Introducing ioscomponents.com
And do yourself a huge favor. Repeat to yourself every morning (and anytime you get frustrated), Developers are friends not food. I use that analogy intentionally, you are selling to the most critical market you will ever sell to. Not just other developers, which is bad enough, but Apple/iOS developers, who in addition to having the normal quirks of being developers, also add the additional quirks of being UX experts, who will pick apart a website over the use of tables. For everyone that offended there, keep in mind, I am calling myself out on this behavior too. When you are selling to other developers, you are always going to be under fire. There will always be things you should do their way. Sometimes the correct answer is 'no'. You have some great ideas, and I think will have some really good customers here, so don't let the bruises and lumps that will come along the way scare you off. Developing for other developers is hard, requires a thick skin, and is often quite thankless, but every now and again, you'll get that one sale that will make it all worth while. Dru On Aug 28, 2013, at 3:14 AM, Tom Davie tom.da...@gmail.com wrote: For reference, I’m not convinced that you needed them here, but instead, that you didn’t devote enough thought to how that UI should work on a touch screen. There’s no reason why your preferences couldn’t have used a column of UISwitches. Your export panel could have used a UISegmentedControl to select the export type, and a UIPicker to select the export format. That said, don’t get disheartened – a good, high quality data table is something that would be very useful on iOS – just try to polish it up more! Tom Davie On 27 Aug 2013, at 04:56, Jason Gibbs iosmaniac...@gmail.com wrote: Also one more thing - A few of you messaged me about this privately - I am quite surprised why everyone is looking at the checkbox/radio button exclusively - This is such a tiny part of the whole thing - we actually built it just because we needed it inside the our main DataGrid product (multi select filter has checkboxes) But we built everything as stand alone so they can be used indepentant of each other. our real product is the iOSDataGridView : http://www.ioscomponents.com/Home/IOSDataGrid Is our site not pushing that message very well? On Mon, Aug 26, 2013 at 10:42 PM, Jason Gibbs iosmaniac...@gmail.comwrote: All, thanks for your candid feedback - I realize we have some work to do, but I am glad to see the feedback. If there is anything else you think we can address, please free to bring it on - we can take it! The one thing I would like to add, we;re not a design company - we are a component vendor - all those components are meant to be skinnable and styleable. In fact we have a number of examples of themes and such. But you are right - we need a good iOS theme which is the default. On Mon, Aug 26, 2013 at 5:33 PM, Fritz Anderson fri...@manoverboard.orgwrote: [It happens I'm replying to Jonathan Hill, when my use of you refers to Jason Gibbs. A vagary of how I try to cut down quotes and recipient lists.] And to pile on, intercaps (camelCase) is a good idea in code (or underscores, I'm not picking a fight here), and common in cheesy trademarks (sorryApple), but when you address normal people, they aren't acceptable. Cheesier still if it isn't even a trademark. Nor are initial caps used in mid-sentence for words that are not proper names, including trademarks. It's a check box, not a CheckBox. Perhaps that's how you spell it in your API. Nobody cares how you spell it in your API, except when they're writing to your API. I'd like to see how this works out. Some very smart people have devoted a lot of thought to how mouse-and-keyboard UI would work on four-inch touch screens. — F On 26 Aug 2013, at 2:17 AM, Jonathan Hull jh...@gbis.com wrote: Good URL. The components don't really feel like they fit on iOS. Feels more like a XP UI than iOS. From your website, it seems like the components have lots of good features, but you should definitely hire a designer with iOS experience to help them feel at home on the platform... ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/iosmaniacdev%40gmail.com This email sent to iosmaniac...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription:
Re: Creating CGFont from PDF Tf operator
On Aug 27, 2013, at 14:46 , Graham Cox graham@bigpond.com wrote: Parsing a PDF, I need to handle the Tf (set font) operator. The font situation in PDF files is inordinately complicated, and reading the spec alone is not really leading to the light-bulb moment. Yes, there are many dark tunnels ahead... Basically, when I get the Tf operator, I need to end up with a CGFontRef I can use. I see a number of CGFontCreate… methods, none of which really fit anything I can see in the PDF spec itself. Perhaps CGFontCreateWithDataProvider is the magic bullet that just works behind the scenes to make sense of the almost innumerable PDF variations, but I can't see how I even get to the point where I could use it. Well, first you have a /Font. This should contain a reference to a /FontDescriptor. If the font is embedded in the file, then you have a /FontFile reference ( or /FontFile1, /FontFile2, /FontFile3), which then points to the PDF Stream containing the actual font. If there is no /FontFile, the font is not embedded and you need to figure out where to get the font to use (by name) or supply a fallback font, which has to match the encoding and metrics. 2013-08-27 12:08:10.304 PDFParser[43098:303] 'Subtype'=[Name]'Type0', 2013-08-27 12:08:10.304 PDFParser[43098:303] 'ToUnicode'=[Stream], I see this in the PDF spec; it's just one among many possible font types and formats, but I have no idea how to go from this to a CGFontRef. Ahh, a Type0 font. Those are fun! Cheers, Marcel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Creating CGFont from PDF Tf operator
On 28/08/2013, at 2:22 PM, Marcel Weiher marcel.wei...@gmail.com wrote: Well, first you have a /Font. This should contain a reference to a /FontDescriptor. If the font is embedded in the file, then you have a /FontFile reference ( or /FontFile1, /FontFile2, /FontFile3), which then points to the PDF Stream containing the actual font. Right. With some help from Antonio Nunes I've got this part working pretty well. If there is no /FontFile, the font is not embedded and you need to figure out where to get the font to use (by name) or supply a fallback font, which has to match the encoding and metrics. Any of the 14 standard fonts are easy enough as well. I have not yet attempted to create a font using the descriptor - in fact I'm not seeing any test cases in any of my PDF files that trigger this. It might be rare enough to leave alone for now. Ahh, a Type0 font. Those are fun! Well, I found that the /DescendantFonts here contains another font dictionary, and by passing it around (recursing) it deals with that just as for any of the other font types. It seems overall that I was right in that once you can get to a stream (font file) or a name, you're home and dry. CGFontCreateWithDataProvider obviously implements an awful lot of magic to deal with the really nasty stuff. One final follow-up question though - how do I go from the character strings referenced by Tj and friends to an array of glyphs? I see a great function in Core Text: CTFontGetGlyphsForCharacters, but I'm not sure whether I can simply use a CGFontRef here or whether using Core Text is the right way ahead. Since my ultimate aim isn't to render the PDF but to create a set of corresponding editable objects, it might be possible to assemble an NSAttributedString object and try and figure out what its bounding box would have ended up as had it been rendered. But doing that seems to need glyph measurement so I'm back to that. Going in circles... --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Experience with keyed archiving forward/backwards compatibility?
Hi folks, does anyone have practical experience with the forward/backward compatibility aspect of keyed archiving? That is define a file format using keyed archiving where backward and forward compatibility was both desirable and achieved? Thanks! Marcel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Experience with keyed archiving forward/backwards compatibility?
On Aug 28, 2013, at 8:53 AM, Marcel Weiher wrote: does anyone have practical experience with the forward/backward compatibility aspect of keyed archiving? That is define a file format using keyed archiving where backward and forward compatibility was both desirable and achieved? Do you mean forward/backward vis a vis application versions, or vis a vis OS versions/platforms? The former is fairly easy--I would have one element of stored data be a version identifier (either app version or file format version, however you prefer) so you app knows what to expect. The latter is fairly transparent as long as you plan for 32/64 bitness. Or do you mean something else? Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Experience with keyed archiving forward/backwards compatibility?
On Aug 28, 2013, at 4:53 PM, Marcel Weiher marcel.wei...@gmail.com wrote: does anyone have practical experience with the forward/backward compatibility aspect of keyed archiving? That is define a file format using keyed archiving where backward and forward compatibility was both desirable and achieved? Hi, I've written code that was supposed to be future-safe with NSKeyedArchiver, and I've written raw binary file access code that was future-safe, but the archiver code I wrote hasn't actually been tested in practice AFAIK (i.e. I never got to see incompatible changes being made). So while I can give you the practice of writing the code, I can't actually confirm that it's bug-free. FWIW, it's usually fairly simple: You can add new fields with new keys without any extra effort, the old version will just ignore them. The new version's -initWithCoder: just has to be written to cope with these fields not being there, and in that case create a default object/assign a default value. encodeWithCoder: doesn't have to know about this, since you've initialized all the ivars with defaults, it can just write the newest version. If that for some reason isn't an option, you can simply write out a version number for each object in encodeWithCoder (just an int with 1 is fine for starters). In initWithCoder:, if the int isn't there or is 0, you assume it's the old format, if it is 1, you know it's the new format and read the new keys. If you want to be really future-safe, you also define that e.g. the bottom 16 bits of the int are the minor revision, and the top 16 bits the newer one. If the minor version changes, that means you can read the file, you just won't get all the data (i.e. you increment the minor version when a change is a compatible change) while if the major version changes, you have a new file the old version of the app can't read. If you did your own binary writing code, you'd probably only need one version for the entire file. However, keyed archiving is encapsulated, per-object. You can have objects from various frameworks, each of which can change independently. This is a good, clean design, but means you need to save the version again for each class. There's no way around that either, as you don't really get a guarantee which object gets de-serialized first, so unless you write the version number to the file manually, then write the serialized object NSData after it, you have no way of reading the version number separately from the other objects to decide whether you can read the file. But you have a clean, compartmentalized OO design that automatically copes with individual objects being modified. Note that every class has a version (+setVersion: and +version) that you can use to store the current version number. You still have to write it out, but the neat thing is your comparison code can initially just compare and write out that current version for every class, and only when it actually changes, you hard-code a particular number different from 0. You can't really use keyed archivers if you want to be able to open and save the new file format with an old version. For one, you can't preserve the data that the old version doesn't know what to do with. You can't anticipate what to keep around (e.g. if you add an index, edit the file in the old version, but carry over the index unchanged, it'll be out of date, leading to wrong search results at best, crashes at worst). In this case I'd recommend you actually build a plist representation, and decide on some convention or separation that makes it easy to determine what can be kept around, and what needs to be deleted because the old version can't keep it in sync. Either a way of naming the keys, or a compatible/incompatible version number scheme like above, maybe again per object. Also, if you add a new class, the old application won't be able to de-serialize it from a keyed archiver. However, keyed archivers work if you only need to be able to open files created by the old version in a new version of the app. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
How to fix warning?
Hi, I am getting the following warning warning: format specifies type 'unsigned short' but the argument has type 'int' [-Wformat] on this statement: NSCharacterSet *stopCharacters = [NSCharacterSet characterSetWithCharactersInString:[NSString stringWithFormat:@ \t\n\r%C%C%C%C, 0x0085, 0x000C, 0x2028, 0x2029]]; What is the best way to fix this? Thanks a lot Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to fix warning?
On 28 Aug 2013, at 22:26, Dave d...@looktowindward.com wrote: Hi, I am getting the following warning warning: format specifies type 'unsigned short' but the argument has type 'int' [-Wformat] on this statement: NSCharacterSet *stopCharacters = [NSCharacterSet characterSetWithCharactersInString:[NSString stringWithFormat:@ \t\n\r%C%C%C%C, 0x0085, 0x000C, 0x2028, 0x2029]]; What is the best way to fix this? The type of integer literals in C is “int” by default. If you want them to be shorts (or unsigned, as is the bigger issue in this case), you must cast them either explicitly (by adding the casts in this expression), or implicitly, by assigning the littorals to a variable of the desired type. Tom Davie ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Introducing ioscomponents.com
Thanks again Dru,Tom, Diederik and everyone who chimed in with your valuable insights. I have made a list of action items from each of your feedback. Back to the kitchen to cook up something nice. Hopefully you guys wont be disappointed next time I come back here. Feel free to message me directly if you get some more ideas. I am very grateful to all of you. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to fix warning?
I think I understand what the problem is and the fix, but what does the following the opening quote signify? Boyd On Aug 28, 2013, at 1:30 PM, Tom Davie tom.da...@gmail.com wrote: On 28 Aug 2013, at 22:26, Dave d...@looktowindward.com wrote: Hi, I am getting the following warning warning: format specifies type 'unsigned short' but the argument has type 'int' [-Wformat] on this statement: NSCharacterSet *stopCharacters = [NSCharacterSet characterSetWithCharactersInString:[NSString stringWithFormat:@ \t\n\r%C%C%C%C, 0x0085, 0x000C, 0x2028, 0x2029]]; What is the best way to fix this? The type of integer literals in C is “int” by default. If you want them to be shorts (or unsigned, as is the bigger issue in this case), you must cast them either explicitly (by adding the casts in this expression), or implicitly, by assigning the littorals to a variable of the desired type. Tom Davie ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/bcollier%40mail.sdsu.edu This email sent to bcoll...@mail.sdsu.edu ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to fix warning?
On Aug 28, 2013, at 4:51 PM, Boyd Collier bcoll...@mail.sdsu.edu wrote: I think I understand what the problem is and the fix, but what does the following the opening quote signify? It’s just a literal ““ character in the string; nothing magic. (The code looks like it’s constructing an NSCharacterSet, and ““ must be one of the characters that should go in the set.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to fix warning?
Are those really always constant? Why not: NSCharacterSet *stopCharacters = [NSCharacterSet characterSetWithCharactersInString:@ \t\n\r\x85\x0C\u2028\u2029]; On Wed, Aug 28, 2013 at 3:26 PM, Dave d...@looktowindward.com wrote: Hi, I am getting the following warning warning: format specifies type 'unsigned short' but the argument has type 'int' [-Wformat] on this statement: NSCharacterSet *stopCharacters = [NSCharacterSet characterSetWithCharactersInString:[NSString stringWithFormat:@ \t\n\r%C%C%C%C, 0x0085, 0x000C, 0x2028, 0x2029]]; What is the best way to fix this? Thanks a lot Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/stephen.butler%40gmail.com This email sent to stephen.but...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
please help with this handler issue
Hi,
Not sure why I am struggling here but if someone could assist me that would be
great. In one part of my code I'm calling this:
[prefs setObject:[self userImage:[i valueForKey:@username] whichAccount:i]
forKey:@User Image];
Which will in turn call this:
- (UIImage *)userImage:(NSString *)name whichAccount:(id)account
{
__block UIImage *image;
__block UIImage *result;
// had to change this to new api: (6/2013)
NSURL *url =
[NSURL URLWithString:@http://api.twitter.com/1.1/users/show.json;];
NSDictionary *params = [NSDictionary dictionaryWithObject:name
forKey:@screen_name];
TWRequest *request2 = [[TWRequest alloc] initWithURL:url
parameters:params
requestMethod:TWRequestMethodGET];
[request2 setAccount:account];
[request2 performRequestWithHandler:^(NSData *responseData,
NSHTTPURLResponse *urlResponse, NSError *error) {
if (responseData) {
NSDictionary *user =
[NSJSONSerialization JSONObjectWithData:responseData
options:NSJSONReadingAllowFragments
error:NULL];
NSString *profileImageUrl = [[user
objectForKey:@profile_image_url]
stringByReplacingOccurrencesOfString:@_normal withString:@];
NSData *imageData =
[NSData dataWithContentsOfURL:
[NSURL URLWithString:profileImageUrl]];
image = [UIImage imageWithData:imageData];
UIGraphicsBeginImageContext(CGSizeMake(128 ,128));
[image drawInRect:CGRectMake(0, 0, 128, 128)];
result = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
}
}];
// new way:
while (result == nil)
{
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate
dateWithTimeIntervalSinceNow:0.01]];
}
UIImage *OrigImage = result;
UIImage *mask = [UIImage imageNamed:@image_m...@2x.png];
UIImage *maskedImage = [UIImage maskImage:OrigImage withMask:mask];
return maskedImage;
}
But this is an unreliable way to do this I know because I have problems. Can
someone please help me with the right way? Because I need for it to wait
before advancing or else it will cause problems in following code. Really
appreciate the time thanks!
rc
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
